写点什么

敏捷战壕里的茶话会,与 David J Bland、Brad Murphy、Peter Saddington 的小聚

  • 2011-11-18
  • 本文字数:3617 字

    阅读完需:约 12 分钟

InfoQ 编辑 Chris Goldsbury 现场报道一场周五下午的轻松谈话,有多位知名敏捷实践者出席。会上畅谈方法学世界的现状和未来趋势,展望理论发展对实践的影响。

InfoQ:Standish Group 发表的 2011 报告说项目成功率(按时、按预算、按功能)提高了 5%。以你们这些老兵的眼光来看,这是不是敏捷实施率上升的结果?还是有别的什么原因?我们稳定交付软件开发项目的能力是否真的提高了?

Brad:我的看法是客户们总体而言,对于软件项目的实施更加小心谨慎了,这可能是成功率提高的原因。我不会把功劳归给敏捷。实际上很难分清是真正实施了敏捷,还是假装实施了敏捷。很多时候我们到客户那里,发现他们其实只是部分地采用了一些实践,而这种半吊子的敏捷却造成一种已经成功实现敏捷的虚假自我认识。

Peter:我同意 Brad 的说法。项目数据变好不是因为敏捷。如果你像我一样研究过敏捷市场现状和趋势,你会发现大量的企业都实施得很差或者浅尝辄止。他们根本不去改变文化,完全是依样画葫芦然后自称敏捷。Standish 的报告也许能让公司相信敏捷能更好地交付项目,但我们的观察不能证明这一点。

Brad:Standish 报告所用的指标可能有缺陷。成熟的敏捷团队会努力使价值最大化,不见得能完全用 Standish 那些刻板的目标范围、进度、预算指标来套。假如项目超期了一点,但我们成功交付了正确的功能,真的算失败吗?如果我们只完成了 40% 的目标,但这部分其实是最主要的价值所在…… 这样其实应该算成功吧?Standish 没有衡量这些情况。

Peter:我们需要一套新的指标来衡量软件开发项目的成功率。我们关注的不仅是目标范围、时间、预算、风险、问题这些指标,我们更重要的是把握总体的价值。Standish 是怎么衡量总体价值的呢?

David:我对 Standish 报告的主要不满是它的逻辑基础就有缺陷。他们假设我们从一开始就知道正确方案,其实很少有这么理想。软件开发没有并多少固定的方案套路,而 Standish 假设我们不会一边交付一边调整最初的方案。

InfoQ:敏捷、精益还有别的一些方法论是不是已经过分炒作了?对你们的生意有什么影响吗?

Peter:围绕敏捷、精益和看板的炒作非常多。这也是好事。围绕这些方法讨论得越多,它们也就越能成长。在某种程度上,炒作已经导致了一些不现实的期望。时薪 $40 的敏捷教练生意挺不错的。你不见得愿意花这么多钱请人讲什么企业文化,但其实敏捷教练做的也就是一样的事情。

Brad:我不反对 Peter 的看法。炒作是好的,也是有问题的。以前我可以直接走进管理层的办公室,给他们讲原原本本的敏捷。但现在我们首先要花时间教育他们什么是真正的敏捷和敏捷实践……纠正各种误解。现在还有 CSM(certified scrum master)这种骇人听闻的事情,半年前上过 CSM 课程的人,现在就可以挂牌做敏捷教练了。市场上充斥着这些毫无经验的教练,已经把敏捷生意给搅和了。

David:我从初创企业的角度来说说。炒作已经渗透到了这个市场。关于敏捷创业、精益创业的文章很多,但实际做得很少。创业者们对这个是比较有热情的,但他们需要帮助,需要有人去引导他们拨开炒作成分,看到价值所在。敏捷、精益创业是有意义的事情,也是建立一家企业的科学方法。炒作会逐渐平息,沉淀出来的价值会被应用到企业里面。这个东西能站得住脚,不过现在确实鼓吹得很厉害。

InfoQ:在你们的经验里,哪种方法最管用?

David:我一般会混用不同的方法,挑最合理的来用。如果必须选一样,我选 XP。

Brad我们刻意把自己首先看作解决问题的工程师,其次才是搞方法论的。我们的着眼点首先是界定要产出什么结果。假如客户的情况不妨碍我们实施,我们会结合使用 Scrum 和 XP。一般我们以 Scrum 为主。如果给我一群特别专业的开发者,我可以不太介意他们怎样组织开发。反正他们肯定能做好。在 GearStream 公司我们一般坚持用 Scrum,加上一点 XP,然后会针对客户需要做大量的调整。

Peter:我把 XP 作为基础。Scrum 的基本结构很好理解,它的三个角色很鲜明,不过其中的“产品负责人”角色争议比较多。我混合使用不同的方法。怎么安排方法确实取决于客户和客户的敏捷水平。你真的要先调查客户的环境才能决定最适合的方案。我一般倾向于为客户量体裁衣最贴身的方案。好的敏捷教练一定擅长平衡各方面的因素。我最后强调一点:我希望所有人都放弃敏捷、看板这类方法论标签,直接把它叫做“我们的做事方法”。

InfoQ:你们是否认为所谓方法论已经在逐渐消解,我们的注意力已经集中到具体的手段上面?未来的道路在哪里?

Brad起名字的游戏不会终结的,我们未来还会看到更多的方法论。这是好事,我们会看到进步,会看到新的软件开发方式。

David我们正走向持续交付。这方面现在才做了一点皮毛而已。速度慢会要命的,你要交付得更快。我没办法说得比较具体,但在初创企业里头这个趋势很明显。

Peter我同意 Brad 和 David 的观点。我们必须更快地部署更多的东西。我们必须领先市场曲线。对于消费者来说,他们希望看到快速的反馈。

Brad这个问题我也插两句话。我同意持续交付是未来方向。但只有当做得对的时候,做得快才有意义。更有效的产品管理和以人为本的设计是下一阶段的重点。很多公司不擅长管理产品的价值,可能需要一些帮助。

InfoQ:社交媒体对你们的生意有什么帮助或阻碍吗?对敏捷的关注是不是社交媒体大发展的结果,还是一种无关的现象?

Brad社交媒体跟敏捷关系不大,但跟发现人才和客户关系较大。通过这些媒介,我们跟客户的联系得更紧密。

Peter作为一名独立的教练,于我而言,社交媒体是不可或缺的。我在 Agile Scout 网站担任的职位有特别重要的意义。我通过各种社交工具获得了可观的生意。

David我特别欣赏 Peter 的社交媒体作战攻略。我真心认为社交媒体有利于长时间维持关系。我在某个会议上听人说用了我在博客上介绍的方法。除了对我是个鼓励,也促使我思考如何进一步调整,让方法适应不同的行业和情况。

InfoQ**:对于打算改进软件开发过程和交付的企业,你们能给一些建议吗?**

Brad从你希望达到的产出目标入手。软件开发并不是真正的目标。我们不应该把软件开发当作公司里一项独立的、没有关联的业务。软件开发是公司运营的内在组成部分。请确保领导人认识到这一点。做到两点:

  1. 确定改进软件开发过程对你的业务策略有何正面影响。
  2. 让业务领导人对软件开发负责,如同他们对其他业务方面负责一样。软件开发业务和别的业务不是分开的。

Peter自我改善。如果公司里没有咨询师或者独立的教练去帮你改进业务,那么改进的责任就是你的。持续培养自己的手艺。向榜样学习,站在他们的肩膀上成长。我们教练和咨询师对于用户的价值,是成为问题解决者。

David我会问客户:你们希望从敏捷得到什么?目标是什么?我不希望讨论敏捷。我希望讨论可见的收益,讨论客户希望解决哪些痛处。从这样的问题开始,我们才能搞清楚你的初创企业需要些什么。

关于访谈嘉宾

David J. Bland – 在行业中浸淫超过十年,David 乐见华盛顿特区周边的多家企业成功实施了敏捷软件开发。他 1999 加入第一家初创企业,帮助它在 2006 年获得 1300 万的收购身价。此后 David 帮助众多团队迅速、频繁地交付了众多产品,领域从电子商务到反恐。David 兼顾敏捷理论与实践,还涉猎周边领域如精益创业、业务模型建设和客户开发。

Brad Murphy – 作为 Gear Stream 的 CEO,Brad 负责总览公司的战略方向、规划与成长。Brad 为 Gear Stream 设定的方向是专注于帮助客户企业在精益、敏捷和 Enterprise 2.0 的环境下协作。Brad 的目标包括帮助客户企业从项目驱动的管理方式转变为精益的、价值流连续的、产品线式的执行方式。在部分敏捷群体只专注于核心开发的时候,Brad 把敏捷开发团队放入一个更大的框架中去发挥作用,开展跨功能、跨角色的同步工作流,纳入产品管理、风险与合规(PMO)、外包伙伴、财务、供销等运营活动。.

Brad 共 27 年的职业生涯包括两次成功的创业,其一为软件 ISV,其二是名为 digitaESP 的领先电子商务外包和咨询公司,2002 年被 Valtech, S.A. 收购。最近 Brad 担任 Valtech U.S. 的 CEO,帮助这家企业成为业界最成功的敏捷咨询企业之一。

Peter Saddington – 独立敏捷教练和 Agile Scout 的拥有者。Peter Saddington 在一家私人顾问企业 Thinqube - Lean Incubator, Inc. 担任 Independent Enterprise Agile Transformation Coach。他从事敏捷软件开发已逾 14 年。自 90 年代中期开始从事软件开发以来,他服务于美国国防部、美国空军、美国疾病控制中心(CDC)、Johnson and Johnson、Primedia、Consumer Source、Blue Cross Blue Shield、T-Mobile,以及其他众多私人企业和财富 500 强企业,帮助他们的开发团队和企业实现敏捷。作为一位活跃的写作者,他是《Scrum Pocket Guide: A Quick Start Guide to Agile Software Development》(www.scrumpocketguide.com)一书的作者,还是 AgileScout ( www.agilescout.com )新闻博客的执行编辑,每天有来自全世界的无数读者。他和夫人 Susan、女儿 Micah 一起居住在 Atlanta, GA。

2011-11-18 11:321461
用户头像

发布了 225 篇内容, 共 65.1 次阅读, 收获喜欢 50 次。

关注

评论

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

游戏夜读 | 如何优化缓冲加载?

game1night

读懂才会用 : 瞅瞅Redis的epoll模型

小眼睛聊技术

redis 缓存 学习 开源 架构 后端

TOTO 2020再次荣获iF、红点两项国际设计大奖

极客编

Java 编程基础

michaelliu

聊聊Serverless

kimmking

Kafka系列第6篇:消息是如何在服务端存储与读取的,你真的知道吗?

z小赵

Java 大数据 kafka 实时计算

一文看懂开源工作流引擎 Flowable

八味阁

Java spring 开源 企业中台 工作流

谈谈控制感(2):怎么让我们更健康

史方远

个人成长 心理

DD 测试linux性能

HU

我站在愚蠢之巅

escray

学习 CSD 认证实战营

想退休,可能没机会了

池建强

读书感悟

CDN云课堂 |可编程CDN – EdgeScript应用场景、语言速览和实操演示

阿里云Edge Plus

一杯茶的时间,上手 Git 团队协作开发

图雀社区

git GitHub

用测试驱动开发学算法

escray

学习 CSD 认证实战营

《Linux就该这么学》笔记(二)

编程随想曲

Linux

可视化 Tekton 组件 Tekton Dashboard

郭旭东

Kubernetes cicd

奔向 10W+ 的第一次 update

赵新龙

InfoQ B站 Quora

由丰巢快递柜引发的思考

Neco.W

创业 思考 丰巢

多个 SSH keys 的配置,方便 Git 对不同仓库的使用与管理

与光

git GitHub SSH

KubeFATE:在Kubernetes上部署联邦学习平台

亨利笔记

人工智能 学习 FATE KUBEFATE

抄作业

escray

学习 CSD 认证实战营

视达荣登ChinaBang Awards 2020智慧零售榜Top10

极客编

MySQL数据类型DECIMAL用法

Simon

MySQL

CDN百科 | 最近,你的APP崩了吗?

阿里云Edge Plus

CDN

CDN百科 | 假如没有CDN,网络世界会变成什么样?

阿里云Edge Plus

用SpreadJS实现在线Excel的录入与展示,提升企业医保信息化服务水平

葡萄城技术团队

SpreadJS 医保信息化 在线excel

概念有时候很坑

伯薇

抽象 思考力 沟通 概念

并发编程如何才能不再头疼:iOS中的协程

超越杨超越

ios 协程 coobjc ucontext

如何推动与影响中型前端团队的成长

堂主

研发管理 大前端 团队建设

GrowingIO 微服务 SaaS 与私有部署运行实践

GrowingIO技术专栏

大数据 微服务 SaaS

CDN云课堂 | EdgeRoutine技术专家教你把JS代码跑到CDN边缘

阿里云Edge Plus

Java CDN edge

敏捷战壕里的茶话会,与David J Bland、Brad Murphy、Peter Saddington的小聚_研发效能_Christopher R. Goldsbury_InfoQ精选文章