敏捷mini培训总结

培训总结
本次MiNi培训，从敏捷理念和基础概念讲起，由软件的发展史，引出当前的发展方向——敏捷。贯彻始终的是敏捷宣言：
个体和交互          胜过       过程和工具
可以工作的软件      胜过       面面俱到的文档
客户合作            胜过       合同谈判
响应变化            胜过       遵循计划

本次培训收获：
作为新员工，首次接触敏捷，对敏捷宣言和敏捷理念触动很大。敏捷宣言和基本概念不能停留在字面意思上，需要深入理解。例如“可以工作的软件胜过面面俱到的文档”并不是说有了敏捷，就不要文档了。必要的文档还是需要的，只是我们不再需要面面俱到的文档，用做好的软件来说话。代码中的注释可以帮助开发和维护人员理解系统，软件界面可以帮助测试和客户深入了解系统的进展及功能。
了解项目级敏捷开发的流程。敏捷项目大致可分为三个阶段：迭代前准备、迭代开发、SIT（系统集成测试）。每个阶段包括一些主要敏捷活动。工作中我是SWE身份，在项目级敏捷开发流程的主要活动中收获最大的是团队的组建、Story概述、估计和澄清、迭代、回顾会议和敏捷实践。
组建团队：首先随机分组，每组5人，由各组自己选出PL、SE、SWE、TE和TSE，培训老师作为用户和敏捷教练双重身份。分配好各自的角色后为自己的队伍起名、设计队徽和口号。然后每组的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划分。
迭代：首先召开站立会议，各自进行工作介绍及当前问题，时间不超过10分钟，然后各自分工合作，开发才用结对编程的方式编程，测试进行测试用例编写。同时每个Story有变化时及时更新状态墙。Story编码完成一个后，测试人员与开发人员一起检查是否符合签收条件，如满足签收条件，签收通过后就转入Story测试。Story测试过程中如发现bug，将对应的Story贴纸由“ST”状态贴到“开发中”状态。由开发修改后再进行签收。由于环境和小组成员没有经验的关系，未能搭建成功持续集成环境，这是本次培训的一个遗憾。
敏捷实践：所有小组到指定的迭代周期结束时间点后停止工作，进入Show Case环节，各小组将两轮迭代的功能打包交给教练。各组交叉验收，每组派一名代表为客户进行演示，并负责解答客户及其他小组提出的问题。听取客户意见，为下次迭代做准备。敏捷时间贯穿整个培训全程，从课程中的小实践，到拉通全程的“大富翁”游戏。
回顾回忆：回顾会议的流程如下：
开场->各抒己见->问题洞察->措施->检测和改进->缓冲时间
回顾会议可以在白板上划分4个区，分别标注在项目过程中的优点、问题和待改进的地方、改进措施和建议。每个人都将自己的想法写在贴纸上，贴在对应的区域。组员一起讨论，得出本轮迭代做的好的方面和不好的方面。组员共同选出3条主要改进建议，在下轮迭代中开始持续跟进。教练负责评阅。
整个MiNi演习结束后进行笔试。在试卷中再一次巩固基础和深化自己在本次培训中的收获和体会。
持续集成、敏捷度量、LLT测试、TDD和敏捷测试等培训课程和敏捷的一些可视化辅助、站立会议、开工会和关闭会议等也让我印象深刻。

对敏捷的认识：
敏捷关键的因素在人。敏捷宣言中的第一条和第三条都聚焦在人身上，就我个人感受，完整团队在敏捷中至关重要。
敏捷需要做到理念与实践并重。在敏捷的初级阶段需要通过实践来摸索积累经验，会遇到不可预见的困难，如果敏捷理念没有深入人心，这个阶段是很难坚持下去的。
交付刚刚好的软件。刚刚好既保证了软件体现用户价值，又减少了开发浪费，是比较好的一种权衡。
随时有稳定软件版本供客户使用。这个能增强团队自信，也能让客户信任开发团队，提高客户满意度和团队战斗力。
敏捷欢迎改变需求。到了开发后期，敏捷也欢迎改变需求，这点虽然我也理解，但是落实起来是相当的困难，让人困惑。

培训过程中小组和个人的成功、不足及如何改进：
团队是一个整体。SE、SWE、TE和TSE及时有效沟通，有共同的目标。最终开发出了参加培训中四个小组中验收发现问题最少的“大富翁”。
在培训中，我学到敏捷不少理论只是，同时积极主动参与团队协作，与团队一起完成共同任务。
没能做到基于TDD开发、LLT测试做的不到位、持续集成也欠缺。团队没有完全熔炼到一起。个人来讲，以前没接触过敏捷，也少有开发经验，在学习理论和实践中遇到不少困难，解决的也不到位，只有留到后续在工作中慢慢体会与回顾。

在实际项目中如何应用敏捷：
帮助项目团队形成敏捷理念
按照项目级敏捷开发流程开发产品。
借助敏捷中的一些优秀实践和主要活动，指导开发。
团队中的各个部门、部门内成员要通力协作，为完成团队共同的目标努力。
尊重客户需求和意见，进行好的设计和架构，以便能较为容易加入新的需求，使得软件易于扩展。