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

1 评论 7958 浏览 23 收藏 10 分钟

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

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

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

体验设计

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

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

功能性需求

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

故事卡模板

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

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

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

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

非功能需求

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

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

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

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

性能是个比较容易量化的需求,比如同时并发访问的人数、页面读取时间等。对于一些用户量较大、高并发的场景,可能需要做多级的性能调优:从应用代码级别、到数据库级别,再到部署架构级别,甚至CDN缓存级别,都可能成为需要考虑的部分。

这部分根据项目的情况不同,差异会很大。有的项目可能并不需要投入太多精力在这上面,只需要对其中明显的性能问题进行一些修复,但有的项目可能整个项目都在满足性能上的要求,所以不可不察。

技术架构

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

开发部署环境

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

与三方的集成

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

测试

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

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

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

验收交接流程

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

总结

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

 

作者:张久坤,ThoughtWorks高级咨询师。程序员出身,参与过多个国内外大型项目的交付工作,对敏捷有深入的理解,目前专注于敏捷项目的业务分析和项目管理的工作。

题图来自unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!