[修改于Pipin版]从美式Scrum说起 (一家美国公司的Scrum敏捷项目记要与思考)

朋友Pipin发表于《程序员》08年8月刊杂志上的文章，写的非常好，这里做了些许的修改，共享给大家！

---------------------------------------------------------

从美式Scrum说起

一家美国公司的Scrum敏捷项目记要与思考

许舟平

2008年7月16日

引子 敏捷是一个过程

从计算机诞生的那一天起，如何编写最符合用户要求的代码就一直是每一个软件开发者所追求的目标。随着计算机应用领域的不断扩大，人们对软件的需求量和功能性要求不断增加，并且迫切需要缩短软件开发的周期。软件危机的到来孕育了软件工程学在1968年的诞生，计算机软件从原来面向的科学计算走到了人民大众的日常生活中。当软件产业已经向服务业靠拢的时候，软件工程也在向着需求工程倾斜着。当客户需求的变化和软件开发模式的固有矛盾相遇时，敏捷开发就从软件工程学中诞生了。

敏捷是一个过程，敏捷开发实际上是根据软件特性和用户需要的敏捷价值观，通过遵循敏捷的原则来进行软件开发的一系列过程的集合。笔者前些日子接触了一个国外运用敏捷开发的项目实例，现在拿来和读者分享，希望能对中国的敏捷开发者有所帮助。

项目背景

美国公司A是一个典型的在硅谷诞生的软件公司，以技术为导向，产品很新，更新速度很快，销售渠道稳健、高效，在销售产品的同时可以有效的把握好客户需求，并能将客户需求趋势反馈给开发团队。项目背景是在通过公司前几个产品将市场打开之后，公司急需推出一个全新版本V，能够将早期的几个产品integration到一个平台之上，并通过客户的需求反馈做产品功能的增删和Bug Fix。开发团队分为二个Team，Team1负责构建一个全新平台，用来integration原有产品；Team2负责进行原有产品的bug修复和根据客户需求变更所做的程序模块改动；Team人数分别在8至10人，项目周期以月而记，分为3个周期，采用Scrum模式来做敏捷开发（Scrum是一种寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进）。项目的风险在于：1.项目开发时间紧，要求在3个月内完成开发阶段工作；2.team1和team2在各自的Scrum开发周期内要完成功能联调和集成，需要并行工作；3.产品测试部门采用外包方式，测试人员在国外，而产品质量必须得到保障。

之所以采用Scrum，是因为Scrum方法将传统开发中的分析、设计、实施视为一个黑箱，认为应加强黑箱内部的混沌性，使项目组工作在混沌的边沿，从而充分发挥每一个程序员的创造力。下面就让我们通过Scrum的方法论来深入解析Team1和Team2的开发过程。

项目组织

在公司A中，分别由二个资深的项目经理来担当每个小组的Scrum Master角色，每个Scrum Master来负责本小组中的人员协调和项目组织工作，他们的真正工作职责并不仅仅是传统意义上的Project Manager或Team Leader，其最主要的工作是使各自所在小组内的工程师有充分的交流。每个小组都是由不同专业的人员组成，其中包括了程序开发人员，UI设计人员，文档人员等。Team1小组人员的划分是按系统层次导向（按体系结构中的分层），Team2的划分则是按功能导向（即按所分配的问题包或Backlog）。

图一：Scrum流程示意图

在项目的初始阶段，Team1和Team2的Scrum Master分别将各自负责的产品功能要求（注意：那时的产品功能并没有得到细化）、用户改进建议、技术升级等任务安装优先级排序形成一个Backlog列表，而后将Backlog列表中的各项按照其耦合性的高低分解称为不同的问题包Packets，并根据不同的问题包Packets来划分相应负责的开发人员，并由他们建立开发运行环境。在这个阶段笔者注意到了一个有趣的地方，那就是在项目设计阶段并没有一个传统意义上的架构师Architect角色。这省却了在传统的开发模型中概要设计和详细设计的时间，但并不意味着没有系统设计和文档，稍后会做介绍。而没有Architect的另一个好处是team中的每一个程序员都分担的Architect的作用，对于中国做敏捷开发的团队，由于传统的Architect存在着固有的领导思维意识，并且经常是由Team Leader或者PM来兼任，所以尽管运用了敏捷开发的方法，但却不能起到真正调动每一个程序员创造力的作用。而在美国，这种情况基本不会发生。

项目进程

经过了项目初始阶段的确定性过程后，项目进入了经验性过程的Sprint阶段。顾名思义，Sprint即为冲刺，运用在Scrum敏捷开发中的Sprint阶段就是在项目初始阶段确定了系统体系结构之后，在一段的限定时间内所完成的一系列开发活动，其中包括在前一个阶段可能没有做完的产品功能细化、设计、编码、单元测试等工作。在项目V中，Team1和Team2分别分解了3个Sprint周期，每个周期为4周，在第3个Sprint周期开始时要保证Team1和Team2完全可以并行工作和可以进行联调。一个Sprint周期结束之后即要完成在该Sprint周期中所规定需完成的Backlog项，并产生可执行的版本。对于开发人员来说，在每个Sprint周期中，他们都需要完成对所分配的Backlog工作进行分析、设计、开发、实施、测试和文档化等工作（在项目V中Team1和Team2的开发人员采用Wiki代替传统软件工程的文档管理）；在完成这些后，通过打包来封装Packets，从而产生满足各自Backlog需求的可执行版本，然后通过评审（Review）和回顾(Retrospective)，提出和解决开发中遇到的问题，并增加新的Backlog项，进行项目风险评估和相应对策，从而确定下一个Sprint的Backlog内容和完成时间。在每个Sprint进行过程中，每个Scrum Team都会通过Daily standup meeting进行沟通，交流遇到的问题，互相帮助。

当项目V进入到最后一个Sprint周期时，Team1和Team2中负责Integration接口模块设计的开发工程师将与QA人员一起进行系统联调，并由二个小组的Scrum Master在每个礼拜一下午召开Scrum Meeting（如图2中所示），来讨论系统需求变化和Bug修复情况。由此根据这个跨Scrum Team的Meeting的情况实时做出Backlog项的调整和从新分配。然后再进行打包封装交给QA人员进行测试。这个周期非常短，可能二、三天甚至一天就会有一个新的版本出现。

在这个过程中，公司A开发工程师的单兵作战能力给笔者留下了很深刻的印象。比如Team1中UI设计师具有10多年的专业设计经验，仅凭一己之力就完成了Team1中所有的界面模块设计和调用接口工作。项目中的每一个工程师都在系统建模、设计、开发环境部署、程序打包上拥有丰富经验，实际上他们已经分别完成了在传统软件工程中系统架构师、Coder、Tester和Build Manager等工作。与他们相比，国内软件公司处于的一线软件工程师大多属于拥有2-5年工作经验这一经验积累阶段，在个人技术的确存在差距，这种差距在某一方面导致我们国内的软件厂商在相似的开发项目上，同样运用敏捷开发方法，却不能充分达到一个良好的效果。这也与我们的国情有关，想想10年前老一辈的程序员，有多少现在还战斗在开发的第一线呢？不过没有关系，中国的软件产业正在慢慢成熟，一个充分良好的开发环境会让越来越多的程序员迅速成长起来，毕竟我们从事软件开发人员的基数是不可小视的。

图二：处在Sprint冲刺阶段的项目示意图

项目成果

在Scrum过程中会认为软件产品的开发是一个持续性过程，除非该软件产品经风险评估后认为可以停止。通过一系列的Sprint阶段，项目V会产生一个稳定可靠的版本交给公司的Release Manager。而处于Scrum过程中的最后阶段――软件产品交付后的巩固活动则近似于传统软件工程中的系统维护和改善工作，其目的在于整理Sprint阶段中由于压力而忽略的工作，为下一个Sprint阶段的开发做准备，以便轻装上阵。

思考：敏捷，不仅仅是敏捷

在中国软件公司的敏捷开发项目里，对比于国外，有着许多影响敏捷开发但又在敏捷开发理论以外的东西。比如开发者经验的不同，开发环境的不同，软件开发公司的管理状态等等。笔者接触过国内的很多软件企业的开发团队和项目管理者，不可否认的是，中国的软件开发在很大程度上一直处于长期借鉴国外软件开发的模式。而在借鉴的过程中，形似而神不似的情况屡屡出现，很多时候，我们只是将国外的开发模式照搬过来，并没有根据中国软件业特有的国情和我们的开发者实际情况作出合理的调整。比如当年CMM火热之时，国内的很多公司都投入巨大的人力物力来做评估，来搞文档管理和过程控制，可是到头来除了取得一纸证书以外并没有给软件产品带来本质性的提高，软件开发效率和质量依旧一塌糊涂，Maintenance team每天还是要不断的应付客户反馈回来的bug和投诉。而对于敏捷开发来说，希望国内的项目管理者能够抓住敏捷开发的精髓，让我们的软件能够真正的敏捷起来。