【IT168 专稿】

　　确实存在一种用于软件开发的可重复和可定义的过程吗？一部分人认为这不仅可能的，而且是必须的，比如那些赞成将CMM（Capability Maturity Model，能力成熟度模型）方法（Approach）用于软件开发的人[Paulk1995]。

　　译注：Approach，国内有研究复杂系统的学者将其译为“趋法”，个人觉得比较贴切，但因软件业界多将其译为方法，故仍将其译为“方法”。CMM定义了5个过程成熟度阶段：初始级（Initial）、可重复级(Repeat)、定义级(Defined)、管理级(Managed)和最优化级(Optimizing)，并让它的用户来定义18个KPA（Key Process Areas）的过程。SEI在2001年推出了CMMI，Capability Maturity Model Integration，其描述有2种方式：连续与等级，CMM于2005年12月已正式停止。

　　然而，很多在此领域第一线的人随着时间的推移逐渐发现，可重复或可定义的过程方法做出了很多不正确的假设，比如：

　　可重复的/可定义的问题。 可重复的/可定义的过程假设，存在一个步骤或数个步骤来捕获需求。但是在大多数情况下，却不能像那样（使用一个或数个步骤）来定义一个应用程序的需求，因为它们要么是无法明确定义的，或者是持续地变化着。

　　可重复的/可定义的解决方案。可重复的/可定义的过程假设，一个体系结构能够被完全地规定。但实际上它是逐渐演进的，部分原因是由于未捕获的或者是变化的需求（正如前面所述的），部分原因是由于创造性的过程包含设计新的软件体系结构。

　　可重复的/可定义的开发人员。 软件开发人员的能力相差很大，以致对一个开发人员起作用的过程可能对其他人却没有效果。

　　译注：在IT早期的日子中，评估生产力的比率，即在最好的个体生产力和最差的个体生产力之间的比值，最大可以达到 5:1。换句话说，最好的职员能够做5倍于最差员工的工作。现在，生产力比率可以达到40:1。一般业界认为1:20~28倍。

　　可重复的/可定义的组织环境。 进度的压力、优先级（例如，质量、价格、人力）、客户的行为等这些都是不可重复的，因为它们是高度主观的，所以很难去定义它们。

　　以上假设的问题在于这些变量具有很大的差异。在现实项目中，经常出现大的动态变化，会很大程度地影响整个项目。例如，在应用程序的实现阶段，由于假设了所有需求都被事先捕获，所以新的需求改变将对项目进度造成彻底的影响。几乎所有需求发生改变的普遍性根源都在于：业务需求驱动的改变、可用性驱动的改变、重新确定优先级驱动的改变、实验性驱动的改变等，消除这一不确定性几乎不可能。这个问题不能简单通过改进确定用户需求的方法来解决，而是需要一种更加复杂的过程从根本上产生全新运作的替代方法。

　　换句话说，一旦我们承认这些动态变量确实存在，我们就需要更具适应性的方法来构建软件。我们担心的是大多数当前的方法不能使我们构建出具有足够弹性的软件，现在的方法和设计范型似乎都阻碍软件都适应性。

　　很多软件从业者倾向于相信存在一种能够计划优先级的非常受欢迎的解决方案，能够实现详述所有需求。与此相反，Scrum从允许我们构建更具弹性的软件出发，认为没有必要预先写出全部的需求。可能用户也不知道什么是需要的，他们将在此过程中寻找他们认为可能的、未写入计划的需求。甚至软件开发人员预先也不完全知道究竟如何能够被构建出来。因此，用户在他能够感受到或接触到之前并没有非常明确的概念。就这一点而言，在此陈述的Scrum模式提供一个经验技术的集合，这些技术预先假设不确定性的存在，而不是提供实际的和特定的技术来驯服不确定性。这些技术扎根于复杂性管理，即自组织、经验过程管理以及知识创造。

　　从该意义上说，Scrum不仅是一种“迭代和增量并行的”开发方法，它也是“适应性”的软件开发方法。

　　译注：迭代（iterative）与增量 （incremental）是两个截然不同的概念，很多人常将两者混为一谈，但两者都被敏捷团队用于交付价值（deliver value）。迭代意味着“Rework”，增量着意味“adding”。两者的具体区别与联系，请参见：http://www.agileproductdesign.com/blog/dont_know_what_i_want.html及http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=108
　　
Scrum是如何工作的？

    Scrum的目标是在一系列（3～8个）短期的时间框（time box）内交付尽可能多的优质软件。其中时间框（固定时间间隔）被称为Sprint，典型地，其将持续大约一个月的时间。

    开发周期（包括需求、分析、设计、演进和交付）中的每个阶段都映射到一个Sprint或者一系列Sprint。传统的软件开发阶段仍将保留，主要是为方便跟踪里程碑。举例来说，需求阶段可能使用一个Sprint，包括原型的交付。分析和设计阶段可能各自占据一个Sprint，而演进阶段可能占据3～5个Sprint。

    近年来，对于大多数的软件产品而言，发布周期已缩短至3个月或以内。在开始Sprint周期前，需求被规格化为足够和及时准备好即可。在Sprint结束时生成可运行软件以供评审。

　　因此，分析、设计与演进发生在每一个Sprint。在许多公司Sprint周期已缩短至2周或更短。在最好的公司，交付（Delivery）包括在每一个Sprint中 。

    与可重复的和可定义的过程方法不同，Scrum中的Sprint没有预先定义的过程。取而代之的是，Scrum会议（Scrum Meeting）驱动分配行动的完成。

　　每个Sprint运作在很多工作项目(work items)上，这些工作项目成为一个Backlog。通常，在一个Sprint里，没有项目（item）从外界添加到Backlog中。最初预先分配的Backlog产生的内部项目则可以添加进来。Sprint的目标是完成尽可能多的优质软件，但一般情况下，实际交付的软件会少一些。

    译注：Backlog有译作待办事宜，这里保留英文。随着Scrum发展现细已分为Product Backlog、Selected Product Backlog、Sprint Backlog、Impediment Backlog等Backlog。本文的Backlog大致等同于前3者。

　　最终的结果是每个Sprint交付的都是非完美的发布版本。

　　在一个Sprint期间，每天举行Scrum会议来确定如下议题：

 • 自从上次Scrum Meeting以来所完成的项目。

 • 需要解决的问题或障碍（Scrum Master是团队的领导角色，负责解决障碍）。

 • 团队应该在下次Scrum会议之前完成的新任务。

　　Scrum Meeting能够使开发团队中成员的知识社会化”，同时产生更为深刻的文化上的超越。这种“知识社会化”（knowledge socialization）可以在日常的开发过程中促进自组织的团队结构。

    译注：Nonaka与Konno两人共同提出SECI模型，藉以解释知识创造与不断累积的过程。他们将知识转化的步骤或程序分为4个阶段：（1）社会化（Socialization），（2）外表化（ Externalization），（3）组合（Combination），以及（4）内化（Internalization）。通常知识在每个阶段的转化过程中，须不断的自我突破与超越，且会像滚雪球一样，越滚越多，不断增加，并显现螺旋式的演进轨迹。社会化（Socialization）是指让许多的个体（individuals）共同在一起生活、工作，而非只靠书面教导，使大家相互了解彼此的思想与感觉，因而促使个人之间彼此交换及分享其隐性知识。

　　在每个Sprint结束时用一个演示来：

 • 向客户展示进展情况。

 • 给开发人员一种成就感。

 • 集成和测试正在开发的软件的适当部分。

 • 确保真实的进度，即Backlog的减少不是用文档来衡量。

　　在收集残留的和新的业务并重新确定优先级以后，形成一个新的Backlog，并开始一个新的Sprint。很多其他的组织和过程模式（Organization and Process Pattern）可以与Scrum模式联合使用。

　　下图展示了Scrum模式之间的关系。

Scrum模式