【AICon】AI 基础设施、LLM运维、大模型训练与推理,一场会议,全方位涵盖! >>> 了解详情
写点什么

讨论:从客户的角度衡量敏捷项目的成功

  • 2008-02-13
  • 本文字数:2006 字

    阅读完需:约 7 分钟

最近在 Scrum Development 用户组中发起了一场精彩的讨论:“客户该如何衡量敏捷项目的成功?”讨论重点放在了“衡量”二字上。看起来各方意见就“客户应该能够以他们自己的方式来衡量成功”这一点达成了一致,而且也得出了一些衡量标准。但没有最好的方式,只有最适合具体情况和客户的方式。

传统软件开发方法论中包括多种矩阵:质量矩阵,如每个发布的缺陷率;计划矩阵,如实际的工作量 / 天数与估算工作量 / 天数之比,又如交付里程碑的完成情况;还有成本矩阵,如预算与实际成本之比。

但是,绝大多数敏捷开发组织在收集和上报衡量标准相关数据的能力上表现薄弱,并因此而为人所诟病。他们确实有一些技术开发衡量标准,例如 checkstyle(译者注:一个 Java 程序源代码风格检查工具)发现的错误,测试代码覆盖率,NCSS(译者注:一款分析统计软件)等等,这些标准对客户而言却没有太大的吸引力。

以客户的角度来衡量项目成功至关重要,因为纵使开发团队遵守正确的流程,最终结果也未必是客户想要的。可能会南辕北辙。

Mike Dwyer 说道:

你这个问题跟外科医生的问题一样:如果我遵守所有的步骤行事,之后病人的生死便与我无关,这种情况下我算是称职吗?我的回答是,你的目标是什么?一个康复的病人还是成功的过程?

在这种情况下,如果最终结果跟我们理智上的期望相同,病人痊愈了。这时我们就可以称之为一个拥有成功过程的成功项目。

Vikrama Dhiman 提供了另一个例子:

我的项目可能是打算造起 1000 层的高楼,我希望把它卖给联合国——团队自组织的非常好,他们也帮我及时意识到自己的远景目标——但联合国不打算买下它,我也不想把它卖给其他人。这个项目是成功的吗?我也许会说是。那这个最终产品是成功的吗?我会说不。那是谁的错?理所当然是产品负责人(Product Owner)的问题。

这里,团队可能正确地遵守了所有的过程,但却可能造出错误的产品。产品负责人应该被指责吗?是的。团队应该被指责吗?是的。客户满意吗?当然不。

那么有没有办法可以让客户衡量一个敏捷项目的成功与否?正如上面几位所述,这个问题的答案与展示一个伟大的过程毫无关联。

有几个人建议说,如果客户满意的话,那他就会认为这个项目是成功的。但“满意度”却很难量化和衡量。在 Agile India 用户组中也有一个类似的讨论,在该组的讨论中得出了几个比较主观的衡量标准用来衡量客户满意度。如果以下情况满足的话,那客户就是满意的:

  • 他得到了项目预期的商业价值。
  • 他能够根据商业需要来调整路线,所发布的功能在发布的那一时刻更有价值。
  • 他能够给出早期反馈。
  • 他能够为特性 / 故事制定优先级,从而在恰当的时刻得到恰当的功能。
  • 他能够在所有的功能被实现完以前终止开发,因为他意识到剩下的功能可能永远都用不到。
  • 他与开发团队之间建立了双向的信任关系。
  • 他在项目过程中没有碰到出乎意料的事情。
  • 他觉得在项目上的投资物有所值。

也有其他几个人认为,在团队启动项目之前,有一个对于完成的定义是很重要的。客户和团队应该能够对一个故事的完成达成一致。一旦团队决定了如何才算“完成”,那么就可以由此来衡量客户满意度和使用其他几个矩阵了。

Mike Dwyer 补充说:

有一个对于完成的简单定义:到 sprint 结束时,团队的工作被客户验收通过,这部分工作就完成了。在这一点上,所有的工作和相关成本就从浪费变成了价值。这就回答了这几个问题:“从计划上来看我们走了多远?(产品 backlog——累计验收的工作)”和“从预算角度来看,我们目前干得怎么样?(完整计划预算——实际成本)”。它同样还回答了这些问题:“我们的效率如何?(全部实际成本 /已完成任务的计划成本)”和“我们的资金消耗率 [译者注:burn rate,一家新公司在赚取营运现金流前消耗创业资金支付日常开支的比率] 怎么样?(每个验收或是已完成任务的平均成本)”。

Scott Ambler 认为应该使用主观衡量标准和客观衡量标准的组合。他建议团队应该先开始收集一些基本信息,例如:

  1. 实际成本(时间,金钱,等等)
  2. 一些交付的功能(用例点,用户故事点,等等)
  3. 缺陷趋势
  4. 相关干系人满意度

通过这种方式,团队就可以用业务词汇(最基本的就是花销和系统能力)跟业务人员沟通,同时还是继续跟踪那些关系到开发成败的衡量标准——如质量。度量相关干系人的满意度也是最重要的衡量标准之一,无论是不是敏捷团队都应该把它引入项目。交付的代码没有缺陷,不一定就意味着交付的软件具备价值。

这里既有主观标准,譬如客户满意度、客户看法;也有客观标准,如已完成的故事、成本、缺陷趋势,它们组合起来帮助客户判断一个敏捷项目的成功与否。

这个讨论看上去在“遵守正确的流程不是最重要的”这个观点上形成了共识。在流程以外,还需要有主观和客观的检查,用以确保项目会走向成功,客户会满意。开发团队需要根据给定的场景来进行选择:是任取其一,还是兼容并蓄?关键是怎样做能够收到最佳成效。

查看英文原文 Discussion: Measuring Success of an Agile Project from the Customer’s Perspective

2008-02-13 19:071040
用户头像

发布了 197 篇内容, 共 52.6 次阅读, 收获喜欢 20 次。

关注

评论

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

践行自主可控3.0,真正开创中国人自己的开源事业

极狐GitLab

git DevOps gitlab 自主可控 极狐GitLab

详解SQL中Groupings Sets 语句的功能和底层实现逻辑

华为云开发者联盟

数据库 sql 聚合函数

现在加盟自助洗车是否还来得及

共享电单车厂家

自助洗车加盟 加盟自助洗车 车白兔自助洗车

无人自助洗车机投放选址有啥要点

共享电单车厂家

自助洗车加盟 车白兔自助洗车 自助洗车机投放

微帧科技荣获全球云计算大会“云鼎奖”!

微帧Visionular

CODING DevSecOps 助力金融企业跑出数字加速度

CODING DevOps

研发效能 DevSecOps CODING 代码评审 持续安全交付

【网易云信】超分辨率技术在实时音视频领域的研究与实践

网易智企

实时音视频

更严苛的英特尔Evo 3.0,正在让合作伙伴们上瘾

科技之家

EMQX 5.0 发布:单集群支持 1 亿 MQTT 连接的开源物联网消息服务器

EMQ映云科技

物联网 IoT mqtt #开源 7月月更

5. 数据访问 - EntityFramework集成

MASA技术团队

C# .net 微软 后端 Framework

单商户 V4.4,初心未变,实力依旧!

CRMEB

Python|数据结构——列表和元组

AXYZdong

7月月更

我们为什么要学习数学建模?

图灵教育

数学 数学建模

通过的英特尔Evo 3.0整机认证到底有多难?忆联科技告诉你

科技之家

华律网牵手观测云,上线系统全链路可观测平台

观测云

Vue和小程序的关系

Geek_99967b

小程序 Vue

RedHat7.4配置yum软件仓库(RHEL7.4)

Albert Edison

7月月更

视觉体验全面升级,豪威集团与英特尔Evo 3.0共同加速PC产业变革

科技之家

2022-Java后端工程师面试指南-(并发-多线程)

自然

多线程 并发 7月月更

跨境支付平台 XTransfer 的低代码实践:如何与其他中台融合是核心

XTransfer技术

技术 前端

养不起真猫,就用代码吸猫 -Unity 粒子实现画猫咪

芝麻粒儿

游戏 Unity 特效 7月月更

MySQL数据库索引教程(超详细)

Albert Edison

7月月更

来看一看智能自助洗车怎么加盟?

共享电单车厂家

自助洗车加盟 加盟自助洗车 车白兔自助洗车

尚硅谷尚优选项目教程发布

小谷哥

Python 入门指南之Python 简介

海拥(haiyong.site)

Python 7月月更

超分辨率技术在实时音视频领域的研究与实践

网易云信

实时音视频

自助共享洗车能挣钱么?分析下

共享电单车厂家

自助洗车加盟 车白兔自助洗车 自助洗车费用

Web3.0时代来了,看天翼云存储资源盘活系统如何赋能新基建(下)

天翼云开发者社区

数字化 云存储

HiEngine:可媲美本地的云原生内存数据库引擎

华为云开发者联盟

数据库 华为云 内容数据库引擎

自助洗车加盟门槛如何?高不高

共享电单车厂家

自助洗车加盟费 车白兔自助洗车 自助洗车加盟门槛

彻底理解为什么网络 I/O 会被阻塞?

C++后台开发

网络编程 socket 非阻塞网络I/O C++后台开发 C++开发

讨论:从客户的角度衡量敏捷项目的成功_研发效能_Vikas Hazrati_InfoQ精选文章