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