敏捷工程流程
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
敏捷迭代前准备的活动包括：
概念和架构设计
规模估计
一体化团队组建
办公环境准备
现状评估
计划的制定
项目启动会议
持续化集成环境准备
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
敏捷迭代前的准备工作
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
一体化团队建设
一体化团队成员包含：Product Owner（以下简称PO）、敏捷教练、项目PL、开发人员、测试人员、资料人员、CI Coordinator（以下简称CI-CO）、配置管理员（以下简称CMO）。
PO：负责收集相关于产品的所有信息，从客户或产品的最终用户、开发团队成员、以及其他利益相关人中获取，并将这些信息转化为User Story，并进行优先级排序。PO一般由SE担任，或由TL、项目骨干等担任，但前提是此人对业务（需求）必须清楚。
敏捷教练：一个敏捷教练可以帮助团队或个人采用和提升敏捷方法和实践，同时帮助人们重新思考和改变他们以往的开发方式。一般要求和团队其它成员一起办公，作为团队成员之一，主要任务是保证团队遵循敏捷开发过程和规则。
项目PL： 负责项目的具体管理工作，协调项目组内部的沟通和交流。
CI-CO：持续集成协调员，有时也称为CIO,负责持续集成环境搭建、日常维护，一般由开发人员或测试人员兼任。
CMO：配置管理员，负责项目配置库的建立和维护，如果没有专人一般由PL兼任。
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
办公环境准备
安排一体化团队成员围坐在一起工作，目的是便于大家的沟通和交流；如果办公环境不能满足，也需要让一体化团队成员尽可能的靠近，尤其不要出现开发和测试不在同一楼层的情况。合理布置项目状态墙和开晨会的位置。
现状评估、计划制定
项目启动时建议项目PL和敏捷教练一起对一体化团队的状况做一评估，包括：团队成员对敏捷的理解程度、技能、项目周期、规模、复杂度、准备采用哪些敏捷实践等。根据评估的结果，输出一个较粗的E2E迭代计划（迭代前准备阶段后期，和每次迭代结束后，都可细化或调整该计划）。同时要对迭代前准备阶段的活动有一个详细计划，包括：对评估发现的问题尽早采取一些措施（例如培训）、Story分析、配置库和持续集成环境准备等。
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
项目启动会议
所有团队成员参加，类似于项目开工会，团队成员介绍、项目背景介绍、项目目标、大致的计划时间点，以及迭代前准备阶段的安排和任务分工等。
建立持续集成环境
项目PL指定项目组的CI-CO人员，协调CMO创建项目文件夹，并初始化配置库；CI-CO要负责搭建持续集成环境。持续集成是最有价值的优秀实践，是敏捷开发的基础，要求持续集成环境必须在迭代开始前准备好，工具推荐使用ICP-CI。
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
1、Story划分
User Story是敏捷开发和管理的核心，要确保Story的输出质量。Story划分这里强调几点要求：
独立性：一定要保证Story在功能上的独立，尽量不要有Story之间的依赖，否则会大大影响将来的开发和测试。
可测试性：要从可测试性考虑需求，同时要考虑能够独立测试。另外注意，伴随Story要同时输出可接受性测试用例（Acceptance Test Case，以下简称AT），用于验证Story是否开发完成，可以给测试人员做Story测试。AT用例在Story协作阶段只是对测试要点、场景的描述，在迭代开发阶段可以继续补充和完善。
可估计行：Story将用于估计代码规模。
大小合适：关于Story的粒度，建议的开发工作量是3-5天（包含针对Story所做的开发者自测工作量）。
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
系统分析
Story输出要点Top3：
Story Card中必须列出该Story涉及到的模块；
如果Story不能拆分到3-5天的开发粒度，则一定要确保该Story在一个迭代周期内可开发测试完成。
每个Story Card要有估计信息，本次估计结果用来制定E2E迭代计划；估计本来就有误差，因此在本次估计上不要话费过多的精力，一般采用专家估计法，PM、SE、项目PL达成一致即可。
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
2、迭代计划会议
重新讨论、确定本次迭代需要实现的Story，达成共同理解；
若有必要的话，则继续细化Story；
对Story进行优先级排序；
开发、测试、资料人员认领任务，估计工作量并做出承诺，这是敏捷的重要实践之一：开发团队决定承诺完成工作量的多少，而不是由SE或项目PL安排工作量。
共同制定本次迭代的迭代开发计划。要输出针对本次迭代的详细的开发计划，开发、测试、资料是以Story为单位的，所以迭代开发计划也是以Story为核心的。计划中要包括本次迭代要开发的每个Story的开发人员是谁？测试人员是谁？什么时候开始？什么结束？谁来Review？等等。
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
优秀实践：
明确任务责任人（包括开发、测试、资料）和任务完成时间点；
任务和问题都可作为跟踪项进行跟踪；
计划中根据Story优先级和依赖关系，严格按Story驱动制定计划，尽量减少Story并行开发；
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
在迭代开始后，通常以一个一个Story分别完成开发的。先由SE给Story开发人员、测试人员以及资料人员进行需求串讲工作，详细介绍Story的业务实现和功能要求。
开发、测试、资料人员以头脑风暴的形式一起讨论，SE和对应这个Story的开发人员、测试人员、资料人员要在这个Story的理解上达成一致，大体的实现方案，并且要思考如何测试这个Story，这也体现了测试先行的理念。
开发人员根据讨论的结果形成Story设计文档，并根据设计文档给SE进行反串讲工作，得到SE确认通过后才可以开始编码。
Story设计
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
Story设计完成标准：
各个模块的接口确认清楚 ；
简单设计方案通过评审；
补充和更新AT用例 ；
测试用例方案通过评审；
如在Story测试阶段需要做性能测试，则在测试方案中要明确说明；
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
功能代码实现：开发人员开始实现功能代码，做好UT，并及时重构。有条件的可以按TDD方式开发。这里要特别强调的是开发人员要做好工具的检查工作，包括：代码规范性检查、PC-Lint或FindBugs检查、圈复杂度检查、重复代码检查、UT测试覆盖率分析等。
本地构建：构建前一定要将配置库的最新代码更新到本地，构建的方式建议在项目组统一使用脚本自动化实现，主要的活动包括：编译、链接、UT测试，只有所有UT用例（包括其他人的）测试通过才能将代码check in到配置库。Check in到配置库的代码也包括测试代码、数据库脚本等，然后将会加入到持续集成环境中。
代码Review：不管是否采用了结对编程，现阶段建议还是要安排代码Review人员，包括测试代码也要安排Review，以弥补结对编程的经验不足。Review的方式不限，可以采用交叉Review的方式，但至少要有一个人能够通读代码（建议MDE），从整体上把握代码架构和质量。
AT测试：编写AT用例，然后做相应的测试。对于能自动化的功能，则建议测试和开发一起实现自动化
Story编码
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
开发完成标准：
通过代码review、完成静态检查和编译 ；
完成单元测试和模块级测试，并集成到CI系统中；
通过AT用例验证，并把补充的用例记录到Story设计文档中；
如测试有自动化用例，则要执行自动化用例，并解决发现的问题才能进行签收。
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
测试的主要任务是设计功能用例和非功能测试用例，同时要开发自动化测试代码或测试脚本，代码和脚本必须要进行Review，并应该要调测通过能够运行，最后才能check in到配置库加入到持续集成环境中。
用例设计前可能需要考虑必要的测试策略和测试方案。
（关于功能用例和非功能用例，也许项目现在还无法实现测试自动化，此时的主要任务还是在设计和完善测试用例上。但必须明确的是能否自动化测试是敏捷项目能否成功的关键因素之一。）
测试用例设计和测试脚本开发
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
资料开发可能会分成两类：
一类是针对单个Story的资料写作，它需要伴随Story开发同步提交，如果可能也要加入到持续集成环境中；
另一类是无法随Story同步提交的端到端资料开发，此类任务需要在迭代前准备阶段明确并体现在E2E迭代计划中。
输出的资料必须得到SE、开发、测试以及资料人员的Review。
资料开发
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
Story演示
在开发人员完成Story后，转测试签收前，由开发责任人组织开发人员、测试、资料、PO等人员进行Story演示，特别是有界面的Story，演示一些基本功能，并收集相关人的意见，相关人对界面以及相关功能的操作达成一致，如有问题，则要把相关问题修改后才能进行Story签收。
Story验收
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
经验建议：
对于界面较多的Story，建议基本功能开发完后尽快进行，避免所有测试都做完了，到演示是发现问题，导致返工；
Story演示中发现的问题，如有新增测试用例，则要补充测试用例；
Story演示中发现的问题，问题解决后要和提出问题人确认修改是否正确，问题闭环；
每次Story演示需要有演示记录，把发现的问题发给SE/项目PL以及相关人；
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
Story签收
每个Story开发完成后，转入Story测试前，需要进行Story签收，这是转Story测试的条件，Story签收的标准是AT是否通过，形式不限。建议开发认为可以转Story签收，则由测试单独执行该Story的AT用例，所有AT用例通过，则完成签收，进入Story测试阶段，否则打回给开发人员继续开发。
为规范化签收，应该通过邮件的方式进行，开发自测完成，并且Story演示通过后，SWE发邮件给TE通知对Story签收。邮件内容参考如下，主送TE，抄送给项目PL、SE以及Story相关人；TE收到邮件后，如签收通过，则回复签收通过邮件，否则回复签收不通过邮件。
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
Story签收前检查点：
开发人员是否完成了自测工作；
该Story 演示是否已经完成；（不需要演示的需要和SE达成一致）；
该Story所有的问题，包括Story演示的问题是否已经解决。
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
Story Test简称ST。ST测试的主体在测试人员，是针对某个特定Story所进行的测试，包括功能测试、非功能测试。测试的前提条件是这个Story的AT用例要能全部测试通过，否则测试人员可以拒绝接受测试。对实现了测试自动化的项目，这个阶段的工作量可能不会太多，但如果无法自动化，那只有手工进行测试。
Story测试
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
Story测试重点：
主要聚焦于单个Story的功能测试，通过该测试，要保证Story功能没有问题；
如该Story有明确的性能测试要求，再Story测试时也需要做性能测试；
建议该阶段发现的问题提缺陷电子流进行跟踪，或者测试和开发约定问题单的跟踪方式。
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
迭代SDV是针对当前迭代内所有Story的完整测试（也会有针对前次迭代问题修改的回归），包括功能的、非功能的。SDV测试的主体是测试人员，项目也可能根据实际情况调整人员一起完成本迭代的SDV测试。SDV测试在Story测试（ST）的基础上，增加针对Story之间的依赖相关的用例和测试代码，当然测试的前提条件也是所有Story的AT和ST要能全部测试通过。对实现了测试自动化的项目这个阶段的工作量可能不会太多，但如果无法自动化，那只有手工进行测试了。测试结束后需要给出测试报告。
迭代SDV测试
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
SDV测试重点：
由迭代开发团队中的测试人员完成，是迭代收尾时进行的系统级别的测试，主要关注特性的用户场景(DR，Story与Story之间的交互与依赖）测试，通过该测试，需要保证迭代交付特性的可用及该特性的相关资料可用；并可根据实际情况，安排部分非功能质量属性的测试（如压力测试、性能测试、可靠性测试等），降低产品风险；
迭代SDV阶段的问题建议使用缺陷电子流记录跟踪；
建议资料也在该阶段进行测试；
要增加必要的性能测试。
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
注意：确保迭代周期内的需求稳定
每次迭代开发过程中，SE的主要任务之一是为下一次迭代开发准备好Story。Story可能会随时更新，以反映客户需求的变化，但是，当前迭代正在开发的Story一般不允许变更。敏捷重要实践之一是：当开发团队确认承诺任务后，SE在此迭代期间不可以添加新的需求。这就意味着在某次迭代的中途，SE不能添加新要求到本迭代中，只能调整后续迭代所要开发的需求。如果一个外部情况出现致使项目优先级的变化，必须对现在正在做的工作进行重大调整，意味着如果开发团队按原计划工作将会是浪费时间，SE此时可以提前结束本次迭代，意味着开发团队停止当前的一切工作，重新开始迭代计划会议等等。此种决断会产生很大的影响，除非在非常特别情况下，一般不要采用这种方式。
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
在迭代的SDV阶段SE或TSE将当前迭代内实现的功能向客户代表做一个全面演示，充分听取客户的反馈，对于客户反馈的问题可以选择在当前迭代周期内解决或遗留到下一次迭代（也许就是下一次迭代的需求）。
Show Case
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
迭代评估会议。
对本次迭代做一个评估和总结，及时吸取经验教训，同时增强团队信心和提高团队效率。
迭代回顾会议。
通常是在迭代结束时侯，召集项目团队成员，每人发不同颜色的几种便签纸（比如红、黄、绿），分别独立写下本次迭代做得好的，存在的问题，改进的建议，然后归类汇总每个人的意见，通过全体成员投票选择最需要下个迭代改进的几个点，并在下个迭代中落实，从而达到改进的目的。
同传统的迭代总结不一样，迭代回顾会议更多的是全体成员都参与发表自己的看法，寻找改进，而传统的阶段总结会议更象是一个总结报告会。
RCA根因分析（可选）。
建议将SDV测试发现的问题做一次RCA分析，还应该考虑RCA和遗留问题如何在后续迭代开发中改进和避免。
迭代的收尾工作
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
迭代结束后，在正式对外发布前，建议将历次迭代实现的所有Story再做一次测试，测试的主体在测试人员，包括功能、非功能，并要给出测试报告。这个活动就称为SIT或发布测试。如果Story 测试、迭代SDV测试都自动化了，则本次测试主要是执行自动化用例、如前面有测试不充分，则补充测试，以及详细性能测试。如果用例自动化程度不高，则本次测试会刷选部分用来进行测试。测试结束后需要给出测试报告。
SIT测试
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
SIT测试重点：
所有迭代开发完成后，由迭代开发团队中的测试人员完成对全系统进行回归测试，达到TR4A的质量标准。
遗留问题要满足TR5的DI目标。
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
每日站立会议(晨会)
这是在每个工作日特定的时间举行的短小（15分钟）的会议，开发团队的每一成员都将参与，通常可以选择在早上或者下午下班前进行。
为了保证其短小精悍，与会成员都保持站立（所以叫“站立会议”）。以此提供给开发团队机会来汇报交流成果和阐述任何存在的障碍。
每个团队成员回答三个问题式的报告进展：(1)从上次会议之后完成了哪些工作;(2)在下次会议之前准备完成哪些工作(3)在工作进行中存在哪些障碍。项目PL和敏捷教练将会把问题记录下来，在会后协助团队成员铲除障碍。在每日的（站立）例会中不容许讨论，只是将以上三个重点信息做一汇报；如果需要讨论，将在会后进行。SE、项目PL和其他利益相关人可以参加会议，但是他们应该在会议结束以前避免问问题或提出讨论，每一与会者应该清楚的是开发团队是在互相汇报和交流情况，并不是向PO、项目PL或敏捷教练汇报。
统一文件夹结构
项目组成员应将本地文件夹结构与配置库保持一致，本地构建的脚本要在项目组内统一。另外，IDE环境也要保持统一，包括各类常用的工具和插件，版本号也要一致。
敏捷其他实践
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
可视化的关键点：
物理实体：可视化一定要做到物理上的实体化，大家在公开场所都容易看到，触摸到；
内容精简，易懂：信息展示一目了然，切实对团队有帮助，切忌贪多求全，难以分辨；
实时刷新：延迟的信息拖延问题暴露，降低运作效率 。
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
*
可视化管理
可视化管理可以清晰、简单和有效的组织和展示工作状况，可视化管理的目的不仅仅是为了“可视化”，更重要的是利用这样的一种方法，打造一种精益式的、Just in time方式的软件开发环境和系统。可视化管理的方式目前有很多种：Story Wall(状态墙)、Burn Down Chart燃尽图、项目组计划墙、特性墙等等。
建议项目组准备1-2个白板、Story卡片等用于可视化展示用，通常至少要展示出Story状态墙。
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
The End
*
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
2010 海辉软件（国际）集团公司 版权所有 （机密文件）
