冲刺计划
Sprint 计划是 Scrum 冲刺的初始阶段。它决定了冲刺期间的工作范围和工作方式。整个 Scrum 团队都参与计划。
冲刺是明确定义的时间段，在此期间必须完成指定的工作。冲刺需要在开始之前进行计划。首先，您需要确定冲刺的持续时间和目标。
在规划研讨会上，任务列表和冲刺目标达成一致。为团队注入正确的工作动力非常重要，这样每个成员都专注于成功。
如果冲刺计划不周，那么这可能会导致团队失败。开发人员将无法满足对他们的期望，因为事实证明这些任务是不切实际的。
计划冲刺时要考虑的问题：
- 客户或软件所有者宣布冲刺的目标，同时解释如何实现它。Scrum 团队找出在未来的冲刺中可以完成哪些任务来实现这个目标。
- 开发人员在他们之间分发工作计划，并与软件客户达成一致。
- 产品的客户（所有者）始终参与制定冲刺计划。他设定了一个目标，编程团队必须找出是否可以在冲刺中实现。
- 该计划应使用产品待办事项列表，可以将其中的信息添加到计划中。
- 团队成员在结束计划会议时应该清楚地了解他们需要什么来实现结果。您可以在冲刺积压工作中显示未来行动的顺序。
计划每周不应超过两个小时。Scrum Master 必须向每个人解释，有时间限制。如果所有工作问题都迅速解决，那么会议可以比平时提前结束。此类会议没有最短持续时间限制。
任务评估
评估工作的复杂性不需要过分。规划过程不需要对开发的复杂性进行精确的评估，但至少需要进行大致的评估。团队不仅要了解冲刺的目标，还要将目标与团队的能力进行比较。
要评估复杂性，您可以使用每个人常用的衣服尺码（L、XL、XXL）。当然，这并不能保证准确性，但仍然如此。
为了更准确地评估复杂性，需要相互理解。团队成员应该公开分享他们的意见，不要害怕向产品负责人提问。
工作完成后对团队的批评可能会导致在计划下一个冲刺时，预测会变得不那么乐观。这将帮助团队避免重蹈覆辙，并保护它在未来不会受到负面评估。
分、分、时分难度评估
通常，开发团队会随着时间的推移估计他们工作的复杂性。但是一些敏捷团队选择以分或分来评价难度。这是实施积压项目或其他分配任务所需总成本的更好指示。
积分是根据工作的复杂性和数量来授予的。此外，还考虑了可能的风险。使用此方法评分有助于有效地将工作分解为小步骤。
通过在计划时定期使用评分方法（分数），团队可以更好、更准确地了解他们需要多少时间才能完成工作。此外，还有其他优点。
- 时间估算不考虑与项目不直接相关的工作，尽管它肯定会出现。通过信使讨论工作问题，召开会议——所有这些对团队成员来说也需要时间。
- 情绪会影响日期的选择。评估工作时的评分消除了这个因素。
- 每个团队对工作复杂性的评估以及相应的完成任务的速度可能不同。有分数的工作不能被视为速度的任何指标。也就是团队没有心理压力。
- 通过正确分配劳动力成本和复杂性，您可以快速且无冲突地为参与者之间执行的工作划分点。
- 完成任务获得的点数取决于其复杂性，而不是花费的时间。所以，程序员会想着提高效率，而不是想着要花多长时间。
复杂性估计的缺点是它经常被误用。例如，此方法不能用于评估员工。
团队应该使用评分系统来更好地了解分配给他们的工作量并正确确定优先级。
每日 Scrum 会议
研讨会很重要：在研讨会上，团队成员分享他们的意见、交流并就进一步的行动达成一致。还需要每日召开例会以提高团队精神并发布时事新闻。
站会是关键项目参与者的简短会议：软件所有者、程序员和 scrum 管理员。站会的结构由三个问题组成。
- 昨天我们能做什么？
- 我们今天在做什么？
- 是什么阻碍了我们取得成果？
提出这些问题可以促进发展，并有助于发现团队内部的问题。当每个参与者交流他/她如何帮助实现共同目标时，这会增进团队内部的相互理解。
重要的是要记住，没有单一的模板来指导如何进行站立会议。每个团队根据团队的特点，按照自己的模式召开会议。
现在让我们讨论完美的站立需要什么，并熟悉有效的站立示例。
首先，您需要选择适合每个人的时间。通常，来自同一办公室的团队的站立会在工作日开始时举行——早上 9 点到 10 点之间。这使您有时间更好地计划当天的日程安排。如果团队成员在不同地区工作，则选择适合每个人的时间。例如，如果一些团队成员居住在加利福尼亚和悉尼，那么站立会议将在加利福尼亚时间 15:30 开始。当然，晚饭后站起来对每个人来说都不方便，但可以让我们与大洋彼岸的同事保持联系。
跟踪站立的生产力。不要开会太久——注意力应该保持在最佳状态。如果可能，站立的时间不要超过 15 分钟。
用球。可以依次扔给对方。因此，每个人都会参与讨论。这个游戏有助于保持团队的注意力。使用团队回顾。许多敏捷方法中都使用了站会，这并不妨碍我们在回顾会议上讨论站会的有效性。有人每天见面，其他团队 - 一周几次。如果团队很难从站立会议中获益，找出原因并做出改变。
冲刺回顾
Spring Review 在冲刺的最后阶段进行。有必要检查产品增量并裁剪积压。整个 scrum 团队和所有利益相关者参与对冲刺结果的审查。会议以轻松的形式举行，以增进项目参与者的互动。
Sprint 结果评审包括以下要素：
- 软件所有者显示积压工作中哪些已完成，哪些尚未完成。
- 程序员讨论什么进展顺利，困难出现在哪里，以及它们是如何消除的。
- 开发团队展示他们在冲刺期间的工作成果，以及他们收到的产品增量。
- 产品负责人分享他对当前积压的想法。它还给出了下一个目标的预测及其实施的截止日期。
- 大家根据市场评估和用户兴趣讨论下一步最好做什么。
- 就增加积压工作的时间、预算和前景交换了意见。
结果是更新的待办事项列表，其中包含后续冲刺的新目标。如果情况需要，可以更改积压。
冲刺回顾
Sprint Retrospective 是一个讨论如何改进工作流程的研讨会。它还为下一个冲刺创建改进计划。会议通常在 sprint 回顾之后举行，持续时间不超过三个小时。主持会议的是 Scrum Master。
Sprint 回顾的主要目标包括：
- Sprint 分析（参与者的工作、结果和问题）。
- 讨论可能的解决方案以改进后续冲刺中的工作流程。
- 在项目实施期间为团队成员制定改进实施计划。
Scrum Master 邀请团队成员就如何提高开发效率提出建议。该团队讨论这些建议并提出实施建议的某些方法和技术。
在 Sprint 回顾结束时，团队应该强调一些改进建议，以便在下一个 sprint 中实施。建议可以随时实施，但 Sprint 回顾提供了一个机会，可以从团队的角度更深入地审视他们可能的适应。
这是我们结束对 Scrum 方法论的讨论的地方。您可以在专题文档或您的第一个工作场所了解更多信息。
GO TO FULL VERSION