User Story 无法在规定的时间内完成, 都是估算人天的方法不对惹的祸?

当User Story无法在规定时间内完成时,许多人的第一反应便是: User Story 估算的方法不对, 所以, 需找一个可 “准确” 估算人天的方法◦

1) 首先,我想任何解决问题的方法,  都没有对错,只有因果◦

       当 User Story无法在规定时间内完成时,我们可以花更多的时间去做 User Story工作量的评估◦ 这绝对是个 “对”的方法, 而这个 “对”的方法, 最终所带来的最大且唯一的价值便是: 证明我们大家都能如期交付 User Story;证明大家都没有做错事◦

      但真正的重点是:证明我们大家都能如期交付 User Story;证明大家都没有做错事,与能高效的交付符合使用者预期的产品间,是否就能划上等号? 我想这才是我们大家, 真正该去严肃面对与深度思考的问题◦

 2) 回到估算人天这件事◦

       软件开发目前还是个纯手工打造的工作◦

       天底下的任何事只要是牵扯到有人类行为的介入,就只能以 “概率”; “高斯曲线”来预估, 预测人类行为的模式或发展◦

      所以,估算人天较为合理的作法应该是:同样的一个需求项 (专题或 User Story)在不同的估算人天数下,会达到的 “概率”是多少?

      也就是说, 某一个需求项 (专题或 User Story),预估可在 20 人天完成的概率是 10%, 预估可在 8 人天完成的概率是 50%,而预估可在 2人天完成的概率是 0%.....等等◦

      唯有经由如此合理但颇为费劲的作法,才能建立起团队开发效率的高斯曲线,客观的 “预估”出, 团队成员的开发人天完成的 “概率”;而非所谓 “准确”的完成天数◦

      所以,敏捷开发期望一切化繁为简,一切以 “人”为本; 以人的主动性来代替耗时且依旧无法提升效率的估算人天模式,以人的主动性来决定 User Story该完成的天数◦ 正因为如此, 敏捷开发中所估算的人天,其中的主要目的, 是要排定迭代内 User Stories的优先级, 而非告诉开发人员, 你有多少人天可以做开发?

3) 我们大家需要深度思考的另一个问题是:我们今天是以问题的表象做决策?还是以问题的根因做决策?

     当 User Story无法在规定的时间内完成时, “人天预估不准确”是问题的表象? 还是问题的根因?