QCon北京「鸿蒙专场」火热来袭!即刻报名,与创新同行~ 了解详情
写点什么

软件项目开发中的三个“不应做”事项

  • 2018-07-27
  • 本文字数:3541 字

    阅读完需:约 12 分钟

本文要点

  • 项目未按时间表完成,或是项目超出了预算,这是导致很多项目失败的原因。前期对项目做出预测,有助于避免从一开始就做出不切实际的承诺。
  • 在做出详细规划前,自上而下、基于范围的估算要比自下而上的规模估计和“猜测”更为有效。
  • 当项目处于初始规划阶段和推进阶段时,自上而下的估算工具有助于确立切合实际的项目边界。这对于设定期望和让利益相关者满意是十分关键的。
  • 通过过度增加人员实现压缩时间表,在很多情况下实现代价高昂,并且常常是无效的。项目经理可以使用自上而下的估算,对投资组合中的适当人员配置和资源需求做可视化。
  • 当项目由于利益相关者的需求或一些不可预见的情况而发生变化时(当然,项目不可避免地会发生变化),项目经理应重新做出预测,进而用于更新计划。

人们通常对“未雨绸缪”一词了然于胸,那么为什么企业却难以遵循这一原则呢?或许是因为人们已习惯于“快速行动起来完成工作”的做事方式。

问题在于,过快的项目推进实际上会导致成事不足,给软件项目带来很大的问题。面对来自于高层的压力,项目经理很可能转而采取仓促行事,跳过项目估算和前期规划。但是从我自身 30 多年的软件项目管理经验看,一个仓促进入开发阶段的项目很有可能注定会失败。

早在上世纪 80 年代,柯达曾致力于实现一种由软件驱动的文档成像解决方案,以此实现胶卷业务的多样化。企业在花费了一年半的时间、投入了数百万美元和大量的人力资源建立系统之后,他们找到我来做项目估算。估算结果显示,完成项目还需要两年的时间,并且还要投入更多的资金。如果预先做了项目估算,那么企业就有机会更好地评估项目的上市时间和投资回报率。反之,整个项目偃旗息鼓,浪费了宝贵的时间和资源。

一位同事曾与我分享过一个类似的悲惨故事。据他讲诉,几年前正值圣诞假期,一位顾客要求他在假期前提供一组合计 22 个估算。他们并不认可他给出的数据驱动估算,因此决定采取自己的方式。正是由于不合理的期望和时间表,他们的项目最终失败了。他们最终还是回头找到我的同事,按他的方式去正确做事。真应该祝圣诞快乐!

当前,一些企业也在犯着同样的错误。最近,一家企业开展了一项大型高强度软件开发项目。尽管他们扩充到 100 多名开发人员,但是由于内部压力以及一些不切实际的短期疯狂计划,他们决定放弃系统集成测试。由于缺少对质量影响和赶进度开发机制的评估,他们最终遗漏了很多系统缺陷。现在,企业正在重新做评估,一切从头做起。

当然,我们没有理由让历史继续重演。如果项目经理能关注那些“不应做”的事情,是可以避免一些会导致成本和时间超支的缺陷的,并给出创造真正价值的解决方案。

事项一:不应跳过估算匆忙进入详细规划,应采用自上而下的估算方法。

任何形式的计划,都好过完全没有计划。自上而下的估算,为详细计划过程提供了有价值的输入。

根据我的个人经验,设置不切实际的期望是项目失败的主要原因。制定准确的目标是企业的核心竞争力,但不少企业尚做得不尽如人意。

部分原因在于,企业在估算项目规模时,倾向于使用传统的范围界定过程,这往往会给出不准确的预测。项目经理在编制项目范围时,传统做法是采用一种自下而上的方式。管理者要求每个团队成员估算自己在特定活动中的工作时长,并根据这些“假设”确定每个成员的日程安排。不幸的是,这种自下而上的过程中缺少了一个关键的因素,那就是“事实”。一项基于 QSM 项目完成情况数据库的研究显示,有三分之二的公司未能比较计划的绩效与历史上类似项目的实际绩效。比较工作可让团队更好地了解完成工作所需的时间、精力和资金情况。他们竭力做出的估算,也许会导致错过最后期限、成本超支、客户不满意,以及开发人员被剥夺权利。

如果项目在开始时采用了自上而下的方式,那么一种非常有效的策略是基于范围的估算。借助于类似项目提供的数据,管理者可以准确地给出完成工作和交付完成工作产品所需的工作量。他们从一开始就全面了解项目的各项功能,并相应地分配资源。

当项目处于初始规划阶段和推进阶段时,自上而下的估算工具有助于确立切合实际的项目边界。如下图所示,一位项目经理具有一个由 10 位开发人员组成的团队,团队正在进行一个为期五个月的发布周期。在整个工作过程中,模拟软件显示了细化的 Backlog,其中给出了需要完成的约 100 个 Story 点。

进一步分析表明,尽管项目经理对团队生产力和劳动力成本的初步估计是有效的,但他可能无法将新的功能添加到建议的时间表中。由于计划是固定的,为了满足利益相关者的期望,项目经理需要聚集于如何调整产品功能和能力。团队可以使用模拟软件衡量实现所有100 个Story 点的概率。也许实现80 个Story 更现实,也许可以实现70 个Story。无论实现的Story 数量多少,至少这是利益相关者可以预期的。

其中并不存在任何主观猜测,一切估算都是基于经过验证的数据点。因此,自顶向下的估算方法可比传统的估算方法给出更准确的估算。团队可以设定准确的期望,在难以管理的时间期限内达到客户满意,降低开发团队交付解决方案的压力。

事项二:不应因为最后期限迫近,而做出增加员工的决策。

“厨子过多,反而做不出好的肉汤”,这是另一件人们常说的事情。然而,在面对日渐积压的最后期限时,许多项目经理的第一反应是为项目配备更多的人员。他们秉持的理念是,做事的人越多,事情完成得越快。

当然,这种做法几乎不会很好地发挥作用。为项目添加更多的资源,通常提高了项目的复杂性,并增大了出错的机会。更多的人员会导致沟通的不畅,这可能会增加缺陷,并导致返工。实际上,更多的人员通常会导致项目耗费更多的时间,而非节省时间。

项目经理可以使用自上而下的估算,对投资组合中的适当人员配置和资源需求做可视化展示。估算可在一段特定的时间内按计划和月份进行细分。他们甚至可以将员工按支出率划分,并与预算限额做比较,确保员工适合于特定项目,或是匹配组织当前的和未来的容量需求。下图可视化展示了估算随时间变化的情况。

事项三:不应为计划所奴役。

事先做好计划,并不意味着团队在整个开发过程中都无法改变方向。即便给出了最好的计划,但是大多数项目在其生命周期中,不可避免地会遇上一些未知因素,或是需要重新确定优先事项。或许管理层会要求添加一些新功能,或许一些团队成员将被转到其它更为关键的任务上。

不确定性虽然随时可能出现,但是它可以纳入到自上而下的计划过程中,从而降低其潜在的影响。本文前面给出的项目例子就是一个很好的证明。不确定性在于团队可能无法达成100 个Story 点。在计划中预先纳入这些不确定性,有助于规避项目早期的突发变化。

在整个开发过程中仍然可能存在一些波动,其中的大部分是由于利益相关者的需求的不断变化所导致的。例如,客户可能需要一些新的功能,以满足不断变化的市场动态。这些需求将不可避免地对开发产生直接的影响。团队需要在尽可能维持最初共识的情况下,做好调整的准备。

不幸的是,当前进的道路上蹦出这些意外障碍物时,许多组织不知道如何做出调整。估算是易于上下微调的(因此称之为“估算”),并且可以通过重新预测去适应不断变化的需求和动态。优先事项也是可以完全改变或移除的,以适应新的工作需求。项目范围也可以做改进,为利益相关者提供切实可用的更新后时间表,使项目保持正常进度。调整是一个动态的过程,可与组织推动敏捷开发的过程紧密结合。

做任何事情都一样,沟通在整个调整过程中至关重要。显示在屏幕上的数字在利益相关者的眼里无疑是福音,即使这些数字在开发过程中会发生波动。项目经理必须能够在项目一开始就有效地让利益相关者明白,他们的开发估算可能会根据许多因素而发生变化(具有讽刺意味的是,大部分因素都是由利益相关者的需求驱动的)。

此外,项目经理还必须表明,估算是在给定时间点(即项目开始时)对项目范围的一个最佳表示。团队将会努力按时、按预算,最重要的是按预期设计,交付所需的功能。

最后一点,也是最重要的,是我们应从以往的错误中吸取教训。这并非仅是将当前的项目与过去的一些努力做比较,而是应从柯达以及其它一些采取了错误步骤的组织中学习。一开始就做好计划,而不是遵循传统规范。这样,项目经理和开发团队才更有可能在不破坏时间表或超出预算的情况下,以客户期望的质量交付满足客户价值的软件。

作者简介

Lawrence H. Putnam, Jr. QSM 的联合首席执行官。QSM 是一家软件过程改进和系统开发评估领域的引领企业。Larry 的主要职责范围是监督 QSM 产品业务的战略方向,包括实现收入目标、战略产品方向、客户关怀和研究。Larry 在软件测量、估算和项目控制方面具有 25 年以上的经验。他于 1987 年加入 QSM,历经企业业务的各个方面,包括业务开发、客户支持、专业服务,已经当前的执行管理。

查看英文原文: Three Things to NOT Do with Your Software Development Projects

2018-07-27 17:571956
用户头像

发布了 391 篇内容, 共 142.0 次阅读, 收获喜欢 257 次。

关注

评论

发布
暂无评论
发现更多内容

Linux驱动开发-编写RFID-RC522射频刷卡模块驱动

DS小龙哥

4月月更

虎符即将引入稳定币USN 并开启USN专场活动

区块链前沿News

虎符交易所 稳定币

如何优雅的记录操作日志

flyhero

Java Spring Boot 后端 造轮子 4月月更

自己动手写Docker系列 -- 5.6实现删除容器

Go Docker 4月月更

2022南京14届-智慧工地-博览会

InfoQ_caf7dbb9aa8a

jackson学习之七:常用Field注解

程序员欣宸

4月月更

Sitemap的重要性

源字节1号

软件开发 网站优化

如何使用参数化查询提高Cypher查询的性能

华为云开发者联盟

参数化 Cypher查询 华为云图引擎 GES 参数化查询

企业如何搭建一个有效的知识管理系统

小炮

企业知识管理 企业知识管理工具

【PIMF】开源鸿蒙首款IDE低代码入门OpenHarmony应用开发

离北况归

低代码 OpenHarmony Openharmony啃论文俱乐部 OpenHarmony应用开发 可视化界面

龙蜥社区成立DeepRec SIG,开源大规模稀疏模型深度学习引擎

OpenAnolis小助手

深度学习 开源 龙蜥社区 sig 稀疏模型

Thinkphp6实现定时任务功能详解教程

CRMEB

云智慧10年资深架构师带你了解:普通程序员向架构师成长必经之路

云智慧AIOps社区

程序人生 架构师 Meetup 晋升 成长计划

web前端培训nginx配置规则

@零度

nginx 前端开发

2022南京14届-物联网-博览会

InfoQ_caf7dbb9aa8a

云效 Projex是什么?Projex企业级高效研发项目管理平台

阿里云云效

阿里云 项目管理 研发 敏捷研发 项目协作

基于Flink-CDC数据同步方案

领创集团Advance Intelligence Group

算法 java

48天打造你的专属 Twilio——浅谈运营商通信中台

网易云信

通信

大数据培训Hive如何控制map个数与性能调优参数

@零度

hive map 大数据开发

“一只股票一张表”, TDengine 在青岛金融研究院量化分析场景中的应用

TDengine

数据库 tdengine 物联网

解析分布式系统的缓存设计

vivo互联网技术

分布式 服务器 缓存服务

坐实大数据资源调度框架之王,Yarn为何这么牛

华为云开发者联盟

大数据 hadoop mapreduce YARN 资源调度框架

Docker 实战教程之从入门到提高(二)

汪子熙

Docker 容器 虚拟化 docker image 4月月更

Android技术分享| Android 中部分内存泄漏示例及解决方案

anyRTC开发者

音视频 内存 内存泄漏 移动开发 Andriod

java培训SpringBoot自动装配原理

@零度

JAVA开发 springboot

2022南京14届-人工智能-博览会

InfoQ_caf7dbb9aa8a

云图说丨不同区块链之间如何跨链交互?

华为云开发者联盟

区块链 跨链 可信 可信跨链服务 跨链交互

欧拉开发者大会即将开启,全球芯片、整机、软件厂商共建数字基础设施开源操作系统

科技热闻

OpenHarmony 3.1 Beta版本关键特性解析——OpenHarmony图形框架

OpenHarmony开发者

OpenHarmony 动画效果

react源码解析7.Fiber架构

buchila11

React

react源码解析8.render阶段

buchila11

React

软件项目开发中的三个“不应做”事项_文化 & 方法_Lawrence Putnam  Jr_InfoQ精选文章