当前位置: 首页 > Linux

Scrum会议太多了!您的团队在Scrum活动中使用了多少时间?

时间:2023-04-07 03:10:09 Linux

Scrum活动-会议太多,太耗时!!!我们有多少时间?几乎每个新公司的Scrum团队都曾在某个时候抱怨过Scrum会议的持续时间。我收到这样的评论:“Scrum会议太多了”“什么?两周冲刺的四小时计划会议!”“我们在这里召开了很多会议,现在你们开更多的会议来扼杀我们”“我无法让我的团队在会议上花那么多时间”“我太忙了”以下是事件Scrum和每个事件的小时数:新手团队可能会看到这些数字在每个事件时间都有大量的小时数,但是如果你遵循检查的原则并实际挖掘时间;您可能会对某些数字感到有些惊讶。出于数学目的,我假设一份平均早上9点到下午5点的工作,工作时间为8小时。我还将承担周一至周五的职责,因为这在我合作的所有团队中都很常见。以下是Sprint中每个事件所花费时间的细目分类:2%回顾团队应该花时间检查他们的流程和实践,并寻找机会把事情做得更好更快。没有这种检查和精神,适应就完全丧失了,敏捷的本质也就不存在了。2.5%评论和反馈在冲刺结束时,团队与利益相关者交谈并寻求他们对刚刚完成的工作的反馈是非常重要的。这种风险管理策略允许团队展示他们构建的内容并让利益相关者同意或纠正它,从而有助于尽早纠正错位的目标。不花时间做这个反馈只会导致错误的产品交付给利益相关者,而不是他们的期望。这支持了对具有定期反馈的增量和迭代开发的总体信念。接下来是对即将进行的工作的审查,并允许产品负责人向团队和利益相关者展示工作管道的健康状况。它有助于透明地交流产品、项目和即将开展的工作。2.5%协调每日站会每天,团队只需要一次15分钟的活动来计划在接下来的24小时内谁做什么,直到下一次每日Scrum。5%规划和设计最大的Scrum活动是规划下一个冲刺,并对如何处理工作进行高级设计。传统开发团队将更多的精力花在规划和设计上,而Scrum团队则完全减少了这一点。不过这个事件是最有争议的,估计团队认为5%还是很久了。我个人并不认为要求任何团队花费5%的时间来规划和设计将要完成的工作是一件大事。当然,专业人士应该能够认识到规划的重要性。88%的工作时间显然我们还有很大一部分时间用于工作。下面是一些更多的事实:每天开会1小时(平均)如果您将其视为每天仅开会一小时的平均会议,那么多多少少是一个见仁见智的问题。时间盒时间盒是事件的最大建议时间,意思是如果你能更快地完成它们,只要它同时提供相同的质量;那么请尽快完成它。如果你的会议多于Scrum会议,那么你就做错了,并且存在需要解决的组织功能障碍。实例计算