《SAFe 4.0参考指南：精益软件与系统工程的规模化敏捷框架》一 2.5 原则#5——基于对可工作系统的客观评价设立里程碑...

本节书摘来自华章出版社《SAFe 4.0参考指南：精益软件与系统工程的规模化敏捷框架》一书中的第2，第2.5节 作者［美］迪恩·莱芬（DeanLeffingwell），更多章节内容可以访问云栖社区“华章计算机”公众号查看。

2.5　原则#5——基于对可工作系统的客观评价设立里程碑

实际上，按时进行“阶段–门限”交付与项目的成功并无关系。但有些数据表明，反过来却是相关的，即成功的项目都是按时进行阶段交付的。

——Dantar P. Oosterwal，《精益机器》

“阶段–门限”里程碑的问题

现在，对于大系统的开发需要进行大量投资，可以达到数百万、上千万，甚者过亿美元的投入。系统构建者和客户有义务共同确保对于新的解决方案的投资可以提供必要的经济收益。否则，就没有理由进行相应的投资。

显然，利益相关者必须进行协作，帮助确保预期的经济效益贯穿在整个开发过程中，而不仅仅是“一厢情愿”地认为在最终可以达到美好的结果。为了应对这一挑战，工业界引入了“阶段–门限”（瀑布式）的开发流程，这种流程会通过对一系列确定的里程碑进行度量和控制。而且这些里程碑也不是任意设置的，它们遵循一定的逻辑性和一系列的流程（发现、需求、设计、实现、测试和交付）。当然，这种里程碑的设置方法并没有获得好的收效，如图2.5-1所示。

导致这个问题的根本原因是没有认识到在“阶段–门限”显示的真实进展情况和消除风险的过程中，犯了四个关键的错误：

1.将需求集中起来，同时进行职能筒仓式的设计决策，导致了在后续的解决方案构建过程中缺乏完整性。

2.过早的设计决策和“虚假的可行性”（参考资料[1]）：一个早期的选择是在当时做出的最佳选择，随后开发流程就假设一切按照计划进行，直到最后才发现最初的选择是不切实际的（原则#3）。

3.假设存在一个确定的解决方案，而且只进行一次尝试就可以构建成功。这样就忽视了流程中固有的变异性，并且没有提供有效的处理方法。改变将是迟早的事。变异性迟早是要表现出来的。

4.在前期就进行决策，创建了大批量的需求、代码和测试，形成了很长的队列。这也导致了大量的工作交接和延迟的反馈（原则#6）。

基于客观事实设立里程碑

显然，“阶段–门限”模型并没有像预期的那样降低风险，所以就需要一种不同的方法。原则#4（通过快速集成学习环，进行增量式构建）提供了解决这一困境的一些要素。

在整个开发过程中，系统进行增量式的构建，每一次构建都是一个集成点，在集成点上可以演示一些已经实现的内容，以验证当前解决方案的可行性。与“阶段–门限”开发方法不同，基于客观事件所设立的每一个里程碑都包含研发的所有步骤（需求、设计、开发、测试），从而达到增量式的价值交付，如图2.5-2所示。此外，这种里程碑会基于节奏进行（原则#7），一个固定的节奏可以形成一种纪律，确保定期提供可用性和评估，同时能提前确定时间边界，也可以用来去除那些不太理想的选择。

在关键的集成点上要对哪些要素进行有效的度量呢？这取决于所要构建系统的类型，但是利益相关者可以在整个解决方案开发周期内，频繁地对系统进行度量、评价和评估。这样可以提供财务、技术和符合目标的组织治理，从而确保持续的投资可以产生与之相匹配的回报。

参考资料

[1]　Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.