敏捷开发过程中的会议_您在敏捷会议中花费的时间

敏捷开发过程中的会议

每当我教授敏捷方法时，我都会讨论团队可能选择的会议。 有人沮丧地转向我。 他们开始将所有会议时间加起来，然后说：“那是很多会议。” 可能。 特别是如果您使用迭代。

您可能会开会：

• 每两周回顾一次。
• 每两个星期进行一次演示。 （每次发布故事时，我都喜欢演示，但这就是我。并非每个团队都能做到这一点。）
• 每两周进行一次积压改进会议。 （如果您不习惯小故事，则可能会更多。）
• 每两周召开一次迭代计划会议。
• 每天站立不超过15分钟。

这些会议的原因是根据需要重新计划频率，并重新组成一个团队。 很好的理由。

真正的问题是团队需要多少合作。 团队合作越多，限制了团队的 WIP（进行中的工作），则您开会所需的时间就越少。

一位客户问我有关迭代（特别是以Scrum形式）与看板的价值以及必要的会议。 他们的问题？ 一次中断工作，一次完成多个项目。

他们在各种Scrum仪式，计划和重新计划上花费了很多时间，以至于在完成重新计划之前，他们很难完成足够的工作。

我建议他们开始使用看板来查看其WIP以及WIP所在的位置。 他们陷入了“每个人都有自己的故事”的陷阱，这拖慢了一切。

我建议他们减少在制品。 以下是一些考虑减少在制品的影响的方法：

• 您只需要每天开会询问：“我们如何全面移动此项目？” 您无需询问障碍，因为团队已经知道。
• 如果您使用的WIP限制大于一个，则可能需要特定时间来讲故事，然后才将其发布。 （请参阅节奏 ）。

如果您使用WIP限制为1，则除了回顾/改善外，根本不需要任何会议。 这是因为整个团队以单一流程一起工作。

如果使用看板，则可以将演示集成到开发板上。 右侧的最后一列是“完成”之前的“演示”列。 无需演示会议。

观看您的团队在会议上花费的时间。 请考虑减少对您团队的在制品限制是否有帮助。 也许是为了进行实验。

翻译自: https://www.javacodegeeks.com/2018/06/time-spend-agile-meetings.html

敏捷开发过程中的会议