識別和描述什麼是敏捷開發方法

㈠ 軟體開發是什麼，發展如何

1. 邊做邊改模型（Build-and-Fix Model）

好吧，其實現在許多產品實際都是使用的「邊做邊改」模型來開發的，特別是很多小公司產品周期壓縮的太短。在這種模型中，既沒有規格說明，也沒有經過設計，軟體隨著客戶的需要一次又一次地不斷被修改。

在這個模型中，開發人員拿到項目立即根據需求編寫程序，調試通過後生成軟體的第一個版本。在提供給用戶使用後，如果程序出現錯誤，或者用戶提出新的要求，開發人員重新修改代碼，直到用戶和測試等等滿意為止。

這是一種類似作坊的開發方式，邊做邊改模型的優點毫無疑問就是前期出成效快。

對編寫邏輯不需要太嚴謹的小程序來說還可以對付得過去，但這種方法對任何規模的開發來說都是不能令人滿意的，其主要問題在於：

1） 缺少規劃和設計環節，軟體的結構隨著不斷的修改越來越糟，導致無法繼續修改；

2） 忽略需求環節，給軟體開發帶來很大的風險；

3） 沒有考慮測試和程序的可維護性，也沒有任何文檔，軟體的維護十分困難。

 

2. 瀑布模型（Waterfall Model）

瀑布模型是一種比較老舊的軟體開發模型，1970年溫斯頓·羅伊斯提出了著名的「瀑布模型」，直到80年代都還是一直被廣泛採用的模型。

瀑布模型將軟體生命周期劃分為制定計劃、需求分析、軟體設計、程序編寫、軟體測試和運行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

在瀑布模型中，軟體開發的各項活動嚴格按照線性方式進行，當前活動接受上一項活動的工作結果，實施完成所需的工作內容。當前活動的工作結果需要進行驗證，如驗證通過，則該結果作為下一項活動的輸入，繼續進行下一項活動，否則返回修改。

瀑布模型優點是嚴格遵循預先計劃的步驟順序進行，一切按部就班比較嚴謹。

瀑布模型強調文檔的作用，並要求每個階段都要仔細驗證。但是，這種模型的線性過程太理想化，已不再適合現代的軟體開發模式，幾乎被業界拋棄，其主要問題在於：

1） 各個階段的劃分完全固定，階段之間產生大量的文檔，極大地增加了工作量；

2） 由於開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增加了開發的風險；

3） 早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果。

4） 各個軟體生命周期銜接花費時間較長，團隊人員交流成本大。

5） 瀑布式方法在需求不明並且在項目進行過程中可能變化的情況下基本是不可行的。

 

3. 迭代模型（stagewise model）（也被稱作迭代增量式開發或迭代進化式開發）

，是一種與傳統的瀑布式開發相反的軟體開發過程，它彌補了傳統開發方式中的一些弱點，具有更高的成功率和生產率。

在迭代式開發方法中，整個開發工作被組織為一系列的短小的、固定長度（如3周）的小項目，被稱為一系列的迭代。每一次迭代都包括了需求分析、設計、實現與測試。採用這種方法，開發工作可以在需求被完整地確定之前啟動，並在一次迭代中完成系統的一部分功能或業務邏輯的開發工作。再通過客戶的反饋來細化需求，並開始新一輪的迭代。

教學中，對迭代和版本的區別，可理解如下： 迭代一般指某版本的生產過程，包括從需求分析到測試完成； 版本一般指某階段軟體開發的結果，一個可交付使用的產品。

與傳統的瀑布模型相比較，迭代過程具有以下優點：

1）降低了在一個增量上的開支風險。如果開發人員重復某個迭代，那麼損失只是這一個開發有誤的迭代的花費。

2）降低了產品無法按照既定進度進入市場的風險。通過在開發早期就確定風險，可以盡早來解決而不至於在開發後期匆匆忙忙。

3）加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率。

4）由於用戶的需求並不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。因此復用性更高

 

4. 快速原型模型（Rapid Prototype Model）

快速原型模型的第一步是建造一個快速原型，實現客戶或未來的用戶與系統的交互，用戶或客戶對原型進行評價，進一步細化待開發軟體的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什麼；第二步則在第一步的基礎上開發客戶滿意的軟體產品。

顯然，快速原型方法可以克服瀑布模型的缺點，減少由於軟體需求不明確帶來的開發風險，具有顯著的效果。

快速原型的關鍵在於盡可能快速地建造出軟體原型，一旦確定了客戶的真正需求，所建造的原型將被丟棄。因此，原型系統的內部結構並不重要，重要的是必須迅速建立原型，隨之迅速修改原型，以反映客戶的需求。

快速原型模型有點整合「邊做邊改」與「瀑布模型」優點的意味。

 

5、增量模型（Incremental Model）

與建造大廈相同，軟體也是一步一步建造起來的。在增量模型中，軟體被作為一系列的增量構件來設計、實現、集成和測試，每一個構件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構成。

增量模型在各個階段並不交付一個可運行的完整產品，而是交付滿足客戶需求的一個子集的可運行產品。整個產品被分解成若干個構件，開發人員逐個構件地交付產品，這樣做的好處是軟體開發可以較好地適應變化，客戶可以不斷地看到所開發的軟體，從而降低開發風險。但是，增量模型也存在以下缺陷：

1） 由於各個構件是逐漸並入已有的軟體體系結構中的，所以加入構件必須不破壞已構造好的系統部分，這需要軟體具備開放式的體系結構。

2） 在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優於瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟體過程的控制失去整體性。

在使用增量模型時，第一個增量往往是實現基本需求的核心產品。核心產品交付用戶使用後，經過評價形成下一個增量的開發計劃，它包括對核心產品的修改和一些新功能的發布。這個過程在每個增量發布後不斷重復，直到產生最終的完善產品。

例如，使用增量模型開發字處理軟體。可以考慮，第一個增量發布基本的文件管理、編輯和文檔生成功能，第二個增量發布更加完善的編輯和文檔生成功能，第三個增量實現拼寫和文法檢查功能，第四個增量完成高級的頁面布局功能。

 

6. 螺旋模型（Spiral Model）

1988年，巴利·玻姆(Barry Boehm)正式發表了軟體系統開發的「螺旋模型」，它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合於大型復雜的系統。

螺旋模型沿著螺線進行若干次迭代，圖中的四個象限代表了以下活動：

1） 制定計劃：確定軟體目標，選定實施方案，弄清項目開發的限制條件；

2） 風險分析：分析評估所選方案，考慮如何識別和消除風險；

3） 實施工程：實施軟體開發和驗證；

4） 客戶評估：評價開發工作，提出修正建議，制定下一步計劃。

螺旋模型由風險驅動，強調可選方案和約束條件從而支持軟體的重用，有助於將軟體質量作為特殊目標融入產品開發之中。但是，螺旋模型也有一定的限制條件，具體如下：

1） 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並做出相關反應是不容易的，因此，這種模型往往適應於內部的大規模軟體開發。

2） 如果執行風險分析將大大影響項目的利潤，那麼進行風險分析毫無意義，因此，螺旋模型只適合於大規模軟體項目。

3） 軟體開發人員應該擅長尋找可能的風險，准確地分析風險，否則將會帶來更大的風險

一個階段首先是確定該階段的目標，完成這些目標的選擇方案及其約束條件，然後從風險角度分析方案的開發策略，努力排除各種潛在的風險，有時需要通過建造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟。最後，評價該階段的結果，並設計下一個階段。

 

7. 敏捷軟體開發 (Agile development)

敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟體項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特徵。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，並分別完成，在此過程中軟體一直處於可使用狀態。

敏捷開發小組主要的工作方式可以歸納為：作為一個整體工作； 按短迭代周期工作； 每次迭代交付一些成果，關注業務優先順序，檢查與調整。

敏捷軟體開發要注意項目規模，規模增長，團隊交流成本就上去了，因此敏捷軟體開發暫時適合不是特別大的團隊開發，比較適合一個組的團隊使用。

 

8. 演化模型（evolutionary model）

主要針對事先不能完整定義需求的軟體開發。用戶可以給出待開發系統的核心需求，並且當看到核心需求實現後，能夠有效地提出反饋，以支持系統的最終設計和實現。軟體開發人員根據用戶的需求，首先開發核心系統。當該核心系統投入運行後，用戶試用之，完成他們的工作，並提出精化系統、增強系統能力的需求。軟體開發人員根據用戶的反饋，實施開發的迭代過程。第一迭代過程均由需求、設計、編碼、測試、集成等階段組成，為整個系統增加一個可定義的、可管理的子集。

在開發模式上採取分批循環開發的辦法，每循環開發一部分的功能，它們成為這個產品的原型的新增功能。於是，設計就不斷地演化出新的系統。 實際上，這個模型可看作是重復執行的多個「瀑布模型」。

「演化模型」要求開發人員有能力把項目的產品需求分解為不同組，以便分批循環開發。這種分組並不是絕對隨意性的，而是要根據功能的重要性及對總體設計的基礎結構的影響而作出判斷。有經驗指出，每個開發循環以六周到八周為適當的長度。

 

9. 噴泉模型（fountain model, (面向對象的生存期模型, 面向對象（Object Oriented,OO）模型））

噴泉模型與傳統的結構化生存期比較，具有更多的增量和迭代性質，生存期的各個階段可以相互重疊和多次反復，而且在項目的整個生存期中還可以嵌入子生存期。就像水噴上去又可以落下來，可以落在中間，也可以落在最底部。

 

10. 智能模型（四代技術（4GL）)

智能模型擁有一組工具（如數據查詢、報表生成、數據處理、屏幕定義、代碼生成、高層圖形功能及電子表格等），每個工具都能使開發人員在高層次上定義軟體的某些特性，並把開發人員定義的這些軟體自動地生成為源代碼。這種方法需要四代語言（4GL）的支持。4GL不同於三代語言，其主要特徵是用戶界面極端友好，即使沒有受過訓練的非專業程序員，也能用它編寫程序；它是一種聲明式、互動式和非過程性編程語言。4GL還具有高效的程序代碼、智能預設假設、完備的資料庫和應用程序生成器。目前市場上流行的4GL（如Foxpro等）都不同程度地具有上述特徵。但4GL目前主要限於事務信息系統的中、小型應用程序的開發。

 

11. 混合模型（hybrid model）

過程開發模型又叫混合模型（hybrid model），或元模型（meta-model）,把幾種不同模型組合成一種混合模型，它允許一個項目能沿著最有效的路徑發展，這就是過程開發模型（或混合模型）。實際上，一些軟體開發單位都是使用幾種不同的開發方法組成他們自己的混合模型。

 

點贊
2

評論
3

分享

收藏
12

手機看

關注
一鍵三連
原來思維導圖有那麼多種用法？
09-28
MindMaster思維導圖可以用於制定學習筆記、會議紀要、頭腦風暴、知識管理、項目規劃、高效演示、分析決策等。
什麼是軟體開發模式
dengyaozhong8958的博客
73
什麼是軟體開發模式呢？我想，於我們學生而言，更加要注重的是我們的個人能力和團隊協作的方面；在這兩個方面，我們必須注意，在一個Team中，首先自己需要有足夠的能力和技術去完成團隊分配下來的任務，其次就是一個團隊在做項目的同時，需要注意與他人的配合。以上即我所認知的軟體開發模式（學生時期）。 轉載於:https://www.cnblogs.com/Ricardo-M-Lu/p/653276...

周小小的慧:默默的問一句，微信小程序開發的微樂鬥地主真的有外掛和輔助存在嗎？我一個同事在小程序上輸到崩潰，去網站買外掛加微信又被騙子騙錢騙到懷疑人生5月前回復

Vanda1812回復:???23天前回復

周小小的慧:默默的問一句，微信小程序開發的微樂鬥地主真的有外掛和輔助存在嗎？我一個同事在小程序上輸到崩潰，去網站買外掛加微信又被騙子騙錢騙到懷疑人生。替他感到無知和生無可戀5月前回復

項目開發流程及開發模式
王晨光的博客
5252
項目開發階段 整體階段：需求分析、設計、編碼、測試、維護。 需求階段：通常定義系統的需求，明白系統的目標。 設計階段：通常確定系統使用什麼資料庫，系統模塊的劃分，各個模塊的功能。 編碼階段：用編程語言對設計階段的實現。 測試階段：分黑盒測試，白盒測試。測試系統的功能是否實現，是否准確。 維護階段：是根據用戶新的需要重新修改系統，使系統更加穩定，更符合用戶的要求。 需求階段：其工作是否到位是整個系...
軟體開發模式之敏捷開發（scrum）
android_Mr_夏
5萬+
簡介 這幾年關於敏捷開發在互聯網企業中越來越廣泛被使用到，運用的比較多的當屬scrum敏捷開發和xp敏捷開發，人人都在談論敏捷開發。那什麼才是敏捷開發呢？ 目錄 什麼是敏捷開發？ 傳統的開發模式和敏捷開發模式的對比？ 敏捷開發scrum的實施。 什麼是敏捷開發 敏捷開發以用戶的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。 在敏捷開發中，軟體項目在構建初期被...
什麼是軟體開發模式_qq_22343633的博客-CSDN博客
9-5
軟體開發模式這個詞在學校的時候就接觸,出名的瀑布模式、螺旋模式都清楚是怎麼回事,但是卻在網路上找不到其定義。今天我斗膽給個基礎定義,拋磚引玉。軟體開發模式,...
什麼是軟體開發模式 - weixin_34358365的博客 - CSDN博客
7-7
什麼是軟體開發模式呢?我想,於我們學生而言,更加要注重的是我們的個人能力和團隊協作的方面;在這兩個方面,我們必須注意,在一個Team中,首先自己需要有足夠的能力和...
軟體開發流程與模式
oscar999的專欄
1萬+
軟體開發角色與流程軟體生命周期： 制定計劃，需求分析，設計，編碼實現，測試，運行維護模型與演進主要模型介紹1. 邊做邊改模型（Build-and-Fix Model）其實現在許多產品實際都是使用的「邊做邊改」模型來開發的，特別是很多小公司產品周期壓縮的太短。在這種模型中，既沒有規格說明，也沒有經過設計，軟體隨著客戶的需要一次又一次地不斷被修改。在這個模型中，開發人員拿到項目立即根據需求編寫
軟體常用開發模式介紹
03-29
軟體開發模型(Software Development Model)是指軟體開發全部過程、活動和任務的結構框架。軟體開發包括需求、設計、編碼和測試等階段，有時也包括維護階段。具體介紹軟體中常用的開發模
軟體開發模式圖文詳解-講義文檔類資源
9-29
軟體開發模式 1391. 邊做邊改模型(Build-and-Fix Model) 好吧,其實現在許多產品實際都是使用的「邊做邊改」模型來開發的,特別是很多小公司產品周期壓縮的太短。
軟體的幾種開發模式_m15712884682的博客-CSDN博客
9-28
瀑布模型強調文檔的作用,並要求每個階段都要仔細驗證。但是,這種模型的線性過程太理想化,已不再適合現代的軟體開發模式,幾乎被業界拋棄,其主要問題在於: ...
國家標准軟體開發文檔模板
12-02
國家標准軟體開發文檔模板，包括：操作手冊（GB8567——88）、測試分析報告（GB8567——88）、測試計劃（GB8567——88）、概要設計說明書（GB8567——88）、開發進度月報（GB85
軟體開發計劃書（是 一個完整的項目開發文檔）
01-09
軟體開發計劃書 ..............1.任務申請.doc ..............2.可行性與計劃階段--可行性研究報告.doc ..............2.可行性與計劃階段--項目開
開發軟體的三種模式,你了解多少?看看哪種適合你_qq_384..._CSDN博客
9-18
問:怎麼區分軟體的定製開發、平台開發、SAAS三種不同開發模式?答:這是三種不同的開發模式,各有優點,和各有缺點,成本也大不相同,沒有絕對優劣,關鍵是看那種模式...
軟體開發模式_qq_43614606的博客-CSDN博客
9-25
軟體開發模式對比(瀑布、迭代、螺旋、敏捷)瀑布模型是由W.W.Royce在1970年最初提出的軟體開發模型, 瀑布式開發是一種老舊的計算機軟體開發方法。通過概念、啟動、...
2020數學建模A題
09-11
2020數學建模國賽A題及其數據 2020數學建模國賽A題及其數據2020數學建模國賽A題及其數據 2020數學建模國賽A題及其數據 2020數學建模國賽A題及其數據 2020數學建模國賽A題及其數據
靈敏度分析使用MATLAB編寫完成
05-29
靈敏度分析matlab代碼編寫，運籌學中的靈敏度分析的求解均可用此方法
app四種開發模式的優缺點
jia12216的專欄
6921
app的四種開發模式： 1.原生App開發（Native App， 本地應用程序）； 2.網頁應用程序（Web App，移動web）。 3.採用Hybrid混合框架開發（Hybrid App，混合應用程序）； 4.採用ReactNative和WEEX等混合框架開發（混合App）；

㈡ 敏捷開發的名詞詳解

AM是一種態度，而不是一個說明性的過程。AM是敏捷建模者們堅持的價值觀、敏捷建模者們相信的原則、敏捷建模者們應用的實踐組成的集合。AM描述了一種建模的風格。當它應用於敏捷的環境中時，能夠提高開發的質量和速度，同時能夠避免過度簡化和不切實際的期望。AM可不是開發的「食譜」，如果你尋覓的是一些細節的指導，如建立UML順序圖或是畫出用戶界面流圖，你可以看看在建模Artifacts中列出的許多建模書籍，我特別推薦我的書The Object Primer 2/e(盡管這有失公允）。
AM是對已有方法的補充，而不是一個完整的方法論。AM的主要焦點是在建模上，其次是文檔。也就是說，AM技術在你的團隊採用敏捷方法（例如eXtreme Programming，Dynamic Systems Development Method （DSDM），Crystal Clear）的基礎上能夠提高建模的效果。AM同樣也可以用於那些傳統過程（例如Unified Process），盡管這種過程較低的敏捷性會使得AM不會那麼成功。
AM是一種有效的共同工作的方法，能夠滿足Project Stakeholder的需要。敏捷開發者們和Project Stakeholder進行團隊協作，他們輪流在系統開發中扮演著直接、主動的角色。在「敏捷」的字典中沒有「我」這個單詞。
AM是有效的，而且也已開始有效。當你學習到更多的AM知識時，有件事對你來說可能不好接受，AM近乎無情的注重有效性。AM告訴你：要使你的 Project Stakeholder的投資最大化；當有清晰的目的以及需要解了受眾的需要時要建立模型或文檔；運用合適的工件來記錄手頭的情形；不論何時都盡可能創建簡單的模型。
AM不是靈丹妙葯。敏捷建模是改進眾多專家軟體開發成果的有效技術，充其量也就是這樣了。它並不是什麼了不得的靈丹妙葯，能夠解決你開發中的所有問題。如果你努力的工作；如果你專注其上；如果打心眼兒里接受它的價值觀、它的原則、它的實踐；你就可以改進你做為一個開發人員的效果。
AM是面向一般的開發人員的，但並不是要排斥有能力的人。AM的價值觀、原則和實踐都簡單易懂，其中的很多內容，可能你都已經採用或期待多年了。應用AM技術並不是要你去練水上飄，但你需要有一些基本的軟體開發技能。AM最難的就是它逼著你去學習更廣泛的建模技術，這是個長期的、持續性的活動。學習建模在一開始可能很難，但你可以試著一次學習一樣技術來完成你的學習。
AM並不是要反對文檔。文檔的創建和維護都會增大項目涉眾的投資。敏捷文檔盡可能的簡單，盡可能的小，目的只集中在和開發的系統有直接關系的事情上，充分了解受眾的需要。
AM也不是要反對CASE工具。敏捷建模者使用那些能夠幫助開發人員提高效果，提升價值的工具。而且，他們還盡力使用那些能夠勝任工作的最簡單的工具。
何時是敏捷的？
要想了解AM，你需要了解模型和敏捷模型之間的區別。模型是一個抽象的概念，它描述了一個的問題的一個或多個方面，或是處理這個問題可能的解決方案。傳統意義上，模型被認為是圖表加上相應的文檔。然而那不夠直觀的artifact，也可以被視為模型，例如CRC卡片集，單條或多條業務規則的文字描述，或是業務流程的一段結構化英文描述。一個敏捷模型就是一個剛剛足夠好的模型。但是你怎麼知道什麼時候模型才是剛剛足夠好呢？當敏捷模型顯現出如下的特性時，它就是剛剛足夠好的：
敏捷模型實現了它們的目的。有時你為溝通而建模，或許你需要把你工作的范圍告訴高級經理；有時你為理解而建模，或許你需要確定一個設計策略，實現一組Java類。一個敏捷模型是否足夠好，要看它是不是滿足了創建它時的初衷。
敏捷模型是可理解的。敏捷模型要能為其預期聽眾所理解。使用用戶能夠理解的業務語言來描述需求模型，反之，技術架構模型則需要使用開發人員熟悉的技術術語。你所使用的建模符號會影響易懂性－－如果你的用戶不了解UML用例圖中的符號的含義，那用例圖對用戶就沒有任何價值。這樣的話，要麼使用另一種方法，要麼教授用戶學習建模技術。風格問題同樣也會影響易懂性，例如避免交叉線。雜亂的圖表比清晰的圖表難懂。模型的細節程度（見下文），也會影響易懂性，因為相較一個不那麼詳細的模型來說，一個過於詳細的模型要難於理解。簡單（見下文）同樣是影響易懂性的一個因素。
敏捷開發
敏捷模型是足夠正確的。模型通常都不需要100%正確，只要足夠正確就行了。舉個例子，如果一張街道地圖漏畫了一條街道，或是它標示某條街道是通行的，但你發現它已經關閉維修了，那你會不會扔掉你的地圖開始在城裡飆車犯罪呢？不太可能。你會考慮更新你的地圖，你可能會拿出筆來自己做修改或是去當地的商店買一張最新版的地圖（你原來的那張過期了）。也許你還是會接受那張雖不完美仍可使用的地圖，因為它對你來說已經足夠好了。你還是可以用這張地圖四處轉轉，因為它還是個正確的模型，標記出了大部分街道的位置。你在發現這張地圖不正確的時候，你沒有立刻扔掉它，原因是你根本不在乎它是否完美。類似的，當你在需求模型、數據模型中發現錯誤的時候，你也會選擇更新或是接受－－雖不完美但已經足夠好了。有些項目成員能夠容忍這種不正確而有些則不能：這取決於項目的特性，每個團隊成員的特性，組織的特性。充分正確性既和模型的聽眾有關，也和你要處理的問題有關。
敏捷模型是足夠一致的。一個敏捷模型並不需要和自己（或其它有用的artifact）保持完全的一致。如果一個用例在它的一個步驟中顯式的調用了另一個用例，那麼相應的用例圖需要用UML的 <> 版型來標記這兩個用例之間的關系。然而，你看了看圖表，發現它們並沒有這樣做，天哪！用例和圖之間不一致！危險！太危險了！紅色警報！快逃命呀！等一下，你的用例模型是有不一致的地方，但也沒到世界末日啊。是的，理想情況下，你的所有artifact最好是能夠完全一致，但這通常是不可能的。當我開發一個簡單的商用系統時，我通常都可以容忍部分的不一致。但有時我是不能容忍這種不一致的。最有力的佐證就是1999年 NASA發射火星太空探測器時採用了精密的測量系統。要樹立一個觀點，敏捷模型只要足夠一致就行了，你通常不需要使用那麼完美的模型。
關於正確性和一致性，很明顯要考慮權衡問題。如果你要維護一個artifact（我們稱之為「保管」），隨著時間的流逝，你需要投入資源來更新它。否則它很會就會過期，對你就沒用了。例如，我可以容忍一張地圖標錯了一兩條街道，但是我絕對無法容忍一張地圖中四分之三的街道都標錯了。這就需要權衡了，進行足夠的努力，保證artifact足夠正確。過多不必要的努力反而會減緩項目的進度，而投入不足就沒有辦法保證artifact的有效性。
敏捷模型有足夠的細節。一張路線圖並不需要標記出每條街道上的每棟房子。那會有太多的細節，使得地圖難以使用。然而，在修路的時候，我想施工人員一定會有這條街道的詳細地圖，包括每幢建築、下水道、電線盒等足夠的細節，這樣的地圖才是有用的。但是這張地圖並不用標記出每個院子和通向它們的路線。因為這樣又太繁瑣了。足夠的細節和聽眾有關，也和他們使用模型的目的有關－－司機需要的是顯示道路的地圖，施工人員需要的是顯示土木工程細節的地圖。
考慮一個架構模型，可能一組畫在白板上的圖表就足夠了－－項目的進行中再對它們更新，也許你需要用CASE 工具來生成一些圖表，也許這些圖表還需要有詳細的文檔，這依賴於環境。不同的項目有不同的需要。在每一個例子中，實際上你都是在開發、維護一個有足夠的細節的架構模型，只是這個「足夠的細節」的概念和環境有關。
敏捷模型能提供正面價值。對項目中的任一artifact，一個基本的要求是它們能夠提供正面價值。一個架構模型給你的項目帶來的價值是不是能夠超過開發它、維護它（可選）的總成本？一個架構模型能夠堅定你們團隊為之努力的願景，所以它當然是有價值的。但是，如果它的成本超過了這個價值，那就是說，它無法提供正面價值。投入100,000美元去開發一個詳細的、重量級的文檔化架構模型，而它的效用，只需一些畫在白板上的圖表就能夠達到，這些圖只需要花你 5,000美元，看看，這是多麼輕率的做法。
敏捷模型要盡可能的簡單。只要能夠達到目的，你應當努力讓你的模型盡可能保持簡單。模型的詳細程度會影響簡單性，而所使用的符號范圍也會影響簡單性。例如，UML的類圖就包括了無數的符號，包括對象約束語言 (Object Constraint Language OCL) ，但大多數的圖使用符號的一部分就能夠完成。所以你常常不需要使用所有的符號，你可以限制自己使用符號的一個子集，當然，這個子集是足夠讓你完成工作的。
因此呢，一個敏捷模型的定義就是一個實現它的目的，沒有畫蛇添足的模型；為你的預期聽眾所理解的模型；簡單的模型；足夠正確、足夠一致、足夠詳細的模型；創建和維護它的投資能夠給項目提供正面價值的模型。
一個普遍的哲學問題是源代碼是不是一個模型，更重要的，它是不是一個敏捷模型。如果你是在我們這篇文章之外問我這個問題，我會回答說，是，源代碼是一個模型，雖然是一個高度細節化的模型，因為它是軟體的一個抽象。同時我還認為，優秀的代碼是一個敏捷模型。但在這里，我還需要把兩者區分開來，源代碼和敏捷模型還是有區別的——敏捷模型幫助你得到源代碼。

㈢ 敏捷方法的敏捷開發

敏捷開發（agile development）是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟體項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特徵。簡言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，並分別完成，在此過程中軟體一直處於可使用狀態。
敏捷開發是全新理論嗎？答案莫衷一是。細心的人們可以發現，敏捷開發其實借鑒了大量軟體工程中的方法。迭代與增量開發，這兩種在任何一本軟體工程教材中都會被提到的方法，在敏捷開發模式中扮演了很重要的角色。再向前追溯，我們還也可見到瀑布式與快速原型法的影子，也許還有更多。
改善，而非創新。敏捷開發可理解為在原有軟體開發方法基礎上的整合——取其精華，去其糟粕。因此敏捷開發繼承了不少原有方法的優勢。「在敏捷軟體開發的過程中，我們每兩周都會得到一個可以工作的軟體，」Fowler介紹，「這種非常短的循環，使終端客戶可以及時、快速地看到他們花錢構建的軟體是一個什麼樣的結果。」
也許是因為時間關系，Fowler只說出了這些優勢中的一部分。允許開發過程中的需求變化、通過早期迭代可以較早發現風險、使代碼重用變得可行、減少項目返工……借鑒了眾多先進方法和豐富經驗，擁有的眾多優勢使得敏捷開發看來已經成為解決軟體危機的標准答案。
問題與思考然而，我們不得不面對的現實卻是，模式與方法的優化並不意味著問題的終結。作為一種開發模式，敏捷開發同樣需要面對眾多挑戰。
大項目的拆分意味著更多子項目的出現，協調這些同步或非同步推進的子項目，合理的資源調配都將變得更加復雜。另外，在當前項目和項目組普遍「增容」的情況下，遇到的問題同樣成倍增長。人的重要性被提到了更高的高度，而缺乏有效協調手段，減少人員流動和項目變更對整個項目造成的影響也將成為一大挑戰……新方法帶來眾多便利的同時，也相應引發了幾乎同樣多的問題。
敏捷開發（agile development）概念從2004年初開始廣為流行。Bailar非常支持這一理論，他採取了敏捷方式組建團隊：Capital One的敏捷團隊包括3名業務人員、兩名操作人員和5～7名IT人員，其中包括1個業務信息指導（實際上是業務部門和IT部門之間的翻譯者）；另外，還有一個由項目經理和至少80名開發人員組成的團隊。這些開發人員都曾被Bailar送去參加過敏捷開發的培訓，具備相關的技能。
每個團隊都有自己的敏捷指導（Bailar聘用了20個敏捷指導），他的工作是關注流程並提供建議和支持。最初提出的需求被歸納成一個目標、一堆記錄詳細需要的卡片及一些供參考的原型和模板。在整個項目階段，團隊人員密切合作，開發有規律地停頓--在9周開發過程中停頓3～4次，以評估過程及決定需求變更是否必要。在Capital One，大的IT項目會被拆分成多個子項目，安排給各敏捷團隊，這種方式在敏捷開發中叫蜂巢式（swarming），所有過程由一名項目經理控制。
為了檢驗這個系統的效果，Bailar將項目拆分，從舊的瀑布式開發轉變為並列式開發，形成了敏捷開發所倡導的精幹而靈活的開發團隊，並將開發階段分成30天一個周期，進行沖刺--每個沖刺始於一個啟動會議，到下個沖刺前結束。
在Bailar將其與傳統的開發方式做了對比後，他感到非常興奮--敏捷開發使開發時間減少了30%～40%，有時甚至接近50%，提高了交付產品的質量。不過，有些需求不能用敏捷開發來處理。 Bailar承認，敏捷開發也有局限性，比如對那些不明確、優先權不清楚的需求或處於較快、較便宜、較優的三角架構中卻不能排列出三者優先順序的需求。此外，他覺得大型項目或有特殊規則的需求的項目，更適宜採用傳統的開發方式。盡管描述需求一直是件困難的事，但經過陣痛之後，需求處理流程會讓CIO受益匪淺。
敏捷開發是由一些業界專家針對一些企業現狀提出了一些讓軟體開發團隊具有快速工作、響應變化能力的價值觀和原則，並於2001初成立了敏捷聯盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟體開發方法。通過這項工作，他們認為： 個體和交互 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文檔 客戶合作 勝過 合同談判 響應變化 勝過 遵循計劃 並提出了以下遵循的原則： 我們最優先要做的是通過盡早的、持續的交付有價值的軟體來使客戶滿意。 即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。 經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。 在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。 圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，並且信任他們能夠完成工作。 在團隊內部，最具有效果並富有效率的傳遞信息的方法，就是面對面的交談。 工作的軟體是首要的進度度量標准。 敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恆定的開發速度。 不斷地關注優秀的技能和好的設計會增強敏捷能力。 簡單是最根本的。 最好的構架、需求和設計出於自組織團隊。 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。 一、敏捷開發方法
（一） 說明 本文是閱讀Alistair Cockburn的Agile Software Development和William C. Wake的XP Explored的一些筆記和想法，Agile Software Development是一組軟體開發方法的總稱，包括（Crystal , Extreme Programming , Adaptive software development等等）。敏捷開發方法又稱為「輕量級」開發方法。
下面這段話摘自Martin Fowler的一篇文章：
從無到繁重再到敏捷多數軟體開發仍然是一個顯得混亂的活動，即典型的「邊寫邊改」 （code and fix）。設計過程充斥著短期的，即時的決定，而無完整的規劃。這種模式對小系統開發其實很管用，但是當系統變得越大越復雜時，要想加入新的功能就越來越困難。同時錯誤故障越來越多，越來越難於排除。一個典型的標志就是當系統功能完成後有一個很長的測試階段，有時甚至有遙遙無期之感，從而對項目的完成產生嚴重的影響。 我們使用這種開發模式已有很長時間了，不過我們實際上也有另外一種選擇，那就是「正規方法」（methodology）。這些方法對開發過程有著嚴格而詳盡的規定，以期使軟體開發更有可預設性並提高效率，這種思路是借鑒了其他工程領域的實踐。 這些正規方法已存在了很長時間了，但是並沒有取得令人矚目的成功，甚至就沒怎麼引起人們的注意。對這些方法最常聽見的批評就是它們的官僚繁瑣，要是按照它的要求來，那有做太多的事情需要做，而延緩整個開發進程。所以它們通常被認為是「繁瑣滯重型」方法，或Jim HighSmith 所稱的「巨型」（monumental)方法。 作為對這些方法的反叛，在過去幾年中出現了一類新方法。盡管它們還沒有正式的名稱，但是一般被稱為「敏捷型」方法。對許多人來說，這類方法的吸引之處在於對繁文縟節的官僚過程的反叛。它們在無過程和過於繁瑣的過程中達到了一種平衡，使得能以不多的步驟過程獲取較滿意的結果。 敏捷型與滯重型方法有一些顯著的區別。其中一個顯而易見的不同反映在文檔上。敏捷型不是很面向文檔，對於一項任務，它們通常只要求盡可能少的文檔。從許多方面來看，它們更象是「面向源碼」（code-oriented）。事實上，它們認為最根本的文檔應該是源碼。 但是，我並不以為文檔方面的特點是敏捷型方法的根本之點。文檔減少僅僅是個表象，它其實反映的是更深層的特點： ? 敏捷型方法是「適配性」而非「預設性」。 重型方法試圖對一個軟體開發項目在很長的時間跨度內作出詳細的計劃，然後依計劃進行開發。這類方法在計劃制定完成後拒絕變化。而敏捷型方法則歡迎變化。其實，它們的目的就是成為適應變化的過程，甚至能允許改變自身來適應變化。 ? 敏捷型方法是「面向人」的(people-oriented) 而非「面向過程」的 (process-oriented)。 它們試圖使軟體開發工作順應人的天性而非逆之。它們強調軟體開發應當是一項愉快的活動。我認為以上兩個特點很好的概括了敏捷開發方法的核心思想：適應變化和以人為中心
（二） 方法背後的思想
Alistair Cockburn在Agile Software Development中講述了敏捷開發方法背後的思想
人們掌握過程（process）可以分為3個階段：1 following 遵循一個定義好的process2 detaching 知道不同process的適用范圍，在不同的場合使用不同的process3 fluent 不關心是否遵循特定的process，知道在什麼情況下採用什麼動作
軟體開發是一個充滿發明和交流的協作性游戲(cooperative game of invertion and communication)。軟體開發的首要目標是生產出軟體，遵循特定的過程和模型只是手段，只要傳遞了足夠的信息，手段是次要的。交流的效果要遠遠重於交流的形式（Effect of communication is more important than the form of communication）。一般軟體開發有兩個目標：1 盡快的生產出軟體2 為下一個team或項目做准備，有時這兩個目標是矛盾的，我們要在這兩個目標之間尋求平衡
在軟體開發中，人的因素要遠遠大於過程和技術。人是有缺陷的：1 容易犯錯誤，因此必須在錯誤擴散之前找到並改正錯誤2 當覺得可能失去較多的時候，不願意冒險3 重新構造而不願意重復使用已有的東西4 難於堅持一個習慣
針對個人因素的幾個建議：1 具體的模型較抽象的模型更容易理解2 從一個例子開始是容易的3 通過觀察他人的成果學習4 要有足夠的不受打擾的時間5 分配的工作要與個人意向，能力匹配6 不正確的獎勵會有壞作用，從長期看個人興趣比獎勵更重要，培養在工作中的自豪感：1) pride in work參與工作的自豪感，通常參與一個重要的工作會有自豪感2) pride in accomplishment 完成工作的自豪感，長期未完的工作會使士氣低落3)pride in contribution 為他人貢獻的自豪感7 鼓勵關心其他人的工作和整體的工作
在一個團隊之間，交流是最重要的，實踐證明面對面的實時的交流是最有效的，對交流的延誤會損失信息，白板是最好的交流工具，交流工具的先進並不能提高交流效果。文檔的作用是記錄和備忘，不能通過文檔交流。
敏捷開發方法要避免的過程設計的幾個常見錯誤1 對所有的項目使用同一種過程2 沒有彈性3 過於沉重4 增加不必要的「必須完成」（「should do」 is really should？）5 沒有經過實踐檢驗
敏捷開發方法過程設計的幾個原理：1 交互的面對面的交流是代價最小，最迅速的交換信息的方法2 超過實際需要的過程是浪費的3 大的團隊需要重量級方法4 處理重大問題的項目需要重量級方法強調5 增加反饋和交流可以減少中間產品和文檔的需求6 輕量級方法更強調理解（understanding）,自律（discipline）和技能(skill)，重量級方法更強調文檔（documentation），過程（process）和正式（formality）understanding指整個團隊關於項目的全部知識，包括討論的過程，documentation只能記錄其中的一部分discipline是指個人主動的完成工作，process指個人根據指令完成工作skill指具有良好技能的人可以省略中間的產品，formality指必須按照規定步驟完成工作
7 確定開發中間的瓶徑，提高它的效率對於瓶徑處的工作應該盡量加快，減少重復，（使用更熟練的人，使用更多的人，使用更好的工具，使瓶徑處的工作的深入盡量穩定）對於非瓶徑處的工作可以多一些重復，在輸入還不確定的情況下也可以盡早開始。
這些原理的幾個結論：1 向一個項目增加人員要花費較大代價（constly），因為原有人員和新人員之間的交流要花費大量時間2 團隊的規模經常是跳躍的，例子：需要6個熟練的程序員，但是只有4個，於是增加不熟練的程序員，結果團隊的大量時間花費在培訓不熟練的程序員上面，最後增加到了20個不熟練的程序員。3 應該側重於提高團隊的技能而不是擴充團隊4 對不同的項目使用不同的過程5 在適用的條件下，輕量級的方法優於重量級的方法6 對不同的項目要裁減過程
敏捷開發方法的原則是「剛剛好」（Light and Sufficient）

㈣ 敏捷開發項目的管理流程

導語：對於敏捷開發項目的管理流程，相關人員要清楚。下面是我收集整理的敏捷開發項目管理流程，供各位閱讀和參考。

前段時間給大家整理了敏捷開發的流程，最近在整理敏捷開發項目的流程和管理制度，其整理的項目管理規程如下，這份規程也不完全算是敏捷專屬的項目管理規程，主要是在結合我們公司實際的情況下編寫出來的，大家在實際嵌入到公司的過程中可以參考下，不能照搬。

1. 目的

規范互聯網軟體產品開發項目管理過程，指導開展項目研發、管理等活動。

2. 適用范圍

本章程的作用范圍為互聯網軟體產品開發立項至結項管理過程。

1.對項目經理開展產品規劃及設計活動以及項目管理手段和應遵循的開發流程提供了指導；

2.對項目團隊的日常管理活動及內容進行了指導；

3. 角色及職責定義

項目經理：

進行產品開發過程中的業務目標、進度、成本、質量控制。

挑選項目團隊並進行團隊建設，激發、鼓舞和改進團隊的生產效率。

識別項目干係人，定期向干係人匯報，並作為團隊和外部的介面，屏蔽外界對團隊的干擾。

確保項目中流程被遵循，組織、監督、培訓項目各實踐活動。

產品策劃

確定產品的功能，拆分用戶故事。

需求功能確定優先順序。

接受或拒絕開發團隊的工作成果。

參與產品開發過程中的有關會議。

UI

根據用戶故事，負責產品的功能交互及界面設計

組織開展人機交互及用戶體驗，不斷跟蹤改進，提高產品表現力。

參與產品開發過程中的有關會議。

開發

根據用戶故事，負責產品的技術架構設計及功能開發

評估、設計及維護產品相應模塊，確保模塊的穩定性、易用性、高效性。

參加產品開發過程中的有關會議。

測試

根據用戶故事，設計產品測試標准，確保產品品質滿足市場需求。

合理分配測試資源，組織產品測試並優化測試流程及測試標准，提高測試效率。

編寫產品測試用例，提交測試問題，編寫測試總結報告，以測試角度來確定產品版本是否發布。

4. 項目管理過程

按照互聯網軟體產品項目開發過程，可將整個項目管理過程分為立項過程、規劃過程、執行與監控過程、結項過程。下面分別闡述在每個階段過程中該如何進行項目管理。

4.1 立項過程

互聯網軟體產品開發項目的立項過程，通常是指從准備項目啟動會到召開會議這個階段，在立項過程中，需要完成項目目標，需求范圍的初步確認，項目團隊成員，其他資源的安排。

確定項目的初步目標並達成共識

對於項目目標，需要和干係人在以下幾點上達成共識：

項目的背景、目標用戶、核心人員及產品定位是什麼

項目的資源投入預算是多少

項目的資源投入是多少

各人員在項目中扮演的角色和對項目的作用是什麼

准備啟動會議文檔

文檔內容包括：

用戶畫像

產品定位

市場策略

業務目標

技術可行性

研發成本預算

路標規劃

召開項目啟動會

參加人員包括：

管理層代表

項目經理及項目團隊

其他干係人代表

主要議題包括：

申明項目目標范圍及對組織目標的貢獻。

管理層正式任命PM，設定期望，統一思想

文檔內容的宣講。

與PM小組確定項目管理要求

項目啟動會完成後，需要與PM小組成員確定項目立項機制以及公司項目管理要求。

4.2 規劃階段

在規劃階段，團隊需要共同完成產品的版本規劃，迭代計劃

版本規劃

從產品的關鍵特性列表中按照優先順序規劃產品每個版本需要完成哪些特性，在規劃完成後需要在項目干係人內達成共識。具體可參考《版本規劃樣例》

迭代如何劃分

迭代劃分是指將特性列表拆分形成用戶故事列表，並將其對應的主要任務劃分到各個迭代中去，形成粗粒度的項目迭代計劃。這個過程主要考慮以下幾個因素：

有些任務間是有依賴關系，某個任務的開始或結束是以另一個任務的開始或結束為前提，在劃分時必須考慮這種前後依賴關系。

在安排每個迭代的任務時，需要對各種因素進行綜合考慮，如平衡每個迭代中任務的技術難度和價值差異。

除了進行初步的迭代任務劃分，還需要確定項目過程中迭代任務調整的規則，如迭代任務未完成時是將剩餘任務延至下一迭代還是延長迭代周期。

確定人員分工

項目經理需要根據每個人員的能力和特點，初步擬定大致分工。在進行任務分工時需考慮以下因素：

任務難度與人員能力相匹配，對於明顯超出能力范圍或過於簡單的任務容易造成負面影響。

耦合度高的盡量分配給同一個人，避免不必要的溝通消耗。

鼓勵團隊內部「任務認領」，提高人員的工作積極性和主動性。

確定迭代運行模式

如一周迭代、兩周迭代，每個迭代包含的工作內容等。

具體的迭代計劃可參考《迭代計劃樣例》

制定其他輔助計劃

制定溝通計劃、風險計劃和質量計劃是必要的，溝通計劃主要包含以下幾個方面：溝通對象、溝通方式、溝通頻率即可，如：

風險計劃包括風險項、負責人、重要性、應對措施，如下：

質量計劃包括：bug分布滿足何種條件可以發布，有幾個致命bug必須停止開發新特性等。。

搭建基礎技術架構

如果是一個全新的項目，需要重新開發系統框架，則這個工作應該在迭代0完成，否則會影響後期的工作開展。系統框架的每次改動必然會導致大量的重復工作量，從而給穩定的團隊節奏帶來很大的毛刺。

4.3 項目執行和監控過程

迭代N的執行

A、迭代N的需求細化

考慮每個迭代需要完成的用戶故事；

用戶故事需包含幾個部分，工作量評估、功能性需求、非功能性需求。具體的可參考《用戶故事模板及樣例及拆分說明》

用戶故事編寫完成後需要在團隊內部進行需求評審，一方面是為了向團隊成員解讀該需求，另一方面團隊成員也可在評審時給出指導性意見。

B、測試用例評審

測試人員根據用戶故事要求編寫對應的測試用例，並組織項目團隊進行測試用例評審。根據評審意見修改測試用例

C、開發

將用戶故事的'需求開發的過程。

D、開發自測

在開發過程中，每完成一個功能點，都需要及時的進行開發自測並通知產品策劃人員進行驗收體驗。

E、驗收

開發完成後，產品策劃需要對開發完成的成果進行驗收，驗證其是否符合用戶故事的要求，驗證通過後方可流到測試環節，否則需與開發詳細討論其不符合性，其驗收的checklist可以參考《產品驗收checklist及模板》

F、測試和回歸

提交測試時，必須要有正確的版本。測試人員根據測試用例進行測試，在IT平台中提交測試bug，並根據測試的角度給出產品是否發布的意見，輸出《測試報告》

G、bug修改

在IT平台中獲取分配給自己的bug進行修改。

H、showCase

階段性必須有可體驗版本進行showCase.需要

確定showCase時間：某個迭代開發、自測完成，准備提交測試前

會議前1-2天發出體驗版給到參與人員

會議期間，由項目經理組織大家體驗、反饋問題、記錄問題。

項目經理根據問題情況，與開發或產品確定問題的解決時間並發出會議紀要。

I、灰度發布

迭代一定版本後，由項目經理與團隊共同決定是否需要進行灰度發布。

監控方式

每日站立會

主持人輪流擔任，負責控制節奏，記錄問題，以備會後跟蹤。

每人講自己昨天做了什麼，有什麼問題，今天的計劃是什麼；

其他人了解別人的工作情況，並發現指出可能存在的問題。

對於發現的問題，鼓勵認領，其餘由項目經理指定責任人。

時間通常控制在15分鍾內。

會議期間，更新任務牆，任務牆樣式如下：

周報

反饋項目計劃的執行情況，強調本周工作要達成的目標

暴露出項目的問題，特別是需要領導或其他團隊需要協助的問題。

周報可在IT平台中輸出。

月報

反饋項目當月的執行情況，包括進度、人力及質量。

反映項目存在的問題和風險。

迭代回顧

每人講述本次迭代做的好的地方和不好的地方

回顧上個迭代不好的地方，看看改進情況。

讓每個人發言。

每次迭代回顧會議完成後，可更新燃盡圖

4.4 結項階段

項目經理指導產品策劃收集總結項目的產品運營數據，同時指導團隊成員從自身角色進行總結，包括測試、開發、UI等。

項目經理與項目團隊成員給出項目總結報告，內容可參考《項目經驗教訓總結-項目團隊》，《項目經驗教訓總結-項目經理》

召開結項會議，各成員進行結項匯報。

PM小組將過程文檔和經驗教訓總結進行歸檔。

㈤ 識別價值流和ART

這是SAFe ® 實施路線圖系列的第五篇。 點擊這里 查看整個路線圖。

實施路線圖的前四項「關鍵舉措」確立了變革的緊迫感，以及有效實施SAFe所需的關鍵知識和專業人員：

有了緊迫感和強大的聯盟，現在是實施SAFe的時候了。本文介紹了下一個關鍵步驟：識別價值流和敏捷發布列車（ART）。價值流和ART是組織實施SAFe的支柱，，對成功完成這一過程至關重要。試圖走捷徑或輕而易舉地完成這一步，就像在你試圖加速的同時把腳踩在剎車上一樣。但是，如果這一步做對了，組織就會在成功轉型的道路上越走越遠。

識別 價值流 和 敏捷發布列車(ART) 需要了解一種新的組織模式，該模式經過優化以促進促進價值在 跨 職能部門、活動和邊界之間的流動，其包括以下步驟：

以下各節將介紹這些活動。

價值流是理解、組織和交付SAFe價值的主要結構。如圖1所示，每一個價值流都是用於創造價值的一系列長期步驟：從概念到為客戶提供有形的結果。就像任何精心設計的 故事（narrative） 一樣，價值流確定了一個按時間順序排列的活動流程。

請注意，有兩種類型的價值流[1]，如圖3所示。

SAFe主要關注的是開發價值流。畢竟，在最短的可持續交付時間內交付新的解決方案是SAFe的重點，而開發價值流則幫助企業了解如何實現目標。然而，必須首先識別企業的運營價值流，以確定支持它們的 開發價值流 。

對於一些組織來說，確定運營價值流很容易。許多隻是公司銷售的產品、服務或解決方案。然而，在大型企業中，這項任務會很復雜。價值流通過分布在組織的許多部分的各種應用、系統和服務流向 內部 和 外部 客戶。

在這些情況下，識別運營價值流是一項重要的分析活動。圖4提供了一組問題，可以幫助利益相關者完成這一識別過程。

識別大型企業中的運營價值流並非易事。它需要認識到組織更廣泛的目標，並明確了解價值的具體要素如何流向客戶。為了幫助你，在下面的章節中提供了兩個例子：一個來自醫療保健領域，另一個來自金融服務領域。

第一個運營價值流的例子是醫療保健網路提供商，如圖5所示[2]。

為了說明問題，這個例子側重於醫院，特別是代表支持患者治療的流程和信息系統的價值流：從收治到治療和結算。

這個運營價值流的觸發點是病人到達醫院。在患者接受治療並為所提供的服務付款後，醫院將獲得全部價值，如圖6所示。

V型標志（chevrons） （價值交付的主要活動）上面所標示的人員就是執行運營價值流中各個步驟的人員。

第二個業務價值流的例子是銀行機構[3]。圖7說明了在這樣一個組織中可能存在的各種價值流。

紅色的矩形突出顯示了下文會進一步說明的「消費者銀行貸款」價值流。價值流是由客戶搜索並找到銀行的貸款產品和利率而觸發的，當客戶帶著利息償還貸款時，價值流就實現了。圖8突出顯示了這些步驟和執行這些步驟的人員。

( 註：客戶也是該價值流的直接參與者。 )

價值流定義模板（value stream definition template） 可用於進一步闡述和理解所識別的運營價值流的特徵。圖9提供了一個示例。

一旦確定了運營價值流的步驟，下一個活動就是確定為支持該價值流而開發的系統。對於較大的價值流，重要的是將系統與價值流中各個步驟的聯系繪制出來。這樣可以使人們更深入地了解它是如何運作的，如圖10中的消費者貸款示例所示。

一旦確定了支持運營價值流的系統，接下來的活動就是估算構建和維護這些系統的人員數量和定位，如圖11所示。

下一步是確定開發價值流，這些流代表開發這些系統所需的步驟以及開發這些系統的人員。由於這些價值流與運營價值流不同，因此組織需要考慮觸發因素和價值是什麼。該系統在運營價值流中支持和實現更好的操作，因此價值是系統中的新功能或修正的功能。觸發因素則是驅動這些功能的需求和想法。

這些觸發因素可以用來確定開發價值流的數量。如果大多數需求需要觸及所有系統才能實現新功能，那麼可能只有一個開發價值流。然而，如果系統是分離的，則可能有幾個。無論如何，開發價值流應該大部分或完全獨立，能夠自行開發和發布，沒有太多的價值流內部依賴關系。在圖12的例子中，大多數需求都會觸及前三個系統或最後一個系統，但很少會觸及所有四個系統，因此存在兩個開發價值流，每個價值流都能夠獨立於另一個開發、集成、部署和發布。

開發價值流努力提供創新的業務解決方案，因此需要的不僅僅是開發團隊的貢獻。參與業務解決方案交付的 每個人 （IT運營、法律、市場營銷、財務、技術支持、合規、安全等）都被認為是開發價值流的一部分。考慮到這一點，下一步是確定這些額外的個人和團隊，他們是上一步確定的開發價值流的一部分。

在圖13的例子中，第一個開發價值流側重於貸款申請流程，包括進行營銷以編制宣傳材料和開展吸引客戶的活動。還包括法律團隊成員，以確定所提供貸款的相關條款和條件。第二個開發價值流是開發管理貸款償還的核心銀行系統，也包括進行營銷以管理與現有客戶群的持續溝通。這兩個開發價值流都包括支持團隊，以應對任何可能出現的客戶問題，以及運營團隊，以管理這些系統在生產中的穩定性。

一旦確定了開發價值流，下一步就是開始了解如何組建 敏捷發布列車（ARTs） 來實現這些價值流。ART包含了提升價值流所需的所有人員和其他資產。第一步是了解組織中哪裡創造了價值，因為那是人員、流程和系統所在的位置。當這樣做的時候，很明顯，開發價值流會跨越許多邊界。企業之所以會有這樣的組織方式，有很多原因：歷史、功能上的便利、集中化的效率、收購、地理環境等等。因此，完全有可能沒有人了解持續開發和增強有助於提供價值的系統所需的一系列完整事件。此外，改進的嘗試往往傾向於功能上的局部改進，這可能導致一個功能或步驟的優化，但端到端流程的優化很少。

正是由於價值流的長期性，引發了精益組織的不同思考方法。為了解決這個問題，企業應用系統思維（ 原則2，應用系統思維 ），來了解系統中的各個部分需要如何共同完成流程的改善。通常情況下，大型企業的組織結構都是按職能劃分的。此外，人員往往是按地域分布的。但是，如圖14所示，價值卻 跨越了 這些界限。

最後一項活動是確定實現價值的ART。經驗表明，最有效的ART具有以下特徵：

根據工作人數的多少，ART設計有三種可能的方案，如圖15所示。

大型開發價值流在大型企業中非常常見，通常需要進行一些額外的分析。在可能的情況下，列車應該集中在一個單一的、主要的解決方案上，或者該價值流中一組密切相關的產品或服務上。這是一個相當簡單的設計：一個ART提供一組定義明確的有價值的東西。

然而，在需要許多人提供單一解決方案的情況下，當團隊一起工作，同時開發具有高度相互依賴性的功能和組件時，這種方法最有效。這就導致了圍繞 特性領域（feature areas） 或子系統組織ART的相對常見的模式。

沒有一個正確的解決方案，大型系統通常需要兩種類型的ART。一個典型的例子是，多個ART基於一個共同的平台提供服務或解決方案。在這種情況下，可能有一個或多個 平台ART（platform ART） 支持 特性ART（feature ART） ，如圖16所示。

還有一種常見的模式，即ART在一個更大的價值流中實現特定的 環節（segments） 。這看起來似乎並不完全是端到端的，但實際上，價值流的「開始和結束」是相對的概念。在這些環節中，輸入、價值、系統的類型可能大不相同，從而形成了一條邏輯分界線。

當然，這些模式的組合也經常出現在更大的價值流中，如圖17中的最終示例所示。

最後，還有其他一些基於地域、口語、成本中心等因素的ART設計和優化方法，這些因素都可能影響ART的設計。但這些都是遠遠不夠理想的。

如圖所示，這個過程中涉及到批判性思維和分析。為了幫助識別價值流，Scaled Agile, Inc.提供了一個 價值流和ART識別工作坊工具包 ，包括一個研討會和其他工具，SAFe項目顧問（SPC）可以用來指導利益相關者。該研討會提供了一個結構化的方法來識別價值流和定義ART，從而梳理出企業的價值流。該工具包提供了一種經過驗證的、系統化的方法，通過考慮依賴性、協調性和約束條件來優化ART設計。

價值流和ART識別研討會通常在與關鍵利益相關者的Leading SAFe課後直接進行。目的是讓他們完成對價值流的識別，設計ART的過程，在他們對SAFe實現的精益-敏捷開發有了基本的了解 之後 ，再選擇首次ART啟動的日期。

由於沒有任何設計是完美的，所以企業有時會在學習了更多知識後需要重復這個研討會，這是 加速 路線圖步驟的一部分。這樣做可以讓企業加深其對價值流和ART的理解，並將新的學習成果融入到組織設計中。

這篇文章介紹了團隊如何做識別價值流和設計ART的工作，這些工作構成了轉型的基本組織結構。

現在是時候進行下一步了，創建實施計劃，這是SAFe實施路線圖的下一篇文章。

[1] Allen Ward, Lean Proct, and Process Development . (video) Lean Enterprise Institute, 2004
[2] Contributed by Jane Tudor, Justine Johnston, Matt Aaron, Steve Mayner, and Thorsten Janning.
[3] Contributed by Darren Wilmshurst, Murray Ford, Per-Magnus Skoogh, Phillip Manketo, Sam Bunting, and Virpi Rowe.
[4] Knaster, Richard and Leffingwell, Dean. SAFe Distilled, Applying the Scaled Agile Framework for Lean Software and Systems Engineering. Addison-Wesley, 2017.

Value Stream and ART Identification Workshop Toolkit for SPCs.

Last update: 28 September 2019

㈥ 什麼是敏捷軟體開發

敏捷軟體開發是一個概念意義上的框架，用來取代軟體工程項目的概念；它強調在項目的整個生命周期中，擁抱並促進由於軟體進化式的發展所帶來的變化。eentirelife-cycleoftheproject.這段定義來自wikipedia，我認為是我接觸ASD以來，對ASD最精闢的論述。請注意其中的三個關鍵詞：在項目的整個生命周期中：這就涉及到了【敏捷項目管理】、【敏捷需求獲取】、狹義的【敏捷軟體開發】三個主要的領域和過程。要注意的是，上述三個過程並不是互相分開的，而是你中有我，我中有你。擁抱並促進變化：世界上唯一不變的是變化。不論在任何領域，漠視、甚至否認、抗拒變化，都不是一個理性，嚴肅的人所應有的態度。學會如何識別變化的大勢，並在可能的時候，促使變化向好的方向發展。這才是面對變化的正確應對之法。軟體進化式的發展：雖然上面提到促進變化的發展，但是軟體的演化過程，我相信是有其自身內在邏輯的，存在一些根本規律和指導方針；並不是完全以人的主觀意識為主導。老子講「順勢而為，無為無不為」，我認為是對上述後兩點的精確概括與指導。了解了這三個方面，下面就要引入大名鼎鼎、如雷貫耳、耳朵都要磨出糨子來的敏捷宣言（）了，讓我們看看2001年提出的第一版的敏捷軟體開發宣言怎麼說：doit.:☆☆☆☆,,wevaluetheitemsontheleftmore.我們正在通過實踐和幫助其他人實踐，揭示更好的開發軟體的方法。我們從實踐中得出的價值觀是：☆人和交互重於過程和工具。☆可以工作的軟體重於求全責備的文檔。☆客戶合作重於合同談判。☆隨時應對變化重於循規蹈矩。雖然右項也具有價值，但我們認為左項具有更大的價值。經過六年的演變，敏捷大師們又提出了敏捷宣言的重構版本，由於尚未形成共識，暫不在此提出。在敏捷宣言的背後，有其遵循的12條原則：:☆eryofvaluablesoftware.☆Welcomechangingrequirements,evenlateindevelopment.'scompetitiveadvantage.☆,,.☆.☆.,andtrustthemtogetthejobdone.☆velopmentteamisface-to-faceconversation.☆.☆.Thesponsors,developers,.☆.☆Simplicity----isessential.☆Thebestarchitectures,requirements,anddesignsemergefromself-organizingteams.☆Atregularintervals,,.★我們最優先要做的是通過盡早的、持續的交付有價值的軟體來使客戶滿意。★即使到了開發的後期，也歡迎改變需求，敏捷過程利用變化來為客戶創造競爭優勢。★經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。★在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。★圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，並且信任他們能夠完成工作。★在團隊內部，最具有效果並且富有效率的傳遞信息的方法，就是面對面的交流。★工作的軟體是首要的進度度量標准。★敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恆定的開發速度。★不斷地關注優秀的技能和好的設計會增強敏捷能力。★簡單--使未完成的工作最大化的藝術---是根本的。★最好的構架、需求和設計出自於自組織的團隊。★每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。

㈦ 軟體開發模式有哪些

. 邊做邊改模型（Build-and-Fix Model）

好吧，其實現在許多產品實際都是使用的「邊做邊改」模型來開發的，特別是很多小公司產品周期壓縮的太短。在這種模型中，既沒有規格說明，也沒有經過設計，軟體隨著客戶的需要一次又一次地不斷被修改。

在這個模型中，開發人員拿到項目立即根據需求編寫程序，調試通過後生成軟體的第一個版本。在提供給用戶使用後，如果程序出現錯誤，或者用戶提出新的要求，開發人員重新修改代碼，直到用戶和測試等等滿意為止。

這是一種類似作坊的開發方式，邊做邊改模型的優點毫無疑問就是前期出成效快。

對編寫邏輯不需要太嚴謹的小程序來說還可以對付得過去，但這種方法對任何規模的開發來說都是不能令人滿意的，其主要問題在於：

• 缺少規劃和設計環節，軟體的結構隨著不斷的修改越來越糟，導致無法繼續修改；

• 忽略需求環節，給軟體開發帶來很大的風險；

• 沒有考慮測試和程序的可維護性，也沒有任何文檔，軟體的維護十分困難。

2. 瀑布模型（Waterfall Model）

瀑布模型是一種比較老舊的軟體開發模型，1970年溫斯頓·羅伊斯提出了著名的「瀑布模型」，直到80年代都還是一直被廣泛採用的模型。

瀑布模型將軟體生命周期劃分為制定計劃、需求分析、軟體設計、程序編寫、軟體測試和運行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

在瀑布模型中，軟體開發的各項活動嚴格按照線性方式進行，當前活動接受上一項活動的工作結果，實施完成所需的工作內容。當前活動的工作結果需要進行驗證，如驗證通過，則該結果作為下一項活動的輸入，繼續進行下一項活動，否則返回修改。

瀑布模型優點是嚴格遵循預先計劃的步驟順序進行，一切按部就班比較嚴謹。

瀑布模型強調文檔的作用，並要求每個階段都要仔細驗證。但是，這種模型的線性過程太理想化，已不再適合現代的軟體開發模式，幾乎被業界拋棄，其主要問題在於：

• 各個階段的劃分完全固定，階段之間產生大量的文檔，極大地增加了工作量；

• 由於開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增加了開發的風險；

• 早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果。

• 各個軟體生命周期銜接花費時間較長，團隊人員交流成本大。

• 瀑布式方法在需求不明並且在項目進行過程中可能變化的情況下基本是不可行的。

3. 迭代模型（stagewise model）

迭代模型（也被稱作迭代增量式開發或迭代進化式開發）是一種與傳統的瀑布式開發相反的軟體開發過程，它彌補了傳統開發方式中的一些弱點，具有更高的成功率和生產率。

在迭代式開發方法中，整個開發工作被組織為一系列的短小的、固定長度（如3周）的小項目，被稱為一系列的迭代。每一次迭代都包括了需求分析、設計、實現與測試。採用這種方法，開發工作可以在需求被完整地確定之前啟動，並在一次迭代中完成系統的一部分功能或業務邏輯的開發工作。再通過客戶的反饋來細化需求，並開始新一輪的迭代。

教學中，對迭代和版本的區別，可理解如下： 迭代一般指某版本的生產過程，包括從需求分析到測試完成； 版本一般指某階段軟體開發的結果，一個可交付使用的產品。

與傳統的瀑布模型相比較，迭代過程具有以下優點：

• 降低了在一個增量上的開支風險。如果開發人員重復某個迭代，那麼損失只是這一個開發有誤的迭代的花費。

• 降低了產品無法按照既定進度進入市場的風險。通過在開發早期就確定風險，可以盡早來解決而不至於在開發後期匆匆忙忙。

• 加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率。

• 由於用戶的需求並不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。因此復用性更高

4. 快速原型模型（Rapid Prototype Model）

快速原型模型的第一步是建造一個快速原型，實現客戶或未來的用戶與系統的交互，用戶或客戶對原型進行評價，進一步細化待開發軟體的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什麼；第二步則在第一步的基礎上開發客戶滿意的軟體產品。

顯然，快速原型方法可以克服瀑布模型的缺點，減少由於軟體需求不明確帶來的開發風險，具有顯著的效果。

快速原型的關鍵在於盡可能快速地建造出軟體原型，一旦確定了客戶的真正需求，所建造的原型將被丟棄。因此，原型系統的內部結構並不重要，重要的是必須迅速建立原型，隨之迅速修改原型，以反映客戶的需求。

快速原型模型有點整合「邊做邊改」與「瀑布模型」優點的意味。

5、增量模型（Incremental Model）

與建造大廈相同，軟體也是一步一步建造起來的。在增量模型中，軟體被作為一系列的增量構件來設計、實現、集成和測試，每一個構件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構成。

增量模型在各個階段並不交付一個可運行的完整產品，而是交付滿足客戶需求的一個子集的可運行產品。整個產品被分解成若干個構件，開發人員逐個構件地交付產品，這樣做的好處是軟體開發可以較好地適應變化，客戶可以不斷地看到所開發的軟體，從而降低開發風險。但是，增量模型也存在以下缺陷：

• 由於各個構件是逐漸並入已有的軟體體系結構中的，所以加入構件必須不破壞已構造好的系統部分，這需要軟體具備開放式的體系結構。

• 在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優於瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟體過程的控制失去整體性。

在使用增量模型時，第一個增量往往是實現基本需求的核心產品。核心產品交付用戶使用後，經過評價形成下一個增量的開發計劃，它包括對核心產品的修改和一些新功能的發布。這個過程在每個增量發布後不斷重復，直到產生最終的完善產品。

例如，使用增量模型開發字處理軟體。可以考慮，第一個增量發布基本的文件管理、編輯和文檔生成功能，第二個增量發布更加完善的編輯和文檔生成功能，第三個增量實現拼寫和文法檢查功能，第四個增量完成高級的頁面布局功能。

6. 螺旋模型（Spiral Model）

1988年，巴利·玻姆(Barry Boehm)正式發表了軟體系統開發的「螺旋模型」，它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合於大型復雜的系統。

螺旋模型沿著螺線進行若干次迭代，圖中的四個象限代表了以下活動：

• 制定計劃：確定軟體目標，選定實施方案，弄清項目開發的限制條件；

• 風險分析：分析評估所選方案，考慮如何識別和消除風險；

• 實施工程：實施軟體開發和驗證；

• 客戶評估：評價開發工作，提出修正建議，制定下一步計劃。

螺旋模型由風險驅動，強調可選方案和約束條件從而支持軟體的重用，有助於將軟體質量作為特殊目標融入產品開發之中。但是，螺旋模型也有一定的限制條件，具體如下：

• 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並做出相關反應是不容易的，因此，這種模型往往適應於內部的大規模軟體開發。

• 如果執行風險分析將大大影響項目的利潤，那麼進行風險分析毫無意義，因此，螺旋模型只適合於大規模軟體項目。

• 軟體開發人員應該擅長尋找可能的風險，准確地分析風險，否則將會帶來更大的風險

一個階段首先是確定該階段的目標，完成這些目標的選擇方案及其約束條件，然後從風險角度分析方案的開發策略，努力排除各種潛在的風險，有時需要通過建造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟。最後，評價該階段的結果，並設計下一個階段。

7. 敏捷軟體開發 (Agile development)

敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟體項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特徵。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，並分別完成，在此過程中軟體一直處於可使用狀態。

敏捷開發小組主要的工作方式可以歸納為：作為一個整體工作； 按短迭代周期工作； 每次迭代交付一些成果，關注業務優先順序，檢查與調整。

敏捷軟體開發要注意項目規模，規模增長，團隊交流成本就上去了，因此敏捷軟體開發暫時適合不是特別大的團隊開發，比較適合一個組的團隊使用。

8. 演化模型（evolutionary model）

主要針對事先不能完整定義需求的軟體開發。用戶可以給出待開發系統的核心需求，並且當看到核心需求實現後，能夠有效地提出反饋，以支持系統的最終設計和實現。軟體開發人員根據用戶的需求，首先開發核心系統。當該核心系統投入運行後，用戶試用之，完成他們的工作，並提出精化系統、增強系統能力的需求。軟體開發人員根據用戶的反饋，實施開發的迭代過程。第一迭代過程均由需求、設計、編碼、測試、集成等階段組成，為整個系統增加一個可定義的、可管理的子集。

在開發模式上採取分批循環開發的辦法，每循環開發一部分的功能，它們成為這個產品的原型的新增功能。於是，設計就不斷地演化出新的系統。 實際上，這個模型可看作是重復執行的多個「瀑布模型」。

「演化模型」要求開發人員有能力把項目的產品需求分解為不同組，以便分批循環開發。這種分組並不是絕對隨意性的，而是要根據功能的重要性及對總體設計的基礎結構的影響而作出判斷。有經驗指出，每個開發循環以六周到八周為適當的長度。

9. 噴泉模型（fountain model, (面向對象的生存期模型, 面向對象（Object Oriented,OO）模型））

噴泉模型與傳統的結構化生存期比較，具有更多的增量和迭代性質，生存期的各個階段可以相互重疊和多次反復，而且在項目的整個生存期中還可以嵌入子生存期。就像水噴上去又可以落下來，可以落在中間，也可以落在最底部。

10. 智能模型（四代技術（4GL）)

智能模型擁有一組工具（如數據查詢、報表生成、數據處理、屏幕定義、代碼生成、高層圖形功能及電子表格等），每個工具都能使開發人員在高層次上定義軟體的某些特性，並把開發人員定義的這些軟體自動地生成為源代碼。這種方法需要四代語言（4GL）的支持。4GL不同於三代語言，其主要特徵是用戶界面極端友好，即使沒有受過訓練的非專業程序員，也能用它編寫程序；它是一種聲明式、互動式和非過程性編程語言。4GL還具有高效的程序代碼、智能預設假設、完備的資料庫和應用程序生成器。目前市場上流行的4GL（如Foxpro等）都不同程度地具有上述特徵。但4GL目前主要限於事務信息系統的中、小型應用程序的開發。

11. 混合模型（hybrid model）

過程開發模型又叫混合模型（hybrid model），或元模型（meta-model）,把幾種不同模型組合成一種混合模型，它允許一個項目能沿著最有效的路徑發展，這就是過程開發模型（或混合模型）。實際上，一些軟體開發單位都是使用幾種不同的開發方法組成他們自己的混合模型。

㈧ 螺旋式和敏捷式軟體開發模式有什麼不同

螺旋開發，1988年，巴利·玻姆(Barry Boehm)正式發表了軟體系統開發的「螺旋模型」，它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合於大型復雜的系統。
「螺旋模型」剛開始規模很小，當項目被定義得更好、更穩定時，逐漸展開。

「螺旋模型」的核心就在於您不需要在剛開始的時候就把所有事情都定義的清清楚楚。您輕松上陣，定義最重要的功能，實現它，然後聽取客戶的意見，之後再進入到下一個階段。如此不斷輪回重復，直到得到您滿意的最終產品。

• 制定計劃：確定軟體目標，選定實施方案，弄清項目開發的限制條件；

• 風險分析：分析評估所選方案，考慮如何識別和消除風險；

• 實施工程：實施軟體開發和驗證；

• 客戶評估：評價開發工作，提出修正建議，制定下一步計劃。

螺旋模型很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發生的循環之前，都必須首先進行風險評估。

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

• 人和交互，重於過程和工具。

• 可以工作的軟體，重於求全而完備的文檔。

• 客戶協作，重於合同談判。

• 隨時應對變化，重於循規蹈矩。

其中位於右邊的內容雖然也有其價值，但是左邊的內容最為重要。人員彼此信任，人少但是精幹，可以面對面的溝通。

項目的敏捷開發

敏捷開發小組主要的工作方式可以歸納為：

• 作為一個整體工作。

• 按短迭代周期工作。

• 每次迭代交付一些成果。

• 關注業務優先順序。

• 檢查與調整。

最重要的因素恐怕是項目的規模。規模增長，面對面的溝通就愈加困難，因此敏捷方法更適用於較小的隊伍，40、30、20、10人或者更少。大規模的敏捷軟體開發尚處於積極研究的領域。

㈨ 什麼是 Agile Software Development（敏捷軟體開發）

敏捷編程是軟體產業適應現代商業環境的具體表現。歷史的第一點，隨著軟體產業的快速發展，軟體系統的規模越來越大，復雜性越來越高，開發周期和成本失控的問題越來越嚴重，也不能保證軟體的可靠性。

為了解決這一系列問題，軟體行業自然而然地轉向傳統的工程和管理方法。軟體工程就是這樣的結果。以「瀑布模型」為代表的傳統軟體開發模型為軟體生命周期的每個階段提供了一組規范，以使項目進展達到預期目的。軟體開發活動的核心重點，所有計劃、調度、交付的活動都是直接或間接與需求相一致的，並強調軟體需求必須形成「文檔」。基於計劃生命周期的軟體開發方法極大地促進了軟體行業的發展，但現在卻變得越來越「無力」。為了適應現代商業環境，提出了「敏捷編程」的開發方法。包括「極限編程」、自適應軟體開發和功能驅動開發。其他的答案是由定義給出的，我已經結合敏捷軟體開發宣言，從商業環境中探索這種開發方法的本質和起源。

總結：它背後的商業環境是，用戶無法有效描述自己需求的最典型的例子是蘋果的iPad和iPhone。在喬布斯沒有推出iPhone之前，用戶不知道他們需要一部智能手機，更准確地說，智能手機的需求無法被有效描述。這也是諾基亞(nokia)和摩托羅拉(MOTOROLA)等公司失敗的原因之一。

㈩ 敏捷開發的實踐

敏捷建模（AM）在AM原則的基礎上定義了一組核心實踐（practice）和補充實踐，其中的某些實踐已經是極限編程（XP）中採用了的，並在 Extreme Programming Explained一書中有詳細的論述，和AM的原則一樣，我們在描述這組實踐時，將會注重於建模的過程，這樣你可以從另外一個角度來觀察這些已或XP採用的素材。 ◆Stakeholder的積極參與 我們對XP的現場客戶（On-Site Customer）的概念做了一個擴充：開發人員需要和用戶保持現場的接觸；現場的用戶要有足夠的許可權和能力，提供建構中的系統相關的信息；及時、中肯的做出和需求相關的決策；並決定它們的優先順序。AM把XP的「現場客戶」實踐擴展為「使project stakeholder積極參與項目」，這個project stakeholder的概念包括了直接用戶、他們的經理、高級經理、操作人員、支持人員。這種參與包括：高級經理及時的資源安排決策，高級經理的對項目的公開和私下的支持，需求開發階段操作人員和支持人員的積極參與，以及他們在各自領域的相關模型。
◆正確使用artifact 每個artifact都有它們各自的適用之處。例如，一個UML的活動圖（activity diagram）適合用於描述一個業務流程，反之，你資料庫的靜態結構，最好能夠使用物理數據（physical data）或數據模型（persistence model）來表示。在很多時候，一張圖表比源代碼更能發揮作用，一圖勝千言，同樣，一個模型也比1K的源代碼有用的多，前提是使用得當（這里借用了 Karl Wieger的Software Requirements中的詞彙）。因為你在研究設計方案時，你可和同伴們和在白板上畫一些圖表來討論，也可以自己坐下來開發一些代碼樣例，而前一種方法要有效的多。這意味著什麼？你需要了解每一種artifact的長處和短處，當你有眾多的模型可供選擇的時候，要做到這一點可沒有那麼容易。
◆集體所有制 只要有需要，所有人都可以使用、修改項目中的任何模型、任何artifact。
◆測試性思維 當你在建立模型的時候，你就要不斷的問自己，「我該如何測試它？」如果你沒辦法測試正在開發的軟體，你根本就不應該開發它。在現代的各種軟體過程中，測試和質保（quality assurance）活動都貫穿於整個項目生命周期，一些過程更是提出了「在編寫軟體之前先編寫測試」的概念（這是XP的一項實踐：「測試優先」）。
◆並行創建模型 由於每種模型都有其長處和短處，沒有一個模型能夠完全滿足建模的需要。例如你在收集需求時，你需要開發一些基本用例或用戶素材，一個基本用戶界面原型，和一些業務規則。再結合實踐切換到另外的Artifact，，敏捷建模者會發現在任何時候，同時進行多個模型的開發工作，要比單純集中於一個模型要有效率的多。
◆創建簡單的內容 你應該盡可能的使你的模型（需求、分析、架構、設計）保持簡單，但前提是能夠滿足你的project stakeholder的需要。這就意味著，除非有充分的理由，你不應該隨便在模型上畫蛇添足－－如果你手頭上沒有系統認證的功能，你就不應該給你的模型增加這么一個功能。要有這樣的勇氣，一旦被要求添加這項功能，自己就能夠馬上做到。這和XP的實踐「簡單設計」的思想是一樣的。
◆簡單地建模 當你考慮所有你能夠使用的圖表（UML圖、用戶界面圖、數據模型等）時，你很快會發現，大部分時候你只需要這些圖表符號的一部分。一個簡單的模型能夠展示你想要了解的主要功能，例如，一個類圖，只要能夠顯示類的主要責任和類之間的關系就已經足夠了。不錯，編碼的標准告訴你需要在模型中加入框架代碼，比如所有的get和set操作，這沒有錯，但是這能提供多少價值呢？恐怕很少。
◆公開展示模型 你應當公開的展示你的模型，模型的載體被稱為「建模之牆」（modeling wall）或「奇跡之牆（wall of wonder）」。這種做法可以在你的團隊之間、你和你的project stakeholder之間營造出開放誠實的溝通氛圍，因為當前所有的模型對他們都是舉手可得的，你沒有向他們隱藏什麼。你把你的模型貼到建模之牆上，所有的開發人員和project stakeholder都可以看建模之牆上的模型，建模之牆可能是客觀存在的，也許是一塊為你的架構圖指定的白板，或是物理數據模型的一份列印輸出，建模之牆也可能是虛擬的，例如一個存放掃描好的圖片的internet網頁。如果你想要多了解一些相關的資料，你可以看看Ellen Gottesdiener的Specifying Requirements With a Wall of Wonder。
◆切換到另外的Artifact 當你在開發一個artifact（例如用例、CRC卡片、順序圖、甚至源碼），你會發現你卡殼了，這時候你應當考慮暫時切換到另一個artifact。每一個artifact都有自己的長處和短處，每一個artifact都適合某一類型的工作。無論何時你發現你在某個artifact上卡殼了，沒辦法再繼續了，這就表示你應該切換到另一個artifact上去。舉個例子，如果你正在製作基本用例，但是在描述業務規則時遇到了困難，你就該試著把你的注意力轉移到別的artifact上去，可能是基本用戶界面原型、CRC模型，可能是業務規則、系統用例、或變化案例。切換到另一個artifact上去之後，你可能就立刻不再卡殼了，因為你能夠在另一個artifact上繼續工作。而且，通過改變你的視角，你往往會發現原先使你卡殼的原因。
◆小增量建模 採用增量開發的方式，你可以把大的工作量分成能夠發布的小塊，每次的增量控制在幾個星期或一兩個月的時間內，促使你更快的把軟體交付給你的用戶，增加了你的敏捷性。
◆和他人一起建模 當你有目的建模時你會發現，你建模可能是為了了解某事，可能是為了同他人交流你的想法，或是為了在你的項目中建立起共同的願景。這是一個團體活動，一個需要大家有效的共同工作才能完成的活動。你發現你的開發團隊必須共同協作，才能建立一組核心模型，這對你的項目是至關重要的。例如，為了建立系統的映像和架構，你需要和同組成員一起建立所有人都贊同的解決方案，同時還要盡可能的保持它的簡單性。大多數時候，最好的方法是和另一些人討論這個問題。
◆用代碼驗證 模型是一種抽象，一種能夠正確反映你正在構建的系統的某個方面的抽象。但它是否能運行呢？要知道結果，你就應該用代碼來驗證你的模型。你已經用一些HTML頁面建立了接受付款地址信息的草圖了嗎？編碼實現它，給你的用戶展示最終的用戶界面，並獲取反饋。你已經做好了表示一個復雜業務規則邏輯的UML順序圖了嗎？寫出測試代碼，業務代碼，運行測試以保證你做的是對的。永遠也別忘了用迭代的方法開發軟體（這是大多數項目的標准做法），也別忘了建模只是眾多任務中的一個。做一會兒建模、做一會兒編碼、做一會兒測試（在其它的活動之中進行）。
◆使用最簡單的工具 大多數的模型都可以畫在白板上，紙上，甚至紙巾的背面。如果你想要保存這些圖標，你可以用數碼相機把它們拍下來，或只是簡單的把他們轉錄到紙上。這樣做是因為大多數的圖表都是可以扔掉的，它們只有在你畫出模型並思考一個問題的時候才有價值，一旦這個問題被解決了它們就不再有意義了。這樣，白板和標簽往往成為你建模工具的最佳選擇：使用畫圖工具來創建圖表，給你重要的project stakeholder看。只有建模工具能夠給我們的編程工作提供價值（例如代碼自動生成）時才使用建模工具。你可以這樣想：如果你正在創建簡單的模型，這些模型都是可以拋棄的。你建模的目的就是為了理解，一旦你理解了問題，模型就沒有存在的必要了，因此模型都是可以丟棄的，這樣，你根本就不必要使用一個復雜的建模工具。 ◆使用建模標准 這項實踐是從XP的編碼標准改名而來，基本的概念是在一個軟體項目中開發人員應該同意並遵守一套共同的建模標准。遵守共同的編碼慣例能夠產生價值：遵守你選擇的編碼指南能夠寫出干凈的代碼，易於理解，這要比不這么做產生出來的代碼好得多。同樣，遵守共同的建模標准也有類似的價值。可供選擇的建模標准有很多，包括對象管理組織（OMG）制定的統一建模語言ML），它給通用的面向對象模型定義了符號和語義。UML開了一個好頭，但並不充分－就像你在Be Realistic About The UML中看到的，UML並沒有囊括所有可能的的建模artifact。而且，在關於建立清楚可看的圖表方面，它沒有提供任何建模風格指南。那麼，風格指南和標准之間的差別在何處呢。對源代碼來說，一項標准可能是規定屬性名必須以attributeName的格式，而風格指南可能是說在一個單元中的一段控制結構（一個if語句，一段循環）的代碼縮進。對模型來說，一項標准可能是使用一個長方形對類建模，一項風格指南可能是圖中子類需要放在父類的下方。
◆逐漸應用模式 高效的建模者會學習通用的架構模式、設計模式和分析模式，並適當的把它們應用在模型之中。然而，就像Martin Fowler在Is Design Dead中指出的那樣，開發人員應當輕松的使用模式，逐漸的應用模式。這反映了簡單的價值觀。換言之，如果你猜測一個模式可能適用，你應當以這樣的方式建模：先實現目前你需要的最小的范圍，但你要為日後的重構留下伏筆。這樣，你就以一種可能的最簡單的方式實現了一個羽翼豐滿的模式了。就是說，不要超出你的模型。舉一個例子，在你的設計中，你發現有個地方適合使用GoF的Strategy模式，但這時候你只有兩個演算法要實現。最簡單的方法莫過於把演算法封裝為單獨的類，並建立操作，能夠選擇相應的演算法，以及為演算法傳遞相關的輸入。這是Strategy模式的部分實現，但你埋下了伏筆，日後如有更多的演算法要實現，你就可以重構你的設計。並沒有必要因為Strategy模式需要，就建立所有的框架。這種方法使你能夠輕松的使用模式。
◆丟棄臨時模型 你創建的大部分的模型都是臨時使用的模型－－設計草圖，低精度原型，索引卡片，可能架構/設計方案等等－－在它們完成了它們的目的之後就再不能提供更多的價值了。模型很快就變得無法和代碼同步，這是正常的。你需要做出決定：如果「同步更新模型」的做法能夠給你的項目增添價值的話，那就同步更新模型；或者，如果更新它們的投入將抵消它們能夠提供的所有價值（即負收益），那就丟棄它們。
◆合同模型要正式 在你的系統需要的信息資源為外部組織所控制的時候，例如資料庫，舊有系統和信息服務，你就需要合同模型。一個合同模型需要雙方都能同意，根據時間，根據需要相互改變。合同模型的例子有API的細節文檔，存儲形式描述，XML DTD或是描述共享資料庫的物理數據模型。作為法律合同，合同模型通常都需要你投入重要資源來開發和維護，以確保它的正確、詳細。你的目標是盡量使你系統的合同模型最少，這和XP的原則traveling light是一致的。注意你幾乎總是需要電子工具來建立合同模型，因為這個模型是隨時需要維護的。
◆為交流建模 建模的次要原因是為了和團隊之外的人交流或建立合同模型。因為有些模型是給團隊之外的客戶的，你需要投入時間，使用諸如文字處理器，畫圖工具包，甚至是那些「被廣告吹得天花亂墜」的CASE工具來美化模型。
◆為理解建模 建模的最重要的應用就是探索問題空間，以識別和分析系統的需求，或是比較和對照可能的設計選擇方法，以識別可能滿足需求的、最簡單的解決方案。根據這項實踐，你通產需要針對軟體的某個方面建立小的、簡單的圖表，例如類的生命周期圖，或屏幕順序，這些圖表通常在你完成目的（理解）之後就被丟棄。
◆重用現有的資源 這是敏捷建模者能夠利用的信息財富。例如，也許一些分析和設計模式適合應用到系統上去，也許你能夠從現有的模型中獲利，例如企業需求模型，業務過程模型，物理數據模型，甚至是描述你用戶團體中的系統如何部署的模型。但是，盡管你常常搜索一些比較正確的模型，可事實是，在大多數組織中，這些模型要麼就不存在，要麼就已經過期了。
◆非到萬不得已不更新 你應當在你確實需要時才更新模型，就是說，當不更新模型造成的代價超出了更新模型所付出的代價的時候。使用這種方法，你會發現你更新模型的數量比以前少多了，因為事實就是，並不是那麼完美的模型才能提供價值的。我家鄉的街道圖已經使用了5年了，5年我自己街道並沒有改變位置，這張地圖對我來說還是有用的。不錯，我可以買一張新地圖，地圖是每年出一次的，但為什麼要這么麻煩呢？缺少一些街道並沒有讓我痛苦到不得不投資買一份新地圖。簡單的說，當地圖還管用的時候，每年花錢買新地圖是沒有任何意義的。為了保持模型、文檔和源代碼之間的同步，已經浪費了太多太多的時間和金錢了，而同步是不太可能做到的。時間和金錢投資到新的軟體上不是更好嗎？
確實不錯的主意
以下的實踐雖然沒有包括在AM中，但是可以做為AM的一份補充：
◆重構 這是一項編碼實踐。重構，就是通過小的變化，使你的代碼支持新的功能，或使你的設計盡可能的簡單。從AM的觀點來看，這項實踐可以保證你在編碼時，你的設計干凈、清楚。重構是XP的一個重要部分。
◆測試優先設計 這是一項開發實踐。在你開始編寫你的業務代碼之前，你要先考慮、編寫你的測試案例。從AM的觀點來看，這項實踐強制要求你在寫代碼之前先通盤考慮你的設計，所以你不再需要細節設 計建模了。測試優先設計是XP的一個重要部分。