Scrum认证是否可以作为学习敏捷开发的开始?

前几天跟别人聊天，谈到敏捷总是谈到Scrum，并且问我是否获得认证。我表示了对敏捷认证的抵触，他认为Scrum认证是学习敏捷的一个开始。当时这个话题没有继续，但我相信有这种想法的人不在少数。但这是否正确呢？虽然我不是Scrum的专家，但我想尝试探讨一下这个问题，让我们从头开始吧。

首先，什么是敏捷呢？

敏捷 Agile最初来源于拉丁词根ag, agi, agit, act也就是to lead, to drive, to do的意思。这让我想起了对立面的一些词汇：跟随，静止。翻阅词典之后发现，agile本身有三种解释：1，快速且协调运动。2，积极的，有活力的。3，思维快速。但是这种行动来自何方？是什么使你有做的动力呢？ 是勇气。想象一下失去勇气的你在什么情况下才能做出行动。在勇气之前呢？那就是一颗勇于面对变化，且积极的心。

那什么是Scrum呢？

来自Wikipedia的解释是

“Scrum is a process skeleton which contains sets of practices and predefined roles.”

Scrum就是一个包含一些内容的过程。这个过程框架给出一些实践与预定义角色可供使用者进行剪裁并形成适合使用者的过程。它定义了过程中的角色、会议与工件(Product backlog, Sprint backlog, Burn down)。

我们再回过头来说说敏捷开发，最能够诠释敏捷开发的是敏捷宣言了。接下来我们将回顾一下经典并且尝试比较一下Scrum，这里需要注意的是 over 后面的内容敏捷不是认为它没有价值，而是前面的价值更多。

• 个体与交互 over 过程与工具
  • Scrum是一个过程的框架，虽然在过程的角度上尽可能的保证交互，但过程缺乏对个体的关注。这让我想起了CMMI，同样的关心过程、同样的宣称可以剪裁、同样的实施认证。如此一来过程的还是过程，套路不同而已，且多了噱头；关心交付的还是关心交付，对大家的考核框架根本没有涉及。总结起来就是，Scrum对过程和工具有所涉及，对个体与交互只是在过程中进行体现。
• 可以工作的软件 over 面面俱到的文档
  • Scrum定义了一些工件( Artifacts)，在中文版本的wiki中更是直接翻译成了“文档”，如果一个过程能够保证可工作的软件的话，那CMM早就可以了。“可工作的软件”这句话在我看来是敏捷开发宣言中最重要的一句话，也就是说敏捷更关心交付，但Scrum只是在精神层面上给我们暗示了方向。拿到认证的人们是否感受到这种暗示呢？对于代码来说隐性的东西是会受到批判的，因为如果你认为什么东西是好的，就应该显性的表示出来，不能让后来看代码的人有错误的想法。使用过程来实现敏捷价值观简直就是隔靴搔痒。
• 客户协作 over 合同谈判
  • 对于这项Scrum规定了客户建议扮演的角色和在过程中应该承担的责任。最有意思的是那个火腿鸡蛋的比喻，Stakeholders (customers, vendors)作为鸡的角色进入项目，试想一下如果用户不能积极参与项目的话，何谈交付。
• 响应变化 over 遵循计划
  • 说到遵循计划与响应变化，我就想起了一个朋友跟我说起的一个段子。他说：你听说过Scrum吗？你肯定没有见过这么烂的软件开发方法论。举个例子来说，比如一个足球游戏，突然在足球场上发现了两个足球，整个项目组还需要等一个月才能着手修正这个问题。当时我很无语，我也不知道这是Scrum的问题还是使用者本身的问题（当然肯定不是方法论的问题;-）。但若干年前我们使用CMM不就是这个样子吗？

说到最后，我还是对敏捷认证保留意见。首先你拿Scrum认证的目的是什么？如果为了更好的软件过程，这个证书又能代表什么？代表你了解了一些过程？还是你嘴中多了一个和别人忽悠的噱头？代表你愿意学习敏捷的意愿？还是职业生涯的又一个资本？

我们为了制造出更好的软件已经学习了太多太多的东西了，而在学习的过程我们在不停充实自己的过程中是否还记得我们最初的初衷？我们是不是应该尝试丢弃一些过程？丢弃一些实践？丢弃一些角色？丢弃一些会议？看看我们是不是还能做出好的软件。认证就类似一门考试，我们在追求考试的过程是不是这本身就不够敏捷？我们是不是想要的太多了？一方面要做好软件，一方面自己要紧跟时代的步伐，一方面要为自己的职业生涯添砖加瓦……

任何一种事物都在于我们对它的理解，从而产生巨大的不同。就如同小时候看到糖果的我，我会对它产生心理上的冲动，不光因为它的味道，父母的严令禁止也是原因之一，直接导致的结果就是牙齿的问题。对于Scrum来说，技术层面上讲我没有任何意见。但它的推广过程中所采取的方式，有可能会对结果造成影响。尽管它可能很火，尽管市场份额可能很大，尽管它可能成为潮流。

引用我一个朋友列出的敏捷学习过程，需要重点指出的是，他把Scrum的学习放在了第一步：

• 过程的敏捷（学习并尝试敏捷的套路）
• 痛苦的敏捷（学习并尝试与代码相关的敏捷实践）
• 真正的敏捷（学习并尝试实现敏捷深层次的价值）

最后，我相信 法无四乘。人心自有等差。不在乎套路也不在乎门派，关键在于内心。