如何在短跑计划中与离群程序员打交道？

Question

人们普遍认为，最好的程序员至少比普通程序员多出一个数量级。。这似乎会给通常的冲刺规划方法带来问题，这些方法主要是围绕评估和速度来进行的。

对于评估而言，伟大的程序员可能会投票给普通程序员。理想情况下，团队使用的是故事点，因此程序员更有可能同意故事的“相对复杂性”，但即便如此，伟大的程序员也更有可能知道一个工具/技巧，这将使他们能够简化问题。这支球队一般会作为一个整体投票，平均/多数获胜。这解决了不准确的估计-除非伟大的程序员拿出这个故事。

“但这不重要！”我听到你说，“伟大的程序员每次冲刺只会得到更多的故事积分”。这就引出了问题2。速度通常是为整个团队测量的，而不是个人来帮助平衡从sprint到sprint的差异。然后，速度被用作一种计算休假、开会时间等的比率。问题是，伟大的程序员不成比例地影响团队的速度。如果他们在度假，通过速度计算所做的工作将比预期的少得多。如果一个普通程序员正在休假，那么速度计算所做的工作将比预期的要多。

那么，在短跑计划过程中，如何处理这种不公平的表现呢？某种加权效应？只是让错误发生，然后随着时间的推移而消失？

Answer 1

估算(例如故事点)是根据典型程序员的时间和精力进行的。当你计算速度时，你要经过一组典型的程序员。这样做有以下几个原因：

1. 高点和低点应该平均下来。也许你有一个摇滚明星，但很可能你也有一个手指头。或者两个低于平均水平但不是很糟糕的程序员。
2. 即使是最好的开发人员有时也会感到困惑。我见过优秀的程序员在每项任务上花费了一半的时间，然后在一堵砖墙上，一个4小时的任务需要3天。也许是因为一个不可预见的困难，也许是开发人员遇到了个人问题，也许是他来工作的时候被困住了。谁知道呢。常有的事。
3. 速度可以根据以前的冲刺来改变。如果你知道你能做的比你想的要多，也许你应该计划一下(但不一定，看我的下一个观点)。
4. 所有这些都不重要，因为如果你走在前面，你总是可以从积压中提取故事，并提前完成。

继续做你正在做的事情，你的其他问题甚至都不会重要。如果你的摇滚明星占了你团队工作时间的20%，并且正在度假，那就少安排20%的短跑故事积分。只要你没有膨胀你的速度，这将自动补偿。

这里的关键是，您不只是孤立地查看每个迭代，而是一次安排整个项目一个迭代，以帮助平衡不可避免地发生的不规则现象。

Answer 2

老实说，我认为最好的答案是，没有什么好办法来解释这个问题。不过，这是一种“没有勺子”的情况。这是一个真正的问题，如果你把更多的重量，速度比它的实际持有。速度是对一个团队在冲刺中可以完成多少个故事点的估计。故事点是对所涉及的努力的估计，这是基于先前对您估计的类似任务所做的努力的估计。换句话说，这是对一个估计值的估计，这几乎就是你的小学数学老师在计算中引入四舍五入错误时对你大喊大叫的地方。

长短的是，速度比不知道要好，但坦率地说，并不多。你可以用它来预测完成日期，因为管理层喜欢艰难的日期，但它永远只是一个预测，如果你在最阳光的一天带着伞一整天，你会充分意识到预测往往是错误的。如果你在冲刺结束时有剩余的工作，那没关系。这可能是一个疯狂的概念，但这是你可以在回顾和学习，以便更好地估计未来。这支队伍没有失败，他们只是按他们的预测离开了。如果在sprint结束之前就没有工作了，那么总是可以添加其他的待办事项。仅仅因为你认为自己没有能力，并不意味着当sprint积压文件为空时，您就必须停止。把速度当作脆弱的测量，别担心。