浅谈软件项目规模估计：估什么？

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

定制化软件开发是一件复杂的事情，尤其是目前我们主要提供的端到端软件交付，它极大拓宽了软件开发的生命周期，更加着眼于业务价值，但这也增加了整个设计、分析、交付过程中的复杂度。软件交付已不仅仅是传统意义上的技术交付，更包括了体验设计、业务分析、测试、管理、运维、运营支持、以及流程管理的内容。
基于笔者几年浅薄的软件交付经验，尝试总结在初期进行规模估计的时候，应该考虑的范围会有哪些。

体验设计

在笔者看来，在互联网产品的影响下，目前客户对体验设计的要求已经到了“奢侈”的程度，经常对仅有几十个、甚至几个用户的系统提出很多关于体验式上的较高要求。但人毕竟是视觉动物，好的展示效果、使用体验往往是产品的加分项，能带来比较大的口碑收益。同时，这也是最容易跟客户（尤其是业务客户）产生交流和互动的地方，有利于跟客户的深入沟通，特别是这些终端用户还经常是项目重要的 Stakeholder。
在端到端交付中，设计人员会参与项目的整个交付过程，从最开始的 Discovery 一直到产品的上线，从与客户沟通设计需求，到方案设计、方案确认，再到开发过程中与开发人员、业务人员协同方案落地，从源头到落地保证方案的准确性。

功能性需求

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

故事卡模板
全部的业务功能会形成一个用户故事列表，来从更细的粒度上描绘业务全景。 这部分是项目规模估计中最重要的一部分。所以业务分析和拆分的整个过程要非常非常非常的仔细，因为初期的这个故事列表很可能会成为对客户的一个承诺，未来如果发现不在故事列表中，但也必须要做的重要支撑功能时，就需要增加跟客户协商谈判的成本，或者默默的认了。
在拆分完成进行复检时，敏捷团队（而不仅仅是BA），可以问自己下面这几个问题：

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

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

非功能需求

除了功能需求外，非功能需求更要引起重视，这往往是项目容易忽略、掉到坑里的地方。
考虑到我们开发的往往是 Web 或者 Mobile的产品，最基本的，要考虑：

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

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

技术架构

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

开发部署环境

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

与三方的集成

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

测试

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

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

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

验收交接流程

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

总结

在初期进行规模估计绝不是一件容易的事情，需要跟客户的深度沟通，敏锐的洞察力，多角色的思考，以及快速的判断，否则后面……
 
作者：张久坤，ThoughtWorks高级咨询师。程序员出身，参与过多个国内外大型项目的交付工作，对敏捷有深入的理解，目前专注于敏捷项目的业务分析和项目管理的工作。

关键字：产品经理, 规模估计, 软件项目

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！