大型敏捷專案

一個常見的問題是大型專案是否可以用敏捷技術來執行。畢竟，許多敏捷方法都是針對較小的專案設計的，而它們所抗拒的重量級概念在較大的專案中更為必要。

這個問題的主要原因之一是因為我們還不知道。新技術往往會先在較小的專案中進行嘗試。只有在較小的規模中運作良好時，人們才會在較大的規模中嘗試它們，即使如此，也需要時間來提升。對於任何技術或技術，我都不建議將其用於比你已經成功使用過的專案規模大兩倍以上的任何專案。

儘管如此，許多敏捷的內容都來自於較大的系統，這取決於你如何定義大型。對於軟體專案，我認為大型的主要衡量標準是人員數量。人員越多，溝通問題就越多。XP 的最佳人數是 20 位團隊成員。FDD 看起來更多，在十幾位左右。與 RUP 的首席設計師 Phillipe Kruchten 談話時，RUP 的本質上是非常敏捷的方法，而 Phillipe 主要與超過 200 人的專案合作。

擴展敏捷方法應該是最後一件事

我最近在 加拿大敏捷網路 中使用了這個詞組。我的意思是字面上的意思。我並不是說你不應該執行大型專案，我的意思是說嘗試將敏捷技術擴展到大型專案，雖然通常有必要，但這不應該是你的首選。

更好的方法是嘗試縮小專案規模。在那個工作坊中，一項不科學的隨機調查顯示，大多數專案可以減少約一半的人員，而不會讓事情進行得更慢。一次又一次地，我聽說當團隊規模大幅縮減時，就會成功。大型團隊在溝通和管理方面負擔沉重的開銷。使用由更多有能力的人員組成的較小團隊通常更快、更便宜，即使每個人在個人方面的支出更高。