敏捷開發概述

時間 2019-11-20

標籤敏捷開發概述简体版

原文原文鏈接

老師上課提出了敏捷開發的概念，經過查閱資料，咱們得知了敏捷開發的的一些定義及內容，敏捷開發是一種以人爲核心、迭代、按部就班的開發方法。在敏捷開發中，軟件項目的構建被切分紅多個子項目，各個子項目的成果都通過測試，具有集成和可運行的特徵。換言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程當中軟件一直處於可以使用狀態。程序員

敏捷開發的路線編程

Test-Driven Development，測試驅動開發。安全

　　它是敏捷開發的最重要的部分。在ThoughtWorks，咱們實現任何一個功能都是從測試開始，首先對業務需求進行分析，分解爲一個一個的Story，記錄在Story Card上。而後兩我的同時坐在電腦前面，一我的依照Story，從業務需求的角度來編寫測試代碼，另外一我的看着他而且進行思考，若是有不一樣的意見就會提出來進行討論，直到達成共識，這樣寫出來的測試代碼就真實反映了業務功能需求。接着由另外一我的控制鍵盤，編寫該測試代碼的實現。若是沒有測試代碼，就不能編寫功能的實現代碼。先寫測試代碼，可以讓開發人員明確目標，就是讓測試經過。架構

　　Continuous Integration，持續集成。工具

　　在以往的軟件開發過程當中，集成是一件很痛苦的事情，一般很長時間纔會作一次集成，這樣的話，會引起不少問題，好比 build未經過或者單元測試失敗。敏捷開發中提倡持續集成，一天以內集成十幾回甚至幾十次，如此頻繁的集成能儘可能減小衝突，因爲集成很頻繁，每一次集成的改變也不多，即便集成失敗也容易定位錯誤。一次集成要作哪些事情呢？它至少包括：得到全部源代碼、編譯源代碼、運行全部測試，包括單元測試、功能測試等；確認編譯和測試是否經過，最後發送報告。固然也會作一些其它的任務，好比說代碼分析、測試覆蓋率分析等等。在咱們公司裏，開發人員的桌上有一個火山燈用來標誌集成的狀態，若是是黃燈，表示正在集成；若是是綠燈，表示上一次集成經過，開發人員在這時候得到的代碼是可用而可靠的；若是顯示爲紅燈，就要當心了，上一次集成未經過，須要儘快定位失敗緣由從而讓燈變綠。在持續集成上，咱們公司使用的是本身開發的產品CruiseControl。單元測試

　　Refactoring，重構。學習

　　相信你們對它都很熟悉了，有不少不少的書用來介紹重構，最著名的是Martin的《重構》，Joshua的《從重構到模式》等。重構是在不改變系統外部行爲下，對內部結構進行整理優化，使得代碼儘可能簡單、優美、可擴展。在以往開發中，一般是在有需求過來，如今的系統架構不容易實現，從而對原有系統進行重構；或者在開發過程當中有剩餘時間了，對如今代碼進行重構整理。可是在敏捷開發中，重構貫穿於整個開發流程，每一次開發者check in代碼以前，都要對所寫代碼進行重構，讓代碼達到clean code that works。值得注意的是，在重構時，每一次改變要儘量小，用單元測試來保證重構是否引發衝突，而且不僅是對實現代碼進行重構，若是測試代碼中有重複，也要對它進行重構。測試

　　Pair-Programming，結對編程。優化

　　在敏捷開發中，作任何事情都是Pair的，包括分析、寫測試、寫實現代碼或者重構。Pair作事有不少好處，兩我的在一塊兒探討很容易產生思想的火花，也不容易走上偏路。在咱們公司，還有不少事都是Pair來作，好比Pair學習，Pair翻譯，Pair作PPT，關於這個話題，錢錢同窗有一篇頗有名的文章對它進行介紹，名爲Pair Programming (結對編程)。ui

　　Stand up，站立會議。

　　天天早上，項目組的全部成員都會站立進行一次會議，因爲是站立的，因此時間不會很長，通常來講是15-20分鐘。會議的內容並非需求分析、任務分配等，而是每一個人都回答三個問題：1. 你昨天作了什麼？2. 你今天要作什麼？ 3. 你遇到了哪些困難？站立會議讓團隊進行交流，彼此相互熟悉工做內容，若是有人曾經遇到過和你相似的問題，那麼在站立會議後，他就會和你進行討論。

　　Frequent Releases，小版本發佈。

　　在敏捷開發中，不會出現這種狀況，拿到需求之後就閉門造車，直到最後纔將產品交付給客戶，而是儘可能多的產品發佈，通常以周、月爲單位。這樣，客戶每隔一段時間就會拿到發佈的產品進行試用，而咱們能夠從客戶那獲得更多的反饋來改進產品。正由於發佈頻繁，每個版本新增的功能簡單，不須要複雜的設計，這樣文檔和設計就在很大程度上簡化了。又由於簡單設計，沒有複雜的架構，因此客戶有新的需求或者需求進行變更，也能很快的適應。

　　Minimal Documentation，較少的文檔。

　　其實敏捷開發中並非沒有文檔，而是有大量的文檔，即測試。這些測試代碼真實的反應了客戶的需求以及系統API 的用法，若是有新人加入團隊，最快的熟悉項目的方法就是給他看測試代碼，而比一邊看着文檔一邊進行debug要高效。若是用書面文檔或者註釋，某天代碼變化了，須要對這些文檔進行更新。一旦忘記更新文檔，就會出現代碼和文檔不匹配的狀況，這更加會讓人迷惑。而在敏捷中並不會出現，由於只有測試變化了，代碼纔會變化，測試是真實反應代碼的。這時有人會問：代碼不寫註釋行嗎？通常來講好的代碼不是須要大量的註釋嗎？其實簡單可讀的代碼纔是好的代碼，既然簡單可讀了，別人一看就可以看懂，這時候根本不須要對代碼進行任何註釋。若你以爲這段代碼不加註釋的話別人可能看不懂，就表示設計還不夠簡單，須要對它進行重構。

　　Collaborative Focus，以合做爲中心，表現爲代碼共享。

　　在敏捷開發中，代碼是歸團隊全部而不是哪些模塊的代碼屬於哪些人，每一個人都有權利得到系統任何一部分的代碼而後修改它，若是有人看到某些代碼不爽的話，那他可以對這部分代碼重構而不須要徵求代碼做者的贊成，極可能也不知道是誰寫的這部分代碼。這樣每一個人都能熟悉系統的代碼，即便團隊的人員變更，也沒有風險。

　　Customer Engagement ，現場客戶。

　　敏捷開發中，客戶是與開發團隊一塊兒工做的，團隊到客戶現場進行開發或者邀請客戶到團隊公司裏來開發。若是開發過程當中有什麼問題或者產品通過一個迭代後，可以以最快速度獲得客戶的反饋。

　　Automated Testing ，自動化測試。

　　爲了減少人力或者重複勞動，全部的測試包括單元測試、功能測試或集成測試等都是自動化的，這對QA人員提出了更高的要求。他們要熟悉開發語言、自動化測試工具，可以編寫自動化測試腳本或者用工具錄製。咱們公司在自動化測試上作了大量的工做，包括Selenium開源項目。

　　Adaptive Planning，可調整計劃。

　　敏捷開發中計劃是可調整的，並非像以往的開發過程當中，需求分析->概要設計->詳細設計->開發 ->測試->交付，每個階段都是有計劃的進行，一個階段結束便開始下一個階段。而敏捷開發中只有一次一次的迭代，小版本的發佈，根據客戶反饋隨時做出相應的調整和變化。

　　敏捷開發過程與傳統的開發過程有很大不一樣，在這過程當中，團隊是有激情有活力的，可以適應更大的變化，作出更高質量的軟件。

項目的敏捷開發方法

敏捷方法不少,包括 Scrum、極限編程、功能驅動開發以及統一過程（RUP）等多種法，這些方法本質其實是同樣的，敏捷開發小組主要的工做方式能夠概括爲：做爲一個總體工做；按短迭代週期工做；每次迭代交付一些成果；關注業務優先級；檢查與調整。

極限編程XP

極限編程是一個輕量級的、靈巧的軟件開發方法；同時它也是一個很是嚴謹和周密的方法。它的基礎和價值觀是交流、樸素、反饋和勇氣；即，任何一個軟件項目均可以從四個方面入手進行改善：增強交流；從簡單作起；尋求反饋；敢於實事求是。XP是一種近螺旋式的開發方法，它將複雜的開發過程分解爲一個個相對比較簡單的小週期；經過積極的交流、反饋以及其它一系列的方法，開發人員和客戶能夠很是清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際狀況及時地調整開發過程。

Scrum過程

Scrum是一個包括了一系列實踐和預約義角色的過程骨架。Scrum中的主要角色包括同項目經理相似的 Scrum主管角色負責維護過程和任務， 產品負責人表明利益全部者， 開發團隊包括了全部開發人員。

在每一次衝刺（一個15到30 天週期，長度由開發團隊決定），開發團隊建立可用的（能夠隨時推出）軟件的一個增量。每個衝刺所要實現的特性來自產品訂單（product backlog），產品訂單是按照優先級排列的要完成的工做的概要的需求。哪些訂單項會被加入一次衝刺由衝刺計劃會議決定。在會議中，產品負責人告訴開發團隊他須要完成產品訂單中的哪些訂單項。開發團隊決定在下一次衝刺中他們可以承諾完成多少訂單項。在衝刺的過程當中，沒有人可以變動衝刺訂單（sprint backlog），這意味着在一個衝刺中需求是被凍結的。

管理Scrum過程有不少實施方法，從白板上的即時貼到軟件包。Scrum最大的好處是它很是容易學習，並且應用Scrum不須要太多的投入。

精益軟件開發

精益開發是從豐田的生產以及開發方式發展出來的一種過程管理方法，從90年代開始被很普遍的研究，其目標是瞭解客戶的價值觀，而後充分利用聰明的、具備創造力的員工的時間和精力，以較少的努力提供更多的價值，即儘可能避免複雜的東西。

精益軟件開發有七個原則：

消滅浪費（Eliminate Waste）：軟件開發中最大的浪費就是多餘的功能，該原則是Lean最基本的一個原則。
品質爲先（Build Quality In）：從一開始就注重品質，而不是最後依靠測試。測試驅動開發（TDD）就是一個很好的實踐。
建立知識（Create Knowledge）：軟件開發是個建立知識的過程，應該有一個鼓勵你們系統學習的開發流程，並且不斷的改進這個流程。
推遲決定（Defer Commitment）：軟件開發一般具備必定的不肯定性，基於多種選擇的方法可以達成更好的結果，儘量的延遲決定，直到可以基於事實而不是不肯定的假定和預測來作出決定。
快速交付（Deliver Fast）：儘快的交付軟件能使客戶滿意，還能夠削除大量的浪費。
尊重員工（Respect People）：軟件開發以人爲本，人是軟件開發團隊中最重要的資源。
全局優化（Optimize the Whole）：一個Lean的團隊應該優化整個價值流（value stream）。

從這些原則看出，精益開發和敏捷開發在不少方面都是相通的，它是軟件開發的一種指導思想。咱們不能期待精益開發能夠解決全部的問題。「精益軟件雖然能夠很好地管理複雜性，可是不能徹底消除複雜性。它只是引領開發人員，而咱們也須要證實它是一個可行的辦法。」

動態系統開發

動態系統開發方法（DSDM）是衆多敏捷開發方法中的一種，它倡導以業務爲核心，快速而有效地進行系統開發。實踐證實DSDM是成功的敏捷開發方法之一。在英國，因爲其在各類規模的軟件組織中的成功，它已成爲應用最爲普遍的快速應用開發方法。本書主要講述這樣幾方面內容：DSDM如何加快產品的交付，爲何像DSDM這樣的敏捷開發方法可以快速體現所開發系統給業務帶來的好處，如何組織用戶參與項目以開發出可用的系統，如何將不一樣知識背景的人組成一個團隊，如何應對常規的業務約束以進行項目管理。

　　DSDM的基本原則 DSDM方法創建在9條原則之上，並且在實施過程當中，這9條缺一不可。

　　原則1：用戶必須持續參與

　　DSDM過程當中，用戶持續參與的概念是：在整個DSDM生命週期中，有一些專業用戶會一直對開發組提供支持和參與。可以隨時解決開發組對業務流程的各類問題，使工做進展順暢，同時用戶也會對原型進行驗收，提出各類建議和想法。

　　原則2：必須授予DSDM團隊制定決策的權利

　　DSDM鼓勵管理層將權利下放，團隊成員都應該獲得受權。爲了使項目快速進行，團隊成員必須可以對他們的工做迅速作出決定，以保證項目可以如期交付。當出現問題時團隊成員應該能作出決定，以下是一些常見的決定：

　　需求的實際含義。

　　從功能、可用性考慮開發中產生的中間產品是否可接受。

　　工做進程中需求的優先級制定。

　　修改技術細節。

　　儘管DSDM不鼓勵團隊在出現問題時，逐層向上級反饋，可是也提供了這種問題的處理途徑。

　　能夠看出，同爲敏捷方法，DSDM方法與SCRUM方法的項目管理思路，特別是對團隊受權和對項目過程問題的處理機制仍是存在很大差異的，SCRUM方法強調團隊成員反饋問題，而且對於開發組不能解決的問題，必須逐層反饋，獲取高層的指導，而且支持高層領導參與項目的SCRUM Meeting，強調迅速向上級反饋，上級迅速作出決定。而DSDM方法中，團隊成員已經被受權直接作出決定了。

　　原則3：注重產品的常常交付

　　常常交付產品，可以讓外部人員檢查團隊內部所作出的決定是否能夠接受。這樣，項目就可以獲得控制。這裏說的產品是不只僅是軟件，還包括數據模型。產品的常常交付可以反映項目當前的進度，也可以衡量項目是否沿着正確的方向在進行。

　　原則4：知足業務用戶用途是接受交付品的主要依據

　　開發人員沒必要沉溺於完美的解決方案之中，耽誤項目時間。在受限的時間內，實現業務利益最大化的交付品纔是最重要的。

　　原則5：迭代和增量式開發對獲得正確的業務解決方案是必不可少的

　　採用迭代開發的方法，可以使業務流程逐步進化，使系統不斷朝着知足業務需求的方向前進。

　　原則6：開發過程的全部變化可逆

　　採用迭代和增量式開發過程當中，極可能會碰到走錯的狀況，此時須要回退到一個已知的可靠的點上。

　　原則7：在高層次上制定需求的基線

　　在業務研究中所得出的需求必須在高層次上達成一致。接下來在迭代過程當中再獲得詳細的需求。

　　原則8：測試自始至終貫穿於開發週期之中

　　開發人員完成一個模塊的開發後，本身會進行單元測試。當模塊集成到現有系統後，測試人員須要執行集成測試。另外，迴歸測試在DSDM中佔有很重要的地位。

　　原則9：全部項目涉衆間的通力合做是不可獲缺的

　　什麼時候使用DSDM？

　　對於具備如下特性的應用，DSDM特別適合：

　　一、交互式、功能經過用戶界面體現。

　　二、有清晰的用戶羣。

　　三、沒有複雜計算。

　　四、若是是大型應用，能夠分解成小的功能部件。

　　五、有時間限制。

　　六、需求不清楚或不肯定

特性驅動開發

FDD是一個模型驅動( model-driven)、短時間遍歷(short-iteration)的過程. 注意，FDD是一個開發過程，過程老是有起點和終點，FDD的起點是起源於建立一個全局的模型輪廓（不要求很精確，大概模樣就能夠），而後大概是兩週的一系列的"design by feature, build by feature"的迭代，逐漸豐富模型功能內容，features是指小的、以軟件用戶的視角看是有用的特徵功能，一個FDD開發過程.

1. 開發一個全局的模型

　　在一個有經驗的組件/對象建模專家（首席架構師）指導下，業務領域需求人員與開發人員一塊兒協調工做，業務領域人員提供一個初始的、具備必定高度的、能夠覆蓋整個系統和業務場景的介紹，領域人員和開發人員會依此產生初始的模型，而後再結成單獨小組，進入詳細繼續討論階段，將模型輪廓描繪出來，而後豐富以前產生的初始模型。

2. 創建特徵列表（Feature List）

　　當初始模型產生之後，有一個單獨小組成員將開始構建複雜的特徵(feature)功能列表.

3. 依據特徵規劃(Plan By Feature)

　　下一步工做就是將主要的特徵功能集合進行排序和計劃，而後分配給主要程序員組長，這時，程序員也會跟着他們在全局對象模型中所負責的類進入相應的程序員小組。例如張三開始是參與Message這個Model構建和規劃，那麼與Message這個對象模型相關的特徵功能列表被分類出來並分配到特定程序員小組時，張三也就是跟着進入這個程序員小組。

4.依據特徵設計/依據特徵構建(Design By Feature / Build By Feature)

　　當每一個程序員小組領到本身的特徵功能集合後，召集4-5個程序員開會，組長挑選一小組適合2周內完成的特徵功能集合，而後執行 'Design By Feature (DBF)' 和 'Build By Feature (BBF)'. 組長將相應的一些類和特徵功能分配給小組Team，特徵Team進行詳細的順序圖設計，而後寫出類和方法邏輯。

　　下面是進入依據特徵構建階段，也就是代碼的編譯調試測試階段，在進入BBF階段以前，Team小組要進行設計代碼複覈，在進入後，類的做者進行類的整合、測試和複覈，一旦程序員組長滿意，完整的特徵功能實現將被提交到主要的Build過程，也就是進入集成測試階段。

　　每一個程序員組長能夠並行負責帶領2-3特徵小組Team運轉，特徵小組中任何人任什麼時候候均可以成爲類的做者（編寫類的具體實現代碼）。

水晶開發

水晶方法，Crystal ，是由 Alistair Cockburn 和 Jim Highsmith 創建的敏捷方法系列，其目的是發展一種提倡「機動性的」[1]方法，包含具備共性的核心元素，每一個都含有獨特的角色、過程模式、工做產品和實踐。Crystal 家族其實是一組通過證實、對不一樣類型項目很是有效的敏捷過程，它的發明使得敏捷團隊能夠根據其項目和環境選擇最合適的 Crystal 家族成員。

透明水晶方法的七大致系特徵：

體系特徵一：常常交付

體系特徵二：反思改進

體系特徵三：滲透式交流

體系特徵四：我的安全

體系特徵五：焦點

體系特徵六：與專家用戶創建方便的聯繫

體系特徵七：配有自動測試、配置管理和常常集成功能的技術環境

一、敏捷小組做爲一個總體工做

　　項目取得成功的關鍵在於，全部項目參與者都把本身當作朝向一個共同目標前進的團隊的一員。「扔過去無論」的心理不是屬於敏捷開發。設計師和架構師不會把程序設計「扔」給編碼人員；編碼人員也不會把只通過部分測試的代碼「扔」給測試人員，一個成功的敏捷開發小組應該具備「咱們一塊兒參與其中的思想」，「幫助他人完成目標」這個理念是敏捷開發的根本管理文化。固然，儘管強調一個總體，小組中應該有必定的角色分配，各類敏捷開發方法角色的起名方案可能不一樣，希望則基本上是同樣的。第一個角色是產品全部者，他的主要職責包括：確認小組成員都在追求一個共同的目標前景；肯定功能的優先等級，以便老是處理最有價值的功能；做出可使項目的投入產生良好回報的決定。產品全部者一般是公司的市場部門或者產品管理部門的人員，在開發內部使用的軟件的時候，產品全部者多是用戶、用戶的上級、分析師，也多是爲項目提供資金的人。

二、敏捷小組按短迭代週期工做

在敏捷項目中，整體上並無什麼上游階段、下游階段，你能夠根據須要定義開發過程在初始階段能夠有一個簡短的分析、建模、設計，但只要項目真正開始，每次迭代都會作一樣的工做（分析、設計、編碼、測試。等等）。迭代是受時間框限制的，也就是說即便放棄一些功能，也必須結束迭代。時間框通常很短，大部分是 2～4周，在 Scrum中採用的是 30個日曆天，也就是 4 周。迭代的時間長度通常是固定的，但也有報告說，有的小組在迭代開始的時候選擇合適的時間長度。

三、敏捷小組每次迭代交付一些成果

　　比選擇特定迭代長度更重要的，是開發小組在一次迭代中要把一個以上的不太精確的需求聲明，通過分析、設計、編碼、測試，變成可交付的軟件（稱之爲功能增量）。固然並不須要把每次迭代的結果交付給用戶，但目標是能夠交付，這就意味着每次迭代都會增長一些小功能，但增長的每一個功能都要達到發佈質量。每次迭代結束的時候讓產品達到可交付狀態十分重要，但這並不意味着要完成發佈的所有工做，由於迭代的結果並非真正發佈產品。假定一個小組須要在發佈產品以前對軟硬件進行爲期兩個月的「平均無端障時間」（MTBF）測試，他們不可能縮短這兩個月的時間，但這個小組仍然是按照 4 周迭代，除了MTBF測試，其它都達到了發佈狀態。

四、敏捷小組關注業務優先級

　　敏捷開發小組從兩個方面顯示出他們對業務優先級的關注。首先，他們按照產品全部者制定的順序交付功能，而產品全部者通常會按照組織在項目上的投資回報最大化的方式來肯定優先級，而且把它組織到產品發佈中去。要達到這個目的，須要綜合考慮開發小組的能力，以及所需功能的優先級來創建發佈計劃。在編寫功能的時候，須要使工能的依賴性最小化。若是開發一個功能必須依賴其它 3 個功能，那產品全部者這就很難肯定功能優先級。功能徹底沒有依賴是不太可能的，但把功能依賴性控制在最低程度仍是至關可行的。

五、敏捷小組檢查與調整

　　任何項目開始的時候所創建的計劃，僅僅是一個當前的猜想。有不少事情可讓這樣的計劃失效：項目成員的增減，某種技術比預期的更好或更差，用戶改變了想法，競爭者迫使咱們作出不一樣的反應，等等。對此，敏捷小組不是懼怕這種變化，而是把這種變化當作使最終軟件更好地反映實際須要的一個機會。每次新迭代開始，敏捷小組都會結合上一次迭代中得到新知識作出相應調整。若是認爲一些因素可能會影響計劃的準確性，也可能更改計劃。好比發現某項工做比預計的更耗費時間，可能就會調整進展速度。也許，用戶看到交付的產品後改變了想法，這就產生反饋，好比他發現他更但願有另外一項功能，或者某個功能並不像先前看得那麼重。經過先期發佈增長更多的用戶但願的功能，或者減小某些低價值功能，就能夠增長產品的價值。迭代開發是在變與不變中尋求平衡，在迭代開始的時候尋求變，而在迭代開發期間不能改變，以期集中精力完成已經肯定的工做。因爲一次迭代的時間並不長，因此就使穩定性和易變性獲得很好的平衡。在兩次迭代期間改變優先級甚至功能自己，對於項目投資最大化是有益處的。從這個觀點來看，迭代週期的長度選擇就比較重要了，由於兩次迭代之間是提供變動的機會，週期太長，變動機會就可能失去；週期過短，會發生頻繁變動，並且分析、設計、編碼、測試這些工做都不容易作到位。綜合考慮，對於一個複雜項目，迭代週期選擇4周仍是有道理的。

　　MIT Sloan Management Review（麻省理工學院項目管理評論）所刊載的一篇爲時兩年對成功軟件項目的研究報告，報告指出了軟件項目得到成功的共同因素，排在首位的是迭代開發，而不是瀑布過程。其它的因素是：

　　一、至少天天把新代碼合併到整個系統，而且經過測試，對設計變動作出快速反應。

　　二、開發團隊具有運做多個產品的工做經驗。

　　三、很早就致力於構建和提供內聚的架構。

宣言原則

最重要的是經過儘早和不斷交付有價值的軟件知足客戶須要。

咱們歡迎需求的變化，即便在開發後期。敏捷過程可以駕馭變化，保持客戶的競爭優點。

常常交付能夠工做的軟件，從幾星期到幾個月，時間尺度越短越好。

業務人員和開發者應該在整個項目過程當中始終朝夕在一塊兒工做。

圍繞鬥志高昂的人進行軟件開發，給開發者提供適宜的環境，知足他們的須要，並相信他們可以完成任務。

在開發小組中最有效率也最有效果的信息傳達方式是面對面的交談。

能夠工做的軟件是進度的主要度量標準。