处理失败的冲刺和截止日期

许多Scrum书籍和文章都说，失败的sprint（当团队无法完成Sprint Backlog的某些功能时）并不是一件坏事，它不时发生，并且如果团队从错误中吸取教训，这实际上很有用。并改善了以下冲刺中的一些功能。并且团队不应因未完成其承诺的工作而受到惩罚。

从开发人员的角度来看，这看起来不错，但是，我们有一家软件公司“ Scrum-Addicts LLC ”为认真的客户（“ Money-Bags Corporation ”）开发一些东西：

1. Scrum-Addicts经理建议为Money-Bags开发一款软件
2. 他们同意功能列表，Money-Bags要求提供发货日期
3. Scrum-Addicts经理咨询了他们的Scrum团队，该团队表示，将需要3周的冲刺来完成所有功能
4. Scrum-Addicts经理增加了1周的安全时间，承诺在1个月内发布该软件，并与Money-Bags签订了合同
5. 经过4个冲刺（交付期限）后，Scrum团队只能交付80％的功能（由于新系统的经验不足，需要在生产环境中修复以前的功能中的关键错误等）。
6. 正如Scrum所建议的那样，该产品目前可以交付，但是如合同中所述，Money-Bags需要100％的功能。因此，他们违反了合同，却一无所获。
7. Scrum-Addicts濒临破产，因为他们没有从Money-Bags获得任何收益，并且投资者对结果感到失望，不愿再为公司提供帮助。

显然，没有哪个软件公司愿意加入Scrum-Addicts的行列。我对敏捷和Scrum的不了解是，他们建议团队如何应对计划和截止日期，以避免上述情况。因此，总而言之，我有两个问题：

谁是罪魁祸首？

1. 经理，因为做适当的计划是他们的工作
2. 团队，因为他们致力于做更多的工作
3. 其他人

什么是要做？

1. 经理应将截止日期推迟到原团队的估计值的2倍（或3倍）。
2. 无论如何，都应鼓励团队成员尽心尽力（通过对冲刺失败进行处罚）
3. 团队应放弃Scrum，因为它不符合公司的截止日期政策
4. 我们都应该放弃软件开发并加入修道院
5. ???

在您的示例中，我看到了一些基本的管理问题：

• 如果Scrum-Addicts经理签署了“硬期限”合同，但是在“涉及新系统”的情况下仅增加了33％的安全边际，那是相当鲁ck的。

• 一个月后提供至少x％功能的可用性本可以用于协商合同，即当客户在截止日期前仅获得80％功能时，客户至少要部分付款。全有或全无的合同是软件供应商和客户都不会从中受益的-这不仅意味着供应商0钱，而且客户0功能。诸如“瀑布”之类的全有或全无的开发方法只会让您编写此类合同，而敏捷方法则提供了更多的可能性。

• 查看前一个或第二个冲刺的结果对经理来说应该很明显，团队无法按时完成任务。因此，他应该早点采取措施，重新安排其余任务和功能的优先级，或者尝试尽早与客户重新谈判。例如，经理可能试图缩小一些剩余功能的范围，因此团队可以交付合同中提到的所有功能，但每个功能都在缩小范围内。

如果一项任务花费的时间比您想象的要长，那么没有任何开发方法可以使您免于此。但是像Scrum这样的敏捷方法为管理层提供了更多机会来控制这种情况下的情况。如果他们没有利用这些机会，那显然是他们的错，不是团队的错，不是“ Scrum”的错，也不是客户的错，因为“他不接受敏捷”。

“ 敏捷软件开发宣言 ”的价值声明之一是：

客户合作而非合同谈判

Scrum-Addicts LLC谈判合同而不是与客户建立合作关系这一事实使我质疑他们的敏捷性。

一件事很清楚：敏捷性需要每个人都接受。敏捷不仅适用于开发人员。管理人员和客户还需要接受敏捷宣言的价值。如果客户不接受敏捷性，但仍然需要严格的合同和最少的协作，则要么不使用敏捷性，要么寻找更好的客户。

客户的错是他们被期限驱动的开发所困在合同泡沫中。

谁该怪？

经理，法律部，会计师-随您便...

我知道这个例子有些人为，但是如果公司不满意，公司可以不支付一毛钱就走开这一事实，应该立即响起警钟，而将瀑布和敏捷思维混为一谈。

客户想要吃蛋糕并吃蛋糕-他们很高兴接受瀑布，小瀑布，敏捷，拉拉土地，只要他们在日期Z之前以$ Y的价格获得产品X。

从方法论的角度来看，敏捷开发绝对要求开发团队和客户在同一页面上。思想差异只会在洗礼中浮出水面，是一厢情愿的想法。

IT项目处理未知数 ; 其中一些未知数甚至是未知数。这意味着什么？

以模型铁路的玩具桥为例。您知道所有参数：

• 你知道山谷有多大

• 您知道山脉的材料，其高度，稳定性等。

• 你知道你需要多少材料

• 您可以从早期的“项目”中了解到，您花了多长时间构建类似的东西

其中涉及许多变量，这些变量会影响您的业余时间和金钱投资计算。但是您可以不假思索地说下周末是否结束。

进一步举例说明：

• 假设您不是为自己的模型铁路建造桥梁，而是为一个完全陌生的人建造桥梁：您的工作是在两座山之间建造一座铁路桥梁

• 假设您在模型景观之前几乎没有任何信息

• 关于风景的信息是，有两座山，似乎不太大

• 山的稠度介于岩石和果冻之间

• 总费用最高为10 $

• 工作场所完全是黑暗的，没有光亮的机会：您只有一盒8支火柴

• 截止时间为3小时

那将类似于一个IT项目。您有建造桥梁的经验，在已知地形上行走很容易。黑暗使之艰难。您几乎无法预测许多事情：仅在黑暗中戳了一段时间后才知道山脉的大小。山脉的一致性也是如此。据此，您可以估算需要花费多长时间以及花费多少。这里是未知的事物，在项目开始时您就不知道这些事物，例如混凝土地形等。但是即使有最丰富的经验和最保守的估计，您也无法预见某些事物。这些东西是未知的未知，带有一些混乱。

每个IT公司都应该知道这一点。他们必须应对项目风险。

1）有几种方法可以最大程度地降低（财务）风险：交易可能包括客户为每个工作增量支付的费用。因此，在交付增量1后，必须支付部分费率。只要Scrum-Addicts LLC能够提供，财务风险就很小。计划的冲刺目标越细，每次冲刺的总风险就越低。这意味着，如果Money-Bags Corporation获得合同的80％，则他们至少应支付合同价值的80％。如果他们在冲刺失败后拒绝支付，则风险不如拒绝支付100％的风险高。

2）Scrum-Addicts LLC的开发人员有问题

Scrum-Addicts经理咨询了他们的Scrum团队，该团队表示需要3周的冲刺才能完成所有功能。Scrum-Addicts经理增加了1周的安全时间，承诺在1个月内发布该软件并签订合同与钱袋子

这表明，a）开发人员没有使用scrum的经验，或者b）他们对scrum的处理错了。团队使用scrum的时间越长，他们的估算就越好。如果团队进行评估，并且经理添加了“安全性”作为“缓冲”，那么经理似乎比团队更了解，这是一个不好的信号。如果您有一支经验丰富的团队，则无需“管理者缓冲”，该团队已将其包括在估算中。这个想法是，团队协作的冲刺越多，团队就越了解自己的优势和劣势，并掌握一些进行实际估算的指标。当然-正如已经提到的- 未知的未知数这往往会使估算变得困难；或至少不精确。但是从长远来看，估算值应该会越来越好。

谁是罪魁祸首？

1）管理

如上所述：风险管理显然存在缺陷。如果公司濒临破产，那么公司应得的。如果您在这样的公司工作：离开！

2）团队

即使管理层完全愚蠢，团队也应该反对这样的项目。好的经理应该知道风险。但是好的开发者应该指出风险。最重要的是：如果出现故障，团队应及早报告。

什么是要做？

现在：将钱袋告上法庭

未来：请勿订立此类合同

Scrum不应归咎于管理失败。Scrum是根据许多IT项目失败的经验开发的。它不能防止失败，也不能治愈团队或管理人员的无能。基本思想是：

• 构建沟通方式（谁在什么时候与谁交谈）

• 鼓励开发人员尽早报告失败

• 在任务和子任务中划分问题

• 安排时间和能力（谁在什么时候工作）

• 在时隙上分配任务

• 使不可预测的部分更具可预测性（计划扑克）

或整体：将风险降到最低。

Scrum就像锤子一样是一种工具。它是否是一个好工具，取决于您对如何使用它的知识。但有时改锥更合适。由你决定。

首先，“谁来负责？” 是个错误的问题。指责是一件很有趣的事情，它可能会让所有人（除了被指责的人）都松一口气（“嘿，这不是我的错，老板这么说！”），但这并不是对时间的有效利用。 ，实际上可能适得其反，并导致员工士气下降。

一种更好的查看方法是“是什么导致了延迟？”。是否缺乏技术经验？在测试/质量检查中未检测到的严重错误？缺乏测试/质量检查？估计太乐观了吗？不考虑团队的不那么乐观的估计吗？有人被公共汽车撞了吗？无论是什么原因，下一个问题是“我们如何确保不再发生这种情况？”。在某些（希望很少）的情况下，答案可能是“摆脱某某某事”，但是如果您从“我需要惩罚负责任的人”开始，那么您不太可能看到大多数情况这不是正确的解决方案。

在项目中，您已经沉没了。截止日期来了又去了，您就警告客户，只要它明显滑倒（因为您确实这样做了，对吗？如果不是，那是问题的一部分），现在必须处理它，但必须清楚说明在合同中（实际上是在合同中阐明了，对吧？）。一般来说，这应该涉及与客户协商如何交付缺失的产品。许多人喜欢将合同视为无法更改的事物，但是面临以下两种情况之一：a）放弃合同，没有买到的东西，b）起诉公司违反合同并在法庭上花费大量金钱， c）谈判如何以尽可能少的麻烦获得产品，大多数公司选择c。

展望未来，在向客户报价或最后期限之前，您应该分析期限缩短或成本超支所涉及的风险（这种情况的可能原因是什么？您可以以某种方式缓解这些原因，而您不能并且只是这样做）进行计划），并使用这些信息来帮助您确定要承诺的目标。如果是100％或什么都不是的情况，您显然会引用更高的价格和更长的期限，因为风险更高。

您会发现，我在整个答案中都没有提到敏捷。这是因为（尽管这非常非常重要，我将忘记客户参与Scrum的一秒钟），但这并不重要。在敏捷，瀑布或您使用的任何开发过程中，您都将面临这个问题。是的，通过让您更早地了解风险是否已成为实际问题，并让客户参与流程本身，以便始终了解风险，敏捷可以帮助您更好地管理风险。但这不是万灵药。

首先，这是任何开发方法都存在的问题。至少在迭代开发系统中，您可以在截止日期结束时向客户展示一些东西，这可能足以获得扩展以完成产品的时间（即使客户不再支付更多费用！）。

在某些情况下，最后期限就是最后期限，请想象您正在编写游戏，并且绝对必须在圣诞节期间及时发布。犯错了使许多公司破产！

对于必须在特定日期之前完成一定数量功能的敏捷方法，scrum可能不是最佳的使用方法（因为我一直发现scrum会使开发速度变慢，并且不允许足够的敏捷性来改变流程。需要。

无论采用哪种方法，您都需要设置所需功能的待办事项以使进度可见。单次冲刺的进度还不够好，您不会知道自己是否达到了最终目标。因此，看板式的方法会更好：将所有功能设置在左侧，并通过系统进行操作以显示完成进度。

这使人们将注意力集中在Scrum无法处理的方式上仍然需要做的事情上，并使开发团队以外的其他人可以看到仍然存在的内容以及您是否有可能达到目标（从而尽早管理客户的期望） ，或在需要之前安排这些加班奖金）。

Scrum是一个永久地陶艺的系统，不断定义和完善某些东西。它根本不适合这种发展。其他人可以管理这种方式，并且仍然保持迭代的开发概念，看板就是这样，Crystal就是这样。但是必须理解的是，如果您虔诚地关注Scrum，那么您就不会敏捷。任何真正的敏捷系统都应该能够变型以应对这些特殊问题，这就是为什么它首先被称为敏捷，它是关于完成需要做的事情的，如果其中有固定的期限，那么您应该将其纳入您的工作方式。

开发范式与合同范式不同步。理想情况下，合同的编写方式会改变，但这不太可能真正发生。但是，即使您丢下混乱，您仍然会感到惊讶和错过最后期限（只有您可能会晚得多，因为您已经预先进行了所有设计，而且全都错了！！）。

在更改或不更改合同编写方式的情况下，您可以交付正在使用的内容。然后，通过吃掉一个开发周期来完成合同，以完成您尚未完成的功能。

您未能兑现承诺之日的承诺，这是否很好？不会，但是如果您能够按时交付可以正常工作的东西，然后比其他客户只是迟到并且根本没有东西给他们提供服务，那么您可以更快地交付其余部分，这会让您的客户高兴得多。

许多Scrum书籍和文章都说，失败的sprint（当团队无法完成Sprint Backlog的某些功能时）并不是一件坏事，它不时发生，并且如果团队从错误中吸取教训，这实际上很有用。并改善了以下冲刺中的一些功能。并且团队不应因未完成其承诺的工作而受到惩罚。

您“惩罚”这种行为的方式是限制未完成的任务可以完成下一个冲刺的工作量。从事凉爽产品的机会正在消失。做好工作的回报是更多的工作。

从开发人员的角度来看，这看起来不错，但是，我们有一家软件公司“ Scrum-Addicts LLC”为认真的客户开发一些产品（“ Money-Bags Corporation”）：

Scrum-Addicts经理建议为Money-Bags开发一款软件，他们同意一系列功能，Money-Bags要求提供发货日期Scrum-Addicts经理咨询其Scrum团队，该团队表示这需要3周的时间长时间的冲刺以完成所有功能Scrum-Addicts经理增加了1周的安全性，承诺在1个月内发布该软件，并与Money-Bags签订了合同。经过4个冲刺（截止日期），Scrum团队只能交付80％功能（由于新系统缺乏经验，需要修复生产环境中以前功能中的关键错误等）。正如Scrum所建议的那样，该产品目前可以发货，但是Money-Bags需要100％合同中提到的功能。因此，他们违反了合同，却一无所获。

Scrum-Addicts濒临破产，因为他们没有从Money-Bags获得任何收益，并且投资者对结果感到失望，不愿再为公司提供帮助。

如果在星期一我打赌给您100美元，它将在星期四下雨，直到星期五才下雨，您才可以提取我的钱。如果您想要天气预报而不是赌博，那么我们需要一份合同，该合同让我在星期二为您提供更新的天气预报。

显然，没有哪个软件公司愿意加入Scrum-Addicts的行列。我对敏捷和Scrum的不了解是，他们建议团队如何应对计划和截止日期，以避免上述情况。

想想为什么MB想要带球回家。MB不需要一开始就在一个月内完成工作。SA承诺在一个月内100％地提供关键功能，但没有兑现。SA设置的最后期限不是MB。SA甚至将最后期限任意增加了一周。那为什么是最后期限呢？

有时，在竞争工作时，软件公司会屈服于炫耀和承诺登月的诱惑。专业人士会仔细确定是否甚至需要月亮。对MoneyBags来说，最关键的需求是什么？一个月内100％的功能或功能正常的产品？他们甚至不知道真正重要的是什么？是否有一些即将到来的活动设定了严格的期限？

如果我是Scrum-Addicts商定此合同的人，我想对Money-Bags的业务需求有更多了解，并设计该合同以赋予Money-Bags可以接受的最大灵活性。我会教给他们敏捷过程如何工作，以便他们知道可以期望我们做什么。

通过这种方式，他们期望在1-2周内评估第一个可交付成果，而不是期望一个月内一切都能突然正常运行。

因此，总而言之，我有两个问题：

谁是罪魁祸首？经理，因为做适当的计划是他们的工作
团队，因为他们致力于做比
别人 更多的工作

在我们走了一个月的路程之前，任何人都可以阻止这种烦恼。

我甚至可以指责Money-Bags Corp雇用了一个明显欺诈性地将瀑布过程表示为敏捷的团队。合同本身明确表明这不是敏捷的。计划在一个月内完成并不能使其变得敏捷。

如果您坚持认为它是敏捷的，那么它只有一个月的冲刺就是敏捷的。是的，我不建议这样做，因为那又和瀑布一样。

什么是要做？

敏捷怎么样？每次冲刺都交付东西吗？在截止日期之前获得反馈？一周的冲刺？在您怀疑最后期限有危险而不是躲藏和祈祷的那一刻，重新谈判严厉的合同又如何呢？至少您可以停止在一个注定的项目上浪费时间，并找到一个更合理的客户。

经理应将截止日期推迟到原团队的估计值的2倍（或3倍）。

截止时间乘数与将手表提前15分钟设置一样有用，因此您永远不会迟到。您只能愚弄自己很久，然后才意识到自己在做什么。

早期估计是错误的。尝试捕捉错误。5个星期或几个星期是一个简单的表达方式，可让您表达完成日期的确切不确定性。您无需猜测准确，而是可以猜测您的猜测有多疯狂。做一些实际的工作并获取一些真实的数据。然后，您可以开始在较窄的范围内进行估算。一到两周的时间是足够的。

无论如何，都应鼓励团队成员尽心尽力（通过对冲刺失败进行处罚）

应鼓励团队成员。失败，提交或其他方式。研究表明，从事创造力工作（例如编程）的人如果提供以下三项内容，则表现最佳：自治，精通和目标，而不是建立任何惩罚性的结果，例如惩罚甚至是奖金（胡萝卜和棍子）。

丹尼尔·平克（Daniel Pink）对此做了TED演讲。演讲是关于动机不是敏捷的，但是我很容易看到如何将这些点映射到敏捷：

自治-我想控制自己的生活-让我从积压的工作中挑选工作。
精通-我想在重要的事情上变得更好-客户反馈。
目的-我想成为比我自己更大的事情的一部分-一个协作团队。

团队应该放弃Scrum，因为它不符合公司的截止日期政策，Scrum可以比瀑布更准确地达到截止日期。只要有最后期限，scrum就可以满足要求。根据时间，功能和技能的不同，它可能仅满足47个功能中的1个，但可以满足。

敏捷项目的样式可以设计得非常出色，以至于团队每晚回家的每个晚上都准备好发货。除非您认为运输要求客户进行测试并提供反馈，否则这似乎很愚蠢。发生的越早，您就越可以进行调整。这是每个可能的截止日期。只是不是每个功能。但这会将您引向重要的功能。

我们都应该放弃软件开发并加入修道院

是的，就像将我锁在远离现实生活的房间中一样，这会让我写更少的代码。

我已将这个答案缩小到最小。如果您好奇，请阅读编辑历史记录。

每个人都必须敏捷。无论您决定哪种方式，各方都将由谁来做什么，如何，何时，何地以及为什么。敏捷的客户，管理人员和开发人员。

您不能将发货日期定得太远。您给出一个估计。

需要有人来管理客户的期望。您不必担心会有几个冲刺落后的原因，是因为您进行调整以防止整个项目落后。如果经过一两次冲刺后得出的结论是您还没有完成“发货日期”，那就是告诉客户。

现在你想做什么？删除不需要的功能或移动日期。如果您可以按时交货，那您会的。不要犹豫，带来坏消息。

谁知道，在某些项目上，您可能会更早发货。

如果客户不愿意，您就不能敏捷。

目标

我认为以下两个“指标”应成为任何业务决策的基础：

• 该工作有利可图（对于客户）
• 我们工作效率如何

这些是非常普遍的。当然，它变得非常复杂，例如，获利的工作是关于产品做正确的事，用户能够使用该产品，正确销售该产品等。-对于这些“ Scrum-Addicts有限责任公司不承担任何责任。

问题

合同不关注上述目标。有一个“全有或全无”子句-完成所有工作并付款，或者什么都不做，不付款。但是，这与所创造的价值没有直接关系。随之而来的另一个缺点是：现在我们需要花费时间和金钱来确保并确认合同得到遵守。我们到底为什么要花这笔钱？当需求在此期间发生变化，并且我们发现订购的软件没有创造任何价值时，如何确保合同得到履行会有所帮助？有更多的钱要花光了！现在，当然，有这种现象的原因：

• 在文化上，我们习惯于购买类似的东西。我们希望像购买汽车一样购买软件：选择配置，有价格和最后期限，如果不能满足这两个条件，就会非常不满意。
• 我们想减轻风险和责任感
• 我们需要稳定性，它有助于规划并让我们感觉更好（还有我们的客户，这是重要的方面！）

归根结底，我们将不得不选择一个折中方案，这将使我们尽可能地实现我们的目标。

这应该是这样的

• 签订服务与工作合同，而不是产品合同
  • 需要在相对短的时间内终止
• 紧密合作以确保最佳效率
• 涉及来自“ Scrum-Addits LLC ”和“ Money-Bags Corporation ”的所有必要方-隧道化所有信息的“单一联系点”在这里行不通

好吧，我基本上只是说“敏捷”。现在，原因如下：

• 流程和合同经过优化，可以在目标上花费尽可能多的钱
• 您将不得不信任承包商来完成他的工作，而无需花费大量资金来证明他能胜任这项工作。
• 如果您的期望/合同得不到满足，起诉承包商的能力通常无济于事，因为这样做不仅要付出代价。这里主要关注的是上市时间。您很可能会因为上法庭而损失的金钱/业务多于获得的收益。
  • 在一天结束时，您只需要承担一些风险。