軟體開發新模式：敏捷開發

做軟體開發的同鞋可能都或多或少的聽說過敏捷開發，但是實際採用這種開發模式的專案場景可能就比較少了，今天針對敏捷開發能實際解決的問題做一個基本的介紹，讓有興趣的小夥伴能對敏捷開發的內涵有個基本的認識。

軟體開發存在些什麼問題？

硬體世界的突破與發展速度逐漸趨緩，軟體世界的需求扶搖直上，面對環境的瞬息萬變，再加上對各類軟體質與量上的快速需求，以往有時間慢慢處理的問題，越來越難以即時處置，例如：

.客戶連需求都講不清楚，分析師只好也不清不楚的混過

.客戶的需求一變再變，設計也只好一改再改

.開發時程的估計有兩種方法：擲茭 ＆ 閉著眼睛喊

.專案準時關閉？你求神保佑吧…

.加班是必需的，傷肝是正常的，誰叫你入錯行

.我們PM的全名是Post Man，把客戶的郵件轉寄工程師，再把工程師的郵件回寄客戶

.那個誰誰誰呢？唉！人又被其他專案拉走了…

.交付給客戶的每個版本，開發週期越來越長，卻依然覺得時間緊迫

.無法依據原始規劃，如期產出最終成品

.版本交付時，仍存在明顯缺陷，雙方都不滿意

.開發時間很長，過程中需求不斷變化，致使初始規劃顯得很不正確

.規劃趕不上變化，新的需求很難加入原始規劃中

.為能如期達交，往往開發人員會犧牲質量

.極重的開發壓力，讓所有人員心情沉重，士氣受創

為何要匯入敏捷開發？

原有的設計流程通常是預測性(Predictive)或稱順序式(Sequential)的設計流程，它啟動時的假設情境是—已建立完整的願景，願景中所有的需求均已定義清楚，同時已策劃出實現願景的詳細計劃(戰 術)，換言之，原有的設計流程是基於下列假設條件而進行規劃的：

需求不會變更，而且已被完全理解，所以設計初期就應明確所有需求。

專案開始前，即可確認預計要採用的「技術」，該技術是足夠的且能發揮正常功效以完成整個設計。

“人”可以像機器一樣可預測並且能夠可靠工作。

只有計劃能以“精準並且保持需求不變”的情境為前提，開發前期用於計劃的投入才有價值。

可惜的是，某些設計專案，在期初通常只有大方向，客戶往往也難以清楚表示“需求”，隨著開發的程式，客戶越懂越多，以前沒想到的需求往往就會隨時浮現。同時，新的技術層出不窮，可能真正要開發時，該項軟體技術已經過時。再加上開發人員的認知、技術、傳達、構思方式不僅人人不同，甚者，不同時間也會出現差異。這些林林總總的噪音加進來，讓過往著重初始規劃，與規劃完成後才進行分工設計的模式，不僅在開發前期投資很高，也感覺初始規劃顯得很不正確。

敏捷開發適用於實體產品的開發嗎？

在專案開發過程中，有幾個主要的情況，是難以採用敏捷開發的，包含：

在價格競爭的環境下，若試執行或塑模（Modeling）成本過高，我們是難以取得此項成本。

敏捷開發主要的精神在於較短的開發迴圈（建立在反覆式開發方式上）以及漸進式開發與交付。若試運轉的時間過長或取得運作結果的時效過慢，發現問題時可能機會已然失去。

顧客對產品缺陷的容忍度極低。如果今天你買了一輛汽車，每半年叫你回原廠做一次調整，你願意嗎？但觀察近年上市的軟體，都是初版發行後，會不斷的調適(debug)與升級，這也不知道是我們使用者真的擁有較大的容忍度，還是已被廠商洗腦而認為這是正常的。

所以敏捷開發較適用軟體開發，又稱為敏捷軟體開發。對於其他開發，雖然無法一體適用，但敏捷開發中所推薦的一些觀念與工具，仍可引用在其他型別的開發專案上，增進開發的績效。

敏捷開發的發展

2001年，十七名軟體開發人員聚會(因在美國猶他州的雪鳥度假村，俗稱雪鳥會議)討論1957~1997年間的一些讓開發不那麼沈重的方法與框架，並由Jeff Sutherland，Ken Schwaber和Alistair Cockburn起草，一同釋出了「敏捷軟體開發宣言」。

2005年，由Alistair Cockburn和Jim Highsmith領導的小組編寫了一份專案管理原則的附錄，即「相互依存宣告」，以便根據敏捷軟體開發方法來指導軟體專案管理。

2009年，Robert C Martin編寫了軟體開發原則的擴充套件，即軟體工藝宣言（Software Craftsmanship Manifesto），根據職業行為和掌握程度來指導敏捷軟體開發。

2011年，敏捷聯盟建立了敏捷實踐指南、敏捷實踐、術語和元素工作定義的演化開放式彙編，以及來自敏捷從業者社群的經驗指南。

2016年，將敏捷實踐指南進行調適並更名為「敏捷詞彙」

敏捷開發的基本精神

將產品開發工作細分微小化，因此大大的減少了前期規劃和設計的數量。

運用迭代(衝刺)這種短時間(1周～1月)的運作的模式來進行1至數個Story的開發與驗證。每個迭代都具有跨功能的團隊，包含了規劃、分析、設計、程式編碼、單元測試和驗收測試。在迭代結束時，將工作產品向利益相關者展示。透過上述方式讓整體風險分散與降低，並使產品能夠快速獲得反饋與適應變化。

迭代的方式，可能不會一次增加足夠的功能來保證可立即釋出使用，但是目標是在每次迭代結束時，有一個可用的發行版（最小化程式缺點）。

完整產品的釋出或新功能可能需要多次迭代。

敏捷開發的框架

如同我們所熟知改善活動有許多不一樣的手法，如QC Story、8D、VA/VE、Lean、DMAIC、DMADV‧‧‧等多種不同型別的框架，敏捷軟體開發的框架也因派別與視角的差異而有持續的發展，例如:自適應軟體開發（Adaptive software development，ASD）、敏捷建模(Agile modeling）、終極程式設計(eXtreme Programming :XP)、迅速應用程式開發、統一處理程式與動態系統開發法（DSDM）、Scrum法、看板(Kanban)法、水晶清透法(Crystal)、功能驅動開發(Feature Driven Development: FDD) ‧‧‧，其中Scrum法是目前看到最廣泛被使用的敏捷開發框架。

敏捷開發的幾個重要作法

每個框架的發展都有其自成系統的工具與之搭配，真的是族繁不及備載，此處僅列出幾個在Scrum中較具特色的管理方法(此處不涉及軟體設計的專業技術)：

迭代和增量式軟體開發：此為相對於傳統「瀑布式開發」的對立作法，瀑布式開發認為初期應有明確的需求與目的，故先做好完整的規劃，將總體目標分拆給不同的群體，各自群體努力工作，完成子系統，然後彙總進行測試。我借用一本書(敏捷開發的逆襲) 的作者Teddy Chen 的比喻來描述兩種不同的模式：切一塊蛋糕給人享用，應是縱切的，每塊蛋糕都有鮮奶油層、蛋糕層、水果層、布丁層‧‧‧(敏捷開發推薦運用基本版本+多次的迭代版本的釋出方式，讓顧客拿到的每個版本都是可以實際使用的)。而不應該橫切，單吃奶油或單吃布丁層，沒人會覺得吃到的是成品蛋糕。不幸的是，在很多時候，我們的開發設計，往往採用橫切法：需求定義>設計規劃>概念設計>各自分工從事細部設計>模型建置>彙整測試>設計修正>原型測試>放行。

非常短的返饋迴路和適應週期:敏捷的 Stand up(站立會議)或日常scrum作法，運用簡短的會議，讓團隊成員相互報告他們前一天(或階段)對於團隊的迭代(或階段)目標與成果、今天(或階段)打算做的目標以及他們可以看到的任何障礙或阻礙，進行資源調配與設計對應方案。頻繁的討論與分享，一有問題大家就會知道，也有可能獲得回饋，人員也不致覺得太孤單。

測試引導開發與結對程式設計(Pair-Programming)：對由業務需求進行分析，分解為不同的Story。然後兩個人同時對某一Story進行運作，經過討論取得共識後，先由一人建構測試程式碼，這樣寫出來的測試程式碼就真實反映了業務功能需求。接著由另一個人控制鍵盤，編寫功能的實現程式碼。先寫測試程式碼，能夠讓開發人員明確目標，就是讓測試透過。Pair做事有很多好處，兩個人在一起探討很容易產生思想的火花，也不容易走上偏路。

持續整合(Continuous Integration)與客戶參與(Customer Engagement):敏捷開發中提倡持續整合，短時間(一天之內十幾次甚至幾十次)的整合，由於整合很頻繁，每一次整合的改變也很少，開發過程中有什麼問題或者產品經過一輪迭代後，能夠以最快速度得到客戶的反饋，即使整合失敗也容易定位錯誤。

小版本釋出(Frequent Releases):在敏捷開發中，希望而是儘量多的產品釋出頻率，一般以周、月為單位。這樣，客戶每隔一段時間就會拿到釋出的產品進行試用，而我們可以從客戶那得到更多的反饋來改進產品。

較少的文件(Minimal Documentation):簡單可讀的程式碼才是好的程式碼，我們的理想為，所寫的東西別人一看就能夠看懂。故而很少需要對程式碼進行補充註釋。

公開與合作(Collaborative Focus)，在敏捷開發中，每個人都有權力獲得系統任何一部分的程式碼，基於互信與合作原則對系統進行最佳化。這樣每個人都能熟悉系統的程式碼，即使團隊的人員變動，風險也低。

自動化測試(Automated Testing):由於需要頻繁的迭代與驗證回饋，測試的時間與成本勢必增加， QA人員則需要有自動化測試的開發能耐。

最後，奉上案例：learun.cn

原文：windy