《SAFe 4.0参考指南:精益软件与系统工程的规模化敏捷框架》一2.3 原则#3——接受变异性,保留可选项-阿里云开发者社区

开发者社区> 华章出版社> 正文

《SAFe 4.0参考指南:精益软件与系统工程的规模化敏捷框架》一2.3 原则#3——接受变异性,保留可选项

简介:

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


2.3 原则#3——接受变异性,保留可选项

创造系统级设计和子系统概念的多种可选方案;而不是过早地选择一个胜出方案,然后消除与之不同的其他可选项。只有那些存活下来的设计选项,才是最强大的可选方案。

——艾伦 C.沃德,《精益产品和流程开发》

系统构建者们都会倾向于减少变异性。表面上看起来,你认为自己知道的越多并且已经做出相应的决策,你就会走得更远。但事实往往并非如此。虽然变异性会导致糟糕的结果,但有些时候也不尽然。变异性的自身无所谓好与坏。相反,是由于时间的经济效应和变异性的类型决定了最终的结果。如果过早地专注于消除变异性,可能会导致企业萌生厌恶风险的文化,这样员工也就不能通过试错和学习来获取经验。

精益系统构建者们认识到,在项目的早期除了一些基本的系统目标之外,对项目的实际情况知之甚少。确实,如果能掌握所有信息,那么系统早就构建成功了。然而,传统的设计方法往往让开发人员迅速地开始实现一个单一的方案——而这个方案仅仅是众多潜在解决方案中的一个——然后再通过修改设计,直到最终满足系统的目标。这也许是一个很有效的方法——当然,前提条件就是最初所选择的单一方案不能有误——然后再通过后续的迭代进行细化,但是最终可能需要花费很长时间才能得到一个并不是最佳设计的解决方案(参考资料[1])。

如果最初选择的单一方案不是最优的,那么后果就是:系统越大、越需要技术创新,所带来的损失也会越大。一个更好的方法是,可以参考使用基于集合的设计(多个设计构成一组)或者基于集合的并行工程(多个并行工程构成一组)(参考资料[2]),如下图所示。

 8086aeb0d2b30136819fea81a1ad79061a3a3b4c 

在基于集合的设计中,系统构建者们最初会考虑非常广泛,提出多种设计选项。接下来,他们持续地评估经济效益和技术难度之间的平衡,在集成的学习点上,可以演示与目标的匹配情况。然后,基于演示的结果和所获取的经验,去除那些不太好的选项,收敛到一个最终的设计。

采取这种流程,可以让设计选项的持续时间尽可能延长,在必要的时候进行收敛,并最终产生更优的技术实现和经济效益。

参考资料

[1] Iansiti, Marco. “Shooting the Rapids: Managing Product Development in Turbulent Environments.” California Management Review 38 (1995): 37–58.

[2] Ward, Allan C. and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute Inc., 2014.


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

华章出版社

官方博客
官网链接