传统软件估算人天的方式, 有的使用 Functional Points, Delphi....等等。
敏捷开发, 使用数学黄金比例; 1, 2, 3, 5, 8, 13; 以各 User Stories 之间 "相对" 的复杂度, 估算各 User Stories 所需的人天。
然而, 只是改变个算法, 是毫无意义的……
软件开发, 存在着许多的误区,使得软件开发的效率与质量无法获得提升。其中之一的误区便是:期望用各式的人/天估算方法,使得开发人员, 可凖时的交付符合预期的软件。
我时常在提的一件事便是: 现今人类的科技再进步,但软件开发对许多人来说, 仍旧是件 “纯手工打造”的活。既然是 "纯手工打造",如何能用所谓的 “人/天”去预期符合期望的软件何时能交付?
所以,真正的重点, 不在于用何种方式去 “估算”人天。
真正的重点在于: 如何利用各 User Story的人天, 使得 Product Owner能充分掌握, 每个 Sprint的重点事项为何? 团队的风险为何? 某个团队成员到底出了什么问题?该制定何种有效的策略, Sprint计划, 才能带领团队发布出真正有价值的版本。
人/天,是用来供 Product Owner 做 “决策”用的, 不是用来 “简化管理”；将完全充满人类行为的软件开发,简化为制式, 单一的机器运作。
