2.4　精益开发原则

在Mary和Tom Poppendieck合著的《Implementing Lean Software Development》一书中，阐述了如何将精益制造方法中的7条原则用于优化整个IT开发的工作流程。我相信应用好这些原则，将有助于进行有效的敏捷开发，并且能够解释为什么敏捷开发技术能够在实践中发挥效用。精益软件开发理论的主要原则如下所示。
消除浪费。精益理论认为任何未能直接给最终产品带来附加价值的行为都是浪费。在软件开发中，最主要的三大浪费来源分别是：添加不必要的功能；项目内耗；以及团体间的沟通壁垒（尤其是利益相关者与开发团队之间的壁垒）。有趣的是，IBM Rational的首席软件经济学家Walker Royce认为，现代迭代式/敏捷开发技术所带来的最主要的益处就在于能够大幅减少项目开发后期的返工和废弃掉的工作量。为了减少浪费，必须让规范敏捷开发团队能够完成自我组织，并按照所完成工作的特点来决定日常工作的方式。
内建质量。整个开发过程必须从一开始就注意质量问题，减少可能发生的缺陷。但是，如果这样做有难度的话，则应每次完成一小部分工作，然后检验其正确性，修正任何发现的问题，然后开始进行下一个循环。在木已成舟的时候回头检查，列出各种问题的做法远不如上面的方法有效。在敏捷开发实践中，上述方法的具体实践包括代码重构、测试驱动开发（Test-Driven Development，TDD）以及非独立开发（比如，结对编程，或者与他人合作建模等）。
创建知识。制定计划是有用的，但是不断学习也是很重要的。倡导诸如迭代式开发这样的策略能够帮助团队弄清楚利益相关者的真实需求，然后以此共识为基础开展下一步工作。对团队来说，经常性地审视正在进行的工作，然后不断改进提高，也是很重要的。
推迟决策。我们没有必要在软件开发过程的最初阶段就规定之后的每个细节，事实上我们都知道这样做的效果并不好。如果你能够采用一种灵活的架构，这种架构能够容忍变化的发生，并且在这种架构之下，人们可以在最后一刻才做出那些不可逆转的决定的话，其实对整个开发流程更加有益。通常，执行这一原则需要灵活衔接各种背靠背的任务，这些任务通常是多个以不同产品为目标的不同项目。DAD的开发流程从敏捷开发思想中取用了相关的策略，能够让团队在整个开发过程中兼顾各种问题，只在合适的时候才做出重要的承诺和决定。
快速交付。快速交付高质量的解决方案是完全能够做到的。每个团队一般都有其能力限制，这种能力限制通常反映在他们完成工作的速度（即团队在每个单位时间内能够交付的实用功能的“点数”）上，如果你能够按照团队的能力限制来为他们制定工作目标的话，那你就能建立起可靠并且可重复的工作流程。一个高效的组织不会要求下属的团队去完成力所不能及工作，相反，他们会允许团队自我组织，让其自行决定他们的工作目标。只要团队自身将持续地交付实用高效的解决方案作为其工作目标，他们就能专注于不断地为产品添加额外价值。这一策略在前面的规范敏捷原则第14条中已有所表述。
尊重他人。Poppendiecks还观察到，从全情投入、独立思考的人身上能够获得持续不断的益处。DAD中“以人为核心”的信条恰恰反映了这一原则。对你的最终成功来说，如何建立和支持你的团队是至关重要的。另外一条原则是，在制定总体策略时，你应该专注于如何激励团队，并为他们提供便利，而不是时刻控制他们。
整体优化。如果想有效地进行解决方案的开发，就必须纵观全局。你需要对更高一级的业务流程有充分的理解，这些业务流程通常横跨多个项目。为了向利益相关者交付完整的解决方案，通常需要管理多个不相关的系统内的项目。这是与主流传统的敏捷开发思想的主要区别，主流敏捷开发思想认为应该侧重于一个项目，然后围绕这个项目做一些局部优化。DAD避免了这一做法带来的问题，因为它主张从公司整体出发，采用精益理论中诸如价值流图（Value Stream Mapping，VSM），流程模型的程式化表达，之类的技术来定位整个业务流程中可能存在的瓶颈环节。应该用一定的标准来衡量你创造商业价值的大小。一套符合精益理论的测量体系是DAD过程框架所主张的恰当治理策略中的重要组成部分。
作为精益理论中一个重要的方法，“看板”（Kanban）方法能够为提高软件开发效率提供一些重要的原则和技术。我们希望能与你分享对你的成功至关重要的两个看板原则。这些原则如下所述。
工作流程可视化。当团队使用看板法时，虽然可以使用电子显示屏，但通常还是会用一张能涂写的白板或者其他公告板。在白板上会显示出很多标示（indication），这些标示称为看板项，它们代表在整个流程中的一部分工作。白板上的内容通常组织为列（或称作栏），每一列代表整个流程中的一步，或者一个工作缓冲区，或者一个工作队列。这些列横排之后，代表不同的工作步骤组合成整个工作流程。每个看板项都应该包含足够的信息，例如，这项工作的名称及编号，以及这项工作的截止时间（如果有的话），这样团队就无需管理者而自行做出工作安排。这种方法的目标就是进行充分的形象化沟通，从而让整个工作流程能够在团队里自我组织和推动。每天由队员们自己根据实际的工作进度，对白板上的内容进行更新，然后在每日例会上对关键的障碍进行总结。
控制进行中的工作总量。控制进行中的工作量能够减少平均开发时间，提高工作的质量以及增进团队的整体效率。缩短开发时间还能够让你更加快速地交付一些有价值的产品功能，这有助于加强利益相关者和团队之间的信任。为了控制进行中的工作总量，你需要了解对自己工作的主要限制因素有哪些，快速定位这些因素，减少所有不必要的队列等待和缓冲。但是这里有一些很微妙的权衡，例如，尽管缓冲和队列等待会增加进行中的工作总量，也会因此增加开发时间，但是这也让整个工作流程更加流畅，并且也提高了整体开发时间的可预见性。此外，因为每个团队都是互不相同的，所以你需要给他们设定不同的进行中工作总量限制，然后根据经验和实际情况对这些限制进行调整。
精益理论对DAD团队是非常重要的，尤其是当你发现自己处在一个大规模环境中时。它的主要作用有以下几方面。
精益理论能够解释为什么敏捷开发思想能够在实践中取得成功。例如，敏捷建模提倡在初始阶段只做简单的需求预想，然后根据实际情况，采用即时（JIT）建模的方法对迭代单元进行建模，因为这样可以让团队只在有实际需求的时候才会专注于某项工作，从而减少资源的浪费。
精益理论能够为软件开发流程的改进提供有用的策略支持。例如，通过理解在IT行业中造成浪费的主要来源，识别出这些浪费，并且消除它们。
精益理论为扩展敏捷方法提供理论基础。精益理论的目标不仅仅是优化软件开发的流程，它还致力于优化整体环境。这就意味着，我们应该关注于向客户交付整体的解决方案，而不是仅仅交付软件本身。
精益理论为我们提供发现浪费的方法。作为一种在精益理论中经常使用的方法，价值流图，可以用来为整个工作流程建模，并且可以用来弄清楚到底你日常工作中有多少时间用来做有价值的工作，而又有多少时间浪费掉了，这样你就能算出自己的工作效率有多高。价值流图是一种简单明了的工具，用于描述整个工作流程，它能够让你发现是否存在一些重大的问题。斯科特曾使用过价值流图为世界各地多个客户分析过他们的工作流程。通过这一工具，他们发现一些自以为处在良好工作状态的员工实际上其效率打分只有20%～30%。你永远无法修复那些连看都看不到的问题。
精益思想所带来的影响是深远的，有很多机构都愿意花时间去深刻理解它。你可以将在最终交付产品之前的所有工作都视为进行中的工作，这其中包括项目计划的制定、需求分析、测试、调试和设计等。精益思想能够帮助我们大幅减少各种浪费源的队列。相比向项目开发人员力推各种要求，我们会从一个具有最高优先级的简短工作序列中抽取一部分，然后快速地进行开发并交付给客户。为了最终的产品交付而提前收集大量的产品需求并不符合精益开发思想。但是，目前绝大多数开发组织都习惯于花费几个月的时间来为下一个待开发的产品收集一大堆需求，然后遵循精密的计划来逐个实现这些已经确定的需求。继续按照这样的方法进行开发的组织其实面临着风险，因为在这些组织完成首个版本开发的时间内，很可能有其他公司已经完成了几个不同版本解决方案的开发。
敏捷开发与精益开发思想都认为不应提前制定非常细节化的需求清单，精益开发甚至比敏捷开发更加注重这一点。在敏捷开发过程的工作项目清单中，并不存在细节化的需求描述，而是由用户故事来代替。工作项目清单实际上包含了产品经理（第4章将会深入讨论这一角色）当前已知的所有关于产品的重要需求点。精益开发思想提倡将这个清单进一步简化，使其仅包含数量非常有限的几个条目，并且只有在这些条目交付给客户之后，才往清单中添加新的条目。类似的例子在现实生活中有很多，例如，面包房里如何安排烘烤派的工作。面包师并不会一下子就烤出能满足一周需求量的派。相反，只有在展柜里的派卖完之后，才会烤更多的派，用来填满展柜里的空位。这个例子正如我们会从队列中抽出不同的产品特性来进行开发，而且只有在这些功能实现之后，才会去考虑如何用新的东西填补到队列中。
你或许会认为每次开发时只提前确定一打左右的主要产品特性（没有任何细节描述）是一种非常激进冒险的方法，这么认为或许是对的。大多数开发团体其实都还不能适应这种即时的开发方法，这种即时的概念是从制造业和零售业中的即时供应链管理方法中借鉴而来的。
或许几年后，一些先进的团体能够更加自如地从精益开发思想中借鉴一些有益的观点来补充其敏捷开发实践。