作为一名软件开发项目管理者，我们常常被各种不靠谱的项目开发工作量评估工作所拖累，被团队成员提出的看似合理的不同想法所牵绊，更被客户不断表达的抱怨所淹没。我们是否清楚这些每天发生的问题已经在很多行业和学术界得到了解决。
20年前就听说有一本布鲁克斯撰写的《人月神话》，讲述在大规模软件开发项目中利用“人月”来评估开发工作量的问题，并且在从需求评估到系统开发、以及上线支持、持续运营，每个环节都存在着大量的技术障碍和资源浪费。作者至少指出了三大核心问题：
1、软件开发不同于流水线生产，以标准的“人月”无法准确评估开发的工作量与难易程度，特别是跨业务跨技术的复杂项目。这里存在各种变量，包括开发人员数量和投入时间、工程师能力、团队协作度、技术复杂度、需求变化性等。
2、软件从需求分析到设计开发，再到运营运维，都涉及不同职能的团队进行协作与交互，沟通协作成本极高。产品经理可能很懂客户和市场需求，但不懂具体技术实现；架构师可能很懂技术框架和主流方法工具，但无法兼顾需求变化和持续改进；开发工程师很懂实现逻辑与编码语言，但难以支撑后续长期运维工作。由此带来的问题是各个板块割裂，资源重复投入，沟通协作低效。
3、大型软件工程项目周期长，导致需求或目标已经变化，但我们依旧还处于滞后的功能开发，最终交付成果也无法满足业务需求。由于技术迭代速度快且前期投入较大，一旦项目交付使用，后续再变更或重构的成本极大，甚至高于原本实施初始成本。
为了应对以上问题，随着实践和理论的螺旋式发展，依次提出了新的管理思路。
1、多维度全方位的“人月”评估，发展出更多方法和角度，以期更全面的掌握项目的各类场景，人月变成人天、增加工程师级别与技能矩阵、添加风险项等。同时发展出了基于功能点、WBS工作拆解、历史数据或参考数据、代码编写量等。
2、Devops就是一组过程、方法与系统的统称，用于促进应用程序/软件工程开发、技术运营和质量保障部门之间的沟通、协作与整合。重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
3、敏捷开发简化了繁琐的流程和文档管理，主张团队内部的面对面沟通和交流。以Scrum为代表，简单、持续集成、不断交付、价值优先、拥抱变化的原则在面对时刻变化的市场经济和不断发展的技术时变得友好。在进行开发任务评估时采用的是相对估算而不是绝对估算，为风险留足了应对空间。同时，Scrum集合了一线人员的参与，经验分享，集思广益，将小型团队转化成独立的管理者，更有利于问题的解决。
网友评论