我工作的公司目前正在寻求从传统瀑布转向Scrum进行开发。我们正在慢慢采用我们可以采取的做法,而没有完全采取行动(在我们完全继续前进之前,我们还有很多东西需要学习!)。
在进行完整切换之前,我们现在想要实现的一件事是任务板。我们都觉得这是一个很好的工具,可以帮助开发,并通过“你在做什么?”帮助那些业务用户摆脱困境。和“怎么样?”问题和会议。
所以尽管如此,我一直想知道的一件事是,任务板上的任务可以改变吗?我知道你不想改变故事,但故事中的任务呢?如果新任务出现或旧任务不再有效怎么办?它们是否可以在sprint中间添加和/或删除(尽管我们并没有真正使用sprint,更像是开发周期较短)。
谢谢!
答案 0 :(得分:10)
我知道你不想改变故事,但故事中的任务呢?如果新任务出现或旧任务不再有效怎么办?它们可以在sprint中间添加和/或删除(...)。
是的,他们可以。在迭代期间,团队通常会收集知识并更好地了解必须完成的工作。因此,团队可能会发现任务不是真正相关的,给定的积压项目需要比预期更多的工作,初始估计是错误的。在这种情况下,你肯定想要更新你的Sprint Backlog和Burndown Chart以坚持现实并保持必须完成的工作:你真的想知道迭代是否仍然在轨道上,如果你可以再拿一件物品等等。
所以,是的,不要犹豫更新,删除,添加任务,您发现必须完成任务。而越早越好。
在我们的团队中,我们使用受Henrik Kniberg Scrum and XP from the Trenches启发的任务板,我们为“计划外项目”提供了一个特殊位置,如下图所示:
我们喜欢这种方法,因为它可以很容易地检测出未计划的项是否会导致迭代。我们还会在回顾期间“审查”这些任务,以了解我们如何改进计划会议,我们的估算,我们分解项目的方式等等。
答案 1 :(得分:3)
团队承诺用户故事,而不是 任务
当您遇到问题或有更好的实施想法时,让某些任务发生变化并不是一个问题。
事实上,在sprint计划会议中,100%“预测”准确的每项任务完成冲刺是非常罕见的。
答案 2 :(得分:2)
他们可以而且应该改变。董事会应至少每天更新一次。
但帕斯卡尔已经回答了这一点 - 我想提出另一个观点:从经验'试图采用'敏捷通过小改变将无法奏效。 Scrum是一个完整的框架 - 我的意思是Scrum(我什么都不说)可以放弃而不会对过程造成伤害并促进功能障碍或至少让功能障碍继续下去(wrote about it) 。慢慢走可能是一些公司/情况下的唯一出路,但它存在这样的风险,即挥之不去的功能障碍会在变化/改善之前将其推向最终并产生效益。答案 3 :(得分:1)
我已经喜欢Pascal和Andy的答案,所以不要重复。
一个有用的替代方案是启动看板。 Henrik Kniberg也有一本很好的“书”,可以在这里找到: http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html
它允许您组织您的工作,并将敏捷思维融入公司。正如Andy所说,Scrum是一个全押,如果不是你会发现'它不起作用'。
答案 4 :(得分:1)
为什么不呢?将空间留给团队以他们想要的方式完成工作。
故事是客户,产品负责人和团队之间的“合同”,因此最好不要在不让他们知道的情况下更改,添加,删除故事。但任务仅适用于团队。
团队应该能够以他们需要的方式跟踪工作量。
可疑的是团队承诺在sprint中完成的工作时间的变化,但是优秀的scrum master和经验丰富的团队能够自我组织。