宝信软件是一家宝钢旗下的上市公司。宝信软件研发部成立于2000年，在2001年启动了以CMM3为模型的过程改进。后续历经CMM4、CMM5，在2006年12月，通过了CMMI V1.1 成熟度5级评估。
在2007年初，宝信软件研发部设有一位总经理、3位总监，共有约120位员工，主要开发方向有三块：1、信息安全；2、实时监控；3、开发平台。以上三个方向对应于三个室，另外有独立的测试室和过程控制室，每个室有一位室经理。EPG（Engineering Process Group，工程过程组，是在CMMI中推进过程改进的小组的缺省名称）组长、专职QA（Quality Assurance，质量保证 本文QA是指过程方面的质量保证工程师，不是指测试工程师）和专职CM（Configuration Management，配置管理，指配置管理工程师）在过程控制室，兼职EPG由每个室派出1~2位的资深人员组成，EPG一共约10人。如下图所示。我时任过程控制室经理兼EPG组长。
在规范方面，经过了多年CMM/CMMI改进，宝信软件研发部积累了完整的组织标准过程集，主要如下。
1，三种生命周期模型及其裁剪指南---瀑布型生命周期模型、原型法生命周期模型、增量生命周期模型，后两种生命周期模型是与瀑布型生命周期模型为基本的。
2，两种需求分析方法---用例分析和传统需求规格说明书分析，一种设计方法---面向对象，四种开发语言的编码规范，覆盖黑盒白盒的测试规范。
3，各类流程，比如评审和同行评审、缺陷跟踪、变更管理、供应商管理、度量规范、决策分析、风险管理、质量保证等等。
4，各类文档的模板，比如计划、需求、设计、方案分析报告、测试报告等等。
5，对于同行评审、生产率、工期偏差开展了统计过程控制，建立了工期、质量的预测模型。收集项目数据，形成了过程能力基线（多个关键指标的基准值，比如生产率，用于后续估算以及整体观察组织情况）。
6，以上各种对应的培训材料。
下面重点介绍下在敏捷导入中发生关系的几个方面。
宝信研发瀑布型生命周期模型源自于传统瀑布型生命周期，分为计划、需求、设计、编码、测试、发布共6个阶段，其中计划、需求、设计三个阶段以通过里程碑评审为阶段退出标志，编码阶段以打首轮BUILD基线（要求所有的需求项全部跟踪到已解决状态）为退出标志，测试阶段以满足发布标准为退出标志，发布阶段以最后结题为退出标志。对宝信研发瀑布型生命周期的总工期并没有限制条件。宝信研发原型法生命周期模型相当于双重瀑布，对原型的要求降低，在两个瀑布之间加入了原型发布和反馈环节。宝信研发增量生命周期模型相当于多重小瀑布的叠加，每个增量版本的工期推荐为2~4个月。
用例分析方法是来自于Rational公司的RUP（Rational Unified Process），要求在需求评审时，展现全面的用例图和用例规约。传统需求规格说明书分析方法则是要求书写需求规格说明书，简称SRS（Software Requirement Specification）。宝信研发当时为了方便跟踪和度量需求，融合源自于微软某个MSF版本中的功能点UBD（U-User Service，B-Business Service, D - Data Service，与MVC架构模式是对应的)划分，以及IFPUG的功能点分析方法，得到了宝信功能点方法，宝信功能点的定义是“一个功能点是对最终用户在业务逻辑上有意义的最小活动单元”，分为三类：1、U-用户服务User Service；2、B-业务服务Business Service；3、D - 数据服务Data Service。宝信功能点是可以从SRS和用例规约中提取出来的，这样，宝信功能点既有实体功能点对应，也是软件规模的度量单位。
宝信功能点的内容是后续设计、编码、测试的依据，宝信功能点的状态用于跟踪管理，宝信功能点的数量说明了软件规模的大小。所以宝信功能点在宝信研发定量管理体系中处于基石的地位。
宝信研发的设计方法采纳了面向对象的设计方法，主要参考自OOAD（面向对象的分析和设计）中的OOA，与所选开发语言无关，要求识别到主要类及其主要方法，画出类图。详细设计在宝信研发设计方法中是可选的，对应于OOAD中的OOD，要求考虑具体开发语言，利用所选开发语言特性，识别多数类和多数方法。在实际中，只有个别项目组选择了做详细设计，所以主体上2007年宝信研发设计方法对应于OOAD的OOA。
同行评审是被认为对软件质量影响巨大的过程，跟踪度量各阶段同行评审，并选择了代码同行评审作为统计过程控制过程。维护了各类同行评审检查表，并跟踪同行评审活动，保留检查表执行记录。选择同行评审的缺陷密度和评审速度作为统计过程控制的指标。
在过程绩效建模方面，识别了同行评审平均缺陷密度、工期压力系数、TCF技术复杂系数、ECF环境复杂系数、代码平均增长速度、交流复杂系数、功能点挣值、已经投入工作量、已经过去的工作日、计划工期、估算功能点数等等作为建模因子，利用复杂的统计学方法得到了数学模型，即是过程绩效模型，并开发了工具。对于项目组，每周将过程中数据代入到数学模型中，可以得到对当前版本工期、缺陷和生产率的预测。如果预测值超出控制限范围，那么识别为问题，并采取措施；如果接近控制限范围，那么识别为风险来处理。
小结
通过以上可以看出，在CMMI的指导下，宝信研发已经建立了系统化、全面的组织过程资产库。在高成熟度建设方面，根据CMMI5的要求，开展了比较全面的定量管理。
对于开展基于CMMI的过程改进，主要有两大目标：
1， 目标1：满足CMMI能力成熟度等级要求；
2， 目标2：提升组织真正绩效。
在安排了外部正式评估并且确定了评估日期的背景下，基于CMMI的过程体系建设的首要目的是满足CMMI，其次要目的才是追求提高组织真正绩效。在满足CMMI23时，以上两个目的重合度是很好的，目标1的实现快速的拉动了目标2的达成，但在CMMI45级，在有些实践方面，目标1的实现对目标2的带动效应明显要比在CMMI23时要小。
敏捷导入过程时间回到2007年，ePass是一个处于维护期的BS结构的软件，项目经理是张龙（化名），张龙是一位硕士，2002年毕业于某江苏的知名211大学计算机系，技术精湛，对Java、OO深有研究。张龙在2006年接触到了敏捷软件开发方法，阅读了关于XP、Scrum等的多本书籍。
eCop维护项目是另一个处于维护期的软件项目，赵虎（化名）是这个项目的负责人，赵虎也是一位硕士，2003年毕业于某武汉知名211大学计算机系，在中兴和华为工作过，技术同样精湛。他在eCop维护项目当中碰到了些难题，主要是如何快速响应用户反馈，保证用户现场问题能够及时解决。
本人是EPG组长，2002年硕士毕业于清华大学电机系，在Intel工作过，自2004年后工作领域主要是过程改进和质量保证，对CMMI、软件工程有较深的认识，也正好是2002年~2003年时ePass第一版的项目经理。。
到了2006年末，张龙就在ePass项目中开始了部分敏捷类的实践，也导致了多个QA问题，主要集中在计划和工作量管理方面。我马上就发现了这个问题，找到张龙沟通具体情况，他跟我介绍了有关敏捷的一些情况，他表示有意愿继续尝试下去。
我同时也了解eCop方面存在一些困难。张龙告诉我：
eCop维护项目过程中,每个子版本的生命周期中,目前的规程阶段划分无法适应下面的实际情况：
在制定子版本的过程中,比如已经确定了5个需求,项目组实际可能先做3个需求,然后提交一个test基线,测试组一遍测,开发组一遍实现另外2个需求.那么这种情况,阶段应该如何划分?
还有就是其它阶段时,中间又来了2个高优先级的需求,确定要在这个子版本中实现,那么此时应该如何划分阶段?
此外,即使阶段划分了,对应的计划等一系列文档都需要变更,也比较繁琐。
在06年的维护过程中总结了一个简易需求开发流程
我之前通过几篇网上文章对敏捷有个初步的了解，就再去阅读学习了更多有关敏捷的文章和书籍，初步判断这值得尝试。当然就算我对敏捷不了解，按照CMMI下鼓励改进的精神、过程试行方法和允许项目自定义过程的原则，作为EPG领导者的我，不能强行拒绝来自于项目一线的探索。于是我在对ePass项目进行一番了解后，发出了如下的信件。
-------------------------------------
发件人: 张克强
发送时间: 2007年2月26日 9:40
收件人: '张龙'
抄送: '赵虎'
主题: 当前ePass项目验证有效的敏捷实践小结
正文：
龙：
对照XP的12个实践，据我的了解，在ePass中得到使用并证实有效的实践是否
为如下所列：
1，测试驱动开发
2，持续集成
3，代码共享
4，编码标准
另外几个方面我存有疑问：
1，计划游戏，对于当前多处项目支持，我们是如何来估算承诺日期的？ 是否
采用了类似于scrum中的做法？ 是否需要积累历史数据以供后续估算呢？
2，小交付，ePass发布是否按某种一致的方式在进行？
3，系统比拟，上次你所介绍的需求分析方法，与部门的用例分析方法非常接
近，在有些部分对文字的要求甚至高于当前部门方法，与早先的user story的做法似乎
有所变化？是否是针对没有现场客户而所做出的调整？
赵虎在eCop快速处理中也有一些有效实践。
安排明天我们三个人碰一碰，初定在明天下午13:00在2409，如何？
-------------
在2007年2月26日，三个人如期进行了讨论，得到了如下的信件。
发件人： 张克强
发送时间： 2007-02-26 16:50:00
收件人： 张龙;赵虎; 部门分管总监; 部门另一位总监; 部门各室经理; EPG
抄送： QA
主题： 答复: 当前ePass项目验证有效的敏捷实践小结
正文：
今天张龙、赵虎和张克强就项目敏捷实践选择进行了讨论，达成如下要点：
1，需求易变的项目适合用敏捷生命周期，维护项目的特点正是需求易变，易新增，也
有缺陷被发现后要修改。从当前的维护项目中总结敏捷生命周期是合适的。
2，敏捷开发与传统开发的一个巨大不同在于敏捷开发认为中间过程及中间工作产品的
验证反馈不是最有效的方法，而从最终用户处获得的对产品实际实现的反馈是最有价值
的。
3，为提高用户满意度，应当追求加快客户需要响应速度，最终用户的使用反馈是最好
的检验。
4，直接实现马上交付给用户，虽然是最快获得用户反馈的途径，但风险过于巨大，因
此在过程中加入验证是必要的。当前识别有二级的验证：1，对需求的验证，方法是开
发人员设计测试用例来验证需求 2，对代码的验证，采用模块级的单元测试手段。
5，经过这次讨论，可以看到一个大框架，与测试的V模型有点像，但都是由开发人员来
完成。
需求 -------------------- 需求验证：测试用例设计
\ /
编码 -------------- 测试驱动开发：单元测试
\ /
交付 ---------- 用户反馈
问题：独立测试组测试需不需要？
6，尚有几个关键问题：如工期承诺如何估算，各类工作产品的要求，后面还将安排这
样的讨论。争取逐步形成较系统的敏捷开发方法。
-------------------
这封信发出后，各方领导都知道了这件事情，ePass项目组就正式获得了试行敏捷实践的机会。对于EPG而言，其试行是在CMMI所推荐的试行规则下，有志愿的项目组来研究分析这个改进机会；对于QA而言，根据试行规则，会同EPG与项目组商量哪些规程可以免遵守，根据新商量的规则来开展这个项目的QA工作；对于项目组而言，项目组根据自己对敏捷开发方法的理解来寻找最适合他们的方式方法；对于部门领导而言，了解了情况，新事物带来的风险在可控范围之内，而且是在规范的开展试行，同意了此项试行。
同时，在部门的公告论坛上，发布了如下的帖子：
标题：敏捷（Agile）开发生命周期引入构想
1 起因
1，以XP为代表的Agile开发模式在软件业界引发热潮，不少组织采用，其中不乏像IBM一样的大公司。
2，部门内ePass项目组采用Agile的部分原则和实践在项目实际中取得了正面的效果。
2 条件和限制
1， CMMI5评估通过，组织本身的革新能力已经得到证实。
2， ePass项目组已经积累了不少的实践和经验。
3， Agile开发是有一定的限制条件的，比如有些方法论要求快速高频度的有效用户反馈。
3 目标
定义一套有针对性的生命周期，吸收敏捷开发方法论的优点又结合部门实际。切实有利于提高部门项目绩效。
-----
并在部门社区转贴了多份介绍XP、Scrum等的文章。
我的回顾点评：
1，作为EPG组长，我碰到敏捷软件开发这个新事物时，反映是比较敏捷的，意识上也是开放的。
2，CMMI下的过程改进机制对引入新事物持欢迎开发态度，这对尝试敏捷开发有很大的帮助，在这样的氛围熏陶下，从领导层到项目一线都支持尝试新事物。
3，及时迅速的沟通各方，获得了尝试的机会。就算各方不支持，至少需要让各方不反对。
4，在沟通中，注意了新事物-敏捷开发与原有事物-传统开发的对比和对接，虽然所谓的V型大框架未必完全正确，但它与大家熟知的V模型有联系，这样容易获得理解和支持。
关于敏捷生命周期模型的说明
组织EPG和相关人员讨论后发现，敏捷软件开发方法与当时基于传统软件开发方法得到的宝信研发过程规范最冲突的地方是在于生命周期模型。在敏捷相关的文章中，虽然少有生命周期模型的论述，但是生命周期是事物发展的客观规律，从项目看，生命周期模型也是最重要的总体主过程。敏捷软件开发方法所处理的软件开发显然也有生命周期，而且敏捷软件开发方法对生命周期模型有预置的、强制的要求，符合敏捷的生命周期模型最大的特征是短迭代，短迭代也是判断是否采用敏捷开发方法的必要条件之一。这与宝信研发的瀑布型生命周期模型存在明显的冲突，与衍生于瀑布型生命周期模型的宝信研发原型法和宝信研发增量型生命周期也有冲突，这些生命周期模型在实际使用中原型或增量版本的时间最短仍然长达3个月。
CMMI是特别重视生命周期的，明确要求书面地建立生命周期的说明。CMMI的具体要求是位于CMMI3级过程域-组织过程定义（OPD）过程域的“SP1.2 建立生命周期模型说明”，其要求如下：
建立并维护生命周期过程模型的说明，经核准后在组织中使用。对于不同的客户与不同的情况，可能开发多个生命周期模式，因为只有一个生命周期模式可能不适用于所有情况。生命周期模式常用来定义的阶段，同时组织对每一产品与服务种类，可能定义不同的生命周期模型。
CMMI本身并没有指定生命周期模型的要求，倒是提醒：对不同的产品和服务种类，需要定义不同的生命周期模型。 我们发现敏捷软件开发方法与和传统软件开发方法最合适对接的地方也是生命周期模型。所以我们引入敏捷的第一步就选择在了探索符合敏捷的生命周期模型，在内部就称为敏捷生命周期模型。
启动试行后，我与两个项目组继续进行沟通交流，赵虎因为刚刚开始接触敏捷软件开发方法，希望能有所指导，虽然口头交流已经有几次了，但还是希望先行的张龙能整理个简单的指南。张龙表示项目事务比较忙，而我作为专职的EPG组长，在此类事情上，缺省是我的职责范围，因此，我主动承担了此事。
在2007年3月22日，经过与张龙的讨论，我发出了《项目敏捷开发方法草案》，主送给了两位总监、各室经理、EPG、QA，抄送给了部门总经理和另一位总监。草案主体部分如下。
------------
适用性
当前识别的敏捷开发方法仅适用于维护类型项目，并且最终用户已经存在。
工程过程
识别开发包
开发包定义为处理限定范围新需求或/和缺陷的一组工作产品和相关的活动。典型的开发包比如针对一个VIP用户新需求的解决，又比如针对三个缺陷的解决。初步估算开发包的关联功能点数量（指新增、删除、修改的功能点数量）。项目经理是本活动的负责人。
开发包的载体可以是卡片，可以是电子文档，可以是SharePoint的一条记录，等等，形式不限，要求在团队内部共享、交流方便。
分配开发包
采用团队会议的形式来分配开发包。
项目团队成员选择适合的开发包，项目经理协调任务和人员的安排。可以渐进地引入鲨鱼抢食的任务分配方式。
分析开发包
开发人员分析开发包：
1， 识别新增和修改的功能点，在功能点管理系统中作相应的变更；
2， 如果修改带来界面变更，需制作界面原型，得到干系人的确认；
3， 如果修改带来接口变更，需完成向下兼容性分析，
4， 统计关联功能点数，估算开发包工作量，对照预定计划，如有偏差，进行必要的调查
5， 通过编写测试用例，进行需求验证
(以上序号并不完全说明任务先后顺序。)
分析开发包的载体推荐采用单个文件的形式，也有项目组采用Wiki形式。
设计实现开发包
推荐采用简单设计原则进行设计，如果书写了设计说明文档，与上述分析开发包的工作产品存放在一起，或直接并在一份文档中；
推荐采用测试驱动开发原则进行编码；
开展单元测试；
执行测试用例验证功能；
跟踪功能点。
组合得到小版本
将开发包组合得到小版本，在只有一个开发包的情况下，也可得到小版本。
进行联合单元测试；
交叉执行测试用例验证功能；
测试通过后，打BUILD基线。
小版本测试
将小版本BUILD基线提交测试组测试，处理发现的缺陷
小版本发布
发布小版本。
收集用户意见，识别下一批次的开发包。
质量保证措施
项目团队
1， 开发人员设计测试用例以验证关联功能；
2， 项目团队对开发包分析结果进行评审；
3， 开发人员开展单元测试；
4， 开发人员执行测试用例；
5， 与干系人交流原型、修改的功能点等等
QA
1， 监察开发包分配；
2， 审核开发包分析结果；
3， 审核测试用例；
4， 监察单元测试；
5， 其它通行QA活动
项目计划和跟踪
项目经理负责项目计划和跟踪，创建和维护《项目说明书》，计划并跟踪小版本和开发包的情况。
小版本周期一般大于2周、小于8周。开发包工作量一般大于40工时、小时320工时。
团队人员的MPP跟踪周期可以设为开发包的周期，任务工时不超过开发包总工作量。
“穿刺”估算方法
如果部门原功能点估算方法不适用于维护项目，采用“穿刺”来定义项目估算方法。
穿刺方法：
1， 结合项目实际，定义标准开发包，所谓标准开发包，应是项目实际中最常见的开发包，比如修复一个3级缺陷，又比如调整二个界面等等；
2， 安排人员分析设计实现开发包，度量全部工作量；
3， 得到标准开发包的工作量；在识别其它开发包时参照标准开发包的大小和工作量。
------------
敏捷开发方法的试行就在这份草案，经过多方沟通后正式开始了。到了2007年7月，我与赵虎进行商量，已经进行了半年多时间，请赵虎整理敏捷生命周期模型。赵虎对敏捷开发已经颇有心得，欣然接受了这个任务。
在7月23日，赵虎发出了《研发部敏捷生命周期模型》V0.1。在2007年8月7日，我组织了对赵虎起草的《研发部敏捷生命周期草案》的讨论，讨论纪要如下。
-------------------------------
发件人: 张克强
发送时间: 2007年8月7日 15:22
收件人: 赵虎、张龙、另外两位同事
抄送: 部门总经理和3位总监、EPG和部门党支部书记
主题: 对敏捷开发进行一个小范围讨论的会议记要
正文：
2007-8-7 张龙，张龙，张克强与另外两位同事就基于代真虎起草的敏捷生命周期进行了一次讨论会，达成如下共识：
1, 以“交付”一词来对应英文”iteration”, 一个交付对应一个交付包，而一个交付对应的项目版本可以是小版本，也可以是小版本下的小小版本。
2, 在交付包处理前期，需要书写“交付包说明书”，必须包括如下5个内容：
1, 起止时间
2, 主要需求范围
3, 分工
4, 规模估算
5, 工作量估算
可以视交付包情况添加其它内容。
此交付包说明书是需要在前期进行同行评审的里程碑性质的工作产品
3, 交付包可以处理新需求、缺陷等等
4, 规模估算基于需求来进行，采用分三档的权重和来估算。
5, 工作量估算与规模估算结合进行，通过数据积累来得到更为准确的估算系数。
尚存有疑问的地方有:
l UEX缩写含义不清
l 验收测试的说法 与测试规程冲突
l 关于交付包设计文档的裁剪 没有说明
在9月13日，根据组织技术革新规程，我组织了关于敏捷生命周期的专题会议。在会后发出了如下的会议纪要。
发件人: 张克强
发送时间: 2007年9月14日 13:39
收件人: 研发部全体，公司过程管理部领导和对口专员
主题: 2007年9月13日研发部技术革新敏捷开发生命周期专题会记要-敏捷开发生命周期发布了
2007年9月13日 9:00~ 11:00，研发部技术革新敏捷开发生命周期专题会议于公司张江总部2402会议室举行。会议由部门副总经理主持，研发部革新小组成员参加了会议。
首先，代真虎详细的介绍了敏捷开发生命周期规程；然后，樊国柱对POR结合Xplaner及Fitness的敏捷实践进行了介绍。
穿插着两位的介绍，会议针对其中具体各项进行了热烈的讨论，并给出了调整的意见。最终总体上通过了规程。
会后委托代真虎根据会议意见对敏捷开发生命周期进行修改，修改后交各方分别评审,通过后交QA审核发布。
纪要发出后，我和部门总经理进行了沟通，部门总经理发表了看法，总体上赞同新的敏捷生命周期模型，但指出交付包的设计应当是必需的。根据部门总经理的意见，修改得到了《敏捷生命周期模型V1.0》，在2007年9月27日得到了正式发布。
《敏捷生命周期模型V1.0》主要内容如下。
1. 宝信研发敏捷开发生命周期来源于部门几个项目的相关实践，其中有在增量型生命周期的基础上进行的敏捷尝试，也有在XP方式下进行的尝试，本文对上述实际进行了相关的总结和归并，并依据SCRUM建立宝信研发敏捷开发模型。本文用于指导宝信软件研发部对维护项目采用敏捷开发方法。
2. 用于指导宝信软件研发部对维护项目采用敏捷开发方法。
3. 在过程框架上采用了Scrum的主体框架，采用了诸如sprint planning meeting、backlog、每日早会、小版本成果发布会、小版本回顾和总结会议等等；
4. 宝信研发敏捷开发生命周期针对的是需求变化较多，传统的开发模型不能很好适应的情况，每一次敏捷开发结果应该是可以发布的，增量式的，与增量型生命周期的最大区别是，其需求整理和架构设计上无需花费大量的时间，所有的功能设计仅仅是够用就行，强调的是设计出来的功能正好满足需要，不要附带额外的、多余的功能；
5. 为了保证适应多变的需求，代码就必须进行经常性的重构；
6. 测试包括开发测试和用户测试。具体而言，对开发测试，可采用相关的单元测试工具，和持续集成测试环境进行保证。从部门项目中的实践，单元测试是必须的，持续集成测试可选做。对用户测试，主要包括：验收测试（Acceptance testing） 、可用性测试（Usability testing）、使用测试（Usage testing）。
7. 敏捷开发每个小版本的开发周期应在1个月内，建议为1个月。
8. 一般地，本生命周期模型流程如下：
1) 将整个产品的开发任务（Scrum中称为backlog，下同）分解成交付包（Sprint Backlog）,这个交付包（Sprint Backlog）是按照目前的人力物力条件可以完成的。
2) 召开敏捷交付版本启动会议（sprint planning meeting），划分，确定这个交付包中需要完成的需求和/或缺陷，标注各项需求或缺陷的优先级并分配给每个成员。
3) 进入敏捷交付版本开发周期，在这个周期内，每天需要召开每日早会。
4) 整个敏捷交付版本周期结束，召开敏捷交付版本成果发布会，将成果演示给产品经理等相关成员.
5) 团队成员最后召开小版本回顾和总结会议，总结问题和经验教训。
6) 这样周而复始，按照同样的步骤进行下一次敏捷交付版本。
9. 对于以上第2步，要求书写“交付包工作说明”，主要包括：
a. 主要处理的需求、缺陷的范围
b. 起止时间
c. 团队成员分工
d. 规模估算
e. 工作量估算
f. 记录变更
g. 设计
10. 对于设计，每个交付包都需开展设计，设计形式一般采用UML来表达，在交付包说明中包括设计或者包括对设计的引用（引用的设计文件必须是项目的配置项），设计需得到同行评审。如果某个交付是基于已有模块，设计不变，则说明参见何处的设计。
回顾
可以看到这《敏捷生命周期模型V1.0》并不完美，笔者本人曾经把它称为是个“重装敏捷”。
但引入敏捷生命周期这个改进提议处理全过程本身是敏捷的：
1， 看到业界新的方法，拥抱这个变化；
2， 从开始到后面的全过程，就注意沟通和交互，采用了快速会议，专题会议，email沟通等等多种手段；
3， 注意收集各方反馈，并能快速处理各方的反馈，对于各方出现的变化，能够快速响应；
4， 在任务分配方面，虽然不是全部都主动获取自己的任务，但经EPG Leader协调，参与各人都和谐的完成了工作。
以CMMI的角度看这个改进提议过程，它也符合CMMI的要求。从以上过程来说，基于CMMI建立的过程改进机制发挥了有效而且高效的作用。
敏捷优化改进过程
在敏捷生命周期1.0发布之后，在具体执行过程中，就出现了原有要求与新生命周期冲突的地方，这些冲突其实也意味改进机会。
需求管理的改进
根据CMMI中需求管理过程域的要求，要保持需求的可追溯性，宝信研发原来的做法是
1， 首先记录原始需求
2， 根据用例分析方法或SRS方法得到功能点，每个功能点根据编码规范得到唯一的编号，功能点进入工作项管理系统，并与原始需求关联
3， 设计文档中各个类需要说明对应的功能点编号
4， 在源代码里，要求代码中按照一定的格式说明相应的功能点编号
5， 在工作项管理系统中设计测试用例（不是单元测试，是界面功能测试），测试用例与功能点关联
6， 测试用例执行发现的测试缺陷自动与测试用例关联
在新的敏捷生命周期中，对功能点是不作强制要求的。没有功能点的敏捷类项目在上述流程下无法运作了，最突出的问题是测试用例无法与需求进行对应，测试室提出没法操作，无法开展测试；其次是迭代需求规模难以统计，给估算带来了麻烦，迭代的速度难以选择。
在2007年11月，这个问题被提了出来。
针对这个问题，EPG组进行了讨论，主要意见：
1， 关于设计中的功能点对应，多数项目组认为用处不大，不必再坚持；
2， 关于代码中的功能点对应，前期工作量不小，真正发挥作用的机会却是很小，在做功能点关联时更多想到的是为了应付规程要求，而不是为了未来的回溯；
3， 一致认为测试对于保证需求得到实现有重要作用。独立的测试工作值得保留，并应当追溯到需求；
4， 原始需求作为需求的第一手素材值得保留并跟踪。
5， 短迭代中可以运行的软件可以更好的帮助确认需求，敏捷需求的表达方式没有必要采用提取功能点的严谨方法，试行项目采用的用例方式是可行的，也没有必要严格遵循原用例规约的写法。
根据以上意见，我提了如下的方案：当前敏捷开发在Fitnesse的需求以功能点形式进入工作项管理系统，直接从Fitnesse已经有的需求描述拷贝到工作项管理系统, 不必再整理，并判断需求的大小类型，大小类型分为3个档，分别是5个功能点、10个功能点、15个功能点，原理参照了User Story Point，选择5、10、15，本质是1倍、2倍和3倍。这是根据了常见需求与功能点的比对，试图保持原有功能点度量的一致性。这样新需求对应的测试用例可以进入工作项管理系统；对应于原始需求，后续测试用例对应于需求；不再要求设计时对应需求，不再要求在代码中记录关联的需求。并且根据需求的大小类型，能够快速的计算迭代的总功能点数量。
张龙在我的方案上提出了改进方案：只把功能需求索引放到工作项管理系统中，并跟踪功能需求的变化，也可以对应测试用例；仍然在fitnesse中对功能需求进行描述，在工作项管理系统中加上链接到fitnesse相关页面。
经过讨论，大家一致认为张龙所提方案合适，采用了张龙所提方案。
回顾
在CMMI需求关联过程域中，指出要求关联需求的可追溯性，但CMMI文本中并没有具体到设计和代码应当如何跟踪与需求的追溯性。在瀑布型生命周期模型下，很自然的要求需求可追溯性在后续的瀑布型阶段---设计、编码、测试中都要建设，这符合瀑布型生命周期的假设逻辑，前期工作指导后期，由于可运行的产物要在后期较晚时才出现，所以前期就更要保证上下的正确性；就算出现变更，也可以回溯，发现关联部分，能够更快更全面的处理变更。
在敏捷开发环境下，着重迭代开发和反馈。在这样的背景下，保持对设计和代码的显式追溯更像是一种浪费，因为后续变更不可预知在何处发生，代码的复杂度也会提升，而设计在敏捷下变得更为概要，而设计和代码本身并不能校验需求是否准确。
而测试用例处理的是可运行的软件，指导测试用例设计的是需求，所以在敏捷中，也注意测试用例的追溯。有两个例子：1，有一种用户故事的写法要求在用户故事里写明如何测试用户故事；2，验收测试驱动开发，测试用例本身成为了需求的载体。
因此经过修改后的需求追溯性保持了这样的追溯链条：
工作项管理系统中原始需求---工作项管理系统需求的索引---测试用例---测试缺陷
|
Fitnesse中需求
需求的索引和内容在两处记录，虽然看上去费事，但在事后看来，还是个很棒的做法。工作项管理系统的长处是在于状态跟踪管理、查询和记录历史，短处是条目化管理的各个工作项难于贯彻上下文，Fitnesse的长处是富有表现力，上下文关联便利，便于阅读。两者组合运用后能各自发挥长处，给团队的需求管理带来方便。
敏捷开发适用到新开发类型的项目
在2009年初，在维护项目上的敏捷实践开展了近2年的时间后，基于自身在维护项目上的实践和业界的分享交流，我们开始探索在新开发项目上使用敏捷开发生命周期。
在开始就遇到了一个突出问题，新开发项目的项目经理提出：
在新项目实施敏捷生命周期时，需要有一个阶段进行整体需求的整理汇总和技术方案、架构的研究和确定，目前的敏捷生命周期不支持这个阶段（不出具体代码），希望增加这个阶段。
我将这个问题发到了部门的EPG组及利用Google Group组建的论坛（部门内绝大部分同事都加入了这个论坛），并给出了初步意见：
1，敏捷方法的要点在于可运行代码来得到验证和调整，可运行的代码是敏捷方法区别
于传统方法的最大特征。不出代码的交付包是难于称之为敏捷的交付
2，业界存在前期规划的做法，可以归为第0周期所做的事务
3，查看了我们的规程，其中对于第0周期有“开始需求建模，开始架构建模”的参考。
4，因此，提议新项目延长第0周期，来处理\"整体需求的整理汇总和技术方案、架构
的研究和确定\"
在后面的7天内，共有9位同事发表了22个帖子来讨论此事，参与同事包括了部门分管总监、2位室经理、多位EPG、QA成员，累计文字字数7000多字。讨论中发现焦点问题在于“敏捷中的架构如何来做?”。具体到项目实际开展而言，问题是第0周期的工期可以有多长？2周还是3个月？
对于敏捷中架构如何来做这个问题，讨论中虽然花费了大量的文字，租房子、建楼房等等都拿出来做比喻，但这种世界级难题岂是一个小小部门中的几位能够解决的，不仅不能解决，也难以达成共识。
也许这样的讨论发生在多个组织内，不妨把其中典型的观点罗列一下，给各位读者参考一下：
1. 需求可以归在第0周期里面。但是在第一交付包之前有一个整体技术方案和机构的设计还是很有必要的，尤其是对新项目，架构是驱动不出来的。这个阶段可以设置为可选。
2. 得\"想方设法\"让工作可以划分成更可测的、更短迭代周期。冗长的、难以检验的所谓架构设计阶段，味道会很不好。也许大家都来想想怎么让我们的工作更可测，要比想着怎么改敏捷规程更有趣一点 ;)
3. 一个方面是：我们能力并没有想象的足，我们仍需在实践中取得我们最佳的成果，不要空谈理论，做起来。另一个方面是：要具备必要的知识，尽量少走弯路，走一步，想两步，人无远虑必有近忧。建议采用“中庸之道”的平衡智慧。
4. 想还是要想的，如果不能想得很清楚，就先把现在清楚地东西做掉。举个切身例子：我刚来上海的时候租房子。因为爱人还没毕业工作尚未找，所以就租在了离地铁站比较近的三室一厅1200/月精装修，方便她以后上班；而放弃了杨家镇450/月的两室一厅毛坯。然而发现房主比较恶，爱人也不喜欢这房子，所以她来了后就搬走了。结果是：我自己住在“离地铁站比较近的三室一厅1200/月精装修”3个月。呵呵，就这样，这个事情告诉我：考虑爱人没问题；但既然说不清楚以后爱人在哪里工作，而知道自己要待3个月，就应该住的便宜些（我不太感冒享受并且当时银根相当紧），而且和大家比较近。房子三个月不满意可以换嘛。
5. 楼上\"自以为\"经验丰富，研究生毕业，一直在外地上学，已经搞到了老婆，对于租房一定有着丰富的经验啦 ;)
问题是环境发生了变化，但是楼上没有从用户需求出发来驱动他的租房行为。或者说他假想了一些他认为根据经验可能存在的需求（交通方便，方便上班），其实这些需求并不存在，因为\"爱人来了后就搬走了\"，如果在其他城市，也许这些并不会导致严重的后果，但是在上海这个初来乍到的地方，因为交通便利就意味了高额的房租，这个代价和其他二线城市，甚至是其他一线城市差比起来要相差很多，楼上的经验在此导致了不好的结果。
如果楼上从用户实际发生的需求出发，本着敏捷开发的思路，走小版本迭代的路线，在爱人没来之前，在节约成本，加强同事联系的需求驱动下，显然会选择杨家镇这块宝地（注：离宝信研发部最近的小区），等到爱人来了再根据新的需求换地方嘛 ;)
现在的租房市场也支持楼上的这种敏捷租房行为，因为没有房东会让你签1年的合同，附上半年的押金。这就是没有\"架构\"约束的好处 ;)
6. 从极限编程中体会到的是走极端的妙处，走极端让我的思考更加深入，换句话说，能够让我最后中庸的更好，没有极端就没有中庸（这句话是废话），必须从各个极端去正真体会一下，特别是在我们学习一样东西时。
7. 想延长第0周期到3个月的做法是典型的捣浆糊，也许算是中庸之道吧，如果能走走极端可能会有新发现。
8. 这不代表我们在进行整体的设计时（我避免使用架构这个词呵呵）可以全然不使劲。以造一个大型建筑为例，也许一开始提出一个可以确保成功的整体架构是不可捉摸的，但是分解来看，总可以确保地基是否牢靠、力学设计是否合理、墙是否撑得住梁、梁是否撑得住屋顶，每一个环节都应该是可以验证的，如果不能验证则需要进一步分解。所有的都验证没有问题，就形成了一个整体方案，还可以对已有方案进行改进，虽不能保证整体方案没有问题，但这个真的就是能力限制问题了。但是这其中的每一步，都是需要设计的。所以，这里就有一个度的问题，和一个规模的问题。也许产品本身就很小，本身就只是一面墙，那么造墙前需不需要整体考虑呢，是不是按照敏捷的思想就不需要设计了呢，流程可以管活，也可以管死，关键还是在人：）
9. 无论用什么方式，无论第0周期有多长，也无论是否有总体需求或总体架构设计阶段，只要最终按期圆满实现预定的目标，就是一个好的过程，不需要对每个过程做过多限制，就像张龙说的，最终目标就是拿出代码产品。项目经理有权决定产品开发的过程，至少可以做尝试。
10. 之所以敏捷过程似乎自由发挥的余地很大，完全是因为敏捷迭代被严格限制在一个很短的时间内，目前业界披露的最短迭代周期是一周，没有见到宣称超过2个月的迭代周期。在一个设定为4周的迭代周期内,\"无论用什么方式，也无论是否有总体需求或总体架构设计阶段，\",甚至无论到期交付的产物是否满足客户要求，在敏捷开发中都是可以被接受的。关键是要对这个交付的产物有客户/用户反馈，根据这个反馈来调整下一次的迭代。
最后我组织了EPG的专题讨论会。会议上并没有出现过多的争论，因为大家都已经看到没有特别妥当的方法，各方所持都有道理。新开发项目团队是在一线工作，碰到具体问题更加实际，而且从传统生命周期切换到敏捷生命周期，前期保留长达3个月的第0周期与传统生命周期的前期做法很是接近，让新项目开发团队感觉更加好一些。而且作为第一个新开发项目采用敏捷生命周期，本来就值得鼓励。
会上比较一致的同意：不在敏捷生命周期中新加一个阶段，允许新项目延长第0周期到3个月，作为试行。这样虽然没有直接同意新开发项目组的要求，但实际上变通的同意了。
会议上也给新开发项目组提出了问题：除开发计划之外，这第0周期的成果物还有哪些？为获得这些成果物，大致采用什么样的过程？ 希望新开发项目组能在第0周期的前期回答。
接下来的3个月，新开发项目组就按3个月的第0周期进行，在3个月结束时开发计划按照模板完成了，在产品框架决策方面做出了选择，其余成果物都没有成形可供展示，可以说是“熟悉了环境、培养了队伍”。再接下来这个项目组采用了一个月作为迭代周期，真正开始了新开发项目的敏捷生命周期。
年中，EPG汇同新开发项目组对3个月第0周期的试行作了小结：
1. 从第0周期3个月本身工作看，成果并不明显；
2. 从后续的工作看，第0周期为数不多的成果在后面被修改了多次；
3. 在架构是个难以看清的难题时，后续迭代的开展更快帮助了架构的推进；
最后的结论是以后不再允许安排长达3个月的第0周期。
后续新开发项目采用敏捷生命周期时，第0周期的长度就都选择在1个月以内。
关于架构的回顾
关于架构的重要性是不需要多说了，但不能因为架构的重要而一定要在前期安排一个长长的阶段来把架构搞清楚，主要有2个原因：
1. 不是每个团队都有一位资深的、足够水平的、前瞻性很好的架构师，换句话说，就算是安排了大量时间来做架构，也难以保证获得很好的架构；
2. 变化总是比计划快，一个是外在的变化，另一个就是内在的变化；外在的变化往往是外界需求变化、工期变化等；而内在的变化往往是团队自身认识的变化。而对于架构的改变，内在变化起得作用更大些。
关于在新开发项目中推进敏捷生命周期的回顾
在关于第0周期的讨论中，已经出现了不赞成3个月的安排，笔者本人也并不赞成安排3个月的第0周期，但并没有坚持，笔者当初最大的目的在与把敏捷生命周期扩展到新开发项目类型，为了达到这个目的，对敏捷生命周期进行了变通，在变通时，并没有按项目组所提出的“在敏捷生命周期前期加入一个可选阶段”，而是延长了第0周期，这样保持了敏捷生命周期的框架，为后面缩短第0周期也带来了方便。
整体项目计划和敏捷迭代规划的问题
文档化的项目开发计划是宝信公司根据ISO9000所强制要求的文档，项目开发计划是一份计划综合性文件，在项目前期完成，指导整个项目周期。宝信研发部在CMM、CMMI建设中，也同样重视项目开发计划，提供了项目开发计划的模板。敏捷软件开发宣言提出应当变化比遵循计划更重要，并非不要计划，如果没有计划，变化是难以拥抱的。所以宝信敏捷生命周期保留了项目开发计划。但在2009年初敏捷生命周期应用到新开发项目上后，马上就出现了原项目开发计划和敏捷迭代规划的冲突。
突出的问题有：
· 开发计划模板中有不少涉及MPP（MPP是指基于MS Project得到项目计划跟踪文件）
· 原开发计划模板中的时间表及相应安排是基于传统生命周期
· 交付包说明书与项目计划中的时间表存在重复和冲突
· 同行评审计划中，对于敏捷型的多次同行评审无法很好地计划
· 配置管理基线计划难以在开发计划中明确
· 关于最终交付产品，敏捷生命周期中没有描述
以上问题首先由项目经理和QA提出，很快到达了EPG。
EPG分析后发现，原开发计划要求得比较细致，讲究在项目前期计划时就能环环相扣。
受敏捷多级项目规划启发，EPG组很快拿出了方案将书面计划分成项目计划和敏捷交付包计划两级。把原项目计划模板中涉及的交付包一级的内容全部移除，主要修改如下：
1. 取消项目整体MPP的要求；
2. 不再在项目计划中安排同行评审；
3. 项目整体时间表只关注项目开始、版本发布和项目结题，不再关注具体里程碑；
4. 配置管理基线计划只关注发布基线和结题基线，不再关注其他基线；
5. 交付产品并不是由生命周期决定，而是实际项目决定，仍然保留在项目开发计划中
而在交付包计划一级，修改如下：
1， 对于新开发项目也不再要求MPP，细节任务不再要求提前计划，但要求在工作项管理系统中跟踪总工时；
2， 仍然要求在交付包前期完成交付包工作说明，并且在工作说明中需要确定“交付方式”，交付方式可选三者之一：1,进行Build测试（可以同时提交给用户试用）、2,用户试用、3,软件正式（release）发布
3， 根据选择的交付方式，沟通确定相应的测试安排和基线计划
4， 同行评审不再进行书面安排，项目组根据自身进度和分工来安排
经过这样的修改后，项目开发计划的要点主要是：
1， 确保各类资源，包括开发人员、测试人员、QA、专家、EPG，开发环境等
2， 关注最终交付物和交付时间
回顾
以上措施中，得到项目经理最多赞成的是取消了MPP的要求。以往MPP占用了项目经理大量的时间，为了保证一个长达6个月甚至更多的版本发布，MPP所带来的甘特图、里程碑、SPI（进度绩效指数）、CPI（成本绩效指数）等等是项目经理的好工具。在敏捷短迭代之下，其实MPP仍然是很棒的工具，但在刚刚好的原则下，就显得累赘。
以上的修改在2周的时间里处理完成，没有遇到阻力，笔者当时身为亲身处理者，倒也不觉得如何重要。现在回头看，这次的修改其实意义非常重大，把原来基于细节管控的管理方式改变为了基于目标管理的管理方式，赋予了团队更多的自主权。虽然之前在维护类项目上已经开展了多时，但维护类项目的分量是远远轻于开发类项目，维护类项目也不是公司项目管理照看的重点。以上的修改符合了敏捷所指出的两个原理：服务型领导和自组织团队。而当时2周之内的顺利改变也有赖于之前敏捷生命周期在维护类项目上所取得的实际效果，有赖于长期通达上下的良好沟通。
在敏捷生命周期进行到2009年末，规划方面另外一端的问题凸现出来，QA发现这样的问题：敏捷方法容易忽视了总体目标，敏捷方法每个迭代关注当时最优先的需要，
如果后续迭代的需要与原计划发生偏离时，可能过于看重当时需要，而忽视总体计划。
敏捷软件开发宣言提出“响应变化重于遵循计划”，在定制类软件（软件最终部署场所只有一处）开发时，响应当前用户带来的变化都是没有问题的，但在产品类软件（软件最终部署场所有很多处）开发时，就存在当前用户需要和未来用户需要的矛盾，而每个迭代的需求优先级排序时，当前用户需要很容易得到高优先级，从而忽视了未来用户需要，如果过于偏向当前用户需要，那么也损害产品类软件的整体利益。而宝信研发部是以产品化软件为导向的。所以在2009年度时这个问题比较明显的冒出了。
针对这个问题，EPG会议上进行了初步讨论，提议：对项目整体（包括所有小版本），比如：
1，release backlog的计划和跟踪， 2，跟踪全部小版本在一张表，比如小版本颗粒度的燃尽图
会后我进行了调研，设计了如下的2张表格，第一张是主要重点内容表，如下示例。
X轴是交付包数
我的解决方案虽然略微增加了工作量，但提供了一个产品化软件项目的整体视图，得到了各方认可，很快部署到了各个敏捷项目当中。从后面的运作看，在每个交付包结束和开始的时候，提醒各方就远期规划和近期需要做出判断，发挥了很好的作用。
拥抱变化的敏捷改进
以上举了3个比较突出的例子，实际上相关的敏捷改进还有很多。下表罗列下在宝信研发部实际收集到改进建议，方便起见只罗列了标题中含有“敏捷”两字的改进建议。
说明：以上是含有敏捷的改进建议，并非是最终采纳的，在标题中没有含有敏捷两字，与敏捷相关的改进建议数量比所列出的还要更多些。以上改进建议的时间跨度是2007年到2011年。
在这里列出试图来说明改进是没有终点的，结合自身实践发展，导入敏捷、保持敏捷、改进敏捷都是动态过程，只有持续改进才能真正的敏捷。
改进建议处理是来自于CMMI的做法，明显的好处有：
1， 聚焦问题，而不是回避问题
2， 有效的沟通各方
3， 聚集智慧，及时解决问题
4， 有效实践可以稳妥的得到推广
5， 珍惜每个改进机会，每个不同的意见和建议都会得到处理
6， 记录所有的改进历史，清晰地显示各项进步
整体回顾
前文在具体实践中都分别进行了回顾。这里简短做个整体性的回顾。
1， 2006年末，一个项目组尝试引入了XP中的几个实践。
2， 2007年2月底，启动了敏捷试行，在2007年3月22日，制定了《项目敏捷开发方法草案》。
3， 2007年7月23日， 起草得到《研发部敏捷生命周期模型V0.1》，在2007年9月27日发布了《敏捷生命周期模型V1.0》。
4， 2007年11月，修订需求管理方法，采用改造后的Use Case，功能点不再具有实体，成为需求规模度量的单位。
5， 2009年1月，开发类型项目开始采用《敏捷生命周期模型》，取消项目全周期MPP，基于细节管控的管理方式改变为了基于目标管理的管理方式，赋予了团队更多的自主权。
6， 2010年1月，启用交付包燃尽图，在产品开发中平衡长期利益和短期利益。
在整体上，宝信研发部的敏捷改进按照某些更纯粹的敏捷观点可能不算彻底，但是获得了成功。产品满意度指标、工期控制、缺陷数量等等自2007年后继续持续的改善，如下表所示。
2009年和2010年在业内软件生产力评比中都名列前茅，在2011年敏捷中国大会征集的敏捷成功案例中，宝信研发的两个案例入选。
从经验和教训的角度看，几点突出体会：
1. 按CMM/CMMI所形成的有效过程改进体系在敏捷导入、敏捷改进中能够发挥有力且有利的作用。
2. 组织有其历史，意识、思想是不会突变的，引入敏捷不能抛开传统软件工程留下的经验和财富，相反要在传统软件工程当中获得推进敏捷的支点，改变并不是能够很快发生，向着正确的方向，采取灵活妥协的措施，是可行的敏捷改进之道。
3. 通达上下的沟通在任何时候都是值得大力鼓励的。
原创作者：张克强
点击关注后，“点击了解更多”你能获取更多的知识哦
