本次MiNi培训，从基础概念讲起，由PC机的硬件发展史到软件的发展史，引出当前的发展方向——敏捷。

贯彻始终的是敏捷宣言：个体和交互           胜过        过程和工具

可以工作的软件       胜过        面面俱到的文档

客户合作             胜过        合同谈判

响应变化             胜过        遵循计划

敏捷宣言的内容要理解。例如“可以工作的软件       胜过        面面俱到的文档”并不是说有了敏捷，就不要文档了。必要的文档还是需要的，只是我们不在需要面面俱到的文档，用做好的软件来说话。代码中的注释可以帮助开发和维护人员理解系统，软件界面可以帮助测试和客户深入了解系统的进展及功能。

敏捷的基本概念是需要了解的，这样才可以进行后面的敏捷实战，例如敏捷的原则、敏捷中常用的方法体系等。其中常用的方法体系有2个——XP和Scrum，XP可以通过“洋葱图”了解概况，Scrum中的3个“三”要深刻体会。

敏捷项目可分为三个阶段：迭代前准备、迭代开发、SIT（系统集成测试）。每个阶段包括的主要活动。根据敏捷的项目过程进行实战演练。

首先进行分组，将使用相同开发语言的人组织到一起，每组8人，由各组自己选出PL、SE、SWE、TE，培训老师作为用户和敏捷教练双重身份。分配好各自的角色后为自己的队伍起名、设计队徽和口号。然后每组的PL作为代表上台公布各自的结果。布置敏捷办公环境，准备白板、便签纸、燃尽图、状态墙。

进行Story培训，Story概念中重点是“对用户或客户有价值的功能点的简单描述”，在后面划分Story时需要严格按这个要求划分。Story的核心：三个“C”Card+Conversation+Confirmation。分析Story的典型步骤为：

识别用户角色—>分析业务场景/流程—>提取Story—>整理Story

根据分析出的Story，制作Story卡片，Story要遵守下面的写作标准：

INVEST，分别代表Independent、Negotiable、Valuable、Estimable、Small、Testable

Story卡片开始使用时要严格按照三段式进行描述：

作为…（角色）

我希望/想要…（功能）                                           

以便于…（目标）

用一个小游戏帮助大家找到Story估计的感觉，这个游戏结束后给大家的提示是：Story估计点要选取合适的对象作为工作点的单位，过大或是过小都会影响到其他Story工作量的估计点数。

在敏捷教练的指导下，各组组织分析用户需求，召开头脑风暴会议，根据大家的发言梳理出业务流程，划分出Story点，评估工作量，划分Story优先级及迭代次数。然后由SE及TE参与，将分析出的Story点整理，并填写到Story模板中。各组分享Story模板，由教练点评Story划分。

由讲师进行工程实践的讲解。对TDD，学员只是停留在了解概念层次，没有做过TDD的实践，本次培训后面的编码阶段，主要实施TDD和结对编程。TDD的目标：简洁可用的代码。对于代码重构，推荐书籍《重构-改善既有代码的设计》。重构的关键点之一：必须有一个可靠的自动化测试环境。关于统一开发环境，了解了CI的概念，并强调持续集成的纪律。

在管理实践的讲解中，涉及到可视化管理的基本概念，管理手段，包括状态墙、燃尽图、系统解剖图、敏捷项目管理工具等。其中敏捷系统管理工具推荐JIRA。我们公司只有部分项目使用到JIRA，只是用来进行缺陷跟踪，并未完全发挥JIRA的功效。JIRA在进行项目管理过程中，可以直接通过此工具将工作任务分解，细化到人，工作时间，这样正和Story的工作量可以对应，JIRA工具可以自动生成各种图形，类似于状态墙及燃尽图。JIRA的燃尽图不需要PO统计工作量后手动绘画，但是查看的时候需要进入工具。站立会议，站立会议不只是站着开会就可以称为“站立会议”，它需要组员自发的在规定时间规定地点，互相通告当前工作进展及问题。在站立会议中看不出谁在像谁汇报，或谁是会议组织者。站立会议建议10-15分钟，一般10分钟左右。Show Case。组内Session，可以制作卡片贴在白板上，卡片内容如下：

20分钟

   主题：SVN使用小技巧

分享人              提出人

敏捷度量，度量的内容可以分为2个角度，外部视角：质量（SDV缺陷密度，网上问题数量）、进度（Story开发进度）和效率（敏捷团队的生产效率）；内部视角：SVN提交规范、SVN提交频率、CI构建次数、CI构建成功率等。

介绍管理和工程实践后，开始进入迭代周期。召开站立会议，各自进行工作介绍及当前问题，时间不超过10分钟，然后各自分工合作，开发才用结对编程的方式进行TDD，先编写测试代码，根据测试代码调整功能代码，测试进行测试用例编写。同时每个Story有变化时及时更新状态墙。Story编码完成一个后，测试人员与开发人员一起检查是否符合签收条件，如满足签收条件，签收通过后就转入Story测试。Story测试过程中如发现bug，将对应的Story贴纸由“ST”状态贴到“开发中”状态。由开发修改后再进行签收。由于环境关系，未能搭建成功持续集成环境，这是本次培训的一个遗憾。

所有小组到指定的迭代周期结束时间点后停止工作，进入Show Case环节，各小组将本轮迭代的功能打包交给教练。每组派一名代表为客户进行演示，并负责解答客户及其他小组提出的问题。听取客户意见，为下次迭代做准备。

敏捷回顾会议，回顾会议的流程如下：

开场—>七嘴八舌—>问题洞察—>措施—>检测和改进—>缓冲时间

回顾会议可以在白板上划分4个区，分别标注在项目过程中的优点、遗憾、问题及疑惑、改进意见与建议。

最后召开回顾会议，由敏捷教练负责召集组员在白板前，划分4个区域，每个人都将自己的想法写在贴纸上，在满意区、遗憾做的不好的区域或是问题区域，或是改进区域贴出自己的想法。由教练带领组员共同将各区中的贴纸想法分类，然后征求组员的认可，得出本轮迭代做的好的方面和不好的方面。组员共同选出3条主要改进建议，在下轮迭代中开始持续跟进。

整个MiNi演习结束后进行笔试。在试卷中再一次巩固基础和深化自己在本次培训中的收获和体会。