讨论：在Scrum环境中使用TDD

Question

当我工作TDD时，我倾向于从大局开始并创建应该成功的测试，以便完成整个任务 - 然后在我挖掘时启动一些支持类/方法/测试在。

如果我的作业已经详细计划，我会打开一个任务，为了解决它，打开另一个，然后打开另一个。只有当整体测试成功时才能关闭原始任务，这意味着在任何给定时间，我都会有许多打开的任务。

我发现这种方法与scrum方法有些冲突，理想情况下，我应该能够在一天的工作中完成并关闭任务 - 并且一次不会打开多个任务。

我正在寻找关于你如何在你的项目中管理这个问题的意见 - 对文章的引用也非常受欢迎，我相信这已经在某个地方进行了彻底的辩论......

'答案刻度'将被授予最佳评论/参考。

感谢您提供任何意见，

丹麦安德斯

Answer 1

听起来好像你的任务可能是横向切片的 - 可能是像“创建数据库表”或“写控制器”这样的技术界限 - 而你的开发是垂直切片的。

我讨厌不得不将故事分成任务（这对新手团队很有用，让项目经理保持高兴，没有别的）但是如果我被迫这样做，我会按照场景将它们分开。通过一个故事走第一条“快乐的道路”。把它变成第一个任务。找到边缘情况。他们每个人都成了另一项任务。例如，如果我被要求编写ATM软件并且故事标题是“让人们拿出现金”，我的任务可能是：

• 允许用户取出现金
• 如果用户没有足够的
，请阻止他们取出现金
• 透支
• 耗尽$ 10
• 根本没有钱
• 用户达到每日现金限额
• 检查它是否适用于Fred的“PIN验证”故事。

这有额外的好处，在任何时候我都可以展示一些东西并得到反馈，让我尽早带来测试人员，帮助我解决问题，如果我错过了什么。

Answer 2

我认为你可能以错误的方式解决这个问题。这听起来像你对工作量的原始估计是偏离的，因为如果它们不是，为什么不只是使用原始任务？这仍然是你想要完成的。如果您发现工作量非常错误或者您错误地分析了问题，那么您应该，IMO，不仅仅是在sprint中添加越来越多的任务，因为它没有帮助。

因此，不是仅创建一个任务，而是尝试创建所有任务并仅打开首先需要启动的任务。因此，不要以自上而下的方式考虑任务，而应将其视为并行任务。

但是，我可能不太了解你的情况。当然，你经常会发现在做事的过程中你没有想到的东西，但是如果你的任务太大而你经常超过你的估计，那么我唯一的建议就是更好地规划你的工作。仅仅因为积压工作有一个大任务并不意味着你不能把它拆分成春天的日志。