LBu*_*kin 9 agile project-management agile-processes
我正在研究一个正在探索采用敏捷开发实践的可能性的团队.
我们遇到的一个问题是决定何时完成迭代(sprint).
假设我们已经定义了我们的功能积压,并为他们制作了故事点估计,我们已经确定第一个30天的冲刺将包括功能A,B,D和F.如果你在你身边,你应该怎么办？到达冲刺结束时你已经完成了A,D和F - 但是B只完成了80%.你应该:
按时完成冲刺但排除功能B(将剩余的工作推迟到未来的冲刺)
将sprint扩展到完成功能B所需的时间,但不启动下一个sprint.
将sprint扩展到完成功能B所需的时间并开始处理下一个sprint.
整个sprint失败,捆绑所有工作成为未来版本的一部分.
我在选项1中看到的问题是团队没有提供它所承诺的内容.在某些情况下,您可能无法在不使整个版本无用(或至少实质上不那么有价值)的情况下排除功能B. 如果没有特征B,可能难以指导下一个冲刺的方向.
选项2的问题在于团队中的某些成员可能在很长一段时间内闲置 - 这会影响整体生产力.您可以添加更多单元测试或抛光功能,但不会增加比例值.在政治上也难以向管理层解释为什么你的大部分团队都处于空闲状态.
选项3似乎违背了敏捷的精神 - 你不会让前一个sprint的结果引导下一次开发迭代,从而使下一个sprint面临风险.
选项4似乎很严重,并且在选项1和3中存在大多数相同的问题.首先,您完全错过了承诺.其次,将更多功能捆绑到后续版本中会使得更难以与客户进行测试和验证 - 并且它再次排除了根据之前版本的反馈来指导未来迭代的能力.
Ste*_*ont 15
选项1当然.你的速度为下一次迭代是要少一些,因为它是基于昨天的天气,所以下一次迭代,你有被完整的一个更好的机会.
在Scrum你是时间拳击.而且您只提供有效的功能.
在sprint计划中,您已经估计了可以提供的内容.客户必须接受估算中的一定程度的不确定性,或准备在团队中拥有太多资源.
如果再次错过下一次迭代,请切换到较短的迭代长度,并确保单个要素的大小较小.