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