当SCRUM Master已经有几个月了，几个月中，我们团队已经形成了一定的团队自组织经验，也有了一些想法和思考，同时自己也看了看敏捷相关的书，学了点相关经验，故稍作分享：
"如果缺少回顾的话，你会发现团队会一而再再而三地犯同样的错误。" 就像电影《土拨鼠之日》中男主角一样，无法打破这个痛苦的循环，除非他们拿出时间来理解所发生的事情并改变他们的行事方式。这就是我们开回顾会议的原因，回顾会议帮助我们识别流程中的痛点，并学会独立解决问题。
在《敏捷教练如何打造优秀的敏捷团队》这边书里面，列出了如何引导敏捷回顾会的方式：
1. 对于上个迭代他们有何见解？
2. 他们希望重点改善哪些领域？
3. 他们下个迭代可以实行哪些想法？
可以把回顾会视为过去迭代何未来迭代之间的一座桥梁。把回顾会一半时间来回顾过去，发生了什么以及为什么发生，然后得出相应的见解。接着换到前进挡，得出可以让情况好转的想法，并制定实施想法的行动计划。
这是一本偏敏捷实践的一本书。
他的每章都包含：一个具体主题，难关，检查表。一个具体主题，围绕这个主题，我们需要做哪些事情，具体怎样做，给出具体实际项目管理以及开发中的例子；然后列举出其中可能存在的难题， 给出每个难题的具体建议；最后列出当前主题需要做的事情的checklisk（检查表）方便一个敏捷教练进行检查，检查你是否符合标准。
我们的团队实践：目前已经开了几轮迭代的回顾会议，尤其是最近一次回顾会，我发现我们团队确实已经形成了一定的自组织与自我发现问题的能力，在团队开发项目期间，技术经理出于架构上的考量，中间让我们进行了一次架构大调整，上生产需要依赖的包比较多，在第一个迭代后期的回顾会中，经过梳理，我们团队人员发现，团队中经常出现以下情况：
1. 前端版本与后端版本不一致
2. 后端开发人员需要修改bug导致需要重新打包上生产
3. 后端人员忘记修改过了相关模块导致打的生产包缺失相关模块的依赖包或者配置文件
针对以上的情况，我们团队成员在开回顾会时，积极做出了反应，说明了相关情况，他们分享了原来项目的经验与措施：
1. 项目本轮迭代前的一两天，进行“封版本”操作，禁止测试人员测出的问题bug 再进入当前的生产版本（针对2）
2. 项目在本轮迭代结束前一两天，举行版本会议，相关前后端人员一起参与，梳理本轮迭代需要上哪些功能，是包，脚本，还是文件模板（针对3）
3. 将上生产日期与当前版本设计的信息做出记录，我们有两方面的记录 一个是在白板上体现出来具体的模块或脚本，二个是每次迭代的写ReleaseNotes（针对1，3）
我觉得敏捷实践也是一个迭代的过程，需要团队成员共同发展，共同实践。
网友评论