每次敏捷迭代都是一次PDCA循环, 迭代的回顾会议则是其中的A(adjust),不断的复盘总结可以帮助项目一次比一次做的更好,使团队形成一个自学习的组织。
近日我旁观了一个敏捷项目组的迭代回顾会议,项目组成员对本次迭代的经验教训进行了总结,我作为外部顾问旁观了整个过程,并对项目组中存在的问题,本次回归会议的优缺点进行了点评,咨询记录如下:
迭代回顾会议咨询笔记 |
|||
类型 |
相关实践 |
现象 |
建议措施 |
改进点 |
Daily meeting |
在每日站立会议上没有每个角色通报任务进展,尤其需要不同角色协同的任务。 |
开发完成了什么,测试测完了什么都需要在站会上通报。每个角色都要了解其他角色完成了什么。并且要在看板上将任务状态可视化。 |
改进点 |
Daily meeting |
在迭代初期发现的测试人力的瓶颈问题,但是没有采取有效措施。 |
当发现测试人员成为瓶颈资源时,需要增加人手。 |
改进点 |
Design |
开发人员做过了过度设计,把需求想复杂了,把设计的通用性想复杂了,并没有和需求沟通。 |
简化原则; |
改进点 |
Design |
缺少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 |
大家都意识到了进度和开发效率提升了,对开发模式建立了信心。 |
继续坚持敏捷的相关世界,不断总结经验教训,积累度量数据,通过数据客观刻画改进效果。 |