我想实现Scrum,但我不能决定Sprint的长度.Ken Schwaber似乎将这30天与事实相关......但我无法想象在没有改变方向或重新优先权的情况下等待30天.
我们的项目通常只使用瀑布式方法持续1-3个月,并且转移到Scrum可能意味着更少的微调机会.
我在考虑一周的短跑,但这看起来像Scrum Micro Management.
有2周的冲刺可能是理想的,但我想知道其他人是否能够成功实施.有什么缺点？管理具有较短冲刺的团队是否更多的工作/更少的工作/相同的工作？
顺便说一句......对我来说,3周冲刺似乎很奇怪,谁进行了为期3周的冲刺？为什么不把它做4周.;)
我参加过一周,两周和四周短跑的团队.这真的取决于您的组织.我更喜欢1或2周的短跑.我正在运行的现有团队正在进行为期4周的冲刺,因为我们正在协调12种不同产品的工作.我希望很快将它们转移到2周的迭代.
定义长度的关键是"完成,完成".对于一些团队来说,这意味着在生产中.对于其他人而言,它可能意味着业务部门使用内部版本来满足他们的需求.我首先定义完成,完成,然后看看如何构建你的sprint.理想情况下,所有故事都在冲刺结束时完成 - 而且您不仅仅是在做Scrummerfall.
京公网安备 11010802040832号 | 京ICP备19059560号-6 