写点什么

敏捷战壕里的茶话会,与 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:321424
用户头像

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

关注

评论

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

【我和openGauss的故事】记一次基于在银河麒麟系统上适配openGauss进阶之旅

daydayup

软件测试 | 编写第一个Java程序

测吧(北京)科技有限公司

测试

质效两全:媒体服务的创新“顶设”

阿里云CloudImagine

云计算 视频云

@Lazy 注解为啥就能破解死循环?

江南一点雨

Java spring

【我和openGauss的故事】openGauss特性:CM支持两节点部署特性

daydayup

【我与openGauss的故事】openGauss 5.0企业版主从部署,实战狂飙

daydayup

opengauss

百度智能云 X 软通动力:将结合大模型开发多领域智能应用

科技热闻

软件测试 | Java程序的运行机制和Java虚拟机

测吧(北京)科技有限公司

测试

12 点半!Voxel51 亚太地区计算机视觉线上 Meetup,速来!

Zilliz

计算机视觉 Milvus Zilliz voxel51

Jedis 参数异常引发服务雪崩案例分析

vivo互联网技术

服务雪崩 Redis集群模式 主从切换 Jedis参数设置

云原生机甲的构想

如水

云原生 servicemesh 云原生机甲 CloudMecha

【我和openGauss的故事】openGauss逻辑备份恢复

daydayup

openGauss DBMind上的多指标关联性分析介绍

daydayup

opengauss

什么是大规模敏捷SAFe?SAFe大规模敏捷管理工具

顿顿顿

敏捷开发 safe 大规模敏捷 scrum工具

百度知道上云与架构演进

百度Geek说

云原生 架构演进 业务上云 企业号 7 月 PK 榜

用热爱,走一些“远”路!

禅道项目管理

【我和openGauss的故事】 openGauss 5.0.0 分区表增强

daydayup

opengauss

博睿数据获聘信通院DGA首批智库专家组

博睿数据

可观测性 智能运维 博睿数据 信通院 专家智库

掌数科技携手华为云GaussDB,助力金融科技创新,联合打造行业标杆

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 7 月 PK 榜

软件测试 | Java开发环境搭建

测吧(北京)科技有限公司

测试

软件测试 | 一个简单的Java范例

测吧(北京)科技有限公司

测试

深耕行业创新 引领视听未来 | 宇视亮相北京Infocomm China 2023展会

新消费日报

对线面试官-Redis 十一 | 双写一致性问题

派大星

Java 面试题

点云标注在自动驾驶中的重要性

来自四九城儿

为什么要做稳定性保障?

老张

SRE 稳定性保障

点云标注在自动驾驶中的挑战

来自四九城儿

MobPush 推送限制策略

MobTech袤博科技

程序员 前端 push 智能推送 推送

揭秘高新技术发展最新趋势,程序猿视角下的技术革新感悟 | 社区征文

三掌柜

年中技术盘点

AIGC第一波裁员已至

互联网工科生

人工智能 裁员 AIGC

敏捷领导力 (CAL E+O / ALJ) 认证

ShineScrum

实现在线直播源码高质量直播体验重要功能_山东布谷科技创作

山东布谷科技

软件开发 直播 源码搭建 直播源码 在线直播源码

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