什麼是敏捷方法論?

2009年，David F Rico博士將Agile與傳統的軟件項目管理方法進行了比較。在他的研究和綜合過程中，他分析了23個敏捷過程，並將它們與7,500個傳統項目進行了比較。

他發現敏捷項目有20項好處：

• 41％的整體業務價值更好
• 83％的人表現出更快的上市時間
• 50％的質量更高
• 50％的成本更低
• 83％的人更有效率

敏捷方法論

有幾種敏捷方法; 所有人都有相似的哲學，特徵和實踐。但是，從實現的角度來看，每個敏捷都有自己的實踐，術語和策略。一些主要的敏捷軟件開發方法組件包括：

Scrum

Scrum是一個管理框架，具有遠程控制和管理所有項目類型中的迭代和增量的能力。它們是輕量級的，可以與其他敏捷方法一起用於各種工程實踐。Scrum在敏捷軟件開發社區中越來越受歡迎，因為它們很簡單並且具有可靠的生產率。

精益和看板 (Lean and Kanban)

1.Lean軟件開發

精益軟件開發是一種最初由Mary和Tom Poppendieck開發的迭代方法。精益軟件開發中的許多原則和實踐來自精益企業運動，並且首先被豐田等大公司使用。這種基於價值的方法側重於為客戶提供有效的“價值流”機制，為項目提供價值。

該方法的主要原則是：

• 消除浪費
• 擴大學習
• 盡可能晚地做出決定
• 盡快交付結果
• 賦予團隊權力
• 建立誠信
• 設想整個項目

通過僅選擇對系統具有實際價值的功能，小批量優先排序和交付可消除浪費。相反，精益方法強調速度和效率; 依靠客戶和程序員之間快速，可靠的反饋。它側重於客戶要求“拉動”產品的想法。重點更多的是個人或小團隊更快，更有效的決策能力，而不是層次控制方法。該方法集中於其團隊資源的效率，確保每個人始終盡可能高效。

看板方法 (Kanban)

組織使用看板方法來管理項目的創建，同時強調持續交付而不會使開發團隊負擔過重。與Scrum一樣，看板流程旨在幫助團隊更有效地協同工作。

有三個原則：

1. 可視化您的工作：查看彼此上下文中的所有項目 – 提供更多信息
2. 限制正在進行的工作量（WIP）：平衡基於流的方法，以便團隊不會立即做太多工作
3. 增強流程：一旦完成一項任務，就從積壓工作開始下一個最高工作

看板方法促進了客戶和團隊的持續協作。它鼓勵持續學習和改進，為團隊提供最佳的工作流程。

極限編程（XP）

極限編程（XP）最初由Kent Beck描述。它是最流行和最有爭議的敏捷方法之一。XP是一種高度自律的方法，可以更快地持續提供高質量的軟件。客戶積極參與緊密團隊，不斷進行規劃，測試和快速反饋，以便經常提供工作軟件。該軟件應每隔三到幾週發送一次。

最初的XP方法基於四個簡單的值：

1. 簡單
2. 通訊
3. 反饋
4. 勇氣

它有12個支持實踐：

1. 規劃遊戲
2. 小版本
3. 客戶驗收測試
4. 設計簡單
5. 結對編程
6. 測試驅動的開發
7. 重構
8. 持續集成
9. 集體代碼所有權
10. 編碼標準
11. 隱喻
12. 可持續發展

水晶 (Crystal)

Crystal方法是開發軟件中最輕量級和適應性最強的方法之一。它由幾個敏捷過程組成，包括透明，水晶黃，水晶橙和其他獨特的特徵方法。推動這些流程的因素包括：團隊規模，系統的重要性以及項目的優先級。

Crystal系列專注於實現每個項目都具有獨特的特徵，因此，必須定制策略和實踐以適應這些功能。

Crystal方法有**幾個基本原則，**包括：

• 團隊合作
• 通訊
• 簡單
• 反射
• 經常調整
• 改善流程

與其他方法一樣，這種敏捷過程可以促進早期和頻繁的工作軟件交付。它鼓勵高度的用戶參與，適應性和消除乾擾和官僚作風。

動態系統開發方法（DSDM）

動態系統開發方法（DSDM）起源於1994年，為當時稱為快速應用程序開發（RAD）的項目交付提供行業標準框架。雖然它在20世紀90年代非常流行，但RAD方法以非結構化的方式發展。

自成立以來，DSDM已經發展成熟; 它為敏捷流程和迭代項目的規劃，管理，執行和擴展提供了全面的基礎。

DSDM有六個圍繞業務需求的關鍵原則：

1. 值
2. 積極的用戶參與
3. 授權團隊
4. 經常發貨
5. 綜合測試
6. 利益相關者合作

DSDM使用“適合商業目的”的方法來實現交付和驗收標準。它側重於公式：80％的系統部署在20％的時間內。

功能驅動開發（FDD）

Jeff De Luca，以及貢獻者Am Rajashima，Lim Bak Wee，Paul Szego，Jon Kern和Stehen Palmer開發了功能驅動開發（FDD）。它是一個模型驅動的短迭代過程，首先建立敏捷模型的形狀。“按功能設計，按功能構建”的迭代每兩週舉行一次。這些功能對客戶很有吸引力，因為它們很小且很有用。

使用以下八種做法提供FDD設計和開發：

1. 域對象建模
2. 開發功能
3. 組件和類所有權
4. 特色團隊
5. 檢查
6. 配置管理
7. 定期構建
8. 進展和結果的可見性

敏捷中的角色 (Scrum Roles)

在敏捷開發過程中，Scrum最清楚地定義了敏捷在項目管理中的作用。

Scrum項目中有三個角色： 產品負責人，Scrum Master和團隊成員。

產品負責人監督項目的所有業務條件，以確保以正確的順序構建正確的產品。一個好的產品負責人可以平衡競爭優先級，為團隊提供，並對項目做出決策。

Scrum Master 是團隊的教練; 他們幫助團隊有效地合作。Scrum Masters通過消除影響進度的障礙，促進會議和討論組，跟踪進度，解決問題以及執行其他項目管理職責來為團隊服務。

團隊共同努力確定實現產品所有者概述的產品目標的最佳方法。該團隊決定哪些成員將管理特定任務，並概述實現預期目標所需的技術實踐。

Scrum Master角色在哪裡適合敏捷軟件開發？

在敏捷項目管理實踐中，Scrum Master的是21 日世紀的項目經理的版本。但是，與傳統的項目經理不同，Scrum Master不會對項目的成功或失敗負責。

他們的權力只延伸到這個過程。Scrum Master在此過程中的專業知識激勵並指導團隊在最高級別上執行。其他傳統管理角色，如項目範圍，成本，人員和風險管理仍然是項目經理的責任。

驚喜：敏捷組織是分層的！

關於敏捷組織的一個常見誤解是它們是非等級的或扁平的。沒有東西會離事實很遠。高層管理人員仍然為組織的其他成員設定方向和基調，人們仍然因沒有完成工作而被解僱。與傳統的官僚組織相比，推動更高績效的努力更加無情。在官僚機構中，表現不佳的員工仍然可以隱藏在系統的角落和縫隙中。但在一個敏捷的組織中，存在一種激進的透明度，使所有同行對其行為負責。

敏捷組織中的層次結構與官僚機構中的層次結構非常不同。該靈活的層次結構是基於能力的，不權威。表現並非基於取悅老闆，而是為客戶增加價值。該組織使用動態水平和垂直通信方法，非常具有互動性。想法可以來自任何位置的任何人，包括客戶。這是一個不斷發展，學習和適應不斷變化的網絡; 它通過利用所呈現的機會為客戶增加新的價值。如果做得好，通過減少工作繼續為客戶提供更多價值，可以為組織帶來更豐厚的回報。

敏捷清楚地區分了剝削和探索之間的差異。在敏捷組織中，所有成員都在不斷探索為客戶增加更多價值的方法。

在敏捷管理的早期階段，批評者認為小型團隊永遠無法處理大型複雜問題。但他們錯了。所有團隊都是交織在一起的網絡的一部分，這種網絡由所有關注共同目標的各方之間的持續對話驅動。各方的共同和一致的節奏，提供了一個堅實的平台，使小型團隊能夠管理更複雜的問題。到目前為止，這是一個比官僚方法更好的系統。

敏捷過程 (Agile Process)

敏捷過程將更大的軟件項目分解為幾個較小的部分，可以按增量和迭代開發。**研究證明，項目規模與成功之間存在負相關關係（即：項目越短，成功率越高）。

敏捷方法通過創建幾個較小的項目來減少項目的大小。這種迭代方法將敏捷管理與其他管理方法區分開來。

與其他方法不同，敏捷管理在規劃和開發階段使用迭代。每次迭代通常為一周。在這些會話期間，項目團隊和客戶團隊協作確定需要添加到迭代的優先級。最終結果是在類似生產環境中快速交付給客戶的工作軟件程序。然後，客戶可以測試他們的程序並根據需要進行更改。隨著程序的更改，在整個過程中會發布許多版本。重複此迭代過程，直到項目完成。

一般管理和敏捷

軟件編程是當今幾乎所有業務的關鍵組件。這意味著敏捷是每種組織和工作形式的必要過程。

融合新價值觀，實踐，原則和利益的敏捷方法是傳統的命令和控制方式的項目管理的**更好的替代方案。**敏捷過程甚至遍布不同的行業和功能，包括C套件。

然而，雖然許多公司正在採用一些敏捷流程，但它們仍採用官僚自上而下的方法運營。在當今的數字化主導經濟體中，公司開發敏捷管理實踐至關重要。但許多公司仍然在**努力應對這種轉變，**並在命令式文化中運作。這體現在高級管理層的思維方式和技能上，是公司今天面臨的最大障礙。

敏捷實踐 (Agile Best Practices)

有許多不同的敏捷實踐 ; 敏捷從業者不會使用許多人。那些想要轉換為使用敏捷過程的人應該了解不同的實踐，以幫助他們將實踐應用到他們的環境中。以下示例有助於說明如何應用敏捷實踐。

每日站立（Standup Meeting）

每日站立會議也稱為每日Scrum會議。Scrum會議每天由團隊舉行，以便他們可以相互分享相關信息。這些會議旨在讓所有團隊成員了解項目狀態並獲得最新信息。每次會議的關鍵是簡潔。

在每日Scrum會議期間，每位成員應回答以下三個問題：

1. 我昨天做了什麼？
2. 我今天要做什麼？
3. 什麼問題阻礙了我的進步？

用戶故事 (User Stories)

用戶故事是最終用戶所需功能的簡要描述。用戶故事有三個要素。他們是：

1. 書面描述，策劃故事（通常寫在卡片上）
2. 關於故事的對話以獲得更好的理解
3. 一系列測試證實了這個故事。

這些故事是從最終用戶的角度編寫的，並使用他們理解的語言。故事充當開發者和客戶之間的貨幣; 雙方都清楚地了解它們。您可以閱讀有關用戶故事沒有“完成”的4個原因的更多信息。

自動化測試 (Automated Testing)

實施正式和徹底的自動化測試是敏捷過程的重要組成部分。測試從源頭查找並消除缺陷，以確保將可用的軟件包交付給客戶。開發人員可以使用各種可用框架在安全網下創建測試代碼，同時開發軟件代碼。此方法在更改軟件時保護其他功能。它也是一種更快，更有效的方法來查找程序中的錯誤。

自動構建 (Automated Generation)

敏捷方法的一個關鍵原則是始終運行軟件。實際上，實現此目的的唯一方法是確保定期自動編譯，構建，部署和測試所有軟件開發。這通常每天進行多次，每次開發人員“檢入”代碼作為開發分支的主要部分時至少進行一次。

敏捷規劃 (Agile Planning)：發布 (Release)，迭代 (Iteration) 和任務 (Task)

敏捷開發計劃有**三個級別：發布，迭代和任務。**在開始階段，項目開發人員和客戶會面討論該軟件所需的主要用戶故事。會議最初的重點是必須具備的功能，以估計和優先處理需要完成的工作。

發布計劃是一個以客戶為導向的計劃會話。客戶和開發人員都會選擇第一個產品發布系列的日期。他們協作決定在每個版本中加入哪些故事。開發人員專注於故事的估計工作，而客戶則專注於故事選擇。有多種形式的估算工作由客戶和開發團隊的需求和需求決定。

迭代計劃需要客戶和開發人員之間的協作，以啟動部分發布計劃。在迭代期間，客戶定義用戶故事並確定其優先級，同時開發人員估計開發每個用戶故事需要多少工作量。迭代的時間線要短得多，只需幾周而不是幾個月。

任務計劃在迭代計劃之後進行。故事分解為開發團隊的一系列可行步驟。任務列表在項目室中開發和發布，因此所有黨員都可以清楚地看到它們。在此計劃會話期間使用的常用工具包括便利貼和白板。每個開發人員都自願執行任務並為其分配估算。

配對編程 (Pair Programming)

在結對編程中，兩個開發人員在一個編程任務上作為一個團隊工作。一個人是司機，即輸入代碼的人，而第二個人是導航員，即在將代碼擬合到整個畫面中時計劃下一步的人。

結對編程的一個常見抱怨是浪費人力資源來完成任務。不應該讓兩個人做一個可以由一個人完成的工作。然而，雖然編程使用更多的人力，但最終的輸出證明了費用。最近的一項研究發現，結**對編程使用了15％的工作量，但缺陷減少了15％。**雖然結果可能因具體情況而異，但開發人員經常發現錯誤的減少值得使用額外的資源。

另一個好處是不需要全時配對。在決定是否更好配對時，團隊可以建立自己的規則和時間表。

持續集成 (Continuous Integratioon)

在持續集成期間，開發團隊在一天中多次將其代碼輸入系統。在添加代碼之前運行一系列測試，以確保它不會損壞系統中其他預先存在的測試或功能。開發人員必須首先運行系統的所有測試，並在集成其他代碼之前解決所有問題。代碼集成到軟件中的次數越多，合併和發現錯誤的速度就越快，越容易。

回顧 (Review)

回顧是在項目結束時或接近結束時舉行的會議。它們使所有相關方都有機會回顧並反思在此過程中所做的工作。整個團隊看什麼進展順利，什麼都沒有，哪裡的改進可以進行，而且最重要的是，他們如何利用他們學到的經驗教訓，並把它們轉化為可操作的變化。

結論

**敏捷管理是一種令人興奮且引人入勝的軟件開發方法。**通過將產品開發人員和客戶集成到規劃和實施流程中，結果是為每個參與者提供更有價值的體驗。

當敏捷編程正確使用時，組織可以不斷尋找增加客戶價值的方法。它為那些積極參與項目的人提供了更多的意義，為客戶創造了更積極的體驗，為公司帶來了更加慷慨的最終結果。