敏捷开发指导书.docx

软件公司敏捷项目操作手册（试行版）
目录
迭代前准备 4..
一体化团队组建 4.
敏捷办公环境布置 5.
现状评估、计划制定 5.
项目启动会议 6.
Story输出 6
Story评审接使用贴在墙上的白纸取代），一个用于sto ry墙，另一个用于日常沟通用、或者用 于度量墙（较详细的sto ry信息）。
现状评估、计划制定
项目启动时建议项目经理和敏捷教练一起对一体化团队的状况做一评估，包括：团队成 员对敏捷的理解程度、技能、项目周期、规模、复杂度、准备采用哪些敏捷实践等。根据评 估的结果，建议此时要有一个较粗的整体计划，同时要对
迭代前准备阶段的活动有一个详细 计划，包括：对评估发现的问题尽早采取一些措施（例如培训）、story输出、配置库和持
续集成环境准备等。
项目启动会议
所有团队成员必须参加，类似于项目开工会，团队成员介绍、项目背景介绍、项目目标、 大致的计划时间点，以及迭代前准备阶段的安排和任务分工等。
Story 输出
Use r Story是敏捷开发和管理的核心，一定要保证sto ry的输出质量，根据目前的公司 现状，Story的记录要文档化，至少要保证团队成员都能理解、无偏差oUser Story输出责 任人是PO,不建议由开发人员分工去写作story,如果实在无法避免，一定要由PO总体把 握，并且端到端地去跟踪确认。要在迭代1开始前把项目要完成的整体需求搞清楚，至少应 将迭代1要实现的st ory正式输出，并符合质量要求。关于sto ry的概念及质量要求，有很多 敏捷的资料可参考学习，但这里特别强调几点sto ry的要求：
independent （独立性）
一定要保证Sto ry是功能上独立的，尽量不要有st ory之间的信赖，否则会大大影响将 来的开发和测试，曾经有敏捷试点项目由于sto ry划分太细、依赖关系复杂而造成后期测试 无法开展的情况。
estimatable（可估计的）
story将用于估计代码规模、story point。
small（user story 大小合适）
关于story的粒度，建议的开发工作量是3-5天（含完成开发人员所负责的测试工作）。
testable （可测试的）
要从可测试性考虑需求，同时要考虑能够独立测试。另外要注意，伴随sto ry要同时输 出可接受性测试用例（Acceptance Test Case，以下简称AT）,用于验证story是否 可以被测试人员做测试了。
PO将分析完成的Story放到Excel表单或敏捷项目管理工具中维护和更新，关于story
模板请参见《User 》，注意其中包含了 AT测试用 例。
Story 评审
评审的形式不限，建议由非P0人员讲解，P0确保开发、测试和资料人员对该Story理 解的正确性。
Story 估计
参与人：一体化团队成员。目标是制定出后面各次迭代的整体计划，包括：每个story 的优先级和工作量、要划分几次迭代、初步计划每次迭代要开发哪些sto ry、每次迭代的开 始结束时间和转测试时间点等。按story商业价值进行排序得至U优先级，最高价值的sto ry 优先级排在前面，另外还可以考虑这几种因素：客户紧急程度、需求稳定性、依赖程度、对 系统架构的影响，一般来说，客户急迫的、相对稳定的、依赖性强、影响系统架构的需求应 该优先做。
迭代计划模板请参见《User Stories模板和E2E迭代计划模板・xls》。
关于估计方法，推荐使用story point方法，point的单位可以直接使用人天。
建立持续集成环境
包括建立配置库。持续集成是最有价值的优秀实践，是敏捷开发的基础，要求持续集成 环境必须在迭代开始前准备好，工具推荐使用ICP-CI。
2 迭代开发
迭代前准备工作完成后就正式进入迭代开发，一次迭代周期建议是2至 4周，每次迭代 后期要有单独的SDV测试，对每次迭代版本质量的要求是要能够达到版本发布的程度oSDV 测试是针对本次迭代完成的所有story的整体测试，当然也会包括前次迭代的测试回归。如 果迭代周期已至，无论任务是否结束，也要求终止当前迭代，未完成任务放至下一次迭代再 做。每次迭代是以迭代计划会议开始的。
迭代计划会议
重新讨论、确定本次迭代需要实现的Story,达成共同理解；
若有必要的话，则继续细化Story；
开发、测试、资料人员认领任务，估计工作量并做出承诺，这是敏捷SCRUM的 重要实践之一：开发团队决定承诺完成工作量的多少，而不是由P0或项目经理安排工作量。
（4）共同制定当次迭代的开发计划。要输出针对本