敏捷軟體指南

在 90 年代對極限編程有正面的體驗後，我開始對類似的方法（例如 Scrum、Crystal 和 DSDM）感到好奇。深入探討後，我提煉出這些新方法的共同特徵：偏好適應性計畫而非預測性計畫，並將人視為比所使用的程序更重要以達成成功。隨著時間的推移，這些方法彙集在敏捷軟體開發的旗幟下（而且我修改了這篇文章），但我仍然認為這篇文章中的觀點是了解敏捷精髓的一個好方法。

它可能不是所有事物的開端，但宣言為這項運動取了一個名稱，並帶來了一股最初的能量。十年後，它仍然捕捉到敏捷方法的精髓。

自我們撰寫敏捷軟體開發宣言以來已過十年，而敏捷迷因比我們預期的還要成功。但就像任何成功一樣，語意擴散的風險也隨之而來。我試著透過描述敏捷軟體開發的精髓來對抗這種疾病：偏好適應性規劃勝於預測性規劃，並偏好人員勝於流程。

然後我描述敏捷流暢性模型，我發現這是一個思考敏捷團隊如何變得熟練的有效方法，以及在您成為敏捷技術更熟練的使用者時通常會經歷的步驟。

軟體開發專案中常見的爭論在於花時間改善軟體品質與專注於釋出更有價值的功能之間。通常交付功能的壓力主導了討論，導致許多開發人員抱怨他們沒有時間處理架構和程式碼品質。這場辯論基於一個假設，即提高品質也會增加成本，這是我們的共同經驗。但反直覺的現實是，內部軟體品質消除了減緩開發新功能的冗餘，從而降低了增強軟體的成本。

軟體開發人員要撰寫在自己的機器上運作的程式碼已經夠困難了。但即使這樣做到了，從那裡到產生價值的軟體還有一段漫長的路要走，因為軟體只有在生產環境中才能產生價值。我對軟體交付的哲學精髓是建構軟體，讓它始終處於可以投入生產的狀態。我們稱之為持續交付，因為我們持續執行部署管線，以測試此軟體是否處於可以交付的狀態。

對於許多與極限程式設計接觸過的人來說，極限程式設計似乎要求軟體設計走向死亡。不僅許多設計活動被嘲笑為「前期大量設計」，而且 UML、彈性架構，甚至模式等設計技術也被淡化或直接忽略。事實上，極限程式設計涉及許多設計，但做法與既定的軟體流程不同。極限程式設計透過允許演化成為可行設計策略的做法，讓演化設計的概念重新煥發生機。它也提供新的挑戰和技能，因為設計師需要學習如何進行簡單的設計、如何使用重構來保持設計的簡潔，以及如何以演化的方式使用模式。

敏捷方法的共同元素之一是，它們將程式設計提升到軟體開發的核心角色，遠遠超過軟體工程社群通常所做的。這部分是將程式碼分類為軟體系統的主要文件，如果不是主要文件的話。

每日站立會議已成為許多團隊的常見儀式，特別是在敏捷軟體開發中。然而，有許多細微的細節區分了有效的站立會議和浪費時間的會議。

許多現今從事軟體開發的人聽過配對程式設計的實務，但它在業界的採用仍然參差不齊。其接受度不一的原因之一是，它的好處並不明顯，它在中長期獲得的回報較多。而且它也不像「兩個人在同一台電腦上工作」那麼簡單，所以許多人在感到不舒服時會很快地放棄它。然而，根據我們的經驗，配對程式設計對於協作團隊合作和高品質軟體至關重要。

使用者故事是軟體系統所需行為的區塊。它們廣泛用於敏捷軟體方法中，將大量的功能劃分為較小的部分以進行規劃。您也會聽到相同的概念稱為功能，但「故事」或「使用者故事」一詞在現今的敏捷圈中已變得普遍。

以下是一個關於敏捷方法的常見誤解。它集中在使用者故事的建立方式，以及它們如何流經開發活動。這個誤解是產品負責人（或業務分析師）建立使用者故事，然後將它們放在開發人員面前進行實作。這個概念是從產品負責人到開發人員的流程，產品負責人負責決定需要執行什麼，而開發人員負責執行的方式。

我最喜歡的簡短語之一是：如果它很痛，就更常做。它有一個快樂的特質，表面上看起來很荒謬，但當你深入探討時，它會產生一些有價值的意義

管理階層喜愛他們的指標。思考方式類似於：「我們需要一個數字來衡量我們的表現。數字可以讓人專注，並幫助我們衡量成功。」儘管用意良善，但數字管理會不直覺地導致有問題的行為，並最終損害更廣泛的專案和組織目標。指標本身並不是一件壞事；只是經常被不適當地使用。本文說明了管理階層傳統使用指標所造成的許多問題，並提供了解決這些功能障礙的替代方案。

遠距與共同定位工作並非簡單的二分法，而是有幾種團隊分配模式，每種模式都有不同的權衡和適合它們的有效技術。雖然無法確定確鑿的證據，但我認為大多數團隊以共同定位的方式工作會更有生產力。但是，你可以透過使用分散式工作模式來建立一個生產力更高的團隊，因為它讓你能夠接觸到更廣泛的人才庫。

過去四年來，Thoughtworks 在印度班加羅爾營運一個實驗室，以支援我們在北美和歐洲的軟體開發專案。傳統的離岸開發方法基於計畫驅動的方法論，但我們非常堅定地站在敏捷陣營。在此，我將討論我們在進行離岸敏捷開發時所獲得的經驗和教訓。到目前為止，我們發現我們可以讓它發揮作用，儘管好處仍有待討論。（儘管本文最後更新於 2006 年，但我於 2011 年拜訪了我們的離岸工作，發現教訓仍然相關，因此本文不需要進一步大幅修改。）

當有人在尋找構成頂尖企業軟體開發人員的要素時，談話通常會轉向框架和語言的知識，或者可能是理解複雜演算法和資料結構的能力。對我來說，程式設計人員，或者說開發團隊中最重要的特質之一，是我稱之為客戶親和力的東西。這是開發人員對軟體所要解決的商業問題以及生活在那個商業世界中的人們的興趣和親近感。

贊助軟體開發的人通常對開發指標（例如速度或部署到生產的頻率）不太感興趣。他們更關心軟體將提供的業務效益，例如降低人工工作、提高銷售轉換率、提高客戶滿意度，也就是業務成果。以成果為導向的團隊是指被授權且具備提供業務成果的能力，此類團隊擁有能夠執行實現成果所需所有必要活動的人員。相比之下，以活動為導向的團隊既沒有設備也沒有授權這樣做。他們只能執行實現成果所需的數項活動之一。

表面上，敏捷軟體開發的世界很光明，因為它現在已成為主流。但現實令人不安，因為許多所做的事情都是偽敏捷，無視敏捷的價值觀和原則。我們應該關注的三個主要挑戰是：對抗敏捷產業綜合體及其強加流程給團隊的習慣、提升技術卓越的重要性，以及圍繞產品（而非專案）組織我們的團隊。儘管有這些問題，但社群的強大之處在於其學習和適應的能力，解決我們原始宣言作者無法想像的問題。

我習慣創造新詞彙來描述我在軟體開發中看到的事物。這是這個領域的作家們的共同習慣，因為軟體開發仍然缺乏許多有用的術語。建立術語的一個問題在於，術語容易在語意擴散的過程中失去其意義 - 使用我們術語中另一個潛在的補充。

根據敏捷聯盟的現任董事會，敏捷方法「已經跨越鴻溝」，我想這表示它們正變得更加普遍。儘管這有其優點，但也帶來問題。當一種方法論或設計方法變得流行時，我們就會看到許多人使用它或教授它，他們專注於流行，而不是真正的細節。這可能會導致以敏捷的名義進行的行為報告，與運動創始者的原則完全相反。

最近我聽說許多專案發生混亂。事情的經過如下

• 他們想要使用敏捷流程，並選擇 Scrum
• 他們採用 Scrum 實務，甚至可能是原則
• 過了一段時間，進度緩慢，因為程式碼庫混亂不堪

敏捷方法的常見（可能是主要的）實務是為正在建置的軟體開發功能清單（通常稱為故事）。這些功能會透過索引卡、工作佇列、燃盡圖表、待辦事項清單或任何您選擇的工具來追蹤。