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


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

http://img1.mukewang.com/5dce11f20001580306400427.jpg

軟件開發存在些什麼問題?框架

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

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

.客戶的需求一變再變,設計也只好一改再改單元測試

.開發時程的估計有兩種方法:擲茭 & 閉着眼睛喊測試

.項目準時關閉?你求神保佑吧…優化

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

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

.那個誰誰誰呢?唉!人又被其餘項目拉走了…debug

.交付給客戶的每一個版本,開發週期愈來愈長,卻依然以爲時間緊迫

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

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

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

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

.爲能如期達交,每每開發人員會犧牲質量

.極重的開發壓力,讓全部人員心情沉重,士氣受創

爲什麼要導入敏捷開發?

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

需求不會變動,並且已被徹底理解,因此設計初期就應明確全部需求。

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

「人」能夠像機器同樣可預測而且可以可靠工做。

只有計劃能以「精準而且保持需求不變」的情境爲前提,開發前期用於計劃的投入纔有價值。

http://img2.mukewang.com/5dce11fd00017d8506400427.jpg

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

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

在項目開發過程當中,有幾個主要的狀況,是難以採用敏捷開發的,包含:

在價格競爭的環境下,若試運行或塑模(Modeling)成本太高,咱們是難以取得此項成本。

敏捷開發主要的精神在於較短的開發循環(創建在反覆式開發方式上)以及漸進式開發與交付。若試運轉的時間過長或取得運做結果的時效過慢,發現問題時可能機會已然失去。

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

因此敏捷開發較適用軟件開發,又稱爲敏捷軟體開發。對於其餘開發,雖然沒法一體適用,但敏捷開發中所推薦的一些觀念與工具,仍可引用在其餘類型的開發項目上,增進開發的績效。

http://img1.mukewang.com/5dce1208000152df06400427.jpg

敏捷開發的發展

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的開發與驗證。每一個迭代都具備跨功能的團隊,包含了規劃、分析、設計、程序編碼、單元測試和驗收測試。在迭代結束時,將工做產品向利益相關者展現。透過上述方式讓總體風險分散與下降,並使產品可以快速得到反饋與適應變化。

迭代的方式,可能不會一次增長足夠的功能來保證可當即發佈使用,可是目標是在每次迭代結束時,有一個可用的發行版(最小化程序缺點)。

完整產品的發佈或新功能可能須要屢次迭代。

http://img.mukewang.com/5dce12100001019919200922.jpg

敏捷開發的框架

如同咱們所熟知改善活動有許多不同的手法,如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作事有不少好處,兩我的在一塊兒探討很容易產生思想的火花,也不容易走上偏路。

http://img.mukewang.com/5dce121800017a1e15550839.jpg

持續集成(Continuous Integration)與客戶參與(Customer Engagement):敏捷開發中提倡持續集成,短期(一天以內十幾回甚至幾十次)的集成,因爲集成很頻繁,每一次集成的改變也不多,開發過程當中有什麼問題或者產品通過一輪迭代後,可以以最快速度獲得客戶的反饋,即便集成失敗也容易定位錯誤。

小版本發佈(Frequent Releases):在敏捷開發中,但願而是儘可能多的產品發佈頻率,通常以周、月爲單位。這樣,客戶每隔一段時間就會拿到發佈的產品進行試用,而咱們能夠從客戶那獲得更多的反饋來改進產品。

較少的文檔(Minimal Documentation):簡單可讀的代碼纔是好的代碼,咱們的理想爲,所寫的東西別人一看就可以看懂。故而不多須要對代碼進行補充註釋。

公開與合做(Collaborative Focus),在敏捷開發中,每一個人都有權力得到系統任何一部分的代碼,基於互信與合做原則對系統進行優化。這樣每一個人都能熟悉系統的代碼,即便團隊的人員變更,風險也低。

自動化測試(Automated Testing):因爲須要頻繁的迭代與驗證回饋,測試的時間與成本勢必增長, QA人員則須要有自動化測試的開發能耐。

最後,奉上案例:learun.cn

原文:windy

相關文章
相關標籤/搜索