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 无法在规定的时间内完成时, “人天预估不准确” 是问题的表象? 还是问题的根因?