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

随着敏捷社区的演化，人们能够找到更多更好信息的地方也在演化。 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