软件公司敏捷项目操作手册（试行版）
软件公司敏捷项目操作手册（试行版）
缩略语清单
缩写 | 英文全名 | 中文解释 |
PO | Product Owner | 产品所有者 |
CI-CO | CI Coordinator | 持续集成协调员 |
UT 康乐公 | Unit Test | 单元测试，开发人员做的 |
FT | Function Test | 功能测试，测试人员做的 |
拉美夫定NFT | Non Function Test 轲比能 | 非功能测试，测试人员做的 |
萧何怎么死的TDD | Test-Driven Development | 线条设计测试驱动开发 |
AT | Acceptance Test Ca | 可接受性测试，开发人员做的，用于story签收 |
ST | System Test | 系统测试，指的是测试人员对单个story的功能和非功能测试 |
1893年属相SDV | System Design Verification | 系统设计验证，指的是测试人员对单次迭代的功能和非功能测试 |
SIT | System Integration Test | 系统集成测试，指的是测试人员对所有迭代的综合测试 |
| | |
| | |
| | |
| | |
过家家儿歌注：关于SDV、SIT无需往IPD上联想，仅是个名称而已。
重要提示：阅读本手册前请先对敏捷、XP、Scrum等知识有足够的了解，同时对公司现有CMMI体系有足够的了解。公司对什么是敏捷已经有了很好的诠释：敏捷 = 理念 + 实践 + 具体应用，首先强调的是理念，推出本操作手册的目的是希望能给大家一个参考，但决不是依照本手册僵化操作，大家在做每个活动的时候多思考为什么？要带着思考去实践，希望大家通过长期积累能够摸清软件开发的真正内在规律。另外，随本文提供的模板仅供参考。
本文将敏捷项目分为三个阶段：迭代前准备、迭代开发、SIT。每次迭代都会有SDV测试，项目后期会针对所有迭代做一次综合的测试，称为SIT。
迭代前准备
迭代前准备的活动包括：一体化团队组建、办公环境布置、现状评估、计划制定、项目启动会议、story输出、story评审、估计、持续集成环境准备等活动。
一体化团队组建
一体化团队成员：Product Owner（以下简称PO）、项目经理、开发人员、测试人员、资料人员、敏捷教练、CI Coordinator（以下简称CI-CO）。
PO：负责收集相关于产品的所有信息，从客户或产品的最终用户、开发团队成员、以及其他管理者中获取，并将这些信息转化为story，PO建议由SE担任，或由TL、项目骨干等担任，但前提是此人对业务（需求）必须清楚。
敏捷教练：由业软敏捷教练组成员担任（请参考《软件公司敏捷教练任命》发文）。
CI-CO：英文字符持续集成环境搭建、日常维护责任人，由开发人员兼任。
团队规模建议控制在7人左右，最多不超过12人， 要打破我们原来的部门壁垒，建议开发人员、测试人员、资料人员统一由项目经理考评，PO的考评至少需要让项目经理作为考评相关人。所有团队成员都必须对产品质量负责，为同一个目标而努力，希望大家在工作中密切配合、充分沟通和交流。
敏捷办公环境布置
Co-Location
Co-Location是敏捷的一个实践之一，就是一体化团队成员（大约7-12人）围坐在一个长方形办公桌一起工作，目的是便于大家的沟通和交流，能做到这样当然更好，但目前大部分办公现状无法改变，所以能够做的是保持现有办公布局不变，但要让一体化团队成员能够就近坐在一起，决不允许出现开发和测试不在同一楼层的情况。
白板
敏捷团队的项目进度、状态信息采用较直接的方式展示，称之为状态墙（或story墙），这也是敏捷的实践之一，此种方式大家普遍认为很有效，所以要求敏捷项目要准备两个白板（或直接使用贴在墙上的白纸取代），一个用于story墙，另一个用于日常沟通用、或者用于度量墙（较详细的story信息）。
现状评估、计划制定
项目启动时建议项目经理和敏捷教练一起对一体化团队的状况做一评估，包括：团队成员对敏捷的理解程度、技能、项目周期、规模、复杂度、准备采用哪些敏捷实践等。根据评估的结果，建议此时要有一个较粗的整体计划，同时要对迭代前准备阶段的活动有一个详
细计划，包括：对评估发现的问题尽早采取一些措施（例如培训）、story输出、配置库和持续集成环境准备等。
