喜欢和有效是两码事

[1000copy]

敏捷宣言和实践刚刚出来的时候，得到了非常多的认可，因为程序员很喜欢。

如今有人在反思，它是否真的象承诺的一样的有效，抑或不过是一场开心的狂欢。

以项目估计时间为例，有些东西有趣但是全无用处，比如 Scrum 的故事点，认真的话，大家不过是默默的把故事点转成小时或者天，不认真的话，估计完了该干嘛干嘛；有些则恰恰相反，看起来面目可憎，用起来却非常舒适。比如 delphi 背对背专家估计时间法。

我引入到团队中，给大家介绍的时候，会去掉专家两字，这样就面目稍微好看一点。我带着团队用这个估计方法，从怀疑懵懂到主动适应和使用，不过三五次就完成了这样的过渡。随着使用次数的增加和过程中解决问题，注意几个要点口诀，信心是逐步加强的。

估计时间这个事情，常用而令开发团队反感，因为不容易做的好。一旦找到方法，把事情做对了且做的不费力，那么就可以很好的和其他的团队协作。因为不管别人想要什么功能，你总是能比较快、无犹豫、可以经受考验的开发时间，也就是给出成本和代价。愿意承担的，那么干起来，不愿意的，就先搁置。

合作起来，爽快，不糟心。

回过头来说，干项目这件事，不仅仅是程序员，还有其他的工种和其他的人，仅仅讨好程序员自己是不够的。也就是敏捷联盟的致命之处。故事点不可靠，那么基于故事点的都不可靠，比如燃尽图。除了估计时间之外，还有不少硬伤。尤其是和其他工种配合的部分。这个可以相见，毕竟程序员有其自身的限制。

也有好的地方，Sprint 提出的快速迭代，一般 2 周到 2 月这个，思路非常好，实践起来也不错。它可以不让错误一直积累，而是给一个重启的机会，其实也是尊重了程序员作为工作主体的诉求，在我看来吗，这是敏捷的比较大的一个进步。然而，没有很好的故事分解的技术作为支撑的话，那么就很容易变成一个价值观而不是可行的实践，那就大打折扣了。

[GeekGao]

给团队制定发版计划：2 周一个版本。 固定这个节律，产品迭代速度特别稳。

[yesterdaysun]

个人理解: 敏捷里面, 快速迭代是最核心的价值, 2 周是一个合适的时间, 超出这个时间, 团队整体就会效率低下, 因为大家需要在一个不长不短的时间节点收到反馈, 互相沟通, 改进方案, 重启下一个迭代

所以估算任务也需要确保所有任务的点数在 2 周范围内完成, 如果超出, 就需要拆分任务到 2 周之内, 分解任务是确保估算准确的核心

虽然理论上故事点不该和天数挂钩, 但是确实事实上一定会挂钩, 只不过不同团队标准不一样罢了, 比如我会定每天的人力为 3 点, 一周 15 点, 2 周 30 点, 我会确保所有分解后任务在 15 点以下.
所以如果我估算一个任务 3 点, 意味着要 1 天做完, 估算 10 点, 大概 3 天做完, 15 点一周做完.

估算故事点的难点在于不同团队的任务是不一样的, 如果是维护型的任务或者 CRUD 之类的, 很好估算, 因为有参照, 但是复杂的任务, 非功能性需求, 或者探索性的任务是不好估算的,
这个时候给出的估算基本上就是纯凭经验, 相当于只是给一个截止日期, 想要准确的话就要 leader 参与分析, 给出他的估算, 最后决定, 不知道这算不算"背对背专家估计"

总之敏捷的核心我认为还是在快速迭代中去应对"变化", 即使我个人认同敏捷宣言中的各项价值观, 但是保不齐就是有人更喜欢文档,流程,计划,工具这些, 所以如何和这些人和谐相处合作, 也算是"敏捷"的一部分

[1000copy]

@yesterdaysun 背对背专家估计作为一个历史悠久用于预测的工作方法，它有些标准的定义和说明。这些内容显得冗长而且面目可憎。但是他的基本点非常不错。

那就是，对于高度被环境影响的社会问题，遵循数理统计，而不是确定性的计算。

确定演绎和数理统计的差别何在？

高中物理中力学问题走的路线，基本上是漂亮干净的数学，都是牛顿爵爷搞出来的东西，物理运动中的每一个参与的物体小到小球答道天体，都有高度的确定性。

还有一类问题，是热力学，应用数理统计方法。其中的每一个粒子高度不确定，但是作为整体表现出来的物理特性是有确定性的。

这样的方法是有效的。案例就在身边。计算机的底层的二极管三极管的输入输出 20%的计算误差算正常，而搭建的操作系统之上的层次，却可以表现出可靠的服务能力。

社会问题，人类协作，项目管理，咋一看混乱不堪，每一个人都有自己的想法，分别为自己奋斗或者躺平，但是整体社群有体现出确定性，这个社群，不一定是海量的人群，十几人和几十人也就是一个社群了。因此数理统计就比较合适。

背对背专家估计就是一种数理统计，看起来每一个专家都是不可靠的，然后搭在一起，一定的方法和组织，却常常提供稳定可靠的估计。当然，实际上我们看到的大量搭配的不好的，所以面目可憎。
以上说的都是理论。说说执行：
人少的项目团队，这个方法意义不大。多少人合适？我试过的 15 人以上的多个类型的团队中，不同的估计场景，效果还是不错的。人再少的，我没试过，因为动机不足。

估计场景类似这样：

1. 你们估下，这个能做不？
2. 还这么简单，你们这个迭代加进去行不？
3. 这个要得急，不加客户不买

要做估计，必须能够应对质疑，可能来自老板和协作团队：

1. 你的估计怎么来的？
2. 你的估计执行下去，是否真的误差不大？
3. 类似的功能，为什么你的估计前后看起来不一致？
4. 你们加个班，每天多工作八小时，是不是就可以减少一半时间？
5. 这个活一小时就干完了，怎么会需要 3 小时？

估计做的不好，你休想干干净净的干活。且任何一件质疑，没有现场有一个好的应对，或者经受不了时间的考验，你的估计方法会立刻被击溃，很难翻身。