扫码阅读
手机扫码阅读
迭代回顾会议咨询记录

我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。


麦哲思科技任甲林
扫码关注公众号

敏捷迭代回顾会议摘要
敏捷迭代中的回顾会议是一个重要的调整环节,它允许团队反思并改善过程,推动团队向自学习组织转型。本摘要总结了一次敏捷迭代回顾会议的观察结果,包括团队在迭代过程中遇到的问题,优缺点,以及给出的建议措施。
改进点
- 每日站立会议需要每个角色通报任务进展并更新看板以实现任务状态的可视化。
- 测试人力出现瓶颈时,应及时增加人手以缓解压力。
- 开发人员应避免过度设计,通过简化原则和及时沟通保持需求对接。
- 缺乏UI设计人员,建议尽快招聘或培训前端开发人员。
- 工作量估计不足,需通过策划会议和需求梳理会议充分沟通。
- 对于未识别的任务,应在估算时考虑可用时间并排除非项目任务。
- 产品负责人(PO)应至少每周与开发团队协作一天,以保证需求沟通。
- 回顾会议不应详尽列出每个任务,而是应侧重于完成的需求和未完成任务的进展。
- Scrum Master(SM)应控制会议不跑题并在会中积极发言。
- 迭代回顾中要积累迭代数据并展示,以便未来的估算和改进。
- 海星法应用于回顾会议,以提供思考主线并鼓励全员参与。
- 会议纪律需要强调,避免中断他人发言并鼓励提出具体的改进建议。
- 开发和部署环境应保持一致性,且环境应固化。
优点
- 坚持后端设计文档编写,有助于减少接口错误。
- 需求反讲方法被证明是有效的。
- SM宣布会议纪律有助于保持会议的秩序和效率。
- 开发和测试之间的需求沟通提升了测试效率。
- 单元测试的培训和实践有助于提高代码质量。
- 全员使用Confluence和Jira等工具提高了项目管理的效率。
- 团队认识到了进度和效率的提升,对敏捷开发模式建立了信心。
想要了解更多内容?


麦哲思科技任甲林
扫码关注公众号

麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 205.4K
麦哲思科技任甲林的其他文章
做事模式的思考:想、说、写、做
模式一:边做边想没有事先的计划,没有思虑周全,在做的过程中再去寻找好的方法,造成的后果就是质量差或返工多,浪费了时间。很多初级的开发人员在编码时就采用了这种工作模式。磨刀不误砍柴工,先想清楚,再动手做,看似慢,实际快!模式二:想->做 想清楚了总比不想好。此种模式没有和别人沟通,没有文档化,这种模式很可能想的不周全,导致在做的过程中存在问题。三思而后行,如何保证三思的质量呢?沟通与文档化。模式三:想->写->做 想了以后文档化,文档化可以促进自我反思,但是没有其他人进行评审,然后去实现,没有其
不要这样做CMMI
很多公司在做CMMI,很多公司也在重复这种错误:“证书优先,机械照搬,文档泛滥,似严实宽。”!1“证书优先”。CMMI的证书成了一个敲门砖,没有这个证书难以承担国外的项目,没有CMMI的证书就难以在国内一些项目的竞标中获胜,也无法获得政府的补助,于是很多公司都选择了要在短时间内获得CMMI证书。证书只是过程改进的附属物,而过程改进的实效才是其真正的价值。为了尽快拿到证书,企业往往忽略了实效,从形式
案例:需求问题的解决方案
讨论时间:2012-09-14下午13:00至14:45参与人员:EPG3人,需求开发部门负责人一名,项目经理一名 1现象与问题:(1)开发人员反映需求没有说清楚, 写的人认为需求很清楚了。(2)是写清楚,还是说清楚?以谁的意见为主?如果说清楚呢,语言没有证据,不如文字规范。将来发生了需求变更时有争议。(3)需求人员没有讲解约定俗成的,默认的东西,开发人员没有概念。(4)需求人员抱怨开发人员写的软
如何分析各类时长数据?
本文列举了分析时长数据时的注意事项,并结合实例给出了时长数据的常用分析方法。
敏捷的过程改进方法:从经验教训中学习
每次去客户现场做差距分析或者运行检查,总是习惯于找他们的缺点,但是每次也总能从客户那里发现他们的优点,时间久了,慢慢地对缺陷麻木了,审丑疲劳了,只有发现他们的优点时,我才会精神一振,心情愉快。 今年1-2月份期间我去给一个客户做运行检查,整理完发现报告后,我查阅了那6个项目组的阶段总结报告与项目总结报告中的经验教训部分,我发现的60%的缺陷他们自己也感觉到了,只是没有人去提取、去系统的归纳整理、
加入社区微信群
与行业大咖零距离交流学习


PMO实践白皮书
白皮书上线
白皮书上线