我工作的公司目前正在寻求从传统的瀑布式转移到 Scrum 进行开发。我们正在慢慢采用我们可以采取的做法，而无需完全采取行动（在我们完全采取行动之前，我们还有很多东西要学习！）。
在进行完全切换之前，我们现在要实现的一件事是任务板。我们都觉得它是一个很好的工具，可以帮助开发，并帮助那些业务用户对“你在做什么？”不理不睬。 “怎么样？”问题和会议。
说了这么多，我一直想知道的一件事是任务板上的任务可以改变吗？我知道你不想改变故事，但是故事中的任务呢？如果出现了新任务，或者旧任务不再有效怎么办？是否可以在冲刺中期添加和/或删除它们（尽管我们并没有真正使用冲刺，更像是较短的开发周期）。
谢谢！
【问题讨论】：
我知道你不想改变故事，但是故事中的任务呢？如果出现了新任务，或者旧任务不再有效怎么办？是否可以在冲刺中期添加和/或删除它们（...）。
是的，他们可以。在迭代期间，团队通常会收集知识并更好地了解必须做什么或不做什么。结果，团队可能会发现某项任务并不真正相关，给定的待办事项项需要比预期更多的工作，初始估计是错误的。在这种情况下，您肯定想更新您的 Sprint Backlog 和 Burndown Chart 以贴近现实并保持必须完成的工作可见：您真的想知道迭代是否仍在轨道上，是否可以再做一项等。
所以，是的，不要犹豫，一旦发现必须完成任务，就立即更新、删除、添加任务。而且越早越好。
在我们的团队中，我们使用受 Henrik Kniberg 的 Scrum and XP from the Trenches 启发的任务板，并且我们为“计划外项目”提供了一个特殊位置，如下图所示：
我们喜欢这种方法，因为它可以轻松检测计划外项目是否正在扼杀迭代。我们还在回顾中“审查”这些任务，以了解我们如何改进我们的计划会议、我们的估计、我们分解项目的方式等。
【讨论】：
团队致力于用户故事，而不是 任务
当您面临问题或有更好的实施想法时，改变一些任务不是问题。
事实上，在 sprint 计划会议上完成每项任务 100%“预测”准确的 sprint 是非常罕见的。
【讨论】：
他们可以而且应该改变。董事会应至少每天更新一次。
但是 Pascal 已经回答了这个问题 - 我想再提一点：从经验中“尝试采用”敏捷通过小的改变是行不通的。 Scrum 是一个完整的框架——我的意思是在 Scrum 中几乎没有什么（我什么都不说）可以在不损害流程并促进功能障碍或至少允许功能障碍继续存在的情况下被丢弃 (wrote about it)。在某些公司/情况下，放慢脚步可能是唯一的出路，但存在这样的风险，即挥之不去的功能障碍会在变革/改进过程达到终点并产生收益之前破坏它。
【讨论】：
我已经喜欢 Pascal 和 Andy 的答案，所以不再重复。
一个有用的替代方法是启动看板。 Henrik Kniberg 也有一本关于它的好“书”，可以在这里找到： http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html
它可以让您组织您的工作，并为公司注入一些敏捷思维。正如 Andy 所说，Scrum 是一个全能的，否则你会发现“它行不通”。
【讨论】：
为什么不呢？将空间留给团队以他们喜欢的方式完成工作。
故事是客户、产品所有者和团队之间的“合同”，因此最好不要在不让他们知道的情况下更改、添加、删除故事。但任务只针对团队。
团队应该能够以他们需要的方式跟踪工作以使其可见。
有问题的是团队承诺在冲刺中完成的时间更改，但优秀的 scrum 管理员和经验丰富的团队能够自行组织。
【讨论】：