Scrum和动机

Question

在创建任务时间时，如何阻止开发团队填充数字？如果没有真正的最后期限，那么他们如何有动力去做他们的工作呢？他们只是根据他们的速度来衡量。

在此截止日期前完成工作

VS

每当我们减少范围，质量或增加资源时，都要完成工作

Answer 1

大多数敏捷方法的基础是 trust 。如果你不相信你的团队，你为什么一开始就雇用他们？如果你认为他们不能胜任这项任务，那么最好不要启动项目，因为它几乎肯定注定要失败 - 要么是因为你是正确的，团队是一群无能的开发人员，要么是因为你错了但是你缺乏信任和过度控制会扼杀团队，实际上削弱了他们的承诺和热情。

OTOH如果你确定你已经聘请了最优秀的人才，并且他们才华横溢并且有动力，最好是给他们一个很好的挑战，让他们工作并试图从他们的方式中消除所有障碍。

根据我的经验，大多数开发人员开始热情并积极地创造他们可以引以为傲的产品。然而，不可能的最后期限，不切实际的期望，过多的官僚主义，过度控制的管理 - 以及最后但并非最不重要的，降低质量 - 可以迅速扼杀这种动力。

敏捷方法的关键在于开发人员是了解/估计特定功能成本的合适人选。如果管理层坚持估算两者分配给项目的资源，范围和时间，那么它几乎总会导致灾难。如果OTOH给予开发人员信任和责任，他们通常会完成任务。在Scrum中，团队共同制定了估算并解决了冲刺期间出现的问题/问题。在一个好的项目中，团队成员很快就会与团队凝聚，他们对项目负有个人责任。这可能会导致落后的成员产生结果，而不是拉回团队。

Answer 2

根据我的经验，由于不确定性，开发人员填补数字。您的产品所有者是否明确其业务要求？这些故事是否足够小，无法估计？

你的两个选择向我表明你对Scrum有一个根本的误解。 Scrum的承诺并没有得到相同的结果，只是更快。它能够快速迭代，响应反馈并改变路线。 Scrum的基础是自我运行的团队。如果您没有自己信任的团队，Scrum可能不适合您的组织。

正如佩特在回应中所说，团队激励是关键，最快捷的方法就是破坏他们。如果团队认为管理层不支持或不相信他们，他们就没有理由做出积极的估计，而只会掩盖他们自己的屁股。作为经理，你的职责是帮助他们成功。

Answer 3

此外，敏捷方法可以促进同行的责任。你不应该只有一个人估计项目。使它成为一个团体的东西，并确保（大多数）每个人都同意估计。如果你让你的整个团队串通起来反对你估计，你会遇到比你想象的更多的问题。

此外，还有很多机会在传统的瀑布式/ BDUF（大型设计前期）工作中填补估算值并找借口。我想说，scrum，每天的scrum会议，有助于控制它，而不是它有助于促进它。

Answer 4

我写了一篇关于估计反模式的博客文章。这是一个有趣的阅读，但可悲的是，所有的模式都是我从同事那里看到或听到过的。我们目前的项目中已经完成了其中的三个;我认为没有任何团队可以完全避免所有这些！

http://lizkeogh.com/2009/11/30/estimation-anti-patterns/

还要研究系统思考，博弈论和反常激励。如果开发人员正在填补估算值，那是因为他们所处的环境正在鼓励他们这样做。改变这种环境将有助于他们。

Answer 5

已经有了这个问题的好答案。基本上，如果你认为开发人员会通过报告时间来欺骗你，他们实际上并没有工作（但是花在玩任何MMORPG现在都很流行）为什么你甚至在第一时间与他们合作？如果你相信他们，为什么你认为他们“垫”？

顺便说一句 - 对于刚接触Scrum的团队来说，首先高估（并且必须从Sprint中丢弃物品），然后 - 因此被烧毁 - 低估以避免再次发生这种情况，这是完全正常的，然后正如其他人指出的那样团队速度将趋于平稳，人们将更好地了解他们在冲刺中可以做多少。

还有一个暗示你可以做什么：不要质疑他们的工作时间，不要试图通过告诉他们这个或那个应该花多少时间来“管理”它们。相反，问他们他们想要如何实现这个或那个，他们想要使用什么解决方案以及为什么？对于优秀的极客来说，他们倾向于过度工程是很常见的 - 如果事情看起来比你预期的要大，那么这里可能存在一个误解，即需要清除的是什么。

Answer 6

实际上很难在scrum中“填补”估计值。在几次冲刺之后，速度将平均，团队将“知道”它可以承诺多少点。没有什么可以填补的。

我认为你的陈述是向后的，因为

  

每当我们减少范围，质量或增加资源时，都要完成工作

是瀑布的精确描述;不是scrum。在Scrum中我们有截止日期，它被称为sprint的结束。在scrum我们从不牺牲质量因为我们知道从长远来看会花费更多。在Scrum中，我们不会添加资源，因为我们知道人们凝聚并组成一个“团队”并且扰乱这种平衡会对生产力产生不利影响。

为什么你在任务时间里一直在烦恼？我唯一一次看到好的开发人员估计是他们被迫对一个未知特征进行估计。我们不会在scrum中这样做。在我们承诺之前，我们知道接受特征的条件是什么。

Answer 7

完全避免这种情况的一种方法是估计故事点，即问问题“与故事相比，这个故事需要更多或更少的工作吗？”。

Answer 8

根据我的经验，开发人员很少填写估算值。开发人员的总体趋势实际上是低估了复杂性和努力。