快好知 kuaihz

浅谈软件项目规模估计——怎么估?

做事所花费的时间总是比你预期的要长,即使你的预期中考虑了侯世达定律。

—— 侯世达,哥德尔、埃舍尔、巴赫

周三的下午,我像平常一样,写着代码听着歌,突然从天而降一份莫名其妙的故事列表,说让我给个人天,用来投标用。作为一个技术异常牛逼的高端程序员,这对我来说岂不是 A Piece Of Shit…哦不,Cake。拿着列表,打眼一看就知道是做什么 — 又是个审批流系统。注册、登录、忘记密码…这些也需要时间?!哦,还要做个SSO,可能要做点数据集成,给个15人天吧!又是一堆CRUD… CRUD 各给2人天一共8个。看起来有4个 Model,乘个4,32个人天差不多。前端还有些工作量,找前端估一下…还有些跟遗留系统集成的部分,这块应该比较麻烦,给个30人天差不多…还要用微服务架构,估计需要一些基础环境,每个组件给3个人天,一共8个组件,算24吧….总共算起来130个开发人天,差不多,再加点buffer,算150吧!差不多了吧…

这一幕是不是有点眼熟?不过,这样的做法可能会带来下面的几个问题:

1. 估计者的估计点数是否能代表团队的估计点数?

问题的答案显而易见。那么有同学会说,此时团队的人员还没完成配置,没办法让真实团队进行功能的估计。确实是这个样子,所以我们只能力所能及的去模拟真实团队进行估计。一般,交付项目的团队肯定不会全上非常有经验的同学,人员配比一定会有 leverage,也就是 Senior 人员和 Junior 人员的比例。所以,在估计的过程中,至少要引入 Junior 的同事,能够从不同经验的角度来看待同样的问题,来使估计不会过分“乐观”。

2. 是否有故事卡片之外的工作时间没有考虑到呢?

上文中的估计看起来是采用的经典的“理想人天”估计法,如果使用这样的估计方法,势必要考虑一些虽然没有在故事卡工作量中,但也一定会花费时间的事务,包括但不限于:

回复电子邮件(沟通成本)

面试(内部耗损)

参加会议(包括内部会议,比如站会、Retro、Code Diff、技术研讨会议、客户沟通会议等)

为当前发布提供支持(上线支持)

培训?(内部的 Session)

任务之间切换/被人打断(程序员出栈入栈的消耗…)

修复bug(一定会有 Bug,一定会花时间修…)

写各种文档(对于对文档比较看重的客户,这一部分会占用不少的时间

这些事务会伴随整个交付过程中发生,基本上都是正常交付必不可少的工作内容,而且根据笔者的经验,这些事情占据的时间并不比完成故事卡的编码工作要少。

3. 故事卡的需求是否清晰呢?

在项目启动前拿到的故事列表,往往只有 Epic 级别的,也就是很粗粒度的故事卡。故事卡中的 AC(Acceptance Criteria,验收条件)往往只考虑了最简单的 Happy Path,然而大部分项目中(尤其是 ToB项目),Exception 才是相对复杂的,这些异常情况往往需要花费更多的时间完成。在这种情况下进行估计,可想而知,一些隐藏的需求点往往难以发现。

问题可能的答案

那么想要解决上面的问题,或者说更好一点的缓解上述问题的方案是什么呢?《敏捷估计与规划》中介绍了一些基本的方法。

首先,要进行集体估计

集体估计可以缓解因为个人能力不同所引发的单点偏差,不同的开发成员对于某个需求在不同角度的阐述,也容易让大家对需求有更全面的理解,也易于发现潜藏在需求中的风险。阐述的过程中,出现复杂问题时,可以及时联系相应的专家资源。对于一些规模较大的卡片,也可以综合大家的意见,进行更合理的拆解。同时,需要由要做次工作的人来进行估计,这样会产生更多的责任感,可以在一定程度上缓解乐观估计的问题(Lederer and Prasad 1992)。

其次,是方法

《敏捷估计与规划》介绍了2种基本的方法:理想人天法和故事点法。

(1)理想人天法

理想人天法就是直接把故事卡估计成理想人天。所谓理想人天,就是“在需求非常明确的情况下,进行编码、测试工作所花费的时间”。就好像篮球比赛一样,每节12分钟,4节总共48分钟,这是比赛的理想时间。但是谁都知道,一般NBA每场比赛都要2个半小时左右,比赛激烈的话三个小时都有可能,比赛真正持续的时间与理想时间是有较大差距的。相比于篮球比赛,软件项目“场外”的工作就更多了,除了上面问题2列出的那些实务之外,像是方案变更引发的大量沟通、集成联调、测试过程中的需求讲解、项目的交接等等,这些工作也需要算到项目时间之内。同时,对于同一个项目,不同的人根据其能力、经验的不同,会有不同的理想人天。

所以在估计完理想人天之后,如何进行实际人天的换算,在实际应用中,仍然是个大问题,所以…最好就不要用了。

(2)故事点法

故事点法就是按照故事卡的规模和难度,给予每张故事卡一个点数。注意,这里的点数代表的不是所需的人天,而更多的是难度系数。

开发人员因为自己技能、经验、能力的不同,解决同样的问题,所花的时间差别是很大的,但对规模的估计却是一样的。就好比从北京到上海,坐飞机1个多小时,高铁5个小时,步行要…一个月左右吧,距离是一样的,根据不同的速度,会花费不同的时间

同时,人们一般很难对一个规模进行准确的估计,比如从北京到上海的绝对距离是多少,估计没几个人知道。但是,人们能够比较容易的比较两件事物的差距或者说倍数关系,比如:北京到上海的距离跟从上海到香港的距离是差不多的,这个距离是北京到郑州距离的两倍。所以我们在做估计的时候,可以按照难度系数分成几波,然后在内部在进行一些比较和排序,然后按照比较的差距分配一个规模点数,比如1、2、3、5、8、13。

大家可以看到,这个规模点数并不是连续的数字,而是采用了菲波那切这一个神奇的数列。这样的数列有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)的部分,通过这种方式来缓冲项目里程碑的风险。

(2)进度缓冲

进度 Buffer,是用来缓冲估计之外的异常情况引发的项目时间的拉长。进度 Buffer 根据项目的不确定性的差异,计算的方法和结果会有较大差异,有兴趣可以参考《敏捷规划与估计》,这里就不赘述了。不过根据 Leach(2000)准则提出的建议,至少要保持整个项目的20%以上,否则也许不能为整个项目提供足够的保护。

不是总结的总结

上面的这些方法能一定程度的规避风险,给开发团队带来一定的空间,但过分的强调估计和交付计划的准确性,会带来更深层级的问题:

output over outcome。客户更关注功能列表的完成,而不是产生的业务价值。

开发团队会倾向于裁剪用户故事的功能,3个点的故事卡,尽量控制在规定时间内完成,即使可以花更多时间把事情做的更好。

控制需求变更。可以进行需求变更,但这个过程更像是一个异常的情况,而不是喜闻乐见的。

当我们发现了更好的业务点、idea时候,会倾向于隐瞒,以免额外的业务功能会增加工作量。需求变更往往会涉及客户谈判的事情,尤其是当客户观念是传统的供应商管理策略:我来控制需求的全景,能多做点就多做点。

在客户合作和谈判的天平上,客户关系会向谈判的方向倾斜。

估计和计划会使团队和客户更多的聚焦在工作量,而不是工作的价值上。如果能够引导客户从 output 导向的思维转变到 outcome 导向上,那么团队就不用再疲于奔命的完成那些并不会用到的feature上,而是可以有更多的时间去提升产品质量,进一步提升业务价值。

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:估计  估计词条  规模  规模词条  项目  项目词条  怎么  怎么词条  软件  软件词条  
产品

 我们应该从裁员浪潮里看到什么?

2016年以来,大量创业公司倒闭,而且在这个下半年愈演愈烈。身边也有好些朋友因为倒闭潮被离职,这些人里面有刚出校门拿到高薪的产品经理,也有跨越不同行业的人。这些...(展开)