在 Gartner 最近的一篇博文中,Thomas Murphy 表达了对敏捷项目变成“死亡行军( Death March )”循环的担忧。
他在文中写道,在一个历时 12 个月的瀑布项目中,团队可能会在前 10 个月过着“正常”生活,然后,迫于不切实际的交付期限和范围所带来的压力,在接下来的 2 个月里过着地狱般的生活。
相比而言,在每两周一次迭代的敏捷项目中:
每年可能会有 26 次冲刺。如果冲刺的 10 个工作日中有 2 天是死亡行军,那么每年有 52 天死亡行军,而在“按年计算的”项目中有 40 天。在死亡行军的天数上,敏捷多出 25%。
他继续谈论可持续的开发速度这一敏捷原则的重要性,并在文中写道:
问题在于什么是可持续。我听说了一些故事,听上去并非只有冲刺的最后 2 天是死亡行军。每天都感觉是死亡行军。这不是一个新话题了,我在本文的后面列出了一些关于该话题的博文链接。组织,确切地说是团队,需要确定对于团队而言什么才是可持续,需要理解 WIP 限制。高速公路 100% 填充就变成了停车场。别让到敏捷的转换变成到不间断运行的转换。全球业务和移动设备只会使它成为一场更具挑战性的战争。
他引用了多篇讨论可持续开发速度和实际工作条件必要性的博文,其中有一篇 Big Visible 上的博文,讨论解决如何实现可持续:
在阅读关于敏捷的著作或者与敏捷参与者交谈的时候,我们经常听到“可持续的开发速度”这一术语。任何工作过度的人都可能会想到两点:一是,可持续的开发速度听上去很好,但不可能实现。在讨论这一术语的时候,很多人都因为相信可以在这一约束下完成需要做的工作而陷入挣扎。二是,有些人认为,软件创建与可持续的开发速度互不相容。
他远不是谈论这些事情的唯一评论员。在上个月, Ben Linders 在 InfoQ 上发表了一篇新闻,探讨如何实现可持续的开发速度。
评论