培训总结
本次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测试做的不到位、持续集成也欠缺。团队没有完全熔炼到一起。个人来讲,以前没接触过敏捷,也少有开发经验,在学习理论和实践中遇到不少困难,解决的也不到位,只有留到后续在工作中慢慢体会与回顾。
在实际项目中如何应用敏捷:
帮助项目团队形成敏捷理念
按照项目级敏捷开发流程开发产品。
借助敏捷中的一些优秀实践和主要活动,指导开发。
团队中的各个部门、部门内成员要通力协作,为完成团队共同的目标努力。
尊重客户需求和意见,进行好的设计和架构,以便能较为容易加入新的需求,使得软件易于扩展。