敏捷开发指导书

《敏捷开发指导书》由会员分享，可在线阅读，更多相关《敏捷开发指导书（14页珍藏版）》请在金锄头文库上搜索。

1、软件公司敏捷项目操作手册（试行版）目录1 迭代前准备 4.1.1一体化团队组建 4.1.2敏捷办公环境布置5.1.3现状评估、计划制定 5.1.4 项目启动会议 6.1.5 Story输出61.6 Story评审61.7 Story估计71.8 建立持续集成环境7.2 迭代开发7.2.1 迭代计划会议7.2.2单个story的完整开发82.3story签收92.4针对单个story的ST测试92.5 确保迭代周期内的需求稳定 9.2.6 SDV测试102.7 Showcase （展示）.102.8 迭代的收尾工作 1.03 SIT1.04 其它敏捷实践介绍 1.14.1 Unified Fol

2、der Structure 1.14.2 一体化团队1.14.3 简单设计 1.14.4 状态墙1.14.5 每日（站立）例会1.15 敏捷试点待探索的问题1.2软件公司敏捷项目操作手册（试行版）缩略语清单缩写英文全名中文解释POProduct Owner产品所有者CI-COCI Coord in ator持续集成协调员UTUn it Test单元测试，开发人员做的FTFun cti on Test功能测试，测试人员做的NFTNon Fun cti on Test非功能测试，测试人员做的TDDTest-Drive n Developme nt测试驱动开发ATAccepta nee Test C

3、ase可接受性测试，开发人员做的，用于story签收STSystem Test系统测试，指的是测试人员对单个story的功能和非功 能测试SDVSystem Desig n Verificati on系统设计验证，指的是测试人员对单次迭代的功能和非 功能测试SITSystem In tegrati on Test系统集成测试，指的是测试人员对所有迭代的综合测试注：关于SDV、SIT无需往IPD上联想，仅是个名称而已。重要提示 ：阅读本手册前请先对敏捷、XP、Scrum等知识有足够的了解，同时对 公司现有CMMI体系有足够的了解。公司对什么是敏捷已经有了很好的诠释：敏捷=理念 +实践+具体应用，

4、首先强调的是理念，推出本操作手册的目的是希望能给大家一个参 考，但决不是依照本手册僵化操作，大家在做每个活动的时候多思考为什么？要带着思考去 实践，希望大家通过长期积累能够摸清软件开发的真正内在规律。另外，随本文提供的模板 仅供参考。本文将敏捷项目分为三个阶段：迭代前准备、迭代开发、SIT。每次迭代都会有SDV测 试，项目后期会针对所有迭代做一次综合的测试，称为SIT。迭代堇准备迭代开发SIT1迭代前准备迭代前准备的活动包括：一体化团队组建、办公环境布置、现状评估、计划制定、项目启动会议、story输出、story评审、估计、持续集成环境准备等活动。11 一体化团队组建一体化团队成员：Prod

5、uct Owner （以下简称PO）、项目经理、开发人员、测试 人员、资料人员、敏捷教练、CI Coordinator（以下简称CI-CO）。PO：负责收集相关于产品的所有信息，从客户或产品的最终用户、开发团队成员、以 及其他管理者中获取，并将这些信息转化为story, P0建议由SE担任，或由TL、项目骨干 等担任，但前提是此人对业务（需求）必须清楚。敏捷教练：由业软敏捷教练组成员担任（请参考软件公司敏捷教练任命发文）。CI-CO：持续集成环境搭建、日常维护责任人，由开发人员兼任。团队规模建议控制在7人左右，最多不超过12人， 要打破我们原来的部门壁垒，建议 开发人员、测试人员、资料人员统一

6、由项目经理考评，PO的考评至少需要让项目经理作为 考评相关人。所有团队成员都必须对产品质量负责，为同一个目标而努力，希望大家在工作 中密切配合、充分沟通和交流。1.2 敏捷办公环境布置1.2.1 Co-LocationCo-Locatio n是敏捷的一个实践之一，就是一体化团队成员（大约7-12人）围坐在一 个长方形办公桌一起工作，目的是便于大家的沟通和交流，能做到这样当然更好，但目前大 部分办公现状无法改变，所以能够做的是保持现有办公布局不变，但要让一体化团队成员能 够就近坐在一起，决不允许出现开发和测试不在同一楼层的情况。1.2.2 白板敏捷团队的项目进度、状态信息采用较直接的方式展示，称

7、之为状态墙（或story墙）， 这也是敏捷的实践之一，此种方式大家普遍认为很有效，所以要求敏捷项目要准备两个白板 （或直接使用贴在墙上的白纸取代），一个用于sto ry墙，另一个用于日常沟通用、或者用 于度量墙（较详细的sto ry信息）。1.3 现状评估、计划制定项目启动时建议项目经理和敏捷教练一起对一体化团队的状况做一评估，包括：团队成 员对敏捷的理解程度、技能、项目周期、规模、复杂度、准备采用哪些敏捷实践等。根据评 估的结果，建议此时要有一个较粗的整体计划，同时要对迭代前准备阶段的活动有一个详细 计划，包括：对评估发现的问题尽早采取一些措施（例如培训）、story输出、配置库和持续集成环

8、境准备等。1.4 项目启动会议所有团队成员必须参加，类似于项目开工会，团队成员介绍、项目背景介绍、项目目标、 大致的计划时间点，以及迭代前准备阶段的安排和任务分工等。1.5 Story 输出Use r Story是敏捷开发和管理的核心，一定要保证sto ry的输出质量，根据目前的公司 现状，Story的记录要文档化，至少要保证团队成员都能理解、无偏差oUser Story输出责 任人是PO,不建议由开发人员分工去写作story,如果实在无法避免，一定要由PO总体把 握，并且端到端地去跟踪确认。要在迭代1开始前把项目要完成的整体需求搞清楚，至少应 将迭代1要实现的st ory正式输出，并符合质量

9、要求。关于sto ry的概念及质量要求，有很多 敏捷的资料可参考学习，但这里特别强调几点sto ry的要求： independent （独立性）一定要保证Sto ry是功能上独立的，尽量不要有st ory之间的信赖，否则会大大影响将 来的开发和测试，曾经有敏捷试点项目由于sto ry划分太细、依赖关系复杂而造成后期测试 无法开展的情况。 estimatable（可估计的）story将用于估计代码规模、story point。 small（user story 大小合适）关于story的粒度，建议的开发工作量是3-5天（含完成开发人员所负责的测试工作）。 testable （可测试的）要从可测试

10、性考虑需求，同时要考虑能够独立测试。另外要注意，伴随sto ry要同时输 出可接受性测试用例（Acceptance Test Case，以下简称AT）,用于验证story是否 可以被测试人员做测试了。PO将分析完成的Story放到Excel表单或敏捷项目管理工具中维护和更新，关于story 模板请参见User Stories模板和E2E迭代计划模板.xls，注意其中包含了 AT测试用 例。1.6 Story 评审评审的形式不限，建议由非P0人员讲解，P0确保开发、测试和资料人员对该Story理 解的正确性。1.7 Story 估计参与人：一体化团队成员。目标是制定出后面各次迭代的整体计划，包括

11、：每个story 的优先级和工作量、要划分几次迭代、初步计划每次迭代要开发哪些sto ry、每次迭代的开 始结束时间和转测试时间点等。按story商业价值进行排序得至U优先级，最高价值的sto ry 优先级排在前面，另外还可以考虑这几种因素：客户紧急程度、需求稳定性、依赖程度、对 系统架构的影响，一般来说，客户急迫的、相对稳定的、依赖性强、影响系统架构的需求应 该优先做。迭代计划模板请参见User Stories模板和E2E迭代计划模板xls。关于估计方法，推荐使用story point方法，point的单位可以直接使用人天。1.8 建立持续集成环境包括建立配置库。持续集成是最有价值的优秀实践

12、，是敏捷开发的基础，要求持续集成 环境必须在迭代开始前准备好，工具推荐使用ICP-CI。2 迭代开发迭代前准备工作完成后就正式进入迭代开发，一次迭代周期建议是2至 4周，每次迭代 后期要有单独的SDV测试，对每次迭代版本质量的要求是要能够达到版本发布的程度oSDV 测试是针对本次迭代完成的所有story的整体测试，当然也会包括前次迭代的测试回归。如 果迭代周期已至，无论任务是否结束，也要求终止当前迭代，未完成任务放至下一次迭代再 做。每次迭代是以迭代计划会议开始的。2.1 迭代计划会议(1) 重新讨论、确定本次迭代需要实现的Story,达成共同理解；(2) 若有必要的话，则继续细化Story；

13、(3) 开发、测试、资料人员认领任务，估计工作量并做出承诺，这是敏捷SCRUM的 重要实践之一：开发团队决定承诺完成工作量的多少，而不是由P0或项目经理安排工作量。（4）共同制定当次迭代的开发计划。要输出针对本次迭代的详细的开发计划，开发、 测试、资料是以sto ry为单位的，所以迭代开发计划也是以sto ry为核心的。计划中要包括 本次迭代要开发的每个st ory的开发人员是谁（一对pai r）?测试人员是谁（一名）？什么 时候开始？什么结束？谁来review？等等。迭代开发计划模板请参见单次迭代开发计划模板.xls22单个story的完整开发单个story开发以story澄清会议开始，然后

14、开发、测试、资料同时行动，各有各的职 责分工。2.2.1 story 澄清会议在每个story开发前建议都有这个story澄清会议，形式不限，P0和对应这个story的开 发人员（一对pair）、测试人员（1名）、资料人员（1名）做一个沟通，大家要在这个story 的理解上达成一致，并且要思考如何测试这个sto ry,这也体现了测试先行的理念。测试项 不需要象以前的测试用例那样详细，模板可参见Story测试项模板.xls，测试类型包括 功能测试项（以下简称FT）和非功能测试项（以下简称NFT）。另外还需要讨论这个Story 的设计，输出形式不限。2.2.2 story 功能代码开发开发人员TD

15、D。一对pair （两名开发人员）按TDD方式开发，先设计UT用例以及实现UT测试 代码，再实现功能代码，然后不断优化重构，直到全部UT测试通过，关于结对编程、TDD 请参阅其它资料，本文不再赘述。这里要特别强调的是大家在做TDD开发的同时要做好工 具的检查工作，包括：代码规范性检查、PC-Lint或FindBugs检查、圈复杂度检查、重复 代码检查、UT测试覆盖率分析等。关于TDD。这是敏捷的一个重要实践之一，这儿的T仅指UT,产品线目前的现状是UT 积累很少，所以进行敏捷试点的项目，刚开始先不管是测试在先还是在后，把UT先做起来， 一点点去积累、 步步 去摸索。AT测试。实现AT的测试代码，然后做相应的测试。（关于AT,也许你的项目现在还 无法实现测试自动化，那只有手工测试了。）代码Review。不管是否采用了结对编程，现阶段建议你还是要安排代码review人员， 包括测试代码也要安排review，以弥补结对编程的经验不足。Review的方式不限，可以采 用交叉r eview的方式，但还是建议你要有一个人能够通读代码（建议PO）,从整体上把握 代码