敏捷开发过程中的会议
每当我教授敏捷方法时,我都会讨论团队可能选择的会议。 有人沮丧地转向我。 他们开始将所有会议时间加起来,然后说:“那是很多会议。” 可能。 特别是如果您使用迭代。
您可能会开会:
- 每两周回顾一次。
- 每两个星期进行一次演示。 (每次发布故事时,我都喜欢演示,但这就是我。并非每个团队都能做到这一点。)
- 每两周进行一次积压改进会议。 (如果您不习惯小故事,则可能会更多。)
- 每两周召开一次迭代计划会议。
- 每天站立不超过15分钟。
这些会议的原因是根据需要重新计划频率,并重新组成一个团队。 很好的理由。
真正的问题是团队需要多少合作。 团队合作越多,限制了团队的 WIP(进行中的工作),则您开会所需的时间就越少。
一位客户问我有关迭代(特别是以Scrum形式)与看板的价值以及必要的会议。 他们的问题? 一次中断工作,一次完成多个项目。
他们在各种Scrum仪式,计划和重新计划上花费了很多时间,以至于在完成重新计划之前,他们很难完成足够的工作。
我建议他们开始使用看板来查看其WIP以及WIP所在的位置。 他们陷入了“每个人都有自己的故事”的陷阱,这拖慢了一切。
我建议他们减少在制品。 以下是一些考虑减少在制品的影响的方法:
- 您只需要每天开会询问:“我们如何全面移动此项目?” 您无需询问障碍,因为团队已经知道。
- 如果您使用的WIP限制大于一个,则可能需要特定时间来讲故事,然后才将其发布。 (请参阅节奏 )。
如果您使用WIP限制为1,则除了回顾/改善外,根本不需要任何会议。 这是因为整个团队以单一流程一起工作。
如果使用看板,则可以将演示集成到开发板上。 右侧的最后一列是“完成”之前的“演示”列。 无需演示会议。
观看您的团队在会议上花费的时间。 请考虑减少对您团队的在制品限制是否有帮助。 也许是为了进行实验。
翻译自: https://www.javacodegeeks.com/2018/06/time-spend-agile-meetings.html
敏捷开发过程中的会议