Scrum 与精益（ Lean ） 软件开发及应用

　　 Scrum 在众多的敏捷方法中更多地提供的是一个框架，而精益（ Lean ）开发则更多地提供了一种思想。二者能很好的结合并相得益彰。

 

Scrum 和精益（ Lean ）软件开发

　　传统的软件工程模型与建筑过程极其相似，尤其是瀑布模型。但是， Scrum 和精益却源于制造工业。当他们被引入软件工业的时候，实际上却继承并扩展了传统的软件工程模型和方法。

 

　　学过软件工程的人都知道瀑布模型。对于那些在初期需求就很完整清晰，并且在开发过程中不会有太多变化的项目，瀑布式开发非常适用。软件业发展的初期，在一些项目中人们用瀑布模型取得了一定的成功。但是随着软件工业的发展和企业运作速度的加快，在很多情况下，软件开发的需求在开发过程中始终在不断的变化。而瀑布式开发显然不能适应这种变化。因此在越来越的项目中，瀑布式开发以失败告终。随后，许多有所改进的开发模式纷纷涌现，比如螺旋模型和统一过程开发（ RUP ）模型。螺旋式结合了瀑布式和原型开发模式，这种模型能在一定程度上管理和控制那些在需求和设计阶段不可预见的需求变化。统一过程开发（ RUP ）模式则更进一步地采用一个或多个迭代周期。一个迭代周期包括四个阶段：初始阶段（ inception ）， 细化阶段（ elaboration ），构造阶段（construction ），交付阶段（ transition ），而在不同的迭代周期则分别侧重不同的阶段。比如：第一个周期可能侧重初始阶段同时也包含很小一部分的细化阶段和构造阶段用以创建原型。下一个迭代周期则会侧重于细化阶段同时也有一定比重的其他阶段，依此类推。原形开发和迭代周期的引进使需求的变化在原形或一个周期后被引入系统加以实现。不过在当代的科技界，越来越多的软件产品被移植到互联网上变成一种服务，以更有效、快速、容易地部署产品服务用户，并获得用户的反馈信息。这种变化大大增加了用户引导的需求变化频率。显然， RUP 模式面对这种情况显得力不从心，并且 RUP 模式还存在其他许多不尽人意的地方。 Scrum 采用时间更短的迭代周期，这种迭代周期被称为 Sprint ，一个 Sprint 通常为 2-4 周的时间。每个 Sprint 只开发价值最高的被称为 product backlogs 的产品需求，并且每个Sprint 周期可能包含全部的开发阶段如需求分析，设计，编写代码，测试，整合以及产品部署。每个短暂的 Sprint 周期过后，都能产生一个可以被整合、审查、展示并且最重要的是可以被用户使用的软件。许多当前的需求变化都可以被提出并且在下一个 sprint 周期得以实现。这样就产生了一个快速的反馈循环，它可以动态管理实现用户频繁的需求变化。与此同时， Scrum 这一模式也涉及诸如团队、流程、沟通等其它方面的元素，这些元素共同发展规范了整个 Scrum 框架结构。

 

　　精益（ Lean ）软件开发模式从一开始便侧重于提高过程中的效率。它最初来自丰田公司的制造工业，其主要思想是分析所有的流程，以查明和消除浪费，不断提高效率。为了达到这个目的，精益（ Lean ）模式提出了一些概念和实用的工具。大部分的工具都是在制造业使用而不能直接应用于软件开发。但是精益软件开发会经常提及其中的两个概念。一个是拉式系统（ pull system ）。在拉式系统中，一个流水线上的任何一个环节的任务完成后 , 都会从前一个环节自动提取下一个任务。该模式以客户的需求而不是市场预测来推动工作进程。另一方面，通过精益模式可以最小化未完成工作以及半成品的数量。它们通常被认为是开发过程中的浪费。除了拉式系统（ pull system ），价值流图（ valuestream mapping ）也经常被应用于软件开发过程中。价值流图能够有效的帮助识别过程中的浪费。

 

　　类似于其它的敏捷方法， Scrum 专注于管理需求变化和团队潜能的发挥，同时也含其它一些具体的规程。精益（ Lean ） 则 更多的教人一种思维模式，帮助形成具有精益思维和习惯的开发团队。将 Scrum 与精益结合可以使他们互相补充，取长补短。我们在许多项目中尝试实现了这种结合。比如，在我们的敏捷协作平台 GScrum 上，通过使用一种称为 WIP 容器的特殊周期，能够将 Scrum 与 Lean 有效结合起来。

 

使用 Scrum 和精益（ lean ）开发的常见问题及解决方法

　　 Scrum 或精益开发模式以及其它的敏捷方法对比于传统的软件工程或项目管理理论与实践有一个共同的优点：简单。不过，虽然 Scrum 和精益开发的精髓很简单，在实际运用过程中却不近然。

 

　　首先，人们普遍倾向于抵制变化，固守成规总是更容易一些。变化对许多人来说难以接受的，特别是那些不能立即为所有人都带来好处的变化。对于初次使用敏捷开发的团队，都需要一个从接受到真正应用的过程。一些敏捷开发实践如测试驱动开发（ as Test Driven Development ）、结对编程（ Pair Programming ）以及每天的 Scrum 会议都需要一段时间让开发团队逐渐适应。如果没有公司上层领导的强力支持，敏捷模式很可能以失败告终，开发人员只能放弃敏捷开发，重新回到原有的开发模式上。因此，公司领导的强力支持和对团队的培训，是让敏捷模式在一个公司生存和持续发展下去的重要因素。

 

　　对于使用 Scrum 的团队，在实践过程中也存在许多技术性的问题。不同的开发团队，不同的开发人员会有不同的感受。

 

　　在 Scrum 实践中， Scrum 专家（ Scrum Master）是一个很重要的角色。这个名词最初由 Scrum Alliance 提出。该角色从字面上很容易被理解为一个在 Scrum 开发团队中拥有极高权力，同时管理所有成员的人。实际上，这个角色并未被赋予真正的职权，但他必须拥有很强的软力量及社交技巧。从我们自己的实践经验看， Scrum 专家必须能理解团队中的每个成员，并且能够将所有人团结起来。同时， Scrum 专家还必须在团队方向与开发人员感受之间取得平衡。一些研究表明， Scrum 专家通常很容易失衡，要么过度关注Scrum 过程和项目进度，要么过分照顾开发人员。一方面，对Scrum 过程和项目进度要求太苛刻，不顾开发团队及成员的想法很容易势得其反，增加开发团队对 Scrum 的反感情绪。另一方面，如果Scrum 专家太有同情心，过度照顾开发人员的感受并且失去对团队整体方向的把握，那么任何一个团队成员的问题都会影响整个团队进度和执行过程。有这样的 Scrum 专家，这个团队可能让人感觉很舒适。但是显然，这样的团队很难取得任何成功，最终有可能放弃 Scrum 模式回到旧的开发模式上，或者出现其它更糟糕的结果。

 

　　 Scrum 提倡让客户全程参与到开发过程中。这就要求客户和产品拥有者有一个清晰的产品发展方向和足够的时间投入。产品拥有者负责任的参与能有效的提高 Scrum 项目的成功率。产品拥有者需要平衡项目利益悠关者之间的利益，从而能够管理产品需求（ product backlogs ）、调整需求的优先级、 完善需求描述，让开发团队有一个清晰的方向，为客户获得最大的投资回报率（ ROI ）。而在许多项目中，人们通常会觉得客户或其管理层太忙，无法参与。开发团队应该让客户明白，如果客户不投入时间和精力关注产品需求，那不可能取得产品的成功。在某些情况下，由全体或部分项目利益悠关者组成的小组或委员会是必须的。但是，项目拥有者仍然应该是客户与开发团队之间实现交流的唯一结合点，这样能避免开发团队受到客户的无序干扰。

 

　　敏捷开发团队要面临的另一大挑战是如何能够不断改进开发过程。在第一年，敏捷开发对于整个开发团队来说可能还是比较新鲜的。但是开发团队很快就会对敏捷方式，特别是每天的 Scrum 会议感到乏味。一旦感到乏味并开始松懈，开发团队要么会放弃敏捷模式回到原有的开发模式上，要么会停留在对敏捷开发的肤浅应用层次上。这样一来，团队的积极性和创造性会受到打击，停滞不前。这重情况下，结合精益（ Lean ）开发方法能有效的解决这些问题。精益（ Lean）模式提倡持续不断地改进, 减少流程中的浪费。这个概念应该被注入到整个团队中，让团队形成精益的思维和长期的习惯。在使用 Scrum 开发项目的过程中，我们会经常应用一些精益的方法。例如，我们发现有些 Sprint 计划过程很可能变成一种浪费，特别是对那些没有连续开发任务的项目。在这种情况下，我们使用GScrum 的 WIP 容器和拉式系统来管理我们的开发。实践证明，这样非常有效，减少了不必要的会议和浪费。我们也尝试使用 GScrum 提供的事件时间表来生成价值流图（value stream maps ），试图找出在开发过程中可能出现的浪费。 例如， GScrum 可以显示每个开发人员的事件时间表。有一次我们发现某个开发人员比其他开发者花费更长的时间来修改一些问题，并且多次被测试人员退回要求重新修改，这促使我们意识到系统有些部分没有单元测试案例。

 

运用精益（ Lean ）开发模式相对比较抽象，有时候会比其他敏捷方法更困难一些。很少一部分成熟的工具和过程能应用于软件开发领域。制造业中使用的精益（ Lean ）工具一般无法直接被用于软件开发行业。最佳的应用精益软件开发的途径是从简单入手，理解其思想，然后针对团队情况摸索创新，让整个团队习惯精益的思维模式和行为。当然，请有相关经验的专家指导、交流会事半功倍。