Scrum是一种流行的项目管理框架，可帮助优化时间和资源管理。 Scrum包含几个旨在进行有效项目管理的仪式。 它使团队可以清除障碍，解决项目中的问题和障碍，提高效率，确定故障单和估算的大小。 在这篇文章中，我们将只讨论其中一些仪式以及解决这些问题的有效方法。
冲刺计划
虽然每个人都有自己的冲刺计划方式，但我遵循的方法可以有效地计划冲刺。 这是我们的处理方法。 假设已经有多个设计的史诗，通常后端开发人员将接管并开始研究史诗下的每张票证。 在这种情况下，在sprint计划中，我们计划后端和前端协调并确定日期。 使用计划委员会可以使我们全面了解sprint的进度，包括需要多少资源才能交付史诗，以及每个团队成员完成给定问题所花费的时间。
积压整理
如您所知，积压整理是对积压项目的审查，以确保正确列出优先事项并在清单中按优先级准备好适当的物料。
这是我们进行修饰的方法。 任务是为开发人员的每张票编写的，如下例所示：
票务t-123任务列表：
- 链接导航到注册页面的会话页面
- 根据控制台设置可访问链接
- 会话数据的API调用– 后端
- 导航到摘要页面
- 计算金额的差异/相加
- API调用以放置订单ID数量少/相等– 需要后端
- ……。
- …………。
根据此任务列表，后端团队知道需要他们的帮助的地方，并提前计划日期和任务。 然后，我们创建如图1所示的甘特图。 基于工作量-故事点，计算出天数的近似估算值。
如图所示，后端开发人员从冲刺的第一天就开始使用API，而前端开发人员则并行完成所有必要的设计。 如果他们在短时间内完成设计，他们将使用模拟数据处理故障单，并保持API集成到冲刺的后期。 在后端开发期间，测试工程师根据验收标准编写测试用例。
回顾会议
要了解此仪式的方法，让我们以上面引用的相同示例为例。 根据计划，理想情况下，epic-1开发应该在17日之前完成，然后进行错误修复以及产品和代码审查。 但是，通常它可能会或可能不会在预期的时间内结束。 因此，回顾性会议有助于我们全面了解导致计划出轨或导致延误的问题。
回顾会议的样本结果
1.开发人员需要写出在Sprint计划过程中进展良好和不成功的地方
2.如果任务按时完成-开发人员需要让团队了解它是按照计划执行的，使用了什么策略，以及他们是否有足够的时间按计划执行代码并将其冻结为策略。即将开始的冲刺
3.如果任务没有按计划完成，开发人员应描述确切花费了更多时间的时间，并评估特定开发人员是否具备执行此类任务的知识并据此制定策略
4.任务列表（请参阅上一节）将帮助我们了解：
一种。 开发人员遇到障碍的特定步骤
b。 开发人员在通过阅读任务列表解决问题之前是否理解了接受标准。 此列表还将帮助技术负责人或架构师跟踪开发人员的进度
C。 开发人员是否已了解特定任务的解决方案，以防将来再次发生
我跑过的一个冲刺中的一个例子
图2.是我的计划板的一个示例。 根据计划，票证t-123应该在1月9日完成（ 这是根据努力和以前的努力完成而得出的粗略估计-3故事点的门票花了不到两天的时间 ）。 但票已于10日完成。 在回溯中，我曾问过前端开发人员门票花费比预期更长的原因。 她说，她已经按照计划完成了，但是后端开发人员有所延迟。
后端开发人员解释说，他预测发送令牌的延迟，因为令牌必须被压缩。 最初，他认为过程很简单。 但是，他后来意识到，它必须与存在隐式OAuth授予并且客户端未使用授权代码授予时可能施加URL限制的浏览器兼容。 这个问题使他推迟了一天的修复时间。 简而言之，他最初并未考虑边缘情况。 计划过程中的问题是，后端开发人员在提供估算时没有想到边缘情况。
不同的观点可以帮助更好地计划
在讨论问题时，应从各个角度与团队和技术负责人一起探讨解决问题的方法，并应考虑所有相关因素来估算工作量。 在前面的示例中，t-123票证的工作量超过了三个故事点，应该考虑诸如极端情况和相关风险之类的因素才能得出准确的估算值。
通过在回顾性会议中将计划和积压工作联系起来，可以取得更好的结果和更好的决策，从而使我们能够对问题进行根本原因分析并制定相应的计划。 让我们知道您对这篇帖子的喜欢以及它是否有助于您更好地计划或与我们分享您的经验。 只需发表评论，我们很高兴收到读者的来信。
