腾讯亿级用户规模自研业务的上云实践解读,立即报名 了解详情
写点什么

差异和学习:PMI-Agile 项目不断升温

  • 2010-07-08
  • 本文字数:2200 字

    阅读完需:约 7 分钟

随着敏捷社区的演化,人们能够找到更多更好信息的地方也在演化。 PMI-Agile Yahoo! 讨论组就是这样的一个好地方,这个讨论组也是 PMI-Agile 项目的产物。这个社区有很多有趣的参与者,包括敏捷宣言的签名者之一 Ron Jeffries,还有 Scrum 联盟的董事会主席兼总裁 Tom Mellor。

InfoQ 去年已经报道了 PMI-Agile 项目的启动。项目的使命是希望将敏捷的知识和技能带给所有的 PMI 实践者,然而现在出现了更有趣的进展:项目的 Yahoo! 讨论组已经演变为冲突的世界。论坛似乎变成了热闹喧天的辩论场所,受人尊敬的、极其自信的、技能娴熟的参与者们拥有 PMI 和 Agile 的背景,积极参与到对敏捷的讨论之中。

举个例子,在最近的一个讨论话题中,一个帖子贴出一个链接,指向美国国防部的 Command and Control Research 项目。该链接构成了 InfoQ 一篇关于军中的敏捷的文章基础。这就是一个典型例子,体现出论坛中涌现出的高质量内容。

最近,敏捷宣言的签名者Ron Jeffires 积极发表意见、事实,反击希望编辑或修改敏捷宣言中对敏捷的定义。InfoQ 采访了Ron,希望找到PMI-Agile 讨论组的吸引力所在。

Ron Jeffries 说:

我参加 PMI-Agile,因为里面有些人对敏捷感兴趣,而且他们也不是很了解敏捷。因此,在我看来,恶劣的项目管理是软件项目失败的一个主要原因。既然敏捷是一种优秀的项目管理方式,我希望讨论组能够了解敏捷的真正含义。我认为我能把这个带到讨论组中。

此外,还有相对不为人知、但是知识丰富的很多项目经理和通过 PMP 认证的人们,他们也有相当的敏捷知识,而且也为对话奉献良多。有些人直接找到 Ron Jeffries。比如 Horia Slusanschi 就这么说:

Ron 你好, 你最近这样写道:

>> 我倾向于认为:项目经理和 Scrum Master 这两种角色

在本质上是不相容的,创建一个项目经理职位出来也是
与敏捷背道而驰,有些(也许是很多,甚至是绝大多数)
项目经理的风格无法适合敏捷……而这最后
一点并不是项目经理角色或个人性格的强制要求。 我认为你的观察可不太友好。我很幸运,认识很多项目经理(我领导 HP 的软件工程人员),他们都很聪明,适合大型组织,而且能够在现有的组织限制条件下尽一切可能支持敏捷项目,因为他们非常关心最终用户能够得到的工作成果。

你也指出了人们看到的、有趣的不兼容状况。 是的,在某些思维方式之间总会存在紧张的状况。然而,我认为我们应该共同努力,以有想象力的方式消除这些紧张状况。

论坛中的差异和多样性导致热度不断升温。除了 Ron Jeffries 之外,还有一些敏捷社区的知名人士参与近来。Scrum 联盟的董事会主席兼总裁 Tom Mellor 也在讨论组中发表了帖子。

下面是 Tom Mellor 最近的帖子:

增量式交付并不一定等同于“交付到生产状态(delivered to production)”或者“送出(shipped)”。其中包含了很多科学方法,尝试和错误、实验和沉思,这就是用到的工具……知识工作本来就很复杂,其中用到反馈循环辅助管理,并去掉了像墨菲定律和帕金森定论之类东西的影响。 线性开发的根本问题在于:流程中能够真正检视工作成果的时间点太晚,而且在这个时间点要进行修正所能做的事情也有限,同时成本高昂……我使用我称之为“逻辑工作组织(Logical Work Organization)”的方法。团队是这个方法的核心,团队决定如何完成工作,以何种顺序,并制定日程。他们会停下来做检视,并按需要调整。他们尽可能坐在一起工作。管理人员不会干预他们,并帮助他们克服困难和障碍。要想采取这样的工作方式,就得把权力赋予能够自我组织、自我导向的团队,团队成员都能对彼此负责,而且他们能够充分利用整个团队的头脑和技能。

不是所有人都同意 Tom 的看法,去 PMI-Agile 讨论组看看就知道了。Tom 提到了他所谓的“逻辑工作组织”。正如本文前面提到的,美国国防部正在研究敏捷在战争中的作用,而且已经形成了一个新词汇:必要的敏捷(Requisite Agility),其定义是:

……必要的敏捷度,就是要寻求到合适的敏捷度,也就是要在某种具体情况下,在获取敏捷的成本和不采纳敏捷的后果之间找到平衡。因此,必要的敏捷,而不是无限的敏捷,才是我们的目标。

“逻辑工作组织”和“必要的敏捷”,这是在讨论组中发表帖子的思想者们的一些见解。有趣之处在于人们的看法和表达出来的意见之间的巨大差异。从讨论组的层面来看,差异是促进学习的原材料之一。因此,PMI-Agile 讨论组应该是了解敏捷演化的一个好地方。

Ron Jeffries 也同意这一点,并正在讨论组中起到“导航”的作用,将人们的注意力导向他认为最有益于社区的地方。Ron Jeffries 认为:

新接触敏捷的人几乎都是阅读一点点材料,然后得出错误结论,常常类似于“我们已经这么做了”。我在尽力为这个讨论组做的事情,是让他们知道什么是真正的敏捷,并鼓励他们在判断敏捷如何适用之前先去尝试。要是不这么做,那就类似于在一个人没有玩过、甚至没有见过棒球之前,就去判断他能否成为一个好的游击手了。

PMI-Agile 讨论组能让人每周都接触方方面面的话题,而且能看到讨论空间中出现的新话题,不同的思维方式互相碰撞,“瀑布式开发遇到经验过程控制的开发”。

如今,时间对于很多职业人士来说非常宝贵。注意力、焦点和时间都很珍贵。知道应该关注什么、应该忽略什么,正在逐渐成为重要的技能。作为项目经理或敏捷职业人士,如果你希望知道“敏捷的可能发展方向”,PMI-Agile 讨论组就是你的必去之所。

查看英文原文: Differences and Learning: the PMI-Agile Project Heats Up

2010-07-08 23:461462
用户头像

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

关注

评论

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

第一周作业(1)

佳明

第一周总结

gen_jin

学习总结

YY

「架构师训练营」学习笔记:第1周

Amy

学习 极客大学架构师训练营

《架构师训练营》--第一周命题作业

极客大学架构师训练营

食堂就餐卡系统设计

跨域刀

极客大学架构师训练营

【架构课笔记-第一周】一般方法与设计文档

Nelson

食堂就餐卡系统设计

逍遥乐天

第一周架构总结

漫步云梯

架构总结

week01-学习心得

强哥

极客大学架构师训练营

就餐卡系统架构设计文档

gen_jin

作业一:食堂就餐卡系统设计

飞翔的风

架构师训练营 第1周作业

Lingjun

极客大学架构师训练营

架构师训练营-作业一

Jemmy

架构学习第一周总结

lwy

关于架构师的理解(第一周学习总结)

架构学习作业-食堂就餐卡系统架构

乐天

第一周作业

仪轩

食堂就餐卡系统设计

weijin

第一周学习总结

Gavin

架构师第一课学习总结

曾祥斌

架构师训练营 第1周总结

Lingjun

极客大学架构师训练营

极客时间-作业一-食堂就餐卡系统设计

刘柯

如何编写一份合格的架构设计文档(一)

izerone

架构师训练Week1 - 学习总结

伊利是个圈

学习 极客大学架构师训练营

食堂就餐卡系统架构设计⽂档

一点点..

关于架构师的一点理解

石刻掌纹

架构0期作业1

Nan Jiang

【架构师训练营 - week1 -2】学习总结

早睡早起

就餐卡系统设计

dongge

架构训练营第一周-作业

无心水

差异和学习:PMI-Agile项目不断升温_敏捷_Dan Mezick_InfoQ精选文章