写点什么

敏捷社区真的不理智吗?

  • 2010-04-07
  • 本文字数:3149 字

    阅读完需:约 10 分钟

雅虎上的pmiagile 讨论组是两个社区得以相聚的地方。这个讨论组的贡献者们有着千差万别的广泛背景。最近上面有个讨论提到:在PMBOK 中所描述的传统项目管理环境中,敏捷实践在适用性方面存在问题。(笔者在此首先为文中出现的大段引用致歉,由于该话题讨论非常激烈,所以很难简单概括。)

Michael James 引用了 PMBOK

大概每三个月一次,我就会遇到一些人,他们认为 PMBOK 与敏捷方法并不冲突。要真是这样就好了。下面这些话引用自 PMBOK 第四版,其中指出:“项目管理”与使用 Scrum 开发产品,这二者不能互相适用。 - “项目不是持续进行的工作。”

  • “达到项目的目标,然后终止,这才是项目的目的。”
  • “认可与褒奖。清晰的奖赏条件及其有规划的使用系统,这会提升并增强期望的行为。”
  • “认可并褒奖期望的行为,这是团队发展过程的一部分。在“人力资源规划”(9.1 节)中,制订了有关如何奖励人们的规划和方式。在管理团队的过程中,会以绩效评估为手段,采取正式或非正式的方式来做出奖励团队的决策。”“举个例子,如果项目日程缩短了,那么就要增加预算,以投入额外资源,这样才能在更短的时间内完成同样的工作量。”

Wayne Mack 了解到敏捷推荐团队进行自我管理时,他表现出了自己的担心:

如果我们推荐项目经理不去管理项目,这好像有点不太靠谱。 目前我所处的工作环境完全像 Michael 在帖子中描述的那样。在我启动一个项目、甚至是分配团队成员致歉,我需要准备日程表、预算和范围,以得到批准。即使客户提出要求,并同意变更项目范围,我也得对日程表和预算做出正确的改动。为什么很多项目经理认为动态范围的建议不可思议?原因在此。

多说一点,我认为 APLN【译注 1】和 Agile CoP 很有趣,而且能让人振奋,但是我一直没有发现,其中有哪些信息可以应用到我的日常工作活动中。在这方面,我常常觉得我是一个人在战斗,因此我愿意与处于相同境况的人分享我的信息。

将敏捷应用于基于 PMI PMBoK 的项目管理活动中,就此话题,我希望我们可以讨论多种策略。这将在最大程度上为 Agile CoP 和 PMI 的成员们提供真正的价值。

Brad Murphy 响应了 Wayne 的评论,并详细指出了敏捷社区的薄弱环节:

请了解您不是一个人在战斗。我已经花费了十余年时间,倡导并帮助大型的主流公司开始并持续向“敏捷”转变,我同意你对于敏捷“原教旨主义者”的意见。尽管我是很多敏捷原则和工程实践的忠实粉丝,然而 APLN 和其他“敏捷”职业小组们常常表现幼稚,而且有时会忽视:组织在变革管理、监管、财务控制和长期规划活动方面有着复杂的现实状况,这会直接造成严重后果。 下面这个例子说明了我提到的幼稚。某个 Scrum 行业领导者提到:自我授权的团队有“权利”将某个表现不好的团队成员驱逐出团队。这个行业领导者主张:当团队有一个人表现不好时,团队应该咨询全部的团队成员,如果团队认为表现不好的人没有修正他或她的行为,那么团队有权将该成员驱逐出队。真的吗?在任何大型组织中,这会导致法律上的争辩、诉讼和来自 HR 的枪林弹雨,没有其他情形会导致此类状况。

我没有说自我授权的团队不应该对团队构成发表意见,但是简单粗暴的做法并没有尊重现有的法务流程和组织结构,这样的做法必须向着能够更有建设性的方向改进,而不是像现在这样,随便解雇员工。

Dan Mezick 指出,Brad 的回复才是真正的问题所在:

你讲述了一个出现问题的故事。确实,一方面,你有 Scrum 来鼓励高生产力的团队文化;另一方面……无法驱逐生产力低下的人(从而无法强调高生产力的文化),这是一种无能,也正是企业问题的内在表现。 这才是真正的问题。如果一家公司无法确定自己要采纳的(新的)高生产力文化,比如赶走、淘汰懒惰的人,那么什么时候才能这么做呢?答案就是:这家公司就会继续吸引、雇佣新的懒人,也就等于告诉大家:懒人在公司内有存在的理由和权利。

这种敏捷正是长期咨询合同的心仪对象。

另一方面,如果公司真的可以淘汰懒人,以这种方式表现对(新)文化的认同,那公司就算是走上了阳光大道,能够展现出高生产率,而且不再依赖任何外来的“敏捷”咨询雇佣军。因为公司已经掌握了真谛,不再依赖咨询顾问。

从提供“敏捷教练”服务的第一天开始,就鼓励客户的自我认知从而得以独立,有多少咨询公司能够做到这一点?

很少,恐怕根本就没有吧。

Sanjiv Augustine 也提出了不同的声音:

Brad、Wayne: 感谢这个激烈的讨论,其中充满乐趣,非常吸引人,让我觉得必须跻身其中。:)

我对你们的沮丧之情感同身受,因为我在某些时候曾经面对类似的难题,没有看那么长远。举个例子,对于管理人员在自组织团队中的角色,一直依赖都是讨论的热点。可以看看我的博客文章: http://lithespeed.blogspot.com/2009/11/self-organization-self-discipline-light.html,其中列出了我的看法。Wayne,我也愿意响应 Brad 的郁闷之情,你并不孤独。我们中有很多人在过去的十来年里一直帮助把敏捷带入到大型的主流企业中。我也愿意相信这就是(至少部分是)大型、主流企业开始不断实施敏捷的原因之一。

同时,我认为倾诉一下也是好的,这样我们就能听到人们的真实想法,互相帮助,让大家展开有积极作用的高效讨论。不过,我会小心对于任何社区的、一棍子打死的以偏概全之论,比如对于 APLN、Scrum 或是 PMI。作为这三个社区的积极参与者(我是 APLN 的联合创始人和现任 VP、积极的 CST 和 PMI CoP 成员),我认为所有知名组织的人们都在以真诚而高效的方式将敏捷推向主流。我也相信他们都以有实效的敏捷为目标而努力工作,尽管他们的观点各自不同。下面这些小事可以支持我的看法:

  • PMI 的 CEO 是去年美国 Scrum Gathering 的主题演讲者。那次 Scrum Gathering 将近一半的参与者都是 PMP(这是根据 Balestrero 先生要求大家举手的结果判断出来的)。
  • 个人来说,我从未在 APLN 中见到或经历过任何可称为幼稚的表现,不管是董事会还是我定期参加的系列会议中。我在 APLN 过去和现在的同事:比如 Jim Highsmith、Pollyanna Pixton、Bob Wysocki、Susan Fotajek、Kent McDonald 和 Todd Little,他们都在积极倾力思考你提出的问题,而且跟我一样,有企业中的发展有类似看法。
  • 我已经在 APLN(查看 http://www.aplnhouston.org/)、PMI(查看 http://www.pmiwdc.org/careerday2009-education#Sanjiv_Augustine)和 Scrum Gathering( http://www.scrumalliance.org/events/105-orlando-scrum-gathering)相关活动中展示了同样的 Agile PMO 演讲主题,提到监管和计划管理的内容。有趣之处在于,我从所有的 3 拨听众中得到了非常类似的积极反馈。

在今天的敏捷社区中,尽快有些声音无法在当今的企业界内得到认同,我还是愿意在尊重的基础上,请求大家不要用同样的眼光看待所有人。同时,我也愿意指出:如果我们发现这些看法充满争议,它们也正是鼓励我们这个整体不断改进、变得更好的动力。比如,Scrum 行业领导者认为自我授权的团队应该能够决定自己的团队构成,我们可以对此提出质疑。然而,事实上,这正是 Whole Foods Coporation 公司的规范做法(来自 http://money.cnn.com/2007/09/26/news/companies/management_hamel.fortune/index.htm,“虽有些争议,但内在逻辑非常有力:Whole Foods 相信至关重要的决策,比如应该雇佣谁,应该由直接受这些决策影响最大的人们做出。)

这么说,有些人认为敏捷社区理想化或是幼稚天真。也许他们说的有理。也许敏捷不适合大型组织环境。又或者,只是也许,敏捷技术真得很容易导致对抗,将之前一直潜在水底、但并未造成过多痛苦以使人们面对的东西带上水面。大家有什么想法?

【译注】

1. APLN,Agile Project Leadership Network,详见 www.apln.org。

2. Agile CoP, Agile Community of Practice,详见 agile-pm.pbworks.com.

查看英文原文: Is the Agile Community Being Unreasonable?

2010-04-07 07:461972
用户头像

发布了 479 篇内容, 共 157.3 次阅读, 收获喜欢 49 次。

关注

评论

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

如果你想做汽车开发,请先看看这篇。

水滴

自动驾驶 软件开发 开发

Neo4j执行计划

脚动两轮男之漂流小王子

那个业务大拿死在了这个地方

小眼睛聊技术

Java 学习 高效工作 程序员 个人成长

k8s上运行我们的springboot服务之——k8s 1.16.0安装

柠檬

k8s

JVM源码分析之堆内存的初始化

猿灯塔

你不知道的JSON.stringify(上)

前端黑板报

Java json

职场提问的“唐太宗”原则

大伟

Jenkins 插件开发之旅:两天内从 idea 到发布(上篇)

donghui

DevOps jenkins jenkins-plugin

Jenkins 插件开发之旅:两天内从 idea 到发布(下篇)

donghui

DevOps jenkins jenkins-plugin

北大学子手写实现《统计学习方法》书中全部算法!

GitHubDaily

人工智能 GitHub 学习 程序员

Flink 从0到1学习—— Flink 不可以连续 Split(分流)?

zhisheng

大数据 flink 流计算

重学 Java 设计模式:实战工厂方法模式

小傅哥

设计模式 小傅哥 重构 架构设计 工厂模式

Deno会在短期内取代Node吗?

葡萄城技术团队

node.js SpreadJS deno

聊一聊采访外籍人员时需要注意的几点事项

李冬梅

态度 体验 感悟

2020年4月云主机性能评测报告

博睿数据

云计算 百度云 ucloud 性能测试 公有云

招联金融助力经济复苏 致力成为“智慧生活的消费金融专家”

极客编

Flink 从0到1学习—— 分享四本 Flink 国外的书和二十多篇 Paper 论文

zhisheng

大数据 flink 流计算

游戏夜读 | 数据整理的难题?

game1night

DDD 实践手册(番外篇: 事件风暴-实践)

Joshua

领域驱动设计 DDD 事件风暴 事件驱动 Event Storming

露营之美,在乎山水之间也

李冬梅

k8s上运行我们的springboot服务之——在linux安装docker并搭建docker私服

柠檬

Docker k8s

k8s上运行我们的springboot服务之——上传服务到docker私服

柠檬

Docker springboot

奈学教育分享:Hadoop分布式系统HDFS工作原理

奈学教育

hadoop hdfs 分布式

《从0到1学习Flink》—— Flink parallelism 和 Slot 介绍

zhisheng

大数据 flink 流计算

《从0到1学习Flink》—— 你上传的 jar 包藏到哪里去了?

zhisheng

大数据 flink 流计算

Flink 从0到1学习 —— 如何使用 Side Output 来分流?

zhisheng

大数据 flink 流计算

如何参与开源项目

郭旭东

GitHub 开源

一文搞懂RSA算法

somenzz

《从0到1学习Flink》—— Flink JobManager 高可用性配置

zhisheng

大数据 flink 流计算

1分钱秒杀!疫情季,如何为孩子的升学保驾护航?

极客编

H2 的全文检索功能

Page

全文检索 lucene H2 内存数据库

敏捷社区真的不理智吗?_研发效能_Amr Elssamadisy_InfoQ精选文章