精益软件开发(Lean Software Development)
介绍
随着软件系统变得越来越复杂，越来越多人参与其中，管理软件开发变得越来越困难。多年来，企业被告知要应对增加的复杂性，他们需要增加更多的指标，更多的控制，更多的检查和均衡。为了确保人们按照他们的要求行事，许多企业在流程合规性审计上花费了大量资源。结果不应该令人惊讶：组织文化越来越强调预测和管理，而对学习和创新的关注则越来越少。
不知何故，客户在我们预测和控制软件开发的渴望中被忽视了。许多组织已经形成了一种心态，将开发人员视为具有可预测性能的商品资源，就像机器件一样。但是，开发软件密集型产品和服务绝不是机械性的。这是一个学习和解决问题的练习，虽然经常是大规模的。我们需要的是一种思考软件开发的方法，该方法强调快速地组织学习，并指导我们所有的努力以产生客户价值。这正是精益软件开发所追求的目标。
第二次世界大战后，“精益企业”的概念起源于丰田。多年来，它发展成为一种独立于行业的管理理念，专注于提供更多客户价值，同时提高增长和盈利能力。有五个核心精益原则：
- 价值：了解为客户增加价值的因素
- 价值流：了解组织如何产生客户价值
- 流程：通过实现连续流动，最大化速度并最小化成本
- 拉动：根据实际客户需求准时交付价值
- 完善：不断提高价值流的表现
这些原则构成了大量支持实践的基础 - 强大的工具和技术可帮助企业最大化客户价值并避免浪费。实施精益的公司经历了高达50％的成本削减和95％的交付周期缩短。在本文中，我们将讨论如何将精益原则应用于管理软件开发的过程。
精益原则＃1：价值由客户定义
许多产品经理并不真正了解客户的业务如何盈利。产品功能的理由应该是通过帮助客户以可量化的方式更好地执行来增加价值，例如提高利润或销售额，或节省时间或金钱。
**任何不直接为客户带来价值的东西都是浪费。**也许软件开发中最大的浪费来源是未使用的功能。根据Standish Group的说法，企业软件应用程序中只有20％的功能被频繁使用，45％从未使用，19％很少使用，其他常见的软件开发浪费来源包括：包括缺陷（返工和测试） ），不必要的文书工作，等待，任务切换，人才浪费，未使用的指标和软件工具的不当使用。
通过分析客户的市场并确定利润和增长瓶颈，您可以更好地了解在何处以及如何增加实际价值。如果可能的话，以涉及客户的方式进行研究 - 与他们一起访问，组建联合分析团队，撰写联合报告等。仅从信誉良好的分析公司购买市场研究报告是不够的。没有什么可以替代做自己的功课，并彻底做到这一点。
精益原则＃2：学会看你的价值流
价值流是开发和交付产品或服务所需的一系列活动。它通常涉及多个流程，团队和部门。由于价值流涉及组织开发产品所做的一切，因此我们避免单独查看工程和市场营销等各个职能部门。与传统的性能改进方法相比，价值流允许我们将产品开发视为一个整体。
如果我们查看价值流中的每个流程并询问谁负责日常绩效以及流程改进，答案通常是没有一个人负有全部责任。相反，责任分散在几个可能存在利益冲突的职能经理人身上。这就是为什么流程改进工作经常与日常执行“不同步”的原因。通过指定价值流经理负责日常业绩和协调每个价值流的流程改进工作，我们可以明确履行卓越绩效的责任。在商业产品开发中，产品经理角色是以这种方式扩展的最自然的工作。在IT组织中，它可能是一名在国防/航空航天公司的项目经理，
精益原则＃3：流程 - 通过实现连续流动，最大限度地提高速度并降低成本
一旦我们发现了我们的价值流实际上是什么样子，我们就可以开始研究它们如何有效地产生客户价值。流程的概念要求我们重新思考如何利用经过的时间。实际花费了多少时间用于为客户增加价值的活动？
流程意味着观点的重大变化。我们不再对保持员工的忙碌程度，或者他们如何“高效”地执行个人任务感兴趣。相反，我们主要关注的是有效利用经过的时间。当我们在为客户增加价值的同时利用经过的时间时，会出现流量。持续流动意味着客户价值的单个单位（例如产品功能）在价值流中移动而没有花费在非增值活动上的时间。
在一个典型的组织中，24小时工作日只有1/3用于工作，剩下的就是停机时间。在停机期间，没有流量，因为没有人在工作。但是我们实际工作的时间呢？许多公司仍将其产品开发流程组织为一系列不同的阶段，例如概念开发，需求定义，架构设计等。每个阶段都会产生大量部分完成的工作。部分完成的工作构成了过程中的库存，这是一种浪费。库存堵塞了开发流程，占用了资源，并增加了响应客户需求所需的时间。
较小批量的工作导致库存减少，这意味着由于等待而损失的时间更少。这就是迭代开发比传统瀑布方法更快的原因。但迭代开发并不是灵丹妙药。除了等待大批量生产之外，软件开发中的抑制因素包括：
- 规格不佳或缺失 - 缺乏信息会导致工作陷入停顿
- 不灵活的架构 - 这些可能使得逐步进展变得尴尬
- 缺陷 - 它们使我们浪费时间进行非增值返工和重新测试
- 不平衡的资源 - 这些导致库存积压和等待
- 配置管理不良 - 无法访问工件会导致延迟
- 不可靠的构建 - 无法可靠地构建版本可能会阻止进度
- 任务切换 - 个人浪费时间试图兼顾多项活动
在软件开发中，从客户的角度来看，高达95％的交付周期和80％的开发工作都没有增值。即使在使用具有较小迭代的“敏捷”方法的组织中，也存在改进流程的重要机会。通过改善流量，我们不仅可以提高速度，还可以大幅节省成本。这是因为非增值活动，包括停机和等待，会消耗宝贵的现金。
精益原则＃4：拉动 - 使开发与实际需求率同步
即使持续流动，如果我们无法按时交付功能，结果是客户等待，我们的经济回报也是如此。如果我们提供不需要的功能，我们也会浪费时间和金钱。为避免这两类浪费，我们需要实际的客户需求，以实时明确地推动我们工作的内容，数量和节奏。
而不是基于预测需求和前期规划“推动”价值流中的工作，Pull意味着我们只在客户实际需要时才构建某些东西。换句话说，我们希望客户从价值流中“拉”新产品发布。传统的计划驱动工作被基于需求的工作所取代，减少了库存并提高了我们对客户需求做出快速反应的能力。
在许多情况下，客户无法尽快发布新产品。为避免大批量工作，这需要我们建立“人工拉动”，其中内部版本是根据客户代表性子集的反馈而生成的。即使我们的所有客户都没有部署版本，频繁发布客户反馈也会大大降低开发不相关功能或设计解决方案的风险，这些解决方案不能很好地实践。
如果我们希望客户反馈推动我们的开发工作，我们必须解决许多实际问题，包括提供反馈的客户的选择，组成和优先级。除非我们为单个客户开发软件，否则我们可能会与大量客户打交道。在这种情况下，我们必须谨慎选择一组具有代表性的客户，并仔细权衡其反馈的相对优先级。另一个实际问题是基础设施 - 如果我们要经常交付和部署新版本，我们必须部署必要的基础设施，以使这项工作顺利进行。反馈的频率也是一个关键问题 - 我们越频繁地获得客户反馈越好，但这意味着参与的客户必须确信在整个工作中保持参与的必要性。
频繁的客户反馈需要信任。建立这种信任的一种方法是明显地投资于努力了解客户的业务问题和机会。我们还必须解释如何使用反馈来为客户增加真正的价值。为了保持和增强已建立的信任，我们必须一次又一次地表明我们会立即对我们收到的反馈采取行动。在某些情况下，通过合同正式确定已达成的理解也是有意义的。对于自定义软件开发尤其如此。这种合同还可以将持续的资金与实际的客户价值联系起来。
Pull对我们处理软件设计的方式具有重要意义。在设计解决方案的可行性存在不确定性或客户需求快速变化的领域，我们必须保持设计的开放性。有时，我们甚至可能同时采用多种策略来处理设计风险。当我们减少不确定性时，保持多个选项开放并缩小我们的选择范围被称为基于集合的并行工程，并且它是在很短的时间内设计复杂产品的有效方法。
精益原则＃5：完善 - 持续改善价值流的表现
实施精益的公司为团队提供技能和激励，以便无情地识别和消除浪费。由于改进的重点是整个价值流，我们避免解决可能对整体经济绩效影响不大的局部瓶颈。跨职能变更团队用于改善价值流性能的典型改进流程可能如下所示：
- （重新）定义客户价值
- 映射价值流
- 确定废物来源
- 设计价值流的“未来状态”（我们希望它看起来像）
- 实施未来状态
- 目前的结果
与财务业绩挂钩的开放式指标显示了团队及其价值流的表现。为了鼓励更高的改进率，团队可以参与友好竞争，但应该要求他们定期分享他们的创新。
为了不断提高绩效，组织必须提高其收集，创建和分享知识的能力。这可以在几个层面上完成。在团队中，尝试交叉培训团队成员并偶尔切换角色。在产品团队之间轮换人员也很有帮助。丰田和诺基亚等高级从业者围绕领域专业领域组织团队。每个域组都以不断改进可重用组件迭代的形式编码其专业知识
对于跨团队的额外学习，请考虑在战略领域建立实践社区，例如客户关系管理，软件设计，可用性，财务，战略，精益思维和团队领导。这些团体应该将其他公司的想法与过去和现在项目的经验教训结合起来。
结论
精益软件开发提供了一种管理理念，以及一套用于设计和交付软件密集型产品和服务的实用工具。这些工具使我们能够根据适用性选择设计解决方案，方法，设计工具和组织结构。这样做的目的是为客户创造价值，同时减少对我们的浪费。
软件工程管理数十年的进步，有一个很棒的工具，方法和技术超市。精益不会使任何这些无效或验证。相反，它为我们提供了智慧购物的智慧，并采用了最大限度地提高客户价值，减少浪费并产生真正的顶线和底线结果所需的正确组合。