如果您的用户故事是“重构类 X”和“设计功能 Y”，那么您就走错了路。 在编写代码之前可能需要重构 X 或设计 Y，但这些可能是完成用户故事“创建新的登录小部件”所必需的任务。
Sounds like you're blurring the definition of user story and task. Simply:
User stories add value. They're created by a product owner.
Tasks are activities undertaken to create that value. They're created by the engineers.
You nailed key parts of the user story by saying they must have clear acceptance criteria, they're standalone, and they can be tested.
Architecture, design, refactoring, and utility classes development are tasks. They're what's done to complete a user story. It's up to each development shop to set different standards for these, but at our company, at least one other developer must have looked at the code (pair programming, code reading, code review).
If you have user stories which are "refactor class X" and "design feature Y", you're on the wrong track. It may be necessary to refactor X or design Y before you write code, but those could be tasks necessary to accomplish the user story "create new login widget".
We've run into similar issues with "behind-the-scenes" code. By "behind-the-scenes" I mean, has no apparent or testable business value.
In those cases, we've decided to define the developers of that portion of the code were the true "users". By creating sample applications and documentation that developers could use and test we had some "done" code.
Usually with scrum though, you would be looking for a piece of business functionality that used a piece of code to determine "done".
For technical tasks such as refactoring, you can check if the refactoring was really done, e.g. call X does no more have any f() method, or no more foobar() function.
There should be Trust towards the team and inside the team as well. Why do you want to review if the task is actually done ? did you encounter situations where someone claim a task were done ans it wasn't ?
For your second question, you should first really strive to break it into several smaller stories (backlog items). For instance, if you are re-architecturing the system, see if the new and the old architecture can coexist the time to do the portation of all your components from one to the other.
If this is really not possible, then this shall be done separately of the rest of the sprint backlog items, and not integrated before it is "done done". If the sprint ends before the completion of all the tasks of the item, then you have to estimate the remaining amount of work and replan it for the next iteration.
Here are twenty ways to split a story that could help having several smaller backlog items, with really is the recommended and safest way.
Third Question "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."
Each sprint creates something that can be released. Maybe it won't be, but it could be.
So, when you have major redesign, you have to eat the elephant one small piece at a time. First, look at the highest value -- most important -- biggest return to the users that you can do, get done, and release.
But -- you say -- there is no such small piece; each piece requires massive redesign before anything can be released.
I disagree. I think you can create a conceptual architecture -- what it will be when you're done -- but not implement the entire thing at once. Instead you create temporary interfaces, bridges, glue, connectors that will get one sprint done.
Then you modify the temporary interfaces, bridges and glue so you can finish the next sprint.
Yes, you've added some code. But, you've also created sprints that you can test and release. Sprints which are complete and any one can be a candidate release.
I would argue that if an internal activity has a benefit to the application (which all backlog items within scrum should have), done is the benefit is realized. For instance, "Design architecture" is too generic to identify the benefit of an activity. "Design architecture for user story A" identifies the scope of your activity. When you've created an architecture for story A, you're done with that task.
Refactoring should likewise be done in context of achieving a user story. "Refactor Customer class to enable multiple phone numbers to support Story B" is something that can be identified as done when the Customer class supports multiple phone numbers.
"Should I allocate special task for debug/fix/system integrations and etc?"
Not the same way you did with a waterfall methodology where nothing really worked.
Remember, you're building and testing incrementally. Each sprint is tested and debugged separately.
When you get to a release candidate, you might want to do some additional testing on that release. Testing leads to bug discovery which leads to backlog. Usually this is high-priority backlog that needs to be fixed before the release.
Sometimes integration testing reveals bugs that become low-priority backlog that doesn't need to be fixed before the next release.
How big is that release test? Not very. You've already tested each sprint... There shouldn't be too many surprises.
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.
发布评论
评论（7）
听起来您模糊了用户故事和任务的定义。 简单地说：
用户故事可以增加价值。 他们是
由产品所有者创建。
任务是为创建该任务而采取的活动
价值。 它们是由
工程师。
您通过说用户故事必须有明确的验收标准、它们是独立的并且可以进行测试来确定用户故事的关键部分。
架构、设计、重构和实用程序类开发是任务。 它们是为了完成用户故事而所做的事情。 每个开发车间都可以为此制定不同的标准，但在我们公司，至少有一名其他开发人员必须查看过代码（结对编程、代码阅读、代码审查）。
如果您的用户故事是“重构类 X”和“设计功能 Y”，那么您就走错了路。 在编写代码之前可能需要重构 X 或设计 Y，但这些可能是完成用户故事“创建新的登录小部件”所必需的任务。
Sounds like you're blurring the definition of user story and task. Simply:
User stories add value. They're
created by a product owner.
Tasks are activities undertaken to create that
value. They're created by the
engineers.
You nailed key parts of the user story by saying they must have clear acceptance criteria, they're standalone, and they can be tested.
Architecture, design, refactoring, and utility classes development are tasks. They're what's done to complete a user story. It's up to each development shop to set different standards for these, but at our company, at least one other developer must have looked at the code (pair programming, code reading, code review).
If you have user stories which are "refactor class X" and "design feature Y", you're on the wrong track. It may be necessary to refactor X or design Y before you write code, but those could be tasks necessary to accomplish the user story "create new login widget".
我们在“幕后”代码中遇到了类似的问题。 我所说的“幕后”是指没有明显或可测试的商业价值。
在这些情况下，我们决定将该部分代码的开发人员定义为真正的“用户”。 通过创建开发人员可以使用和测试的示例应用程序和文档，我们获得了一些“完成”的代码。
通常，对于 Scrum，您会寻找使用一段代码来确定“完成”的业务功能。
We've run into similar issues with "behind-the-scenes" code. By "behind-the-scenes" I mean, has no apparent or testable business value.
In those cases, we've decided to define the developers of that portion of the code were the true "users". By creating sample applications and documentation that developers could use and test we had some "done" code.
Usually with scrum though, you would be looking for a piece of business functionality that used a piece of code to determine "done".
对于重构等技术任务，您可以检查重构是否真正完成，例如call X不再有任何f()方法，或者不再有foobar()函数。
对团队和团队内部也应该有信任。 为什么要审查任务是否真正完成？ 您是否遇到过有人声称任务已完成但实际上并未完成的情况？
对于第二个问题，您应该首先努力将其分成几个较小的故事（积压项目）。 例如，如果您正在重新构建系统，请查看新旧架构是否可以共存，然后将所有组件从一个组件移植到另一个组件。
如果这确实不可能，那么这应与其余冲刺积压项目分开完成，并且在“完成”之前不集成。 如果冲刺在项目的所有任务完成之前结束，那么您必须估计剩余工作量并为下一次迭代重新计划。
这里有二十种分割故事的方法，可以帮助拥有几个较小的积压项目，确实是推荐且最安全的方法。
For technical tasks such as refactoring, you can check if the refactoring was really done, e.g. call X does no more have any f() method, or no more foobar() function.
There should be Trust towards the team and inside the team as well. Why do you want to review if the task is actually done ? did you encounter situations where someone claim a task were done ans it wasn't ?
For your second question, you should first really strive to break it into several smaller stories (backlog items). For instance, if you are re-architecturing the system, see if the new and the old architecture can coexist the time to do the portation of all your components from one to the other.
If this is really not possible, then this shall be done separately of the rest of the sprint backlog items, and not integrated before it is "done done". If the sprint ends before the completion of all the tasks of the item, then you have to estimate the remaining amount of work and replan it for the next iteration.
Here are twenty ways to split a story that could help having several smaller backlog items, with really is the recommended and safest way.
第三个问题“一些大模块重新设计（用新的架构替换新的过时架构）。当然，这项任务分为几十个小任务。但是，我知道最后我们将进行相当长的调试/修复会话。”
每个冲刺都会创建一些可以发布的东西。 也许不会，但也有可能。
所以，当你进行重大重新设计时，你必须一次只吃一小块大象。 首先，看看你可以做、完成和发布的最高价值——最重要的——对用户的最大回报。
但是——你说——不存在这么小的一块； 每件作品在发布之前都需要进行大规模的重新设计。
我不同意。 我认为你可以创建一个概念架构——完成后会是什么样子——但不能立即实现整个事情。 相反，您可以创建临时接口、桥梁、胶水、连接器来完成一次冲刺。
然后修改临时接口、桥梁和胶水，以便完成下一个冲刺。
是的，您已经添加了一些代码。 但是，您还创建了可以测试和发布的冲刺。 已完成的 Sprint，任何一个都可以成为候选版本。
Third Question "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."
Each sprint creates something that can be released. Maybe it won't be, but it could be.
So, when you have major redesign, you have to eat the elephant one small piece at a time. First, look at the highest value -- most important -- biggest return to the users that you can do, get done, and release.
But -- you say -- there is no such small piece; each piece requires massive redesign before anything can be released.
I disagree. I think you can create a conceptual architecture -- what it will be when you're done -- but not implement the entire thing at once. Instead you create temporary interfaces, bridges, glue, connectors that will get one sprint done.
Then you modify the temporary interfaces, bridges and glue so you can finish the next sprint.
Yes, you've added some code. But, you've also created sprints that you can test and release. Sprints which are complete and any one can be a candidate release.
我认为，如果内部活动对应用程序有好处（scrum 中的所有积压项目都应该有），那么完成就是实现好处。 例如，“设计架构”太笼统，无法识别活动的好处。 “为用户故事 A 设计架构”确定了您的活动范围。 当您为故事 A 创建架构后，您就完成了该任务。
重构同样应该在实现用户故事的背景下进行。 当 Customer 类支持多个电话号码时，可以将“重构 Customer 类以启用多个电话号码来支持故事 B”视为已完成的操作。
I would argue that if an internal activity has a benefit to the application (which all backlog items within scrum should have), done is the benefit is realized. For instance, "Design architecture" is too generic to identify the benefit of an activity. "Design architecture for user story A" identifies the scope of your activity. When you've created an architecture for story A, you're done with that task.
Refactoring should likewise be done in context of achieving a user story. "Refactor Customer class to enable multiple phone numbers to support Story B" is something that can be identified as done when the Customer class supports multiple phone numbers.
“我应该为调试/修复/系统集成等分配特殊任务吗？”
与瀑布方法不同，瀑布方法没有任何效果。
请记住，您正在逐步构建和测试。 每个冲刺都是单独测试和调试的。
当您获得候选版本时，您可能需要对该版本进行一些额外的测试。 测试会导致错误发现，从而导致积压。 通常这是高优先级的待办事项，需要在发布之前修复。
有时，集成测试会发现一些错误，这些错误会成为低优先级的积压工作，在下一个版本之前不需要修复。
发布测试有多大？ 不是特别的。 您已经测试了每个冲刺...不应该有太多惊喜。
"Should I allocate special task for debug/fix/system integrations and etc?"
Not the same way you did with a waterfall methodology where nothing really worked.
Remember, you're building and testing incrementally. Each sprint is tested and debugged separately.
When you get to a release candidate, you might want to do some additional testing on that release. Testing leads to bug discovery which leads to backlog. Usually this is high-priority backlog that needs to be fixed before the release.
Sometimes integration testing reveals bugs that become low-priority backlog that doesn't need to be fixed before the next release.
How big is that release test? Not very. You've already tested each sprint... There shouldn't be too many surprises.
对于第一部分“架构设计 - 重构 - 一些实用程序类开发”，这些永远不会“完成”，因为你是边走边做的。 分成碎片。
您想要做足够的架构来启动第一个版本。 然后，对于下一个版本，需要更多的架构。
重构是您查找实用程序类的方式（您并不是要创建实用程序类——而是在重构过程中发现它们）。
重构是在发布之前根据需要分段进行的事情。 或者作为一个大功能的一部分。 或者当您在编写测试时遇到困难时。 或者当您难以通过测试并需要“调试”时。
在项目的生命周期中，这些事情的一小部分会被一遍又一遍地完成。 它们并不是真正的“发布候选者”，因此它们只是在发布过程中完成的冲刺（或冲刺的一部分）。
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.