Agile 原則和價值，作者：Jeff Sutherland
Jeff Sutherland 於 1993 年發明 Scrum，並與 Ken Schwaber 一起於 OOPSLA'95 正式發表 Scrum。 他們為許多軟體公司擴充及改進 Scrum，而且協助撰寫敏捷宣言 (英文) Jeff 的部落格 http://scrum.jeffsutherland.com (英文) 檢閱 Scrum 的起源和最佳做法。 |
敏捷 (Agile) 開發是從敏捷宣言 (Agile Manifesto) 衍生的術語，於 2001 年由一群人共同撰寫，包括 Scrum、極致程式設計 (Extreme Programming，XP)、動態系統開發方法 (Dynamic Systems Development Method，DSDM) 和 Crystal 的創造者、功能導向開發的代表，以及軟體產業中公認的其他諸多領導者。 敏捷宣言針對當時所有不同的敏捷方法建立一套共同的最高價值和原則。 它詳細說明造就高效率小組的四個核心價值。
個人及其反覆項目
交付可行軟體
客戶合作
隨著變化做出反應
這些核心價值以 12 項原則為後盾，您可以在下列網站找到這些原則：敏捷軟體開發宣言 (英文)。
這些價值並不是敏捷宣言的創造者隨口說說而已， 而是實際有用的價值。 各種敏捷方法實現這些價值的方式稍有差異，但所有方法都有特定的流程和做法來培養其中一項或多項價值。
個人和互動
個人和互動是高效率小組不可或缺的要素。 根據一個專案期間的「溝通飽合度」研究，指出溝通沒有問題時，小組的表現可以比產業平均值更優秀 50 倍。 為了讓溝通順利進行，敏捷方法依賴頻繁的「檢查並調整」週期。 這些週期的範圍小至雙人程式設計的幾分鐘，大至連續整合的幾小時、每日站立會議的每一天，以及需要檢閱和追溯的每一次反覆。
然而，徒增回饋和溝通次數並不足以消除通訊問題。 只有在小組成員表現出幾項重要的行為時，這些「檢查並調整」週期才能發揮作用：
尊重每個人的價值
每一次溝通的真實性
所有資料、動作和決策的透明度
相信每個人都願意支援小組
奉獻給小組和致力於小組的目標
為了鼓勵這幾種行為，敏捷管理部門必須提供支援的環境、小組教練必須敦促這些行為的內涵，而小組成員必須表現出這些行為。 唯有如此，小組才能完全發揮潛力。
達到這幾種行為並不像表面那麼簡單。 由於文化規範或以往從誠實溝通所造成的衝突中得到的負面經驗，大多數小組會規避真實性、透明度和信任。 為了克服這些傾向，領導階層和小組成員必須努力營造有建設性的衝突。 這樣做不僅有助於產生有建設性的行為，還有其他幾種好處：
流程改良仰賴小組製作一份存在組織中的障礙或問題清單，並坦然面對，然後有計劃地依優先順序予以排除。
唯有能夠順暢地交換有衝突的想法，才會有改革，Scrum 教父 Takeuchi 和 Nonaka 曾經研究並發表這種現象。
為了讓小組朝共同的目標邁進，小組必須找出並解決有衝突的事項。
唯有當所有人都同意一個共同的目標且每個人和整個小組都努力改善時，才會出現承諾一起合作的情形。
關於承諾的最後一項尤其重要。 這唯有在每個人和小組都承諾願意貢獻最高價值時才會發生，這也是軟體開發小組的精髓所在。 敏捷方法建議小組從排好優先權的工作清單中取得工作、管理自己的工作，並專注於改善他們的工作習慣，以此來協助實現承諾。 這種做法是自我組織的基礎，也是敏捷小組中達成結果的動力。
為了造就高效率的小組，敏捷方法對於人和互動的重視程度，高於流程和工具。 就實際而言，所有敏捷方法都是透過頻繁的「檢查並調整」週期，以設法加強溝通和合作。 然而，唯有當敏捷領導者支持有建議性的衝突時，這些週期才有作用，需要有這種衝突，敏捷領導者才能為其敏捷小組打造真實性、透明度、信任、尊重和承諾的堅固基礎。
可行軟體勝於鉅細靡遺的文件
可行軟體是敏捷開發帶來的其中一項重大的差異。 敏捷宣言中提出的所有敏捷方法都強調應該定期交付較小的可行軟體給客戶。
所有敏捷小組都必須對他們所謂的「可行軟體」制定明確的解釋，通常稱為「完工定義」。 概略而言，一項功能唯有在其各部分通過所有測試且可供使用者操作時，這項功能才算完成。 小組的工作至少必須超越單元測試層級和系統層級的測試。 最佳的小組在其所謂一件功能完成的定義中，也包括整合測試、效能測試和客戶接受度測試。
有一家 CMMI Level 5 公司透過許多專案上的龐大資料指出，搭配功能來定義接受度測試、連續並按優先順序實作功能、對每一項功能立即執行接受度測試，以及修正視為最高優先的任何 Bug，將能夠有計劃地將生產速度加快兩倍，並將缺失減少 40%。 這項結論出自於全球缺失率最低的其中一家公司。
敏捷宣言建議小組應該定期交付可行軟體。 為了讓敏捷小組表現出達成此目標所需的高效率和高品質，一致同意完工定義的解釋是其中一種可行的做法。
客戶合作勝於合約談判
過去二十年來，世界各地的專案成功率已成長兩倍以上。 這要歸功於專案較小和經常交付，使得客戶可以定期對可行軟體提出意見。 宣言的作者在強調讓客戶參與軟體開發流程是成功的關鍵時，即已深切了解到這種重要性。
敏捷方法建議客戶代表與開發小組攜手共同合作，以培養這項價值。 假設第一個 Scrum 小組擁有數千位客戶。 因為不可能讓所有客戶都參與產品開發，所以他們選擇一位客戶代理人 (稱為產品擁有者)，這個人不僅代表領域內的所有客戶，也代表管理、銷售、支援、客戶服務和其他專案關係人。 隨著小組發行可行軟體，產品擁有者要負責考量客戶和專案關係人的現況和實際意見，必須每隔四週更新一次需求清單。 這樣可讓客戶協助設計正在建立的軟體。
第一個 XP 小組以內部 IT 專案來著手進行。 他們能夠請到小組中的一位公司使用者每天與他們一起合作。 大約有一成的機會，顧問公司和內部小組都能找到一位使用者可以每天與小組一起合作。 有九成的機會必須指派一位代理人。 這位客戶代理人 (XP 小組稱之為客戶) 與使用者一起合作，提供一份清楚、排好優先權的功能清單，供開發人員實作。
業界資料指出平均而言，全球敏捷專案的成功率是傳統專案的兩倍，其中一個重要原因就是每天與客戶 (或客戶代理人) 共同合作。 敏捷方法體認到這一點，因此，早就在開發小組中特別為客戶代表保留一個席位。
隨著變化做出反應勝於墨守計劃
為了建立能夠滿足客戶並提供商業價值的產品，關鍵就是隨著變化做出反應。 業界資料指出在軟體開發期間，有超過 60% 的產品或專案需求會出現變化。 傳統專案即使準時完成、未超出預算且實現計劃內的所有功能，但客戶往往還是不滿意，因為他們覺得這並不是他們真正想要的產品。「 韓弗瑞定律」(Humphrey's Law) 指出客戶在見到可行軟體之前，永遠不知道他們想要什麼。 如果客戶等到專案結束時才見到可行軟體，屆時再採納他們的意見就為時已晚。 敏捷方法在整個專案期間會徵詢客戶的意見，因此可以在產品開發的同時採納意見和新的資訊。
所有敏捷方法都提供內建的流程，可以根據客戶或客戶代理人的意見，定期變更計劃。 這些計劃一律以實現最高商業價值為優先。 因為有 80% 的價值存在於 20% 的功能中，管理得當的敏捷專案經常會提早完成，反之，大多數傳統專案總是落後完成。 因此，客戶會更滿意，開發人員也會工作得更愉快。 敏捷方法深知必須隨著變化而修正計劃，才能成功。 這就是為何具有內建流程的原因 (例如檢閱和追溯性)，這些流程特別設計為根據客戶意見和商務價值，以定期調整優先權。
敏捷是總稱 - 方法是實作
敏捷開發的本身並不是方法。 敏捷開發是一個概括術語，描述多種敏捷方法。 2001 年簽署敏捷宣言時，這些方法包括 Scrum、XP、Crystal、FDD 和 DSDM。 從那時以後，精益 (Lean) 做法也浮現成為有用的敏捷方法，所以在本主題稍後的插圖中，也納入敏捷開發總稱之下。
各種敏捷方法以稍微不同的作法來實作敏捷宣言的核心價值，就像許多電腦語言以不同的方式來表現物件導向程式設計的核心功能一樣。 最近一份調查指出約有 50% 的敏捷實踐者表示，他們的小組都採用 Scrum。 另有 20% 表示他們採用 Scrum 加上 XP 元件。 還有 12% 表示他們只採用 XP。 因為全球有超過 80% 的敏捷實作都是 Scrum 或 XP，所以 MSF for Agile Software Development v5.0 將重點集中在 Scrum 和 XP 的核心流程和做法。
.png "Agile 傘")
Scrum 是敏捷開發流程的架構， 不含特定的工程做法。 相反地，XP 著重於工程做法，但不含開發流程的完整架構。 這不表示 Scrum 沒有建議某些工程做法或 XP 沒有任何程序。 例如，第一個 Scrum 實作的所有工程做法就是現在所謂的 XP。 然而，Scrum 軟體開發架構的設計可讓小組在二至三天內開工，反之，實作工程做法通常需要幾個月的時間。 因此，何時 (和是否) 實作特定的做法，就留給每一個小組決定。 Scrum 共同創立者 Jeff Sutherland 和 Ken Schwaber 建議 Scrum 小組立即著手建立一份障礙清單和一套流程改善計劃。 工程做法視同障礙，小組應該尋求 XP 做法來做為改善之道。 最好的小組是搭配 XP 做法來輔助進行 Scrum。 Scrum 協助 XP 充分發揮，而 XP 協助 Scrum 運作順暢。
下表顯示 Scrum 和 XP 中的關鍵字如何互用。
Scrum |
XP |
|---|---|
產品擁有者 |
客戶 |
scrum 主管 |
XP 教練 |
小組 |
小組 |
期程 (Sprint) |
反覆項目 |
期程計劃會議 |
計劃遊戲 |