敏捷宣言：四大核心價值與十二項原則解析

下圖來自敏捷宣言網站並展示了四個敏捷價值聲明。

Agile Manifesto and the 4 Agile Values answer what agility is

如您在價值聲明的序言中所見，作者指出他們正在尋找開發軟體及幫助他人的更好方法。所有價值皆重要，但左側的價值優先於右側。

個人與互動勝於流程與工具

如前所述，當敏捷宣言發布時，它挑戰了重型方法論。當時，能力成熟度模型（CMM）與ITIL是流程導向方法的流行趨勢。

因此，這些思想領袖選擇從人開始，令人感到驚訝。他們相信，找到團隊中的合適人選（個人）並協助他們有效合作（互動）遠比遵循任何特定流程和/或使用特定工具更重要。這就是為什麼他們將重點放在左側：個人與互動。

可運作的軟體勝於完整的文件

在傳統或瀑布式軟體開發中，團隊會花費大量時間收集需求並開發設計與規格，直到生命周期後期才建立出具體成果。宣言的作者認為，擁有可運作的解決方案，比擁有大量描述解決方案運作方式的文件更具價值。

客戶合作勝於合約談判

第三項價值是客戶合作勝於合約談判——其中合約談判意指爭論範圍內包含哪些內容。例如，您可能會聽到類似「那並不在您的需求文件中」的說法。這些思想領袖認為，與客戶合作以交付他們真正需要的解決方案，遠比其他事情更重要。

回應變更勝於遵循計畫

第四且最後一項敏捷價值是回應變更勝於遵循計畫。作者們同意規劃很重要——事實上，敏捷團隊會進行大量規劃。但這些思想領袖認為，應對不可避免變更的能力，比堅持在專案初期（資訊仍有限時）所制定的計畫更為關鍵。

宣言中的所有價值皆重要，但左側的價值優先於右側。

十二項敏捷原則

除了這四項敏捷價值外，敏捷宣言的作者們也同意一組十二項敏捷原則，這成為敏捷工作方式的基礎。雖然不如四項敏捷價值廣為人知，但我認為十二項敏捷原則更具實用性，並為敏捷實踐提供更明確的指引。

12 Agile Principles behind the Agile Manifesto

為方便起見，我為十二項原則編了號，儘管在官方網站.

  1. 第一項原則是最高優先事項是透過早期且持續交付高價值軟體來滿足客戶。有些人對「高價值軟體」這個詞語感到困惑。請記住，在2001年，當這些思想領袖提出敏捷價值與原則時，他們僅專注於軟體開發。自那以後，敏捷已廣泛應用於幾乎每個產業——建築、汽車製造，甚至戰鬥機生產。若您覺得更清楚，可將「高價值軟體」替換為「高價值解決方案」。
  2. 第二項原則是歡迎變更需求，即使在開發的後期也是如此。雖然目前大多數人專注於控制變更或管理「範圍蔓延」，但現實是變更是不可避免的。敏捷流程延遲決策，縮短開發週期，並支援及時分析需求。這使得敏捷團隊能夠快速且低成本地適應變更。這帶來了競爭優勢，也是敏捷工作模式的核心支柱之一。
  3. 第三個原則是經常交付可運作的軟體，時間從幾週到幾個月不等，最好採用較短的時間間隔。頻繁交付的主要好處之一是獲得反饋，以確保你走在正確的軌道上，並真正打造出客戶所需的產品。
  4. 第四個敏捷原則是關於業務人員與開發人員每日共同合作於整個專案期間。如今，業務利益相關者經常撰寫需求文件，並將其「丟過牆」給開發人員。數月甚至數年後，開發人員將解決方案交付給需求提出者進行最終測試——卻發現解決方案被誤解、錯誤建構，或已不再需要。此原則的重點在於讓開發解決方案的人與使用解決方案的人之間進行協作，以避免這種結果。
  5. 第五個敏捷原則是以有動機的個人為核心來建構專案，為他們提供所需的環境與支援，並信任他們完成工作。這本質上是一種三步驟方法：賦予人員權能、給予他們自主性，並信任他們。
  6. 第六個敏捷原則提倡永續發展。贊助者、開發人員與使用者應能持續以穩定節奏運作。我剛開始從事科技專案時，專案經常持續六個月、十二個月甚至更久。在最初一個或兩個月內，往往進展甚微。毫不意外，這導致專案尾聲出現巨大的壓力期，必須完成龐大的工作量。團隊成員被期望加班或在週末工作，以達成固定的期限與範圍。這被稱為「死亡行軍」專案。敏捷並未表示你永遠不會加班或在週末工作——但它強調的是讓所有人都能以可持續的節奏工作。
  7. 第七個原則是可運作的軟體是進度的主要衡量標準。傳統上，會以完成百分比來追蹤專案進度。完成百分比極不可靠，因為很難判斷，特別是當達到80%或90%時。90%的完成度往往僅代表剩餘10%的工作或時間。敏捷團隊透過將工作拆解為功能或模組，再細分為小塊，並追蹤這些小塊是否完成，來避免使用完成百分比。這種做法可避免產生誤導性的進度指標。
  8. 第八個原則是：向開發團隊傳達資訊，以及在團隊內部溝通，最有效且高效的方式是透過面對面的對話。如今，最流行的溝通工具可能是電子郵件。對發送者而言非常高效——畢竟他們可以一次傳送訊息給數百或數千人。但這並非真正的溝通。研究顯示，閱讀他人撰寫的文字會留下大量誤解的空間。敏捷倡導者已學會，真正的共識需要將人們聚集在一起。若無法面對面，則應使用最高傳輸頻寬的溝通方式——這可能是視訊或電話會議。這遠勝於將文件上傳至 SharePoint！這裡的重點是使用可用的最高傳輸頻寬溝通渠道。偏好面對面互動的一個附帶效果是，讓同一敏捷團隊的成員共處一地是合乎邏輯的。然而，如今許多組織卻忽略了這看似顯而易見的重點。
  9. 第九個原則是持續關注技術卓越與優良設計以提升敏捷性。重點在於避免走捷徑或累積技術債務。不要做那些短期看似更快，但長期成本更高的事情。如果你持續累積技術債務，將會失去敏捷性。這在具有固定時程的瀑布式專案中很常見。為了達成承諾的期限，會採取妥協做法。測試週期可能被縮短或取消以節省時間，導致產品上線後出現更多問題。這導致疲於奔命的救火，以及難以維護的程式碼。
  10. 第十個原則是保持簡單並消除不必要的工作。簡單——即最大化未完成工作的量——是不可或缺的。換句話說，我們應檢視自身流程，並消除任何對客戶無價值的事物，從而最大化未完成的工作量，同時仍能交付所需內容。
  11. 第十個原則也關於自組織團隊。最佳的架構、需求與設計來自於自組織團隊。我們應讓最接近工作的人員決定如何最有效地完成任務——這正是此原則的核心。
  12. 最後一個原則，第十二個，是關於回顧。團隊定期反思如何變得更有效，然後調整並適應根據情況調整他們的行為。

敏捷價值觀與原則在今天看來可能並不算激進，但當它們於2001年公布時，卻相當具有革命性。因此稱為「宣言」。它們闡述了一種與前一個世紀組織運作方式截然不同的工作方式。在此之前，軟體開發主要模仿工業時代的工作模式。理解這一歷史背景至關重要，如下所述。

 

 

Leave a Reply