有关Scrum的两个问题

本文介绍了有关Scrum的两个问题的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

关于Scrum，我有两个相关的问题。

I have two related question regarding Scrum.

我们的公司正在尝试实施它，并确保我们跳过了难题。

Our company is trying to implement it and sure we are jumping over hoops.

两个问题都关于完成意味着完成！

Both question are about "done means Done!"

1）对于已经拥有$ b $的任务定义完成确实很容易b-明确的测试接受标准-完全独立的-最后由测试人员测试

1) It's really easy to define "Done" for tasks which are/have - clear test acceptance criterias - completely standalone - tested at the end by testers

诸如$ b $这样的任务应该做什么b-建筑设计-重构-一些实用程序类开发

What should be done with tasks like: - architecture design - refactoring - some utility classes development

它的主要问题在于，它几乎完全是内部实体并且无法从外部进行检查/测试。

The main issue with it, that it's almost completely internal entity and there is no way to check/test it from outside.

例如，功能实现是二进制的-完成了（通过了所有测试用例）还是没有完成（不要通过一些测试用例）。

As example feature implementation is kind of binary - it's done (and passes all test cases) or it's not done (don't pass some test cases).

我想到的最好的事情是请另一个开发人员审查该任务。但是，无论如何，都无法提供明确的方法来确定是否已完全完成。

The best thing which comes to my head is to ask another developer to review that task. However, it's any way doesn't provide a clear way to determine is it completely done or not.

因此，问题是，您如何定义这样的内部任务完成了吗？

So, the question is how do you define "Done" for such internal tasks?

2）调试/错误修复任务

2) Debug/bugfix task

我知道敏捷方法不会建议做大任务。至少如果任务很大，应该将其划分为较小的任务。

I know that agile methodology doesn't recommend to have big tasks. At least if task is big, it should be divided on smaller tasks.

让我们说我们有一个很大的问题-一些大的模块重新设计（到用新的替换过时的体系结构）。当然，这个任务被划分为数十个小任务。但是，我知道最后我们将有相当长的调试/修复会话。

Let say we have some quite large problem - some big module redesign (to replace new outdate architecture with new one). Sure, this task is divided on dozens of small tasks. However, I know that at the end we will have quite long session of debug/fix.

我知道通常是瀑布模型的问题。但是，我认为很难摆脱（特别是对于很大的更改）。

I know that's usually the problem of waterfall model. However, I think it's hard to get rid of it (especially for quite big changes).

我应该为调试/修复/系统集成分配特殊任务吗？ 等？

Should I allocate special task for debug/fix/system integrations and etc?

在这种情况下，与相比，通常我的任务非常艰巨，这很难将其划分为较小的任务。

In the case, if I do so, usually this task is just huge comparing to everything else and it's kind of hard to divide it on smaller tasks.

我不喜欢这种方式，因为这项庞大的整体任务。

I don't like this way, because of this huge monolith task.

还有另一种方式。我可以创建较小的任务（与错误相关），将它们放入积压中，在活动结束时确定优先级并将其添加到迭代中，这时我将知道什么是错误。

There is another way. I can create smaller tasks (associated with bugs), put them in backlog, prioritize and add them to iterations at the end of activity, when I will know what are the bugs.

我不喜欢这种方式，因为在这种情况下，整个估算将变成的假货。我们估算任务，随时将其标记为完成。我们将用新的估算值打开新的bug任务。因此，我们最终将得到实际时间=估计时间，这绝对不好。

I don't like this way, because in such case the whole estimation will became fake. We estimate the task, mark it ask complete at any time. And we will open the new tasks for bugs with new estimates. So, we will end up with actual time = estimate time, which is definitely not good.

您如何解决此问题？

致谢， Victor

Regards, Victor

推荐答案

第一部分体系结构设计-重构-某些实用程序类的开发，因为您可以随时进行操作，所以它们永远都不会完成。

For the first part " architecture design - refactoring - some utility classes development" These are never "done" because you do them as you go. In pieces.

您想要做的只是足够的架构以使第一个发行版发行。然后，在下一个发行版中，将使用一些体系结构。

You want to do just enough architecture to get the first release going. Then, for the next release, a little more architecture.

重构是找到实用程序类的方式（您并未着手创建实用程序类，而是发现它们重构期间）。

Refactoring is how you find utility classes (you don't set out to create utility classes -- you discover them during refactoring).

在发布之前，您需要根据需要进行重构。或作为重要功能的一部分。或者在编写测试时遇到困难。或者，当您无法通过测试并需要调试时。

Refactoring is something you do in pieces, as needed, prior to a release. Or as part of a big piece of functionality. Or when you have trouble writing a test. Or when you have trouble getting a test to pass and need to "debug".

在项目的整个生命周期中，一遍又一遍地完成这些小工作。它们并不是真正的发布候选者，因此它们只是在发布过程中完成的冲刺（或冲刺的一部分）。

Small pieces of these things are done over and over again through the life of the project. They aren't really "release candidates" so they're just sprints (or parts of sprints) that gets done in the process of getting to a release.