软件开发平台 DevCloud软件开发平台 DevCloud

更新时间:2021/03/18 GMT+08:00
分享

精益软件开发的精髓

关于精益软件开发

在敏捷软件业界中已经使用了很多的精益思想,比如准时制生产、看板管理、TQM(全面质量管理)、零缺陷等。

有关精益概念的历史最远可以追溯到20世纪50年代发展起来的精益制造和丰田生产系统TPS。这个系统和它蕴含的思想,为日本制造业,尤其是丰田公司,赢得了广泛的信誉。在基于精益制造和丰田生产系统的工作方法中,精益已经开始作为一个涵盖性的术语在使用了,包括精益建造,精益实验室以及精益软件开发。

实际上,敏捷软件开发与精益软件开发的某些思想是一致的。许多对敏捷贡献良多的人都受到过精益生产及其所蕴含的思想的影响,在精益和敏捷上,我们是可以看到他们的很多共性的。

精益软件开发所体现出来的主导思想和原理,无论对工程实践还是生产管理,最终目标是高效的产品开发或生产,无论这个产品是一辆轿车,还是一套软件。

精益关注的是快速流动、高效的开发产品,同时为客户创造尽可能多的价值。

精益开发的七大原则

精益开发共有七大原则。

  • 第一个是消除浪费。例如减少每周工作天数。

    消除浪费不仅仅是说消除物质资源上的浪费,更是消除人力资源上的浪费。根据权威调查,在绝大多数情况下,没有精益开发经验的软件项目经理, 在软件的设计开发阶段所做的工作都会或多或少地存在人力资源浪费。譬如,软件的架构师和产品经理设计了很多额外的功能,并为此浪费了大量时间来编写文档,而软件开发人员又依照这样的设计文档,开发了许多额外的功能,但是客户根本不用或者很少用到,这就是80/20原则,即20%的功能可以满足客户80%的需求。在精益开发的理论看来,任何不能够为最终产品增加用户认可价值的东西都是浪费。无用的需求是浪费,无用的设计是浪费,超出了功能范围,不能够被马上利用的代码也是浪费, 而由此投入的人力资源则是最大的浪费。

  • 精益开发的第二个原则:强化学习,鼓励改进。

    软件开发是一个不断发现问题,解决问题的过程。而学习能力的强化,能够令软件开发工作不断地获得改进。

    这和敏捷开发有点相似,敏捷软件开发的原则之一就是:通过短期迭代的方式,来达到持续改善的目的。

  • 精益开发的第三点与敏捷开发也有异曲同工之处, 那就是注重质量。

    质量驱动的开发实践,如测试驱动开发TDD、测试自动化、持续集成等。这些实践都是内建质量(Build-in Quality)的典范!质量就是要从需求、从每一行代码做起。

  • 精益开发的第四个原则,那就是推迟承诺(defer commitment)。

    今天绝大多数的软件开发都工作在一个不确定的环境中,而环境的变化会对软件开发本身造成致命的伤害。推迟决策,并不是鼓励你优柔寡断,而是说推迟到当环境变得足够清晰后,让你有充足的信息和理由来进行最正确的决策。对于一套大型软件的架构设计来说,如何构建一个可拥抱变化的系统架构是至关重要的问题。

    推迟承诺并不是我们对不能按时完成项目所找的借口,反而是让我们学会如何在正确的时间段做出正确的判断。

  • 下一个原则是“尽快交付”。

    自从互联网应用以来,发布速度已成为商业中的至关重要的因素,甚至有人说Web 2.0上的软件永远处于Beta版。软件阶段性交付的周期越短,软件的风险就越容易识别,用户的需求就越清晰,软件的质量就越高。

    延期是精益软件开发里面最深恶痛绝的浪费。我们可以尽可能快地以小功能的形式交付软件,以减少延期,这需要减少组织内的开销。譬如测试不会因为等待开发人员编码结束而停下来;我们不会同时做多个项目,避免不断切换情境和混乱,相反,我们一次只做一个项目,对DONE有非常明确的定义。

  • 下一个原则是“尊重员工”。尊重员工实际上是要对团队授权,让团队自己做决定,很显然,信任是基石。实际上,这一点和Scrum里面提到的自管理、自组织是一致的。
  • 最后一个原则,是优化整体(optimize the whole)。

    要想缩短整个开发周期,需要采用系统化的解决方法。找出系统中的瓶颈,评估它,找到解决方法,然后重新开始。如果你只优化系统中的一个部分,或许其他地方会出现问题,效果就会大打折扣。

TOC理论

TOC是Theory of Constraints的简称,约束理论的意思。是由以色列的一位物理学家艾利·高德拉特(Eliyahu M. Goldratt)博士所创立的。TOC认为,任何系统至少存在着一个约束,否则它就可能有无限地产出。因此要提高一个系统(任何企业或组织均可视为一个系统)的产出,必须要打破系统的约束。任何系统可以想象成是由一连串的环所构成的,环环相扣。一个系统的强度就取决于其最弱的一环,而不是其最强的一环。TOC可以应用到生产管理中。有一种著名的生产排程的方法叫鼓- 缓冲器-绳(Drum-Buffer-Rope,DBR)。TOC也应用到分销、供应链及项目管理等其他领域,且获得了很好的成效。

高德拉特博士最开始就是在处理工业领域出现的问题时而提出的TOC,现在也将TOC用到了软件开发领域,他认为,在软件开发的每个项目团队里面,也都应该存在瓶颈资源,对吧?如果一个团队说没有出现过瓶颈,则说明要么是专业化分工不够,要么是每个团队成员都是多面手,但这种可能性并不大,并且如果真是没有瓶颈资源,那大部分开发工作的效率应该不会太高。

如果团队里面的瓶颈出现在成本消耗最低的资源上面,譬如对技术要求不高的工作环节的人力资源。此时,根据TOC约束理论之一,需要迅速增加该瓶颈资源的人力投入,避免耗费高成本的人力资源做这些附加值不高的工作和劳动。反之,则不能简单地增加该瓶颈资源,需要慎重地进行系统思考。TOC的另外一个理论是考虑如何通过不仅仅是简单地增加资源来改善瓶颈的效能,另外就是如何让其他资源具备部分瓶颈资源才有的能力。

在TOC约束理论里,通过一个最弱环节法则,即链条的强度取决于最弱的一环。

下面是持续改善的几个步骤:

0. 理清系统的目标(定义制约与问题)

1. 识别系统制约因素(最弱环节)

2. 决定如何充分利用制约资源

3. 所有其他环节迁就上述决定

4. 为制约因素松绑

5. 如果通过上述步骤,制约因素得到解决,回头从第1步开始。

在高德拉特博士写的《关键链》的一书中,提出了围绕关键的瓶颈资源来安排计划的。其中,关键的一点就是如何有效地设置和利用缓冲,解决了项目管理中的帕金森效应(工作总会把时间撑满)和学生症候群(不到临考不会学习)。

关于看板

看板的重要作用就是把传统的推动式生产转变为拉动生产,通过按需生产来减少浪费。对于看板,一方面需要控制在制品数量,一方面是要考虑整个看板工序形成的流动速率。在敏捷软件开发中,可以把原始的用户需求或者故事,当成卡片,作为信息载体,采用拉动的方式组织开发。

有了拉动,我们就可以看到敏捷故事卡在整个看板上的流动。对于每一个工序都存在(To Do、Doing、Done)三种状态,每一个用户场景在当前工序一完成后就会在看板上面进行移动,从上一个工序的Done移动到下一个工序的To Do。在敏捷软件开发中,可以把当前Sprint要做的每个任务,通过这种可视化看板管理起来,每个任务只能处于这三个状态,当所有的任务都移动到了Done状态时,这个Sprint才能结束。这样更能让所有人清楚当前的项目状态,以及当前的项目瓶颈出现在哪个任务上。这样,就可以避免燃尽图所带来的假象了。举一个案例:一个团队在过去的Sprint中,燃尽图看上去一直很好,一直处于航空线下,突然有一天,就上去了,并且连续两天是平的!当时,团队成员也隐约觉得有问题,但没意识到问题的严重性。通过这个看板,就可以提前预知了。

这种方式可以避免人力或者其他瓶颈资源的等待问题,减少了浪费。其实你也可以多划分几个状态,譬如设计、开发、测试、部署、UAT、发布等,而不仅仅是To Do/Doing/Done三个大状态。对了,软件开发中最大的浪费往往源自Defect/Bug Fixing(缺陷修复)。对于这个问题可以通过引入迭代和持续集成的机制,加以预防,这也是与精益开发里面减少浪费的思想相通的。如果每一次迭代都给出可以向用户独立交付的产品,那么敏捷软件开发中也可以讲:

  • 准时化开发=迭代开发+持续集成+多次交付。
  • 零库存=每次迭代都给出可以发布的版本。

精益软件开发的要点

  1. 精益软件开发的七大原则:
    • 消除浪费(Eliminate Waste)
    • 强化学习,鼓励改进(Focus on Learning)
    • 注重质量(Build Quality In)
    • 推迟承诺(Defer Commitment)
    • 尽快交付(Deliver Fast)
    • 尊重员工(Respect People)
    • 优化整体(Optimize the Whole)
  2. 准时化开发=迭代开发+持续集成+多次交付。
  3. 零库存=每次迭代都给出可以发布的版本。

消除浪费

精益软件开发一词,源于波彭迪克夫妇(Mary Poppendieck和Tom Poppendieck)在2003年写的《精益软件开发》一书。书中介绍了7大原则以及22个实践工具。

消除浪费(或者叫Muda)原则,最初是由大野耐一(丰田生产方式之父)的理念所产生的。

对于践行精益软件开发的企业和团队而言,消除浪费的第一步,是鉴别什么是浪费,如何识别并感知到,这种对浪费的认识和感知的能力,是精益软件开发能否成功的关键。第二步是指出浪费的根源并消灭它。丰田生产系统TPS,欧美车企从80年代就开始学习,可刚刚学出一点门道,发现人家又精进了。所以丰田最核心的能力不是在TPS或者精益本身,而是称之为KATA(套路练习)的持续识别浪费并加以消除并改善的文化。

大野耐一认为,任何不能为客户创造价值的事务都是一种浪费,生产过剩、库存、移动、运输、等待、额外工序、缺陷等都是浪费;波彭迪克夫妇将这些浪费对应到软件开发中,包括部分完成的工作、额外特性、额外过程、任务调换、等待、移动、缺陷等。其中,额外的特性,交付不需要的功能,是产品开发中最大的浪费。我们要做一个能卖出去的产品,而不是反过来。

在精益软件开发的七个原则中,消除浪费是最重要的一个,是其他原则的基础,也是其他原则的目的所在。 举一个推迟承诺例子。传统开发模式中,在项目早期,信息最少的时候,我们要做出一个涉及最多决策的计划,这不是矛盾么;而这些决策往往并不准确,在未来需要调整,那么前期投入的时间就是浪费;此外,如果我们在前期花了大量时间做计划并进行决策,未来进行调整的时候,沉没成本会影响我们调整的决心和勇气。

因为软件开发通常具有一定的不确定性,尽可能地延迟决策,直到能够基于事实而不是不确定的假定和预测来做出决定。系统越复杂,那么这个系统容纳变化的能力就应该越强,使其能够具备推迟重要以及关键的决策的能力。

本文内容节选自《敏捷无敌之DevOps时代》,作者:王立杰、许舟平、姚冬(清华大学出版社)

分享:

    相关文档

    相关产品