内联脚本被视为是有害的_承诺被认为有害

内联脚本被视为是有害的

一些敏捷的传福音者非常热衷于“承诺”的概念。 也就是说，开发团队“承诺”在一个时间范围内（通常是迭代）进行大量工作。开发团队会在地狱或繁重的工作中完成这项工作。 他们做需要的事。 一旦他们说他们会做，他们就会做。

我相信承诺的思想已经渗透到Scrum中–例如，请参见Larman，Benefield和Deemer撰写的Scrum Primer 。 我听说Jeff Sutherland亲自宣布了承诺的力量。 但是现在看来，Scrum不太喜欢它。 在2011年10月“的Scrum指南”由Schwaber的和萨瑟兰不包含单词提交或承诺 ，所以我想“承诺”是Scrum的不再一部分。 谁知道？

我一直怀有对承诺的怀疑（例如，从去年开始，请参阅“敏捷和Scrum中潜伏的文化差异”和“我扭曲，疯狂，错误的敏捷版本” ，从2010年开始， “填充迭代的两种方法” ），但是现在，我将进一步讲说， 用于填充迭代的承诺协议在短期内不会对软件开发团队造成积极损害 。 重新评估是由以下因素引发的：a） 在Twitter上观看#NoEstimates讨论； b）团队尝试遵循承诺协议时拜访客户。

1. 承诺会导致开发者缺乏承诺的动机进行游戏（我在“两种填充迭代的方式”中的观点）。
2. 承诺会导致需求/业务方面的博弈，他们有动机促使团队过度承诺
3. 承诺与速度测量和任务估计相结合，导致将工作安排到冲刺的方式混乱而又不透明，因为（第一和第二位）开发人员过度估计了故事和任务，而业务代表施加了减少估计的压力。 这样可以防止自由浮动的点数和速度变成战场。 （积分是法定货币 ，如果您不允许它在某处浮动，则必须提供货币支持；开发人员会加班，或者更可能是计量不准确。）
4. 在一个客户的承诺下，Sprint的前一半（测试人员处于工作状态）导致繁忙的开发人员，然后随着Sprint接近尾声，非常繁忙的测试人员与开发人员将事情变得轻松了一点。 除了开发人员也向测试人员提供错误外，大量的错误使开发人员忙于开发，但是这意味着一个Sprint并没有真正关闭，因为每个Sprint都包含错误。 在纸上，冲刺关闭的那一天，冲刺完成了，但是很快就需要返工。 也有人怀疑，随着sprint即将结束，测试人员降低了接受阈值，并且在sprint之后，开发人员和测试人员都提出了更少的探测问题，这些问题可能会造成破坏。
5. 开发人员在承受甚至施加自我压力的压力下，可能会选择偷工减料，即让漏洞通过。 错误昂贵且具有破坏性。
6. 要求开发人员提交的要求在sprint开始之前提供更多详细信息。 一种“掩盖自己的屁股”的态度扎根，商店开始类似于旧的功能要求以及所带来的所有旧问题。
7. 开发人员对用户故事和接受标准持防御态度，并说“标准中不包含您的错误，因此我没有这样做”（“掩盖自己的态度”的另一端）。
8. 尚未完全掌握“测试驱动开发”的开发人员会被诱惑甚至被激励去跳过这种做法，以便更快地进行开发。 从短期来看，它们甚至可能走得更快-积累了“技术债务”-但从长远来看，它将走得慢得多。
9. 相反，业务/客户没有动力来支持TDD的开发采用或自己投资自动化验收测试（ATDD，BDD，SbE等），因为毕竟开发人员是有决心的。

也许我应该说，我目前相信估算可以工作，我对#NoEstimates观点表示同情，但是我有一些客户在估算工作所在的地方，一位经理声称可以使用估算“将项目付诸实践”。 所以我很难调和#NoEstimates与经验。

#NoEstimates参数的一部分是，“估计”很容易被误认为是“承诺”，当这样做时，不能指望团队兑现这些承诺，但是有些人会这样做。 显然，如果您删除承诺，那么传输机制将被删除，估计可能仍然有用。

尽管我一直怀疑上面的大部分内容需要花费我一段时间才能得出这些结论。 在某种程度上，这是因为我看不到有很多团队真正在履行承诺。 我见过的大多数球队都在英国，我一直认为承诺是一个非常美国的想法-它始终在我的脑海中创造出美式橄榄球队的形象- “为吉普车赢得胜利” 。

实际上，我看到的大多数团队都是我所教过的团队，所以他们不这样做。 （老实说，他们会对Xanpan进行一些修改 ）。 在谈论承诺时，我在讲授Velocity协议，它是Xanpan的估算和速度。 （我希望很快就能在Xanpan上发布我的笔记，因此加入列表 。）

参考： 敏捷，精益，模式博客中的JCG合作伙伴 Allan Kelly 认为该承诺有害 。

翻译自: https://www.javacodegeeks.com/2013/07/commitment-considered-harmful.html

内联脚本被视为是有害的