这是敏捷开发一千零一问系列的第三十篇。(在这里提问,之一,之二,之三,问题总目录)
续前文,预计未来还要有一篇,暂时做为中篇。
方案
方案一:用早期功能点估算法进行报价或早期制定项目计划
这个在之前谈到过很多次了,具体可以参考敏捷开发绩效管理系列的之六、之七。另外在敏捷开发用户故事分类与组织结构(一期) (整个活动1期)中有详细描述。
这个是国际上迄今为止唯一被大规模推广使用的方法,中国即将发布的国标就是基于这个的。现在世界上有6000多认证的功能点估算专家,中国只有2个(本人不是),所以显得不太出名。这可能是软件界中外差距最大的一个知识领域了。
方案二:用敏捷扑克防止大规模的代码和工作量浪费
几种错误做法
可不是用了扑克牌就是敏捷估算的,比如下面的玩法:
1. 随机抽一张牌,是多少就是多少
这个是最快的扑克牌估算,很快,还没有争议。但相信没有人喜欢,所以“快”不是我们敏捷估算的目的。
2. 各自出一张牌,加在一起除以人数
这个听起来理智多了,还很民主,很有点放权的意思。是不是正解?嗯……如果有人出1,也有人执意出100人天,怎么办?(1+100)/2 = 50.5?看来,民主和放权也未必是正解。
3. 不用扑克,主动领取,谁干谁说了算,自己估算的自己干着才带劲
这个听着也很敏捷,放权,激励,承诺……都有了。不过,不管是不是敏捷,如果前面那几位4000行和19万代码的来了,那就完了。不管高手有多厉害外加多热情,代码冗余不可避免;而新手在写下一份简历的时候,大概在想:我这两年做的事情,实际上被一个家伙两个月重写了。
这里有个标准问题了:到底是选择符合敏捷标准的,还是符合最小代码和工作量的?
是我会选择后者。毕竟敏捷是来服务我们的,不是让我们来“遵守”或“追随”的,如果都伤害了团队和项目的利益,就算它是敏捷又如何。