|
理想人天法就是直接把故事卡估计成理想人天。所谓理想人天，就是“在需求非常明确的情况下，进行编码、测试工作所花费的时间”。就好像篮球比赛一样，每节12分钟，4节总共48分钟，这是比赛的理想时间。但是谁都知道，一般NBA每场比赛都要2个半小时左右，比赛激烈的话三个小时都有可能，比赛真正持续的时间与理想时间是有较大差距的。相比于篮球比赛，软件项目“场外”的工作就更多了，除了上面问题2列出的那些实务之外，像是方案变更引发的大量沟通、集成联调、测试过程中的需求讲解、项目的交接等等，这些工作也需要算到项目时间之内。同时，对于同一个项目，不同的人根据其能力、经验的不同，会有不同的理想人天。项目管理者联盟
所以在估计完理想人天之后，如何进行实际人天的换算，在实际应用中，仍然是个大问题，所以…最好就不要用了。项目管理者联盟
(2)故事点法项目管理者联盟
故事点法就是按照故事卡的规模和难度，给予每张故事卡一个点数。注意，这里的点数代表的不是所需的人天，而更多的是难度系数。项目管理者联盟
开发人员因为自己技能、经验、能力的不同，解决同样的问题，所花的时间差别是很大的，但对规模的估计却是一样的。就好比从北京到上海，坐飞机1个多小时，高铁5个小时，步行要…一个月左右吧，距离是一样的，根据不同的速度，会花费不同的时间。项目管理者联盟
同时，人们一般很难对一个规模进行准确的估计，比如从北京到上海的绝对距离是多少，估计没几个人知道。但是，人们能够比较容易的比较两件事物的差距或者说倍数关系，比如：北京到上海的距离跟从上海到香港的距离是差不多的，这个距离是北京到郑州距离的两倍。所以我们在做估计的时候，可以按照难度系数分成几波，然后在内部在进行一些比较和排序，然后按照比较的差距分配一个规模点数，比如1、2、3、5、8、13。talent.mypm.net
大家可以看到，这个规模点数并不是连续的数字，而是采用了菲波那切这一个神奇的数列。这样的数列有2个好处，一个是不会出现连续的倍数关系，比如4点的故事卡片是2点故事卡片的2倍;其次是表明出规模越大的卡片，其不确定性也承递增趋势，所以会给更高的点数。项目管理者联盟
有了故事点数，我们仍然无法判定项目什么时间能够交付，因为缺少一个“速度”，也就是团队的开发速度。如果面对的是一个成熟的团队，并且使用类似的技术栈，且与客户的合作模式基本相同的话，那么可以参考前一个项目的速度，来进行交付时间的计算。但如果面对的是全新的客户、不同的技术栈，以及完全重新配置的团队，那么速度基本是不可估的。这时候，有时候会根据
Tech Lead 和 PM
的(Pai)经(Nao)验(Dai)，进行硬估：把每个点数转化成N个人天。比如1个点数需要2个人天，那么100个点数的项目就是200个人天。当然，这种方法…说多了会掉泪。项目管理者联盟
最后，给项目加些缓冲(Buffer)项目管理者联盟
一般来说，面对这种情况，本着对客户和我们自己负责的态度，需要给项目加一些缓冲区(Buffer)。Buffer
分两种，一种是功能Buffer，一种是进度 Buffer。项目管理者联盟
(1)功能缓冲项目管理者联盟
增加功能 Buffer，简单来说，就是把全部的故事列表进行估计，假设得到总点数是100点;然后按照优先级进行排序，挑出其中的MVP，要少于总量的
70%，作为必须要做(Must Have)的部分。剩下的 30% 作为做了更好、不做也不影响主要功能(Nice To
Have)的部分，通过这种方式来缓冲项目里程碑的风险。bbs.mypm.net
(2)进度缓冲项目管理者联盟
进度 Buffer，是用来缓冲估计之外的异常情况引发的项目时间的拉长。进度 Buffer
根据项目的不确定性的差异，计算的方法和结果会有较大差异，有兴趣可以参考《敏捷规划与估计》，这里就不赘述了。不过根据
Leach(2000)准则提出的建议，至少要保持整个项目的20%以上，否则也许不能为整个项目提供足够的保护。项目经理博客
不是总结的总结pmp.mypm.net
上面的这些方法能一定程度的规避风险，给开发团队带来一定的空间，但过分的强调估计和交付计划的准确性，会带来更深层级的问题：项目管理者联盟
output over outcome。客户更关注功能列表的完成，而不是产生的业务价值。training.mypm.net
开发团队会倾向于裁剪用户故事的功能，3个点的故事卡，尽量控制在规定时间内完成，即使可以花更多时间把事情做的更好。项目管理者联盟
控制需求变更。可以进行需求变更，但这个过程更像是一个异常的情况，而不是喜闻乐见的。项目管理者联盟文章
当我们发现了更好的业务点、idea时候，会倾向于隐瞒，以免额外的业务功能会增加工作量。需求变更往往会涉及客户谈判的事情，尤其是当客户观念是传统的供应商管理策略：我来控制需求的全景，能多做点就多做点。项目管理者联盟
在客户合作和谈判的天平上，客户关系会向谈判的方向倾斜。项目管理者联盟
估计和计划会使团队和客户更多的聚焦在工作量，而不是工作的价值上。如果能够引导客户从 output 导向的思维转变到 outcome
导向上，那么团队就不用再疲于奔命的完成那些并不会用到的feature上，而是可以有更多的时间去提升产品质量，进一步提升业务价值。项目管理者联盟
作者：张久坤，ThoughtWorks高级咨询师。程序员出身，参与过多个国内外大型项目的交付工作，对敏捷有深入的理解，目前专注于敏捷项目的业务分析和项目管理的工作。项目管理者联盟
talent.mypm.net
来源：人人都是产品经理项目管理者联盟
|
