迭代回顾会议咨询记录

       每次敏捷迭代都是一次PDCA循环， 迭代的回顾会议则是其中的A(adjust)，不断的复盘总结可以帮助项目一次比一次做的更好，使团队形成一个自学习的组织。

       近日我旁观了一个敏捷项目组的迭代回顾会议，项目组成员对本次迭代的经验教训进行了总结，我作为外部顾问旁观了整个过程，并对项目组中存在的问题，本次回归会议的优缺点进行了点评，咨询记录如下： 

迭代回顾会议咨询笔记
类型	相关实践	现象	建议措施
改进点	Daily meeting	在每日站立会议上没有每个角色通报任务进展，尤其需要不同角色协同的任务。	开发完成了什么，测试测完了什么都需要在站会上通报。每个角色都要了解其他角色完成了什么。并且要在看板上将任务状态可视化。
改进点	Daily meeting	在迭代初期发现的测试人力的瓶颈问题，但是没有采取有效措施。	当发现测试人员成为瓶颈资源时，需要增加人手。
改进点	Design	开发人员做过了过度设计，把需求想复杂了，把设计的通用性想复杂了，并没有和需求沟通。	简化原则； 站立会议上及时通报进展；
改进点	Design	缺少UI设计，导致开发出的软件不够美观，操作不简便。	尽快招聘UI设计人员到位； 对前端开发人员进行UI设计的培训。
改进点	Planning	测试工作量、开发工作量估计不足。	策划会议上要沟通，策划扑克法； 需要召开需求梳理会议，充分沟通需求。
改进点	Planning	有些任务没有识别出来，有计划外任务。	估算时要识别可以提供的时间，把一些公司培训任务等排除在外。
改进点	Requirement	PO出国2周，开发人员无法及时与PO沟通需求。	每周，PO和开发至少1天一起工作。
改进点	Retrospective	Retro会议详细回顾每个任务的进展。	不需要详细列出每个任务的完成情况。首先回顾完成的需求； 其次说明没有完成的需求：任务的进展。
改进点	Retrospective	SM在会议中很少发言，没有及时制止跑题。	SM要控制会议不要跑题。
改进点	Retrospective	SM不需要对已发生的问题先分析原因。	只列现象即可，不要引导成员的结论，不要限制成员的思考。
改进点	Retrospective	迭代回顾时，没有迭代数据的积累与展示。	统计某个迭代实际上班时间，投入本项目的时间，%； 统计某个迭代的实际生产率； 统计某个迭代的缺陷个数； 统计缺陷修复类任务的工作量分布，为以后做缺陷修复工作量的估算提供参考。
改进点	Retrospective	让大家自由发言，没有总结的主线。	要采用海星法总结，给大家一个思考的主线。
改进点	Retrospective	在回顾会上，有同事一直没有发言。	要采用海星法总结，让所有人都参与进来。
改进点	Retrospective	有人打断别人的发言，替他人总结问题	在会议纪律中要强调一下；
改进点	Retrospective	问题提的多，措施提的少。	每个人在提出现象时，要给出改进建议；
改进点	Support	开发环境，部署环境一致性。	环境固化，使用提前通知，安排资源 开发全自动化部署工具（专题讨论会）
优点	Design	后端坐了设计文档，前后端的接口更容易，减少了接口错误。	坚持。
优点	Requirement	需求反讲很有效。	坚持。
优点	Retrospective	SM先宣布了会议纪律。	会议纪律文档化： 聚焦本次迭代； 专心听其他人讲； 不要强迫别人接受你的观点； 不要跑题； 每提出一个现象就要提出一个措施；
优点	Testing	在测试之前，开发和测试做了需求沟通，有利于测试效率的提升。	坚持。
优点	Testing	做了UT的培训，开始做单元测试了。	坚持TDD。
优点	Support	大家都在使用confluence, Jira工具。	继续在JIRA 中维护需求，集成更多的工具进来。
优点	Mindset	大家都意识到了进度和开发效率提升了，对开发模式建立了信心。	继续坚持敏捷的相关世界，不断总结经验教训，积累度量数据，通过数据客观刻画改进效果。