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

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

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

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

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

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

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

.項目準時關閉？你求神保佑吧…

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

.咱們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