有些人强调敏捷认证培训的必要性，例如，它有助于选择面试人员并为敏捷转型奠定了基础。有些人则反对认证，因为他们认为没有正确地反映出人的能力与技能，没有认证的候选人可能比有认证的更好。
Daniel Gullo 在 LinkedIn Pulse 上发表了一篇名为《认证这件事...》的文章 ，讨论了敏捷认证。他举例解释为什么他认为认证是需要的：
如果我是一名招聘经理、招聘人员，或者甚至是开发团队的一员来负责补充团队成员。如果有 1000-2000 多个人，他们对此感兴趣而且相信他们可能会适合我们给出的一个职位，但我没有时间与他们一一对话。我需要某种标准，至少对知识建立一个基本线，这样我才能缩小范围。我希望看到某种形式的初步证据，通过他们的成就展现这个人对他 / 她的职业生涯或者终身学习有积极的兴趣，例如认证或其他的。
Gullo 解释说，认证只是一个起点，但它是不够的：
如果与我交谈的这个人有多个认证，但不能通过例子和类比来清晰地告诉我这个概念，而且他们不能展示如何应用知识、通过认证如何获得成长、如何看待认证的局限等等。那么我就不会雇佣这个人。
Gullo 陈述的其中一个评论是，“（…）认证是值得重视的事，作为出发点它比没有强。” 而Tobias Mayer则做出如下回应：
我不认为认证比没有认证强，在哪些方面强？我曾合作过的最好的教练都是没有参加过培训和没有认证的。正是这种缺乏规则、过程、教条和正式学习…才使他如此出色。很多优秀的开发人员并不是“一无所有”，他们有着丰富的经验，有思考和实践的能力。没有认证不意味着什么都不是，而是意味着在做出假设之前我们需要一些时间去了解他。
Savita Pahuja 在另一个评论中分享了他对认证的看法：
很好的文章。我同意…. 我们需要明白，问题不在于有没有认证。更多的是我们如何使用这个信息。如果参与者为了学习参加培训，他们得到多余的一纸证书并没有害处。但不要只是为了一纸证书，而没有抱着学习的目的去花钱。
Ron Quartel 在他的博客《对敏捷认证说不，敏捷魅力失宠》中分享了他对敏捷认证的观点：
要理解的是，发给某人一个证书说他们参加了我的课程，我对此没有问题。这很好。但仅仅是因为他们参加了你的课程而证明某人是专家，这与证明他们上过你的课程截然不同。每个人都可以参加课程，但不是每个人都可以成为专家。这一点就是关键不同，这也是我为什么不喜欢大多数的敏捷认证的原因。
我对所看到的任何敏捷课程的内容都没有问题。但因为你参加了课程而声称自己是被证明过的，对任何行业来说都是个笑柄。为什么在敏捷领域里变得如此普遍呢？我把建议写在了《敏捷魅力失宠》中。
Quartel 一直发带有 # 对敏捷认证说不（#SayNoToAgileCertification）的微博。他这么解释这样做的原因：
要做出改变，首先必须要改变自己。而且这就是我在公众场合所做的。我放开认证，我觉得那些要么不是价值很小，要么就是没有价值，我还鼓励其他人和我做同样的事情，而不是继续支撑这个赚钱，而非改变世界的体系。#SayNoToAgileCertification
Michael Valdes 写了一篇名为《认证 VS. 现实世界的经验》的文章。他解释说明了为什么他觉得认证重要，但还不够：
与当今技术保持同步，一部分是通过获取新的经验。但经验对某些人来说是一个无形的概念，并且开始是很难证明的。因此，认证就用作对一个人某一技术知识的认同。但我发现，即使某人获得了认证，他们对在现实世界中如何实施仍不太熟悉。与我交谈的一个人对此概念称之为“一纸证书”。意思就是尽管某人有了证书，只是因为他 / 她通过了考试，但仍不知道在现实世界中如何实施这一技术。
Valdes 说与技术保持同步，经验比认证重要。
依我看来，市场已经表明 IT 专业人员的技术步伐太快，认证无法始终让技术保持领先，而经验最终会胜出，因为这样更敏捷。（…）在市场上 ，IT 专业人员通过获得经验与技术同步，这样更加敏捷，而不是通过得到认证来保持技术领先。
在博文《 敏捷认证培训至关重要，但仅靠认证不能让你成为专家》中，James Harvey 描述了认证培训如何适应敏捷的旅程。
理想的场景是开始于一个简要的敏捷变革计划。概括出你的路线图是什么。通过适当及相关的敏捷培训计划获得认证，然后把你从课堂上所学的知识，通过研讨会和活动应用到实际的研究案例中。
根据 Harvey 所说的，培训和认证提高了敏捷转型的成功率：
认证的敏捷培训应视为你的起点，用这些基本理论充实你的大脑，然后利用一些工作坊和敏捷教练的支持来应用你的知识，并增添实际项目的真正价值。
敏捷认证，你是赞成，还是反对？
注册/登录 InfoQ 发表评论