早在 2000 年 3 月，Joel 就在他的 blog 中提及到进度计划问题。他当时关注的问题，如今在传统和敏捷软件开发团队中都很普遍，主要包括：
- 很难及时地跟踪评估的准确性
- 计划中的任务必须是细粒度的
- 人们普遍觉得计划刚写出来就已经过时了
- 开发人员缺乏做进度计划的意愿
几乎所有的程序员都不想要进度计划。根据我的经验，绝大多数人希望根本没有进度计划。而少数人做了进度计划，却只是为了应付老板。除了高层管理者，没人真正相信这个计划。而高管们一边坚信存在 UFO，一边却又相信“不存在按时完成的软件项目”。
那么为什么没有人做进度计划呢？有两个关键原因。一是做进度计划真的很痛苦。二是人们都认为做进度计划没有意义。如果进度计划没法做对，何必费那么大功夫去弄它呢？既然已经看穿进度计划总是一贯错误的，而且随着时间的推移只会更糟，干嘛要无谓地受苦呢？
基于实据的日程计划方法（Evidence Based Scheduling，EBS）试图以团队（或成员个人）历次评估的准确性为依据，为团队管理者预测在某一日期完成计划的可能性。同时鼓励团队用更小粒度的任务（最多 16 小时）来制定计划，而不是一星期的任务，这样才能取得团队效率方面有事实依据的历史数据。
你把那些来源于历史数据的信息再反馈到进度计划。那么，你所得到的就不仅仅是一个计划日期啦：
你得到的是一个充满自信的分布曲线，显示出在任一日期交付的可能性。
在 Joel 提出的这个方法中，创新之处是运用了 Monte Carlo 方法来生成对可能性的统计，它将开发者所作评估的准确性的历史信息应用于对交付日期的预测。结果可以被画在一张图上，以便非常直观地告诉项目管理者，项目可能在什么时间交付：
有证据表明，这项技术已被郑重地应用于这一领域，最近被 FogBugz 6.0 采纳也表明它的应用越来越广泛。然而，这一方法依赖于细粒度的任务管理，因此要求团队管理更偏向于控制——与敏捷方法推崇的人性化的自组织团队背道而驰。
在您的团队中有使用 EBS 的经验吗？如果有，其结果和现实相匹配吗？
FogBugz 6.0 可以用托管服务的形式按月购买，也可以安装到自己的主机。
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论