敏捷开发指导书

软件公司敏捷项目操作手册（试行版）
目录
1迭代前准备 (4)
1.1一体化团队组建 (4)
1.2敏捷办公环境布置 (5)
1.3现状评估、计划制定 (5)
1.4项目启动会议 (6)
1.5Story输出 (6)
1.6Story评审 (6)
1.7Story估计 (7)
1.8建立持续集成环境 (7)
2迭代开发 (7)
2.1迭代计划会议 (7)
2.2单个story的完整开发 (8)
2.3story签收 (9)
2.4针对单个story的ST测试 (9)
2.5确保迭代周期内的需求稳定 (9)
2.6SDV测试 (10)
2.7Showcase（展示） (10)
2.8迭代的收尾工作 (10)
3SIT (10)
4其它敏捷实践介绍 (11)
4.1Unified Folder Structure (11)
4.2一体化团队 (11)
4.3简单设计 (11)
4.4状态墙 (11)
4.5每日（站立）例会 (11)
5敏捷试点待探索的问题 (12)
软件公司敏捷项目操作手册（试行版）缩略语清单
注：关于SDV、SIT无需往IPD上联想，仅是个名称而已。

重要提示：阅读本手册前请先对敏捷、XP、Scrum等知识有足够的了解，同时对公司现有CMMI体系有足够的了解。

公司对什么是敏捷已经有了很好的诠释：敏捷= 理念+ 实践+ 具体应用，首先强调的是理念，推出本操作手册的目的是希望能给大家一个参考，但决不是依照本手册僵化操作，大家在做每个活动的时候多思考为什么？要带着思考去实践，希望大家通过长期积累能够摸清软件开发的真正内在规律。

另外，随本文提供的模板仅供参考。

本文将敏捷项目分为三个阶段：迭代前准备、迭代开发、SIT。

每次迭代都会有SDV测试，项目后期会针对所有迭代做一次综合的测试，称为SIT。

1 迭代前准备
迭代前准备的活动包括：一体化团队组建、办公环境布置、现状评估、计划制定、项目启动会议、story输出、story评审、估计、持续集成环境准备等活动。

1.1 一体化团队组建
一体化团队成员：Product Owner（以下简称PO）、项目经理、开发人员、测试人员、资料人员、敏捷教练、CI Coordinator（以下简称CI-CO）。

PO：负责收集相关于产品的所有信息，从客户或产品的最终用户、开发团队成员、以及其他管理者中获取，并将这些信息转化为story，PO建议由SE担任，或由TL、项目骨干等担任，但前提是此人对业务（需求）必须清楚。

敏捷教练：由业软敏捷教练组成员担任（请参考《软件公司敏捷教练任命》发文）。

CI-CO：持续集成环境搭建、日常维护责任人，由开发人员兼任。

团队规模建议控制在7人左右，最多不超过12人，要打破我们原来的部门壁垒，建议开发人员、测试人员、资料人员统一由项目经理考评，PO的考评至少需要让项目经理作为考评相关人。

所有团队成员都必须对产品质量负责，为同一个目标而努力，希望大家在工作中密切配合、充分沟通和交流。

1.2 敏捷办公环境布置
1.2.1 Co-Location
Co-Location是敏捷的一个实践之一，就是一体化团队成员（大约7-12人）围坐在一个长方形办公桌一起工作，目的是便于大家的沟通和交流，能做到这样当然更好，但目前大部分办公现状无法改变，所以能够做的是保持现有办公布局不变，但要让一体化团队成员能够就近坐在一起，决不允许出现开发和测试不在同一楼层的情况。

1.2.2 白板
敏捷团队的项目进度、状态信息采用较直接的方式展示，称之为状态墙（或story墙），这也是敏捷的实践之一，此种方式大家普遍认为很有效，所以要求敏捷项目要准备两个白板（或直接使用贴在墙上的白纸取代），一个用于story墙，另一个用于日常沟通用、或者用于度量墙（较详细的story信息）。

1.3 现状评估、计划制定
项目启动时建议项目经理和敏捷教练一起对一体化团队的状况做一评估，包括：团队成员对敏捷的理解程度、技能、项目周期、规模、复杂度、准备采用哪些敏捷实践等。

根据评估的结果，建议此时要有一个较粗的整体计划，同时要对迭代前准备阶段的活动有一个详细计划，包括：对评估发现的问题尽早采取一些措施（例如培训）、story输出、配置库和持
续集成环境准备等。

1.4 项目启动会议
所有团队成员必须参加，类似于项目开工会，团队成员介绍、项目背景介绍、项目目标、大致的计划时间点，以及迭代前准备阶段的安排和任务分工等。

1.5 Story输出
User Story是敏捷开发和管理的核心，一定要保证story的输出质量，根据目前的公司现状，Story的记录要文档化，至少要保证团队成员都能理解、无偏差。

User Story输出责任人是PO，不建议由开发人员分工去写作story，如果实在无法避免，一定要由PO总体把握，并且端到端地去跟踪确认。

要在迭代1开始前把项目要完成的整体需求搞清楚，至少应将迭代1要实现的story正式输出，并符合质量要求。

关于story的概念及质量要求，有很多敏捷的资料可参考学习，但这里特别强调几点story的要求：
◆independent（独立性）
一定要保证Story是功能上独立的，尽量不要有story之间的信赖，否则会大大影响将来的开发和测试，曾经有敏捷试点项目由于story划分太细、依赖关系复杂而造成后期测试无法开展的情况。

◆estimatable(可估计的)
story将用于估计代码规模、story point。

◆small（user story大小合适）
关于story的粒度，建议的开发工作量是3-5天（含完成开发人员所负责的测试工作）。

◆testable（可测试的）
要从可测试性考虑需求，同时要考虑能够独立测试。

另外要注意，伴随story要同时输出可接受性测试用例（Acceptance Test Case，以下简称AT），用于验证story是否可以被测试人员做测试了。

PO将分析完成的Story放到Excel表单或敏捷项目管理工具中维护和更新，关于story 模板请参见《User Stories模板和E2E迭代计划模板.xls》，注意其中包含了AT测试用例。

1.6 Story评审
评审的形式不限，建议由非PO人员讲解，PO确保开发、测试和资料人员对该Story理解的正确性。

1.7 Story估计
参与人：一体化团队成员。

目标是制定出后面各次迭代的整体计划，包括：每个story 的优先级和工作量、要划分几次迭代、初步计划每次迭代要开发哪些story、每次迭代的开始结束时间和转测试时间点等。

按story商业价值进行排序得到优先级，最高价值的story 优先级排在前面，另外还可以考虑这几种因素：客户紧急程度、需求稳定性、依赖程度、对系统架构的影响，一般来说，客户急迫的、相对稳定的、依赖性强、影响系统架构的需求应该优先做。

迭代计划模板请参见《User Stories模板和E2E迭代计划模板.xls》。

关于估计方法，推荐使用story point方法，point的单位可以直接使用人天。

1.8 建立持续集成环境
包括建立配置库。

持续集成是最有价值的优秀实践，是敏捷开发的基础，要求持续集成环境必须在迭代开始前准备好，工具推荐使用ICP-CI。

2 迭代开发
迭代前准备工作完成后就正式进入迭代开发，一次迭代周期建议是2到4周，每次迭代后期要有单独的SDV测试，对每次迭代版本质量的要求是要能够达到版本发布的程度。

SDV 测试是针对本次迭代完成的所有story的整体测试，当然也会包括前次迭代的测试回归。

如果迭代周期已到，无论任务是否结束，也要求终止当前迭代，未完成任务放到下一次迭代再做。

每次迭代是以迭代计划会议开始的。

2.1 迭代计划会议
（1）重新讨论、确定本次迭代需要实现的Story，达成共同理解；
（2）若有必要的话，则继续细化Story；
（3）开发、测试、资料人员认领任务，估计工作量并做出承诺，这是敏捷SCRUM的重要实践之一：开发团队决定承诺完成工作量的多少，而不是由PO或项目经理安排工作量。

（4）共同制定当次迭代的开发计划。

要输出针对本次迭代的详细的开发计划，开发、测试、资料是以story为单位的，所以迭代开发计划也是以story为核心的。

计划中要包括本次迭代要开发的每个story的开发人员是谁（一对pair）？测试人员是谁（一名）？什么时候开始？什么结束？谁来review？等等。

迭代开发计划模板请参见《单次迭代开发计划模板.xls》
2.2 单个story的完整开发
单个story开发以story澄清会议开始，然后开发、测试、资料同时行动，各有各的职责分工。

2.2.1 story澄清会议
在每个story开发前建议都有这个story澄清会议，形式不限，PO和对应这个story的开发人员（一对pair）、测试人员（1名）、资料人员（1名）做一个沟通，大家要在这个story 的理解上达成一致，并且要思考如何测试这个story，这也体现了测试先行的理念。

测试项不需要象以前的测试用例那样详细，模板可参见《Story测试项模板.xls》，测试类型包括功能测试项（以下简称FT）和非功能测试项（以下简称NFT）。

另外还需要讨论这个Story 的设计，输出形式不限。

2.2.2 story功能代码开发—开发人员
TDD。

一对pair（两名开发人员）按TDD方式开发，先设计UT用例以及实现UT测试代码，再实现功能代码，然后不断优化重构，直到全部UT测试通过，关于结对编程、TDD 请参阅其它资料，本文不再赘述。

这里要特别强调的是大家在做TDD开发的同时要做好工具的检查工作，包括：代码规范性检查、PC-Lint或FindBugs检查、圈复杂度检查、重复代码检查、UT测试覆盖率分析等。

关于TDD。

这是敏捷的一个重要实践之一，这儿的T仅指UT，产品线目前的现状是UT 积累很少，所以进行敏捷试点的项目，刚开始先不管是测试在先还是在后，把UT先做起来，一点点去积累、一步步去摸索。

AT测试。

实现AT的测试代码，然后做相应的测试。

（关于AT，也许你的项目现在还无法实现测试自动化，那只有手工测试了。

）
代码Review。

不管是否采用了结对编程，现阶段建议你还是要安排代码review人员，包括测试代码也要安排review，以弥补结对编程的经验不足。

Review的方式不限，可以采
用交叉review的方式，但还是建议你要有一个人能够通读代码（建议PO），从整体上把握代码架构和质量。

本地构建。

构建前一定要将配置库的最新代码更新到本地，构建的方式建议在项目组统一使用脚本自动化实现，主要的活动包括：编译、链接、UT测试，只有所有UT用例（包括其她人的）测试通过才能将代码check in到配置库。

Check in到配置库的代码也包括测试代码、数据库脚本等，然后将会加入到持续集成环境中。

2.2.3 测试用例设计和测试代码开发—测试人员
测试的主要任务是设计FT和NFT测试用例，同时要开发自动化测试代码或测试脚本，代码和脚本要得到review，最后才能check in到配置库加入到持续集成环境中。

（关于FT、NFT，也许你的项目现在还无法实现测试自动化，此时的主要任务还是在设计和完善测试用例上。

但必须明确的是能否自动化测试是敏捷项目能否成功的关键因素之一）
2.2.4 资料开发—资料人员
进行资料写作，并得到PO、开发、测试以及资料人员的Review，最后check in到配置库加入到持续集成环境中。

注意资料的开发也是针对某特定story的。

2.3 story签收
Story开发完成后，转入ST测试前，需要进行签收，这是转ST测试的条件，签收的标准是AT是否通过，形式不限，开发人员可以将测试人员叫到自己的机器上直接运行AT即可。

2.4 针对单个story的ST测试
ST测试的主体在测试人员，是针对某个特定story的测试，包括FT、NFT，测试的前提条件是这个story的AT要能全部测试通过，否则测试人员可以拒绝接受测试。

对实现了测试自动化的项目这个阶段的工作量可能不会太多，但如果无法自动化，那只有手工进行测试了。

2.5 确保迭代周期内的需求稳定
每次迭代开发过程中PO的主要任务之一是为下一次迭代开发准备好story。

注意story 可能会随时更新，以反映客户需求的变化，但是，当前迭代正在开发的story一般不允许变更。

敏捷重要实践之一是：当开发团队确认承诺任务后，PO在此迭代期间不可以添加新的需求。

这就意味着即使在迭代的中途，PO想要添加新要求，他在下一次的迭代开始前不可
能作出任何变更的决定。

如果一个外部情况出现致使项目优先级的变化，意味着如果开发团队按原计划工作将会是浪费时间，PO此时可以提前结束本次迭代，意味着开发团队停止一切工作，重新开始迭代计划会议等等。

此种决断会产生很大的影响，除非在非常特别情况下，一般不要采用这种方式。

2.6 SDV测试
SDV测试的主体在测试人员，是针对当前迭代内所有story的完整测试（也会有针对前次迭代的回归），包括FT、NFT，当然测试的前提条件也是所有story的AT要能全部测试通过。

对实现了测试自动化的项目这个阶段的工作量可能不会太多，但如果无法自动化，那只有手工进行测试了。

测试结束后需要给出测试报告。

除非是向用户正式发布的版本要走正式的转测试电子流外，其它情况下转测试流程可以简化。

2.7 Showcase（展示）
目前对showcase有两种理解：（1）开发人员在开发过程中随时将完成的功能演示给PO、团队成员看，形式不限，可能只花15分钟，目的有两个，一方面可以听取大家的意见，另一方面让团队所有成员了解项目的进展；（2）在SDV阶段PO或测试人员将当前迭代内实现的功能向客户代表做一个全面演示，充分听取客户的反馈，对于客户反馈的问题可以选择在当前迭代周期内解决或遗留到下一次迭代（也许就是下一次迭代的需求）。

2.8 迭代的收尾工作
迭代评估及回顾会议。

对本次迭代做一个评估和总结，及时吸取经验教训。

迭代评估模板请参见《迭代评估报告模板.doc》。

RCA分析（可选）。

建议你将SDV测试发现的问题做一次RCA分析，分析方法和表单同以前。

还应该考虑RCA和遗留问题如何在后续迭代开发中改进和避免。

3 SIT
所有迭代结束后，建议你将历次迭代实现的所有story再做一次完整的测试，测试的主体在测试人员，包括FT、NFT，并要给出测试报告。

最后，项目经理需要输出项目关闭报告，并召开所有团队成员参加的关闭会议。

4 其它敏捷实践介绍
大家常常津津乐道的敏捷实践不再本文单独详述，本文只谈另外一些值得学习的实践。

4.1 Unified Folder Structure
项目组成员应将本地文件夹结构与配置库保持一致，本地构建的脚本要在项目组内统一。

另外，IDE环境也要保持统一，包括各类常用的工具和插件。

4.2 一体化团队
PO、开发、测试、资料要融合，但也要职责分明。

另外，每位成员不仅要了解自己的职责是什么，同时也要清楚其它团队成员的职责，只有这样大家才能有效地协同作战。

4.3 简单设计
简单设计并不代表就不做设计，也不是代表只做粗粒度设计、或简化设计，而是指只针对当前需求做设计。

设计的方式和输出形式可以不限，但一定要思考设计。

4.4 状态墙
状态墙的字段推荐（非强制，项目组可自行选择）：初始化/分析、等待开发、开发中、开发完成、SDV测试、缺陷修改、资料Review、完成。

状态墙的样式如下：
4.5 每日（站立）例会
这是在每个工作日特定的时间举行的短小（15分钟）的会议，开发团队的每一成员都将参与，通常可以选择在早上或者下午下班前进行。

为了保证其短小精悍，与会成员都保持站立（所以叫“站立会议”）。

以此提供给开发团队机会来汇报交流成果和阐述任何存在的障碍。

一个接一个，每个团队成员回答三个问题式的报告进展：从上次会议之后完成了哪些工作，在下次会议之前准备完成哪些工作，在工作进行中存在哪些障碍。

项目经理和敏捷教练将会把问题记录下来，在会后协助团队成员铲除障碍。

在每日的（站立）例会中不容许讨论，只是将以上三个重点信息做一汇报；如果需要讨论，将在会后进行。

PO、项目经理和其他利益相关人可以参加会议，但是他们应该在会议结束以前避免问问题或提出讨论，每一与会者应该清楚的是开发团队是在互相汇报和交流情况，并不是向PO、项目经理或敏捷教练汇报。

5 敏捷试点待探索的问题
1、分配需求（设计规格）与story的关系？能否用story直接取代原来的设计规格？
2、story应该由谁来做比较合适？PO、开发、测试、资料应该如何参与story输出？
3、如何依据story做估计？估计的方法？
4、测试需求分析是否有必要做？
原来的PTM有一个重要工程活动就是测试需求分析，对于敏捷项目是否要做？怎么做？
5、无法实现自动化测试的项目如何敏捷？
无法实现测试自动化是业软的一个普遍现状，大部分项目无法实现功能和非功能测试自动化（测试人员做的）、同样也存在开发人员做的UT很难做起来的现状。

无法进行自动化测试就会存在大量的手工回归测试工作量消耗，这样的情况下如何更好地敏捷呢？
6、TDD是否真的适合业软的现状？是否真的有效？
7、Pair是否真的适合业软的现状？是否真的有效？
8、在没有实施Pair的情况下如何才能更有效地Review？。