敏捷开发下该怎样正确的看待人/天这件事?

传统软件估算人天的方式, 有的使用 Functional Points, Delphi....等等。

敏捷开发, 使用数学黄金比例; 1, 2, 3, 5, 8, 13; 以各 User Stories 之间 "相对" 的复杂度, 估算各 User Stories 所需的人天。

然而, 仅仅是改变个算法, 是毫无意义的……

软件开发, 存在着很多的误区,使得软件开发的效率与质量无法获得提升。当中之中的一个的误区便是:期望用各式的人/天估算方法,使得开发者,
可凖时的交付符合预期的软件。

我时常在提的一件事便是: 现今人类的科技再进步,但软件开发对很多人来说,
仍旧是件 “纯手工打造”的活。既然是 "纯手工打造",怎样能用所谓的
“人/天”去预期符合期望的软件何时能交付?

所以,真正的重点,
不在于用何种方式去 “估算”人天。

真正的重点在于: 怎样利用各 User Story的人天,
使得 Product Owner能充分掌握, 每一个 Sprint的重点事项为何?
团队的风险为何?

某个团队成员究竟出了什么问题?

该制定何种有效的策略, Sprint计划,
才干带领团队公布出真正有价值的版本号。

人/天,是用来供 Product Owner
做 “决策”用的,
不是用来 “简化管理”；将全然充满人类行为的软件开发,简化为制式,
单一的机器运作。