我是一名开发人员，致力于开发具有大型后端组件的Android和iOS新移动应用程序。我们已经进入了该项目的三个冲刺阶段，并且我们将Scrum与它的所有仪式（完善，计划，每日，回顾等）一起使用。

在两次冲刺中，团队不得不加班和周末工作（无偿），因为管理层非常震惊，我们无法按时完成冲刺承诺。每个人都努力工作，但是一些外部依赖性和乐观估计使我们难以完成所有的冲刺故事。

以我的经验，在一些冲刺中完成一小部分故事是不正常的，可以在下一个中解决。但是我们的项目经理说，这是我们自己做的估算，这是我们的错，因此我们应该完成sprint中的所有项目。

1. 我不知道这是Scrum的可接受/常见变化吗？

2. 您如何建议我对此采取行动？

一些事情对我很重要。

管理层要求团队致力于一系列工作的想法与最新版本的《 Scrum指南》不一致。“提交”或“承诺”一词仅在最新（2017年11月）的《 Scrum指南》中使用过两次-一次是在列出Scrum值时，一次是表示“人们个人致力于实现Scrum团队的目标”。

目标的想法对Scrum很重要。组织和团队不仅具有广泛的目标，而且在Scrum中，每个Sprint都有一个Sprint目标，该目标在Sprint计划中定义为产品所有者和开发团队之间的协作。通过实施产品待办事项列表中的项目可以达到Sprint目标，但这并不是简单地“完成此工作”，并且通常不能代表完整的Sprint待办事项列表。也就是说，您应该能够完成Sprint目标，而无需完成为Sprint选择的每个产品Backlog项目或Sprint Backlog中的每个项目。我目前的想法是，完成Sprint目标所需的工作应该占团队能力的60-70％左右，但是您要考虑能力。尽管不同的组织会有所不同，但这是

加班和周末也是反敏捷软件开发的一种做法。基本原则之一是，所有努力的利益相关者都能够以可持续的速度前进。漫长的日子和周末，即使他们得到了报酬，对于团队来说也是无法承受的。

此时，有几个后续步骤。团队的Scrum Master应该在管理方面教育Scrum和敏捷软件开发的价值和原则（例如“承诺”和“可持续发展”）。团队应发挥其预测工作和与产品负责人协商范围的能力。团队还应该确定并努力解决或防止导致这种情况的障碍（消除或减少外部依赖的影响）。

您所描述的情况（管理层要求团队加班以完成所有计划的故事）是Scrum文献停止使用“承诺”一词的原因之一。只有在消除所有不确定性的情况下，才能做出真正的承诺，包括不确定第三方的依赖关系，每个项目的工作量，考虑疾病的每个人都有多少时间等等。

Scrum的基本思想之一是团队以可持续的速度工作，这实质上意味着正常工作时间而没有加班（有偿或无偿）。这直接意味着您没有遇到可接受的Scrum版本。

您可以做什么取决于您的角色。

如果您是开发人员，那么您可以做的最好的就是

• （统称为开发团队）拒绝“承担”更多的工作，这超出了您绝对确定可以在sprint中完成的任务。这可能比管理层希望您做的要少。
• 专注于完成工作，而不是开始新任务。如果您发现某些工作无法完成，请尽早指出，以便可以调整计划。

如果您是Scrum的高手，那么您可以通过向管理人员介绍Scrum来真正证明自己的价值。一些要点对我很突出：

• 如第一段所述，团队不会在冲刺计划期间做出承诺，但会给出他们预期已完成的工作的预测。
• 尽管团队应避免在冲刺结束时进行未完成的工作，但这种情况在项目开始时（或团队组成发生变化之后）几乎是不可避免的。团队只能在短跑中实际完成多少工作才能根据团队在此构架中最后几个短跑的历史数据来确定。在项目的早期，这种历史数据根本就不存在，因此在前三个sprint中完成任务的团队确切地为每个sprint计划的事情比好的计划更容易出错。在以可持续的速度进行约5次冲刺之后，有足够的数据可以合理地了解团队可以在一个冲刺中实际完成多少工作。

您的PM与Scrum无关。

您的项目经理没有业务要求您支付加班费。

显而易见，要做的是估算所有任务，以便可以保证它们会及时完成。然后，您应该能够以第二种方式去酒吧，因为很明显，如果低估任务意味着您免费完成任务，那么高估意味着您有时间没有工作。

这样做有很多方面，但是从更高的角度讲，是的-PM将绝对要清楚地了解为什么计划的工作尚未完成。但是，应该在回顾中提出（并解决）。从开发人员的角度来看，有许多因素可能导致sprint失败。

您可能需要考虑的一些事项：

冲刺中太多

如果您经常进行过多的工作，则冲刺将失败。应该随时间跟踪冲刺速度，以找出最佳点数（或天数）。

资源分配

确保sprint计划充分考虑了非开发活动，例如仪式，假期，培训，管理，支持和其他项目等。自动假设每个人每小时都在办公室里工作，这是不切实际的，并且会立即让您从一开始就后退。

估计变化

您正在进行优化，但是某些任务总是会超载吗？通常，这些都是由于缺少或含糊的要求。如果要求很苛刻，那么除非经过充分完善或计划加急，否则故事甚至不应进入冲刺。

速度

如果正确地跟踪了速度，则故事的真实数量应该清楚。这并不是说它们会一直按时完成，但是这会使事情变得容易得多。

善意

在任何项目上，善意都是有限的。如果您不停地工作以致于无法交付，那么士气就会受到打击，开发人员将精疲力尽- 这是项目管理的失败。正如我已经概述的那样，请确保冲刺计划仅使用速度和峰值来安排实际数量的故事，以帮助您一路走好。

尖刺

如果某件商品的精制效果差或只是毛茸茸的，不要担心会加钉，以便为以后的冲刺提供更好的估计。是的，有些人只是估计不足，但是大多数时候，当时还不了解全部事实。理想情况下，应该在优化中将其覆盖或由PO尽早获取，但有时它们可​​能会陷入冲刺。开发人员应该努力避免这些问题，因为这些问题很容易使鱼雷冲刺，否则效果会很好。

不，这不是公认的敏捷形式，这是一个非常重要的原因：如果您要交付所有内容，那么您就不是在做敏捷，而是在做瀑布-如果您认为自己是在做敏捷，那可能是您在Waterfall方面做得不好。我敢肯定，您已经听过老字号：“好，快，便宜，选两个”，对吗？通过软件开发，它更像是“按时，按预算交付所有功能，选择其中的前两个”。瀑布选择第一个，敏捷选择第二个。

如果您要变得敏捷，则需要灵活地将无法及时完成的​​故事从Sprint中删除。一种可行的方法是让您的产品负责人使用MoSCoW优先级评估案例。这将涉及选择不超过60％的故事（按总故事点数）作为必须完成的故事，选择20％作为要在项目结束时完成的应有故事，并发布最低可行产品，选择20％作为如果您有时间，可以完成可能拥有的东西，以及任何超出当前发行版范围的东西（如“没有拥有”）。同样重要的是要注意，当组合在一起时，必备食品应该有足够的肉来制造最低限度的可行产品，而无需包括其他类别的任何物品。

在团队提出要求之后，确定是否从Sprint待办事项中删除项目是产品所有者的责任，从Sprint待办事项中删除的任何项目都由产品所有者进行评估，然后由完全从项目中删除，或放置在项目待办事项列表中的适当位置。

在这种情况下，我猜您的产品负责人是您的项目经理，对吗？确定要放弃的任务是他的工作，因此他当然不应该责怪您过度承诺，​​因为放弃任务以弥补这一点是他的工作，而且看来他没有这样做。

他是正确的，冲刺之间不应有任何残留。在冲刺之间结转的Scrum团队是一种反模式，不是规范的Scrum接受的有效结果。

但是，他的方法不是一个好方法。

在冲刺过程中，团队应不断监视正在完成的工作，是否可以保持冲刺计划中有关完成选定故事的承诺。如果团队确定无法完成所有故事，则应与PO会面并选择要从冲刺中删除的故事。这样，每个人都停止研究故事，并专注于完成剩余的故事。切记：完全完成一个故事总比使两个故事完成一半更好。

外部依存关系和估计不精确的问题正是回顾存在的原因。在Retro期间，团队应反思并找出这些问题。然后，团队应该找到并实施针对这些问题的解决方案。通过更好地了解系统和简单的经验，可以使估算更加精确。外部依赖性较难，但并非不可能解决。

Scrum Master不允许您的PM（甚至是Scrum团队中PM所做的事情？）来强迫您完成所有故事。相反，如果他有投诉，则应保留以进行回顾。甚至更好的是，应该解决导致故事无法按时完成的问题。

我不知道这是Scrum的可接受/常见变化吗？

没有。这是完全错误的。我也许同情支付加班费，如果PO制作的发放估计为冲刺年底前事实错误，但无偿加班是完全荒谬的，会让我另找工作尽快。

您如何建议我对此采取行动？

以我的经验，很多人不会听逻辑上的争论。他们看到它有多破碎的唯一方法是show，而不是分辨。因此，下次您进行估算和提交时，请尽可能减少提交量。承诺在冲刺结束前完成一张小票。您可以在一天内完成。查看您的PM的反应。然后开始上什么系统是用于什么系统从那里的讨论应该被用于。

通常，在项目开始时，当我们决定团队的速度时，考虑到这是一个新团队，我们会选择一个保守的（比平时低）的数字，这会使团队安定下来需要一些时间，相互了解，了解功能和NFR要求等。基本上，在前几个sprint之后，我们优化了团队速度，显然速度只会从这一点开始提高。

在开始时提高速度并扩大团队以实现这一目标是没有意义的。

还有一件事是，在一次性的情况下，有一个不可错过的交付承诺，项目经理可能会向团队施加压力，要求他们进行拉伸，延迟工作和在周末工作。但是，那必须视为例外，而不是工作规范。那样的工作可能会在短期内提高速度，但从长远来看会适得其反，因为它可能导致代码质量问题，团队倦怠问题，动力低下的团队不满意等。

承诺常见问题

这是正常现象吗？

我不确定。

令人惊讶吗？

不会。有些人会永远理解“承诺”，这意味着承诺中的所有内容都必须完成。

这是个好主意吗？

不会。敏捷开发将可持续性作为中心主题：无限地努力，尽力而为。在大多数时候，这是一个明智的主意。（如果您的管理层不接受这一点，则他们不应称其组织敏捷。）

我们应该做什么？

• 解释sprint的内容是基于估计的。“估计”表示有时仅是正确的，通常是错误的。错误时，它有时会太低而有时又会太高。
• 说明改变估计行为比工作速度容易得多。
• 解释说，当团队因评估过高而受到惩罚时，它将只评估较低的水平，这样，与将某些内容偶尔从一个冲刺推到下一个冲刺相比，管理层将失去更多进步。

令人高兴的是：您的项目经理已经知道所有这些事情，并认为它们是正确的。只是在短期内人们可能更愿意忽略它们。

我不同意您的管理团队。他们不应该让您加班完成冲刺。

但是，无法做出承诺的想法来自对软件开发的误解。我已经看到许多团队试图通过他们在先前冲刺中完成的故事点数来预测他们可以在冲刺中完成的故事。如果可能的话，可以说软件开发是线性的，也就是说，如果我工作两个小时，我完成的工作将是一小时内完成的工作的两倍。

软件开发是有创造力的，因此不是线性的。对于团队来说，最好的做法是告诉管理层他们可以在冲刺中做什么，然后提供这些故事。如果您始终不履行自己的承诺，那么您要么不知道故事的开头，要么受到产品所有者的压力，要求承担更多责任。

在前一种情况下，您必须先确保了解故事的范围，然后再同意接受它。如果是后者，则说明您存在文化问题，几乎无能为力。