Scrum是敏捷软件开发的一种形式，对我的帮助最大。
它帮助我改变了我所开发的Web开发小组的绩效’曾在我目前的公司和我的上一家公司任职。
但是，有时候，我确实想知道Scrum是否真的足够敏捷？
Scrum中有很多定期会议。对于短距离的Sprint，这可能是一个很大的开销。对我来说’在哪里可以看到为什么 精益方法 吸引力，特别是对开发人员。
但是，这些会议也很有价值。所以我以为我’d依次查看每次Scrum会议，并评估它们的价值是否真的胜过努力？
首先，有Sprint计划。
Sprint计划在每个Sprint之前进行。就我们而言’通常每两到三周一次。在Scrum中，该会议分为两个部分…
第一部分是讨论作为Sprint团队的所有用户故事的要求，并为团队中的每个人提供了解所需内容的机会。提出问题并希望得到回答，这些问题可以使人们深入了解如何设计每个用户故事。减少了歧义，希望团队可以对用户故事和下一个Sprint的要求有一个共识。团队的集体经验意味着每个人都有机会输入，并且解决方案的质量和适当性可能因此得到改善。对于为期2周的Sprint，Sprint计划的这一部分通常需要2个小时左右，如果对相关用户故事的要求很了解或事先准备好，则可能会少一些。
如果没有这次会议，则当有人选择要开发的用户故事时，该讨论仍会临时进行。但是，很有可能随后仅与产品负责人或一个或两个用户代表进行讨论。与让整个团队参与相比，这将不那么麻烦。’肯定是，但它赢了’受益于从群体方法进行Sprint计划中获得的群众智慧。这种临时方法的另一件事是它’对于产品负责人而言，这更为繁重。他们将需要每天大部分时间都可用，并且在开发团队的呼召下也可以使用。如果您的产品负责人不是全职的，而是与开发团队一起工作，则Sprint计划是一种确保充分利用其时间的有用方法，并且’这是在每个人中预先计划这项定期活动的有用方法’s diaries.
权衡所有这些因素后，我个人认为Sprint Planning的成本很高（就时间而言），但确实值得。
Sprint计划的第二部分可以在第一部分之后立即进行，尽管有些团队需要一天左右的时间 ’两次会议之间的时间间隔，以便在进入下一阶段之前弄清所有未解决的问题。 Sprint计划的第二部分的目的是详细计划Sprint。
这个想法是团队共同努力将所有用户故事分解为任务，并在数小时内估算每个任务。然后，团队计划下一个Sprint的容量，并共同决定要在Sprint中投入多少。
就个人而言，我认为考虑较大的User Stories的任务很有用，但对于较小或更简单的任务则不必这样做。尽管Scrum建议在几个小时内估算所有任务并执行详细的计划过程，但我个人认为这会带来一些负面影响…
显然，这可能会花费很长时间，而且由于整个团队的参与，这使会议成本很高。但我也认为– ironically –真的会阻碍团队’准时交货的能力。有两个原因。首先，团队仅估算其可以识别的任务。他们不’估计他们所完成的任务’t确定。不可避免地有一些。其次，到现在我们都知道大多数开发人员在估算时没有希望。他们的估计不可避免地会是错误的。
如果你’在一个大型项目中，您可能已经估算了“产品待办事项”中的所有“用户案例” 点数，以了解整个项目的规模。如果是这样，我个人认为’对于团队来说，承诺他们认为可以在Sprint中提供多少点并坚持到底，而不是几个小时内估计任务并尝试详细计划，就更加准确了。以我的经验，曾经有一个团队’速度（在Sprint中传递的点数）已经稳定，这是一种衡量团队可以在Sprint中传递什么的更准确的方法，并且花费的时间更少。有关更多信息，请参阅我的文章 准时交货的秘密.
如果尚未对Sprint计划的第一部分中讨论的用户故事进行分值估算，我建议团队在讨论每个用户故事的需求后就其大小进行投票。 规划扑克 这是一种很棒的技术。
因此，总而言之，我对Sprint计划的个人看法是：值得讨论下一个Sprint团队对预期用户故事的要求。值得评估用户故事的积分，无论是他们积压的订单，还是使用Planning Poker在Sprint Planning中作为团队评估的用户故事。对于团队来说，值得根据他们过去的Velocity经验来决定下一次Sprint可以承担的积分数量。尽管将每个故事分解成任务，旨在识别每个任务，在几个小时内估算每个任务，为下一个Sprint制定团队的精确能力并以此为基础进行承诺，但这不一定是值得的。这需要很长时间，并且可能导致无法交付的东西具有可预测性，这意味着团队不会’兑现承诺，使人们感到失望。
在Sprint期间，Scrum中唯一的例行会议是Daily Scrum本身。
整个团队每天在这里开会，回答三个基本问题：
- 你昨天做了什么？
- 你今天打算做什么？
- 有什么阻碍您前进的吗？
该会议应花费5至15分钟。不再。
毫无疑问，每日Scrum非常值得。
它使整个团队保持联系，并为产品负责人提供进度的清晰可见性以及任何影响团队的问题。这是Scrum帮助确保开发团队保持利益相关者的关键方法之一’的期望与他们的新兴现实相符。这是至关重要的。至少在我看来，一个成功项目的定义是达到或超过期望的项目。因此，我永远不会亲自建议一个团队没有其每日Scrum。它’这是一种在非常细微的级别上管理期望，确保期望和现实不发生的方法’沿途发散。
在Sprint的末尾，还有两个会议：Sprint审查和Sprint回顾。这些会议很有用，但是因为它们’在Sprint结束时，它们与下一个Sprint开始时的Sprint计划会议相吻合。有时，这可能会使Sprint遇到大约1天的超负荷运行，老实说，这可能有点累。
Sprint审查会议的目的是邀请所有感兴趣的人参加，并查看团队在上一个Sprint中取得的成就。如果保持简短和非正式，我认为是的’对团队展示他们的东西非常好’ve done. It’对于对项目感兴趣的人’一直都参与其中’并有机会定期提供反馈。这是另一种重要的管理期望值的方法，’我已经提到我认为对于任何项目的成功都至关重要。它’这也是团队在每个Sprint中取得良好结果的有用动力，因为此后将召开审核会议，这样可以使团队更加专注于交付。
最后但并非最不重要的一点是Sprint回顾展。回顾的目的是在常规的Sprint周期中不断改进。同样，每个Sprint之后，团队将在Sprint回顾中讨论三个关键问题：
- 一切顺利吗？
- 什么没’t?
- 在下一个Sprint中，团队将做些什么？
在整个项目中如此定期地进行这些回顾，意味着学习实际上有助于改善团队’在整个项目中（以及以后）的速度。如果它’为了保持简单，团队在下一个Sprint中想要做的不同的事情应该是可行的，并且实际上应该对团队和项目的效率和福祉有所不同。那里’毫无疑问，这是一次会议，您可以’不能放弃。那里’太有价值了。
但是，由于在每个Sprint的开始和结束时它与其他许多会议同时发生，因此它’保持简短很重要。对于2周的Sprint，半小时应该有足够的时间来快速集思广益这三个问题并在下一个Sprint中采取任何措施。
所以总而言之–表面上，所有这些会议都没有’t seem very 敏捷，我相信Scrum会议确实可以帮助团队在每个Sprint中保持敏捷。他们帮助团队对什么达成共识’要求，提高解决方案的质量。它们帮助团队对进度和问题达成共识，从而提高团队合作水平和整个团队的知名度。他们帮助团队了解什么’已实现，从而提高了满意度，并有助于管理期望。他们帮助团队从过去的问题中学习并在不久的将来对其进行改进。
我的结论呢？说话需要时间。但这也增加了价值。
凯莉
有关Scrum的更多信息，请参阅我的系列： 如何通过10个简单的步骤实施Scrum！
摄影者 以防万一
