精益软件开发

维基百科,自由的百科全书
跳转至: 导航搜索

精益软件开发精益制造原则和实践在软件开发领域的翻译。由丰田生产方式(TPS)而发,一个高级精益时代正从敏捷社区融合而出。

起源[编辑]

精益软件开发一词起源于Mary PoppendieckTom Poppendieck写的一本同名书籍。这本书将传统的精益原则以一种新的方式呈现---作为22种敏捷开发实践工具之一,并且和其他工具进行了比较。

Mary 和 Tom's 在敏捷软件开发社区中提出的改进,包括在敏捷开发会议上的几次演讲,已经形成了被敏捷开发社区广泛接受的概念。 例如:咨询公司NetObjectives 和C.C. Pace 就使用了“精益-敏捷”以及其他一些列入的概念。

精益原则[编辑]

和精益制造原则的概念相近,精益开发也可以总结为如下七条原则:

  • 消除浪费
  • 增强学习
  • 尽量延迟决定
  • 尽快发布
  • 下放权力
  • 嵌入质量
  • 全局优化

消除浪费[编辑]

消除浪费(或者叫muda,是丰田管理词典中的一种特殊的浪费)原则,最初是由大野耐一Taiichi Ohno丰田生产方式之父)的理念所采用的。他将如下行为视为浪费:

  • 储存的等着被使用的汽车零配件
  • 生产任何不是马上就需要的产品
  • 不必要的配件移动
  • 等待其他配件被生产
  • 制造过程中多余的处理步骤
  • 缺陷(质量差)

换句话说,按照精益思维,任何不能为客户增加价值的行为即是浪费。包括:

为了消除浪费,首先必须能够识别、认识到浪费。如果某项活动可以被跳过或者没有这些活动也能达成最终的结果,那它就是浪费。在开发过程中作成但最终被废弃的代码是浪费。客户不经常使用的额外的处理和特性是浪费。等待其他活动、团队、处理是浪费。缺陷和低品质是浪费。不产生实际价值的、过度的管理也是浪费。以价值流来区分的方法被用来区分识别浪费。第二步就是指出浪费的根源并消灭它。持续不断的消除浪费直到一些甚至看起来必不可少的过程和步骤被清除。

增强学习[编辑]

面对开发团队以及最终的产品大小的额外挑战,可以说软件开发是个持续学习的过程。最佳的改善软件开发环境的做法就是增强学习。在代码完成后马上进行测试可以避免缺陷的累积。不是去做成更多的文档或详细设计,而是对各种各样的想法进行实际的编码尝试。用户需求的收集过程可以简单地通过给最终客户演示,并听取他们的反馈来完成。

使用短周期的迭代(每个迭代都应包括重构和集成测试)可以加速学习过程。在决定当前阶段的开发内容并对未来改善的努力方向进行调整时,在客户端帮助下通过简短的反馈会议来增强反馈。通过这些简短的反馈会议,客户代表和开发团队会更多地发现在进一步开发时会遇到的主要问题及可能的解决方案。从而,基于已开发出的原型,客户可以更好地理解自己的需求,开发者也能了解到如何才能更好地满足客户的需求。另一个关于和客户沟通、学习的想法是“基于组的开发”,这种方法聚焦于未来解决方案的约束限定而不是各种可能的解决方案,因此通过和客户的对话加速了解决方案的产生。

尽量延迟决定[编辑]

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

尽快发布[编辑]

在一个技术发展非常迅速的时代,尽早的发布产品有助于更快的获得用户的反馈来改善当前产品的质量,从而更快的完成下一次迭代。如果每一次快速的发布都能满足用户的需求,那么这个产品就可以视为成功的。每一次迭代的时间越短,团队内部的学习和交流就会变得更好。拥有了速度,决策会被延迟。拥有了速度,就可以更好的满足客户当前而非昨天的需求。

下放权力[编辑]

传统的团队里都是由团队的领导者来决定和分配每个人所要完成的任务。但是精益开发主张将这种权利下放到团队的每个人手里,从而使开发人员有权利来阐述自己观点并提出建议。

嵌入质量[编辑]

质量的管理在精益软件开发中尤其重要。在这里,质量的保证一开始便被贯穿在开发过程中的每一个阶段,而不只是在测试阶段来发现质量问题。

全局优化[编辑]

全局优化使得每个部门之间的联系更紧密。相对于努力降低每个部门内的成本,消除部门之间的隔阂和浪费会产生更显著的效果。在DevOps成为一大趋势的今天,开发部门,质量管理部门和运行维护部门之间的协同变得越来越重要了。

參看[编辑]

外部連結[编辑]