敏捷采纳中的死亡计划

当企业采用敏捷，并开始配置自组织团队的时候，管理层会感到对事情失去控制。流程、评审委员会和咨询机构，在转型到敏捷方式的时候这些都成了多余的东西，但他们却不自知，Marcel Heijmans 如此评论道。试图通过增加额外的计划来重新获得控制权，这只会让事情更糟糕，造成“死亡计划（（Death by planning））”的结果。

Marcel Heijmans 是一名在 Mnemonics 名义下工作的独立软件工程师，他将在敏捷与软件架构研讨会2014 上发表名为死亡计划的演讲。这是在荷兰召开的为期一天的会议，软件架构师、开发工程师、需求工程师和信息分析师在一起分享软件架构知识。

InfoQ 采访了 Marcel，就敏捷项目计划、规模化敏捷、以及对于那些想做更小、更频繁交付的企业而言，在敏捷采纳和实践当中架构的作用等问题进行了讨论。

InfoQ: 你演讲的标题是《死亡计划》。你能阐述一下这是什么意思吗？

Marcel: “死亡计划”是一个项目管理反模式，描述了软件项目中由于过度计划导致的问题。对于确定性的、线性扩展的过程，详细地计划是很恰当的。当过程表现出更多的随机行为，详细计划的复杂度会大幅增加。许多软件项目，其本质上就包含了未知的、无序的活动。

InfoQ: 计划在敏捷和瀑布式项目中有什么不同？

Marcel: “项目”受限于固定期限、固定成本、以及 / 或固定范围。瀑布式方法提供了一种结构来规划和控制这些参数。我认为“敏捷式项目”是一种自相矛盾的说法。如果放宽“计划”的定义，你可以认为对产品待办事项列表的排序是一种计划。当然，Scrum 里的 Sprint 是典型的计划行为，Sprint 受限于时间和范围。因为一个 Sprint 的周期足够小，详细的计划是有用的。

InfoQ: 你认为软件开发是系统工程（Engineering）。这意味着什么？

Marcel: 工程（Engineering）是（工作中）用于解决问题的部分，先于制造环节，并且难以计划。在很多领域里，有大量工作都需要很精确地执行，但只执行一次，工程只是这些工作中的一小部分。但工程贯穿于软件开发始终，因此对软件开发过程做详细的计划是不太适合的。

InfoQ: 对于企业采纳敏捷，你的观点是怎样的？你能使敏捷开发规模化吗，如果能的话你是怎么做的？

Marcel: 企业接纳敏捷，因为它能带来成功。敏捷（Scrum）中的很多方面都很容易被企业所接受。而那些不容易被接受的、基本的方面，则常常被忽视掉。“用户反馈”部分（以及对应的产品负责人角色）对于大型组织而言确实很难接受。讽刺的是，敏捷广受好评的成功，主要来源于这一部分。此外，敏捷中那些容易被接纳的部分是可以被规模化的，例如创建团队、迭代式工作、每日站会、Sprint 回顾，而且有许多框架可以帮助做到。“用户反馈”决定了产品是否准备就绪；规模化“用户反馈”循环的难度，与企业在敏捷上的文化共识度成反比。

InfoQ: 企业采纳敏捷的过程中，架构在计划里扮演了什么角色？

Marcel: 软件开发的工程性质、加上大型组织里固有的复杂性、以及企业无法始终如一地实施敏捷，导致了不可预测性。当管理层感觉失去控制的时候，会祭出“标准”计划管理工具，以期重新获得控制权。但是详细的计划对于工程活动是不合适的；架构师的作用是为手头的问题提供技术解决方案。因此，对于一些问题而言，架构设计不是最好的解决方案。

InfoQ: 从你的经验看来，对于想要更小、更频繁交付的企业，有什么实践可以推荐一下吗？

Marcel: 许多企业即便采纳了敏捷，也会保留发布频率很低的发布时间表。这种方法为管理层的过度计划提供了完美的温床。系统环境的复杂性、系统间相互依赖是导致发布问题的主要原因。频繁发布是需要通过技术手段解决的。通过“计划”在十多个互相依赖的系统上同步发布时间表，这是一种时间上的巨大浪费。

运用类似 Fowler 描述的“功能开关（Feature Toggle）”机制，可以解耦提供者和消费者之间的发布依赖性。这样用一个很小的额外努力（构建“功能开关”），就能减少发布的复杂性。

另一种实践是做到自动化部署。我发现用工具将发布变得更可靠、更自动化，这将提高发布频率。尽管系统间仍然存在依赖关系，较高的发布频率依然可以降低对发布时间表同步的压力。

查看英文原文： Death by Planning in Agile Adoption

感谢曹知渊对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。