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

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

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

周三的下午,我像平常一样,写着代码听着歌,突然从天而降一份莫名其妙的故事列表,说让我给个人天,用来投标用。作为一个技术异常牛逼的高端程序员,这对我来说岂不是 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。

功能缓冲

增加功能 Buffer,简单来说,就是把全部的故事列表进行估计,假设得到总点数是100点;然后按照优先级进行排序,挑出其中的MVP,要少于总量的 70%,作为必须要做(Must Have)的部分。剩下的 30% 作为做了更好、不做也不影响主要功能(Nice To Have)的部分,通过这种方式来缓冲项目里程碑的风险。

进度缓冲

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

不是总结的总结

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

  1. output over outcome。客户更关注功能列表的完成,而不是产生的业务价值。
  2. 开发团队会倾向于裁剪用户故事的功能,3个点的故事卡,尽量控制在规定时间内完成,即使可以花更多时间把事情做的更好。
  3. 控制需求变更。可以进行需求变更,但这个过程更像是一个异常的情况,而不是喜闻乐见的。
  4. 当我们发现了更好的业务点、idea时候,会倾向于隐瞒,以免额外的业务功能会增加工作量。需求变更往往会涉及客户谈判的事情,尤其是当客户观念是传统的供应商管理策略:我来控制需求的全景,能多做点就多做点。
  5. 在客户合作和谈判的天平上,客户关系会向谈判的方向倾斜。

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


更多精彩洞见,请关注微信公众号:思特沃克

Share

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

预测是一件非常困难的事情,尤其是预测未来。—— 尼尔斯.玻尔

玻尔

定制化软件开发是一件复杂的事情,尤其是目前我们主要提供的端到端软件交付,它极大拓宽了软件开发的生命周期,更加着眼于业务价值,但这也增加了整个设计、分析、交付过程中的复杂度。软件交付已不仅仅是传统意义上的技术交付,更包括了体验设计、业务分析、测试、管理、运维、运营支持、以及流程管理的内容。

基于笔者几年浅薄的软件交付经验,尝试总结在初期进行规模估计的时候,应该考虑的范围会有哪些。

体验设计

在笔者看来,在互联网产品的影响下,目前客户对体验设计的要求已经到了“奢侈”的程度,经常对仅有几十个、甚至几个用户的系统提出很多关于体验式上的较高要求。但人毕竟是视觉动物,好的展示效果、使用体验往往是产品的加分项,能带来比较大的口碑收益。同时,这也是最容易跟客户(尤其是业务客户)产生交流和互动的地方,有利于跟客户的深入沟通,特别是这些终端用户还经常是项目重要的 Stakeholder。

在端到端交付中,设计人员会参与项目的整个交付过程,从最开始的 Discovery 一直到产品的上线,从与客户沟通设计需求,到方案设计、方案确认,再到开发过程中与开发人员、业务人员协同方案落地,从源头到落地保证方案的准确性。

功能性需求

在敏捷软件开发中,系统的业务功能会从终端用户的业务价值交付出发,被拆解为一个个用户故事,形如:

故事卡模板

全部的业务功能会形成一个用户故事列表,来从更细的粒度上描绘业务全景。 这部分是项目规模估计中最重要的一部分。所以业务分析和拆分的整个过程要非常非常非常的仔细,因为初期的这个故事列表很可能会成为对客户的一个承诺,未来如果发现不在故事列表中,但也必须要做的重要支撑功能时,就需要增加跟客户协商谈判的成本,或者默默的认了。

在拆分完成进行复检时,敏捷团队(而不仅仅是BA),可以问自己下面这几个问题:

  • 客户所处的行业是什么?本行业有没有固定的业务领域模型?客户想做的是哪个模型的扩展?
  • 有没有类似的竞品可以参考?
  • 有没有考虑系统交互的全部的用户角色?
  • 有没有系统自动推进、不需要用户交互的任务?
  • 有没有考虑全部的业务场景?正常的场景和异常的场景?
  • 每个场景的每一步是如何对接的?具体的详情是什么?是否可以进行进一步拆分?
  • 每个环节使用的用户数量是多少,会有性能要求么(精确到每个指标)?
  • 系统边界是什么?待开发系统和待集成系统各自完成的业务功能是什么?
  • 是全新的系统,还是需要与旧有系统做数据迁移,逐步替代?是否有逐步替代的计划和方案?

拆分方法可以参考《庖丁解牛:产品需求分析》,在这里就不展开了。

非功能需求

除了功能需求外,非功能需求更要引起重视,这往往是项目容易忽略、掉到坑里的地方。

考虑到我们开发的往往是 Web 或者 Mobile的产品,最基本的,要考虑:

  • 浏览器的兼容性问题:兼容哪些浏览器,兼容版本。
  • 移动端的兼容性问题:兼容哪些手机设备,操作系统,版本号。

除此之外还包括:性能,可维护性,可测试性,可用性,可移植性,可扩展性等,项目太多就不展开了,这里单说下性能。

性能是个比较容易量化的需求,比如同时并发访问的人数、页面读取时间等。对于一些用户量较大、高并发的场景,可能需要做多级的性能调优:从应用代码级别、到数据库级别,再到部署架构级别,甚至CDN缓存级别,都可能成为需要考虑的部分。这部分根据项目的情况不同,差异会很大。有的项目可能并不需要投入太多精力在这上面,只需要对其中明显的性能问题进行一些修复,但有的项目可能整个项目都在满足性能上的要求,所以不可不察。

技术架构

有些项目,客户会比较看重我们对产品架构的设计能力。这个时候,技术架构不仅仅需要简单满足短期项目的诉求,还需要有更长远的规划。在这种情况下,前期 Inception 的时间不能支撑整个项目技术架构的设计和搭建,可能是需要更长时间的设计和演进,这部分可以作为独立的工作来进行估计。部署架构亦然。

开发部署环境

同时,为了能够支撑持续集成/持续交付,整个交付过程往往需要一系列的开发、测试、上线的环境,包括但不限于:CI环境、开发环境、QA环境、SIT环境、UAT环境、Pre-Prod和Prod环境。如果这些没有预先准备好的话,这些环境的准备工作也会花不少时间,尤其是当同时涉及客户内网和外网的情况下,甚至会成为项目的严重风险。

与三方的集成

集成往往不是个小问题。目前的软件项目,往往都是基于现有的系统进行开发,所以集成的工作必不可少。如何进行契约的制定、数据的迁移、其它供应商三方系统开发工作的推进、接口的集成联调等,往往都是项目全周期的工作重点。一定从项目第一天开始就要思考持续集成、持续交付,万不可把这部分工作留到最后处理,血泪经验之谈。

测试

敏捷项目中的测试,跟传统的先开发、再测试的这种方式极为不同的一点是:没有固定的 Tester,而是全员来保证软件的质量。测试包括的范畴也比较广,目前项目中的标配包括了:

  • 自动化测试:单元测试/集成测试/功能测试
  • 迭代内探索性测试
  • 业务回归测试
  • 性能测试
  • 安全测试
  • 代码质量测试

这些测试根据项目规模、复杂度的不同,规模估计上会有较大差距。就比如安全测试,有的系统是面对企业内部用户使用的,仅部署在内网,这样仅实现内部权限控制即可,一般不会有安全问题,安全测试的粒度也可以适当放粗;但有的系统要部署在互联网上,供终端用户使用,此时安全测试不仅仅要考虑应用层面的权限隔离,还要考虑网络层面的防火墙、防攻击策略等。这部分可以由专业的安全专家提供建议方案,看如何合理的将测试任务放到总的规模估计中,并与客户提早达成一致。

验收交接流程

这部分是比较容易忽略的,主要包括了软件的整个验收流程、代码交接、文档撰写工作,根据情况不同,可能会使项目延长1周~4周不等的时间,在项目之初也要考虑到。

总结

在初期进行规模估计绝不是一件容易的事情,需要跟客户的深度沟通,敏锐的洞察力,多角色的思考,以及快速的判断,否则后面。。。

Share