Agile Software Development

前言 速度是企業競爭致勝的關鍵因素，軟體專案的最大挑戰在於 一方面要應付變動中的需求， 一方面要在緊縮的時程內完成專案， 所以軟體團隊除了在技術上必須日益精進，更需要運用有效的開發流程，以確保團隊能夠發揮綜效。這正是 Agile Process (敏捷的軟體開發流程) 於近年來興起的主要原因。

歷史 敏捷軟體開發又稱敏捷開發， 它們的具體名稱、理念、過程、術語都不盡相同，相對於「非敏捷」，更強調 從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法， 是一種應對快速變化的需求的一種軟體開發能力。 它們的具體名稱、理念、過程、術語都不盡相同，相對於「非敏捷」，更強調 程式設計師團隊與業務專家之間的緊密協作、 面對面的溝通（認為比書面的文檔更有效）、 頻繁交付新的軟體版本、 緊湊而自我組織型的團隊、 能夠很快地適應需求變化的代碼編寫和團隊組織方法，也更注重做為軟體開發中，人的作用。

歷史 2001年初，因觀察到許多的軟體團隊身陷不斷擴大的流程之中的困境，一群業界專家聚集在一起，勾勒出一些能讓軟體團隊迅速工作，以及回應變化的價值觀和原則。他們自稱為Agile Alliance。 之後的七個月裡，他們創造具有價值的聲明，也就是敏捷軟體的開發宣言。

敏捷開發的價值觀 雪鳥會議中共同起草了敏捷軟體開發宣言。 其中最重要的部分就是對一些與會者一致同意的軟體開發價值觀的表述： 個人及互動勝於流程與工具。 可用的軟體勝於詳盡的文件。 與客戶合作勝於合同談判。 隨時應對變化重於墨守計畫。

敏捷開發的12個原則 1.經由及早與持續的交付有價值軟體以滿足客戶需求是我們最優先順序。 2.竭誠歡迎改變需求，甚至以處於開發後期亦然。敏捷流程掌控變更，以維護客戶的競爭優勢。 3.經常交付可用的軟體，頻率可以是數週到數個月，以較短時間間隔為佳。 4.業務人員與開發者必須在專案全程中天天一起工作。

敏捷開發的12個原則 5.用動機強的人來建構專案，給予他們適當的環境，充分的資源，並相信他們可完成工作。 6.開發團隊之內與團隊之間，效率最高效果最佳傳達資訊的方法是面對面的溝通。 7.可用的軟體是最主要的進度量測方法。 8.敏捷開發提倡能持續的開發步調。贊助者、開發人員以及使用者應當能維持一個可以穩定而恆久的步調。

敏捷開發的12個原則 9.持續追求優越的技術與優良的設計，以強化敏捷性。 10.簡單化—如何擴大不需處理之工作的技巧—是不可或缺的。 11.最佳的架構、需求與設計皆源自於自身組織良好的開發團隊。 12.再規律的時間區隔中，開發團隊因應如何變得更有效率，然後據之適當地調整與修整自己的行為。

Agile Process - 敏捷的開發流程 客戶與開發人員形成密切合作的團隊，因為客戶無法於初期定義完整的規格，而開發人員於開發過程中也常常無法知悉外在環境或業務的變動，所以需要兩者密切合作方能開發適用的軟體。 專案最終的目標是可執行的程式，因此所有的中間產品必須經過審慎評估，確認有助於最終目標，才需要製作中間產品。 採用 Iterative 與 Incremental 方式分階段進行，密集 review 是否符合需求。 流程可以簡單，但規劃與執行必須嚴謹。 強調團隊合作，賦予高度的責任，團隊有自主權得以因應變化做調整。

Agile VS. Iterative development 大部分敏捷的方法是共用遞迴開發所強調的方法:在短時間內建置出可釋出的軟體。 敏捷的方法不同於遞迴的方法，軟體被量測的時間是在數週內，而不是數個月內。 有高度密切的合作夥伴。

Agile VS. Waterfall’s model 固定的、沒有彈性的。 很困難去達到互動。 假如說需求沒有完全的被了解，或是可能需要完全地改變專案的需求，瀑布式的model是比較不適合的。 Agile 完整地開發，每少數幾週或是少數幾個月裡可以測試功能。 強調在獲得最簡短的可執行功能的部分，能夠及早給予企業價值。 在整個專案的生命週期裡，可以持續的改善、增加未來的功能。

Agile VS. Cowboy coding Cowboy coding Agile 團隊成員做他們覺得對的事。 常會再評估專案計畫 強調面對面的溝通 使用較少的文件 這會引起使用cowboy coding的人覺得困擾

敏捷的方法 有一些我們已知的敏捷軟體開發方法 Extreme Programming (XP) 極限編程 Scrum Agile Modeling 敏捷建模 Adaptive Software Development (ASD)自適應軟體開發 Crystal Clear and Other Crystal Methodologies 水晶方法 Dynamic Systems Development Method (DSDM)動態系統開發方法 Feature Driven Development (FDD)特性驅動開發 Lean software development 精益軟體開發 Agile Unified Process (AUP)

敏捷的方法 其它的方法 Agile Documentation ICONIX Process Microsoft Solutions Framework (MSF) Agile Data Method Database refactoring 在非軟體活動中，使用敏捷原則的例子 Lean manufacturing

eXtreme Programming XP我們一般稱為極限編程，是最輕量級的開發流程。 最主要的精神是 它強調客戶所要的是 『在客戶有系統需求時，給予及時滿意的可執行程式』，所以最適合需求快速變動的專案。 它強調客戶所要的是 workable 的執行碼，所以把與撰寫程式無關的工作降至最低，並要求客戶與開發人員最好以 side-by-side 的方式一起工作。

XP 開發流程的基本步驟 1. 開發人員隨時可以和客戶進行有效溝通，撰寫 user stories 以確認需求。 2. 簡易快速的系統設計，撰寫獨立的驗證程式以解決特殊困難的問題，找出演算法即可丟棄驗證程式。 3. 規劃多次小型階段的專案計劃，以最快速度完成每一階段的程式交付客戶，客戶負責 Acceptance tests； 4. Coding 前必須完成 Unit Test 與 Acceptance tests 程序，所有模組整合前都須經過 Unit Tests； 5. 開發人員必須快速回應 Bug 與需求變更； 6. 要求二人一組使用一台電腦設計程式，當一人 coding 時，另一人負責思考與設計； 7. 程式必須符合程式規範，並常做程式的重構(Refactoring)。

XP 開發流程的基本步驟 XP 屬於較精簡的流程，於導入應注意幾件事情 1. 最好有顧問給予協助； 2. 持續的 Review； 3. 可適當調整流程，但不可失去其基本精神。

SCRUM 開發流程 SCRUM 開發流程是 Agile Process 的一種，以英式橄欖球爭球隊形 (Scrum) 為名。 基本假設是 『開發軟體就像開發新產品，無法一開始就能定義 Final Product 的規程，過程中需要研發、創意、嘗試錯誤，所以沒有一種固定的流程可以保證專案成功』

SCRUM 開發流程 Scrum 將軟體開發團隊比擬成橄欖球隊， 因此 SCRUM 非常適用於產品開發專案。 有明確的最高目標， 熟悉開發流程中所需具備的最佳典範與技術， 具有高度自主權， 緊密地溝通合作， 以高度彈性解決各種挑戰， 確保每天、每個階段都朝向目標有明確的推進， 因此 SCRUM 非常適用於產品開發專案。

SCRUM 開發流程 以 30 天為一個階段，由客戶提供新產品的需求規格開始，開發團隊與客戶於每一個階段開始時挑選該完成的規格部份，開發團隊必須盡力於 30 天後交付成果，團隊每天用 15 分鐘開會檢視每個成員的進度與計畫，了解所遭遇的困難並設法排除。 SCRUM 與傳統開發流程及專案管理差異較大，於導入時最好有顧問協助。

Scrum構成要素 Product Backlog Sprint 整套專案依照各項 feature、需求的優先性，被切成一個個獨立的工作（Task）。 Sprint 執行Scrum的單位時程，通常是一個月。 Sprint Backlog and Sprint Planning Meeting Sprint 規劃會議裡團隊依照優先性，從Product Backlog裡挑出下個Sprint的Sprint Backlog，還要確認完成這些工作所需的前置作業。 討論重點放在優先性最高的工作上， 並擬出大約的—主要的目標。 Brief Daily Meeting( Daily Scrum) 在Sprint期間，團隊每日的簡短會議（建議不超過15分鐘），主要讓全部成員了解前一日的工作情況及今日的工作。

Scrum構成要素 Sprint Review Meeting Iteration 在Daily Scrum Meeting裡，每個人必須回答三個問題： 昨天做了什麼事？ 今天要做什麼事？ 工作上是否遇到任何的阻礙或問題 主持者必須快速解決成員所遇到的困難。 Sprint Review Meeting 一個Sprint結束，Review Meeting 通常是對作新功能的demo，會議裡可能有其他部門、主管或是Client參與。但無須把Review Meeting 開得太長或過於正式，只要demo目的達到即可。主持者和參與者可以先檢視整個Sprint是否達成Sprint Goal，整體而言，達成Sprint Goal會比完成Sprint Backlog上每個工作來得意義深遠。 Iteration 重覆以上幾個步驟。

Scrum流程圖

Crystal 具有以下共同特徵的一系列方法學： Crystal 的這些特徵包括： 注重頻繁交付 密切溝通 深思熟慮的改進 經濟合作遊戲模型 所選的優先順序 屬性 原則 示例技術 項目示例

動態系統開發方法(DSDM) 提供了一個用於構建和維護系統的控制項框架，該框架滿足緊急時間限制的要求，而且是成功進行可重複快速應用程式開發 (RAD) 的一劑藥方。 下面列出了 DSDM 的控制原則： 活動用戶必須參與。 必須授權 DSDM 團隊進行決策。 注重頻繁交付產品。 判斷產品是否可接受的一個基本標準是要符合業務目的。 對準確的業務解決方案需要採用迴圈和增量開發。 開發期間的所有更改都是可逆的。 基本要求是高層次的並區分優先順序（以在低優先順序的項目上獲得一定的靈活性）。 在整個生命週期集成測試。 在所有參與者之間採用協作和合作方法是一項基本要求。

自適應軟體開發 ASD強調開發方法的適應性，這一思想來源於複雜系統的混沌理論。 ASD不象其他方法那樣有很多具體的實踐做法，它更側重為ASD的重要性提供最根本的基礎，並從更高的組織和管理層次來闡述開發方法為什麼要具備適應性。

敏捷性的量測 Agility Index Measurements 去幫專案做評分，依據一些敏捷的特徵是否有達成敏捷的特性的總數。 Agility Measurements Index相對於軟體專案的五個維度去做評分。 時間、風險、新穎、效用、交互作用。

敏捷性的評論 包含 缺乏結構與必須的文件 只能採用較資深的開發者來工作 整合不足的開發 要求太多的改變以致於不能被採用，可能會導致更困難的合約談判

結論 Agile Software Development是軟體開發所強調的一個精神，而不是一個方法。 遵循Agile Alliance所提的四個價值觀與12個原則。 最常見的開發方式 XP SCRUM

XP 流程圖