敏捷認證

敏捷方法是否應該有認證計畫？

認證計畫在軟體產業很常見，但我認識的大部分有能力的開發人員卻不太重視它們。普遍的看法是 認證與能力幾乎沒有相關性。這在敏捷社群中更加嚴重，因為認證與 CMM 有關，而 CMM 從來就不是敏捷的。

認證普遍存在的問題之一是認證計畫非常薄弱。許多面向開發人員的認證計畫幾乎只是選擇題，雖然容易設定和評分，但無法有效測驗死背以外的能力。另一個常見的問題不僅存在於軟體產業中，那就是認證本身變成了一個產業，這會導致考試和更新不斷增加，而它們的目的越來越只是為了提高認證和測試公司的利潤率。

這些問題不一定是認證本身的缺點。或許可以提出一個確實與能力相關的認證計畫。但認證對於敏捷方法來說仍然有特定的問題。

在計畫驅動的流程中，重點在於遵循流程至關重要。因此，認證計畫可以測試團隊或組織是否能妥善遵循定義的流程。然而，在敏捷世界中，每個流程都遵循自我調整，也就是說，團隊預期會根據其當地情況調整流程。這使得任何認證都更難設計。

我記得在 2002 年 XP Universe 之後，我們在喝啤酒時聊到這個話題。我們想知道 XP 認證需要具備什麼條件。我們認為這將需要數週的觀察，觀察人們如何處理軟體專案的各個階段，觀察他們使用各種技能，包括調整流程。這樣的測試執行起來會很昂貴。人們會願意為這種計畫付費嗎？

儘管有這麼多疑慮，我還是希望軟體產業能找到方法提出有意義的認證計畫。這將有助於區分能力較強的人，並讓能力較強的人因其技能獲得更好的報酬。我不認為這個產業有能力提出單一的計畫，因此我對 Swebok 持懷疑態度。但特定的軟體開發學派，例如 XP，或許可以提出一些東西。但那東西看起來會與我們目前看到的認證計畫大不相同。