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

#1 楼

我在您的示例中看到了几个基本的管理问题：


如果Scrum-Addicts经理签署了“硬期限”合同，但在以下情况下仅增加了33％的安全边际“涉及新系统”，这是相当鲁ck的。
一个月后提供至少x％功能的可用性本可以用于协商合同，即当客户在截止日期前仅获得80％功能时，客户至少要部分付款。全有或全无的合同是软件供应商和客户都不会从中受益的-这不仅意味着供应商0钱，而且客户0功能。而且诸如“瀑布”之类的全有或全无的开发方法只会让您编写此类合同，而敏捷的方法则提供了更多的可能性。
看看头一个或两个冲刺的结果应该对管理者显而易见团队无法按时完成任务。因此，他应该早点采取措施，重新安排其余任务和功能的优先级，或者尝试早些时候与客户重新谈判。例如，经理可能试图缩小某些剩余功能的范围，因此团队可以交付合同中提到的所有功能，但每个功能都在缩小的范围内。

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

#2 楼

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


客户通过合同谈判进行合作


Scrum- Addicts LLC谈判了合同而不是与客户建立了合作关系，这使我对他们的敏捷性提出了质疑。

很明显：敏捷需要被所有人接受。敏捷不仅适用于开发人员。管理人员和客户还需要接受敏捷宣言的价值。如果客户不接受敏捷性，仍然需要严格的合同和最少的协作，则要么不使用敏捷性，要么寻找更好的客户。

客户的错是他们被锁定在合同泡沫之内，而截止日期是-驱动的开发。

#3 楼

谁应该责怪？如果没有100％满意就不用付一毛钱，应该像敲响瀑布声和敏捷思维一样响起立即响起的警钟。

客户想要吃蛋糕并吃蛋糕-他们很高兴接受瀑布，小瀑布，敏捷，拉拉土地，只要它们在日期Z之前以$ Y的价格获得产品X。从方法论的角度来看。思维差异只会在洗净中浮出水面，是如意算盘。

#4 楼

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个月内发布该软件，并与Money-Bags签订了合同


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

应该责怪谁？

1）管理

如上所述：风险管理显然存在失败。如果公司濒临破产，那么公司应得的。如果您在这样的公司工作：请离开！一个好的经理应该知道风险。但一个好的开发人员应该指出风险。
最重要的是：如果出现故障，团队应该尽早报告。

现在该怎么办？

现在：将“钱袋”告上法庭

对于未来：不要签订此类合同

管理不为失败负责。 Scrum是根据许多IT项目失败的经验开发的。它不能防止失败，也不能解决团队或管理人员的能力不足。
基本思想是：


构建沟通方式（谁在什么时候与谁说话）
鼓励开发人员尽早报告故障
将任务和子任务中的问题划分
以构造时间和容量（谁在什么时候工作）
在时隙上分配任务
使不可预测的东西（计划扑克）更加可预测。

或总体而言：最大限度地降低风险。

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

#5 楼

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

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

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

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

您会注意到我在这里没有谈论敏捷整个答案。这是因为（虽然这非常非常重要，但我会暂时忘记客户参与Scrum的时间），这并不重要。在敏捷，瀑布或您使用的任何开发过程中，您都会遇到此问题。是的，通过让您更早地了解风险是否已成为实际问题，并让客户参与流程本身，以便始终了解风险，敏捷可以帮助您更好地管理风险。但这不是万灵药。

#6 楼

首先，这是任何开发方法都存在的问题。至少在迭代开发系统中，您可以在截止日期结束时向客户展示一些东西，这可能足以获得扩展以完成产品（即使客户不再支付更多费用！）。 >
在某些情况下，最后期限就是最后期限，请想象您正在编写游戏，并且绝对必须在圣诞节期间及时发布。犯错了使许多公司破产了。

对于必须在某个日期之前完成一定数量功能的敏捷方法，scrum可能不是最好的使用方法（正如我一直发现的那样）

无论采用哪种方法，您都需要建立一个积压的必需功能以使进度可见，而Scrum会使开发人员的工作变慢，并且不允许足够的敏捷性在需要时更改流程。每次打印的进度还不够好，您不会知道自己是否达到了最终目标，因此看板式的方法会更好：将所有功能设置在左侧，然后通过系统进行操作以显示完成进度。

使人们的思想集中在Scrum无法处理的方面仍需完成的工作，并允许开发团队以外的其他人查看还剩下什么以及您是否'有可能达到目标（从而尽早管理客户的期望，或安排加班奖金b在需要它们之前。）

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

#7 楼

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

更改或更改合同的方式后，您将交付自己正在使用的内容。然后，通过吃掉一个开发周期来完成合同，以完成您尚未完成的功能。

在承诺的那一天，您未能兑现承诺的一切，这很好吗？不会，但是如果您可以按时交付可以正常工作的东西，然后比其他客户只是迟到并且根本没有东西给他们提供服务的话，则可以在以后更快地交付剩余的东西，您的客户会更加高兴。

#8 楼

许多Scrum书籍和文章都说，失败的sprint（当团队无法完成Sprint待办事项中的某些功能时）并不是一件坏事，它不时发生，并且如果团队有效从他们的错误中学习，并在接下来的冲刺中改善一些东西。而且团队不应因未完成他们所承诺的工作而受到惩罚。


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


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

Scrum-Addicts经理建议为Money-Bags开发一款软件
他们同意一系列功能，并且Money-Bags要求提供发货日期
Scrum-Addicts经理咨询了他们的Scrum团队，该团队表示需要3周的冲刺来完成所有功能
Scrum-Addicts经理添加了1为了安全起见，我们承诺将在1个月内发布该软件，并与Money-Bags签订合同。
经过4个冲刺（截止日期），Scrum团队只能提供80％的功能（由于对新系统缺乏经验，需要修复生产环境中以前功能中的严重错误等）。
正如Scrum所建议的那样，此产品可能已经出货文件，但Money-Bags需要100％的功能，如合同中所述。因此，他们违反了合同，却一无所获。公司了。


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


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


想想为什么MB想要带球回家。 MB不需要一开始就在一个月内完成工作。 SA承诺在一个月内提供100％的关键功能，但没有交付。 SA设置的最后期限不是MB。 SA甚至将最后期限任意增加了一周。那么，为什么这是最后期限呢？专业人士会仔细确定是否甚至需要月亮。对MoneyBags来说，最关键的需求是什么？一个月内100％的功能或功能正常的产品？他们甚至不知道真正重要的是什么？是否有一些即将到来的活动设定了严格的期限？

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

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


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

谁应该责备经理？
经理，因为做正确的计划是他们的工作
团队，因为他们致力于做更多的工作
其他人


在我们还不到一个月的时间之前，任何人都可以制止这种烦恼。

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

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


要做什么？


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


经理应将截止日期推迟到原始团队估计的时间两倍或三倍。 。


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

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


应当鼓励团队成员无论做什么都要做他们所做的所有工作（通过对冲刺失败进行处罚）。应鼓励团队成员。失败，提交或其他方式。研究表明，从事诸如程序设计之类的创造性工作的人，如果具备以下三项才能做到最好，那就是：自治，精通和目的，这是最好的。

Daniel Pink发表了TED演讲。演讲是关于动机而不是敏捷，但我很容易看到如何将这些点映射到敏捷：

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


团队应该放弃Scrum，因为它不符合公司的截止日期政策
Scrum可以比瀑布更准确地达到截止日期。只要有最后期限，scrum就可以满足要求。根据时间，功能和技能的不同，它可能只具有47个功能中的1个，但它可以满足。回家就可以发货了。除非您认为运输要求客户进行测试并提供反馈，否则这似乎很愚蠢。发生的越早，您就越可以进行调整。这是每个可能的截止日期。只是不是每个功能。但这会引导您使用重要的功能。


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


对，就像把我锁起来一样在远离现实生活的房间里会让我写更少的代码。

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

#9 楼

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

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

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

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

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

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

#10 楼

目标

我认为以下两个“指标”应该成为任何业务决策的基础： >我们是否在尽可能高效地工作？

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

问题

合同未集中于上述目标。有一个“全有或全无”子句-完成所有工作并付款，或者什么都不做，不付款。但是，这与创造价值没有直接关系。我们到底为什么要花这笔钱？同时，当需求发生变化并且确保发现订购的软件无法创造任何价值时，如何确保履行合同会有所帮助？ />现在，这种行为当然是有原因的：


从文化上讲，我们习惯于购买这样的东西。我们希望像购买汽车一样购买软件：选择配置，有价格和最后期限，如果不能满足这两个条件，我们将非常不高兴。
我们希望减轻风险和责任感
我们需要稳定性，它可以帮助您进行计划，并使我们感觉更好（还有我们的客户，这是重要的方面！）

最终，我们必须选择一个折中方案将使我们尽可能地满足我们的目标。

这就是它应该如何工作的方式


需要在相对短的时间内终止



紧密合作以确保最佳效率
使“ Scrum-Addits LLC”和“ Money-Bags Corporation”的所有必要方都参与进来-贯穿所有信息的“单一联系点”在这里行不通

好吧，我基本上只是说“敏捷”。尽可能达到目标
，您将不得不相信承包商能够胜任其工作，而无需花费大量资金来验证他是否能胜任这项工作。 /合同未达成通常是无济于事的，因为这样做不仅要付出代价，还需要付出更多。这里主要关注的是上市时间。您很可能会因上法庭而失去比自己所能获得的更多的金钱/业务。 br />