敏捷適合所有人嗎

一般的開發人員可以使用敏捷方法嗎？

我經常聽到有人聲稱，只有優秀的開發人員才能使用敏捷方法，而一般或低於一般水準的開發人員應該避免使用敏捷方法。當有人這麼問我時，我只能回答我不知道答案，而且這種無知在任何新技術中都是很自然的。

當一種新技術或工具出現時，通常會先由能力較高的開發人員試用。這是一個很自然的反應。早期採用者必須是那些對自己的專業更周到、更關心的人。新的方法通常會先由他們試用，然後才會在多數人身上試用。因此，對於任何新的方法，你都必須問這個問題：這種方法是否只適合這些比較有冒險精神的人？這是一個無法回答的問題，因為在能力較一般的團隊試用之前，你無法得知這種方法對他們來說會如何運作。

當然，這並不能阻止人們猜測，只要我們都明白這只是猜測，我很樂意加入這個有趣的討論。

敏捷方法的一個重點，也是它與計畫驅動方法之間一個明確的區別，在於敏捷主義者堅信「個人與互動」比「流程與工具」更重要。這個 以人為本 的假設意味著，敏捷主義者總是期望能力較高的凝聚力團隊表現優於能力較低的團隊，無論哪個團隊遵循更敏捷的方法。這個假設意味著，組織應該將其主要重點放在為團隊獲得和培養能力較高的人員。這並不意味著能力較低的團隊使用敏捷方法會比使用計畫驅動方法表現得更差

敏捷方法的許多部分都需要明智的技能。自我適應是改變流程所必需的，許多敏捷技術都專注於磨練技能水準。我認為這一定意味著一個有效的敏捷團隊需要有一些能力較高的人員。但這也適用於計畫驅動方法。畢竟，計畫驅動方法假設能力較高的人員會擬定計畫。這兩種方法都需要一些能力較高的人員，儘管這些領導者與團隊合作的方式不同。一個開放的問題是，你從計畫或協作中獲得能力較高人員的槓桿作用是否更大。

Thoughtworks 目前為止的經驗讓我們對敏捷方法感到非常正向，但當然 Thoughtworks 以只雇用高能力人員而聞名。然而，我們的專案比較混雜，因為我們通常與客戶共同外包，而客戶人員通常涵蓋了各種能力。我們當然比較喜歡團隊中有大量的 ThoughtWorkers，這讓我們擁有臨界質量，有助於我們的交付和技能轉移。到目前為止，我們發現敏捷方法的協作性質對我們很有幫助。

更新：Ralph Johnson 描述他與學生的經驗 - 結論是 XP 比 RUP 更適合技術較差的開發人員。