敏捷開發方法學及應用

?

簡介

?

本篇文章是有關敏捷軟件開發方法學及應用的基礎知識。敏捷開發是有關團隊怎么樣合作去實現一個常規目標。敏捷開發并不僅僅適用于軟件開發者，也適用于團隊領導人，項目經理，產品經理，開發經理，測試人員，質量保證經理，質量保證工程師，技術作者，用戶體驗設計者，以及任何與制做發布軟件相關的人員。本文著重于技術團隊怎么很好的合作去計劃，開發并發布軟件。本文不著重于編碼，技術細節或微軟工具。希望本文能改善你的專業生活和團隊效率。

?

背景

下圖是Winston Royce的瀑布式開發模型： （?"Managing the Development of Large Software Systems"，1970 IEE paper）

?

無論項目有多大有多復雜，有兩個關鍵的步驟常用于所有的計算機程序開發：1) 分析 2) 編碼。

接下來，Winston Royce介紹了最重要的五步：

第一步：程序設計

分配任務處理流程，功能，數據庫處理，明確數據庫流程，分配執行時間，明確操作系統間的接口與處理流程模塊，描述輸入與輸出流程，并且明確初步的操作流程。撰寫容易理解的，信息量大的，當前時新的概要文檔。

第二步：撰寫設計文檔

管理軟件開發的第一條規則就是無條件服從的執行文檔需求。

第三步：重復兩次

第二個非常重要的成功標準以產品是否完全原始為重中之重。如果把還有疑問的計算機程序開發為第一版，考慮到嚴格的設計/操作領域，那么給客戶正式部署的版本實際上是第二版本。

第四步：計劃，控制，監控測試

在成本和計劃方面上，這是最有風險的一步。當備選方案幾乎或一點不可用時，它會出現在日程安排的最近時間點上。

第五步：讓客戶參與

讓客戶參與到項目中是非常重要的，因為客戶可能在最終發布之前較早的認可項目工作。 仔細閱讀Royce的文章后發現：

每一階段都應該迭代式地傳遞到下一階段。

軟件發布前對軟件整體流程實踐兩次。

簡單單一的階段傳遞會造成項目失敗。

不幸地是，上面列出的步驟當中，設計迭代從來沒被限制成連續的步驟。 下面這些東西都是什么？ 答案是： 敏捷開發并不意味著只是一種方法。上面雨傘下的術語代表著不同的敏捷開發方法。

敏捷軟件開發宣言

我們一直在實踐中探尋更好的軟件開發方法，身體力行的同時也幫助他人。由此我們建立了如下價值觀：

• 個人與交互?高于?流程和工具
• 可用軟件?高于?詳盡的文檔
• 客戶合作?高于?合同談判
• 響應變化?高于?遵循計劃

也就是說，上面右側（藍色字體）內容有其價值，但我們更重視左側（紅色字體）產生的價值。

敏捷宣言的十二條原則

我們遵循以下原則：

我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。

欣然面對需求變化，即使在開發后期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。

經常地交付可工作的軟件，相隔幾星期或一兩個月，傾向于采取較短的周期。

業務人員和開發人員必須相互合作，項目中的每一天都不例外。

激發個體的斗志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。

不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面的交談。

可工作的軟件是進度的首要度量標準。

敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。

堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。

以簡潔為本，它是極力減少不必要工作量的藝術。

最好的架構、需求和設計出自自組織團隊。

團隊定期地反思如何能提高成效，并依此調整自身的舉止表現。

很多開發者都經過這樣的噩夢：沒有任何實踐可以輔佐的項目。由于缺乏有效的實踐，項目變得不可預測，重復出現錯誤，還有白白浪費的辛苦。計劃延期，超出預算，質量低下使客戶感到失望。開發者也由于更長時間的工作而換來更糟糕的軟件而心灰意冷。

DSDM

DSDM（Dynamic Software Development Method），動態軟件開發方法，通過提供一個負責整體開發周期的框架來彌補RAD(Rapid Application Development)快速程序開發的不足。下面是DSDM的主要功能：

用戶參與

迭代和遞增開發

提高了發布頻率

集成測式于每一階段

已發布產品的可接受程度直接取決于需求的實現

FDD

FDD（Feature Driven Development），功能驅動開發，是一種包裝方法學。它允許你在非常高的級別上應用一個方法來管理項目，但它也允許你在較低的級別上應用其它方法學。FDD的著重點是能夠把估算，日程計劃，項目狀態匯報作為一個整體或放到顆粒級別上，但是FDD不會規定一個非常細節化的方法讓你應用去創建日程計劃，相反FDD讓你去覺決定該用什么方法。FDD的觀點是你可以查看一下你的項目，陳術一下項目的確切狀態，如項目進度是否及時，延時或過早等等。

Lean

Lean思想是一種進行系統優化的途徑，它關注于減少浪費，提高整個系統總體流程。Lean在制造業上有著豐富的歷史，近幾年在在軟件開發行業也越來越流行。Lean來源于制造業中的Lean(Lean Manufacturing:?http://www.mindtools.com/pages/article/newSTR_44.htm)，它是一組為滿足質量，速度和客戶需求而定制的原則。

七大Lean軟件開發原則：

估算浪費

構建質量

創建知識

延遲承諾

快速交付

尊重人

優化整體

軟件產品的交付工作應用這些原則并不是我們的最終目的。我們并不是說讓我們用Lean吧，而是把Lean原則做為決策的向導或參考去選擇可以改善整體系統的技術。比如，TDD測試驅動開發，通過在每一個功能點上創建功能自我測試從而構建軟件的完整性和完善性。

Plan（譯外話：指瀑布式開發Waterfall Development）

在計劃驅動開發中，如果一個項目確切的按照計劃執行，那么它就是成功的。因此，在軟件開發中計劃驅動開發依賴于需求的穩定性，明確性和固定性。你或許知道這些奢侈的性質是在大多數軟件項目中不存在的。 計劃驅動方法學，在初期的設計階段的需求變更中成本花費較低，但是一旦到了開發階段需求變更將會花費昂貴的代價。所以，很多的工作被要求在初期計劃設計階段完成。然而，軟件開發不同于普通的項目，我們不能保證將來的開發階段會完全按照初期的設計進行，無論你的設計有多么出色。 "Walking on water and developing software from a specification are easy if both are frozen."- Edward V. Berard 在水上行走和開發軟件都只有當它們被凍結時才會變得容易。 敏捷開發打破了對需求穩定性的依賴，它有一個專門的流程用于負責需求變化，主要體現在它的自適應計劃和進化式設計。 自適應計劃，意思是多次的仔細檢查整體項目流程，經常會再次制定計劃并再次適應。 進化式設計，有一些實踐對它很有幫助，如自我測試代碼，持續集成，重構，簡易設計等。 敏捷開發是價值驅動，傳統的瀑布式開發是計劃驅動。這并不是說計劃驅動就沒有價值，在特定的實際情況下它們都有各自的有優缺點。關鍵是怎么平衡使用兩種方法，在特定情況下采取它們的長處而回避它們的短處。

Plan VS Agile

計劃驅動開發模式和敏捷驅動開發模式在基本原理差異上有兩大不同。 第一大不同：計劃驅動模型中只能在項目完成時才能部署一個新模塊，而且是較大的模塊。敏捷驅動模型中可以頻繁的部署新模塊，甚至較小的模塊。 第二大不同：計劃驅動是序列化的，敏捷驅動是并發的。在計劃驅動模型中，一個流程的開始必須在前一個流程完全成功結束的前提下進行。在敏捷驅動模型中，任何時候都可能在做計劃，流程是并發的或互相穿插的。 “Plan your work, then work your Plan” by Martin Fowler and Neal Ford 先計劃你的工作，后工作你的計劃。 敏捷開發和計劃驅動開發(瀑布式開發)：

• 都提供了操作流程，操作工具和操作技術。
• 都需要嚴格的有條不紊的方法進行軟件開發。
• 都各自有優缺點。
• 敏捷開發適合的情況，計劃驅動模型不一定適應。
• 敏捷開發強調流程上的不同。
• 計劃驅動模型強調正式的溝通與控制。
• 敏捷開發強調連續的溝通和處理變化的能力
• 計劃驅動模型是關卡式控制質量，敏捷開發是高迭代式開發確保質量。
• 計劃驅動模型僅在產品最終完成后進檢查，敏捷開發每完成一小塊工作就進行檢查。
• 計劃驅動模型以預估什么將被交付為起點，敏捷開發以完成一個需求為目標做為起點

適應變化能力(Y軸) ? ? ? ? ? ? ? ? ? ? ? ? ? ?時間(X軸) 可見性(Y軸) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 時間(X軸) 在敏捷開發中： 客戶滿意度是以迅速，持續的交付可用軟件為導向。
強調人和互動要高于強調流程和工具。 客戶，開發者，還有測試人員一直保持互動。
可用軟件頻繁的被交付使用（按周交付高于按月交付） 面對面交流是最好的溝通形式。
業務人員和開發者保持近距離的，日常的協作。
持續關注出色的技術和設計。
適應易變情況。
需求中較晚的改動也受歡迎。

善于使用計劃驅動模型的管理團隊同樣也能夠善于使用敏捷開發方法。

缺乏能力使用計劃驅動模型的管理團隊也沒有能力使用敏捷開發方法。

敏捷開發Agile

敏捷軟件開發的原理和價值用于幫助團隊打破流程循環膨脹，著重于用簡單的技術去實現目標。目標？什么是目標？

每一個軟件開發者，開發團隊的主要目標是為老板和客戶制造盡可能高的價值。

敏捷開發的核心是把傳統的軟件開發方法(瀑布式開發)的五個步驟壓縮成一個一周的開發周期。用敏捷開發方法去開發一個系統時，項目中會不斷貫穿著重復的周期開發和較小模塊的開發，并在開發過程中允許開發者測試和檢查。高速度，低成本，靈活性是敏捷開發的主要優勢。 敏捷開發發展極為迅速，從2001年的只有1%的開發者使用敏捷開發到現在的60-80%的開發者在使用敏捷開發。更大的吸引力是因為敏捷開發提供：

• 改善的質量
• 在項目過程中有更多的機會做出修改更正
• 提高客戶或商業滿意度
• 使業務和IT更好的組合在一起
• 更優化的面向市場的時間

敏捷開發使用者從來不會害怕變化。他們把需求變化看作是好事，因為這些變化意味著團隊又收獲了更多關于怎樣滿足客戶的經驗。敏捷開發團隊成員一起協作項目的方方面面。每一個成員都允許為項目整體提出意見或做貢獻。沒有一個團隊成員是單一的負責架構或者需求或者測試。團隊分享這些責任，同時每個成員都會對它們產生影響。

我們有很多的敏捷開發流程：Scrum，crystal，BDD(Behavior-Driven Development行為驅動開發)，TDD(Test-Driven Development測試驅動開發)，FDD(Feature-Driven Development功能驅動開發)，ADP(Adaptive Software Development自適應軟件開發)，XP(Extreme Programming極限編程)，等等等等。然而，大量成功的敏捷開發團隊從所有這些方法中吸取經驗與知識，進而調整生成他們自己特有的敏捷開發方式。這些改編后的方法通常與SCRUM還有XP組合在一起，SCRUM實踐用來管理使用極限編程XP的團隊。

極限編程XP

As developers we need to remember that XP is not the only game in town.- Pete McBreen
作為開發者，我們需要記住極限編程并不是城里唯一的游戲。

極限編程強調團隊合作(經理，客戶，開發者)。它從五個關鍵點改善軟件項目：溝通，簡明，反饋，尊重，還有勇氣


維基百科對極限編程的定義：極限編程XP是一種軟件開發方法，它的意圖是提搞軟件質量及對用戶需求變化的響應能力。作為一種敏捷軟件開發方法，它提倡在短開發周期中頻繁地發布，從而提高軟件生產力并提出新客戶需求能夠被采納的檢查點。


極限編程是一系列嵌入到敏捷開發中的簡易并堅實的實踐。極限編程是一個非常好的通用軟件開發方法。許多項目團隊都采用它，同時更多的團隊通過添加或修改實踐來把它變得更適用。

• 它是大多數敏捷開發方法的始祖
• 在90年代末期和21世紀初期，Kent Beck提出了熱門的話題
• 協調流程與實踐

?Kent Beck 的基本觀念:

• 采取已關注過的有效團隊實踐
• 迫使它們走向極端

“迫使它們走向極端”是什么意思呢？是不是如下圖一樣？ 或者下圖 不，這不是極限編程。讓我們看看它的真正意思： 出色的實踐? ? ??迫使它走向極端

代碼復查	結對編程
測試	TDD測試驅動開發和常數回歸
軟件設計	不停地重構
簡單	最簡單的事會有意想不到的效果
集成測試	不斷的集成/整合
短迭代	把制定計劃當作游戲

極限編程是一系列遵循敏捷開發原則和價值的實踐。極限編程是離散的方法，而敏捷開發是一類方法。有很多的敏捷開發方法，極限編程只是其中一種。 極限編程在敏捷開發方法中是范圍寬闊，出類拔萃的。Scrum有些類似極限編程，擁有極限編程的大多數特征。但是在細節是它們有很多的不同，公平的說Scrum是是極限編程的子集。甚至，許多Scrum團隊爭論著要把極限編程實踐加入Scrum流程中，如滿意度測試，結對編程，持續集成，以及測試驅動開發。
?

在所有敏捷開發方法當中，極限編程是唯一的一種方法為開發者的日常工作提供深度的，意義深遠的開發準則。在這些準則中，測試驅動開發是最革命性的。下圖中都是一些出色的極限編程實踐。

Scrum

Scrum是和種迭代式及遞增式的敏捷軟件開發框架，它用于管理軟件項目，產品，或程序的開發。它的著重點是一個靈活的，全面的產品開發策略，它把一個開發團隊通常作為一個單位進而實現一個常規目的。相反，它不著重于傳遞的序列化式的方法。Scrum會問傳統瀑布式開發“為什么我們要花費這么長時間，這么多努力去做一件事？為什么我們不能衡量出做一件事所需時間和人力？” Scrum擁抱變化和創造力，因為這是人們的工作方式。Scrum有一個流程學習結構，能夠讓團隊評估他們做了什么以及他們怎樣做的。

• 1986年，Scrum第一次被定義成一個靈活的全面的產品開發策略。--Hirotaka Takeuchi，Ikujiro Nonaka
• 1995年，Sutherland和Schwaber共同地發表了一篇關于Scrum方法學的論文。

Scrum角色

三個核心角色：

產品持有人 Product Owner

開發團隊 Development Team

Scrum領導人 ScrumMaster

產品持有人 Product Owner

• 產品持有人代表著公司或股東的權益并傳遞客戶的聲音。
• 專門負責確保商業價值
• 制定以客戶為中心的一些工作條目，排序后放到產品待處理列表（Product backlog）中。
• Scrum團隊應該有一個產品持有人，他/她也可以是開發團隊中的一員。
• 產品持有人不是Scrum領導者(ScrumMaster)。

開發團隊 Development Team

• 在每一個Sprint周期結束后，負責交付將來需要發布的產品的模塊。
• 由3到9人組成并擁有各種所需技能（分析，設計，開發，測試，技術溝通，文檔，等等）。
• 自我組織，有可能需要與更高級的項目管理部門交流。

Scrum領導人 ScrumMaster

• 專門負責掃清團隊在交付Sprint目標或產品中遇到的障礙。
• 不是團隊領導人，但是扮演著團隊與可能分散團隊注意力的影響之間的緩沖區。
• 確保Scrum流程的使用在計劃中。
• 規則強制執行人。團隊保護者，以保持團隊專注于他們手中的工作。
• 也會被看作一個人民公仆去加強這些雙重觀點。
• 不同于一個項目經理，沒有與ScrumMaster不相關的人員管理職責
• 沒有任何額外的員工責任。

Backlog未完成項列表

產品的待完成項列表是一個需求的排列列表，我們維護這個列表是為了更好的開發產品。它的組成有功能，BUG修復，非功能需求等任何為了成功發布可用軟件系統的所必須的內容。在Scrum中，開始一個項目不必先開發一個冗長文檔去記錄所有的需求。這個敏捷產品backlog對于第一個Sprint足夠了。當有更多產品需求時和客戶需求時，Scrum產品backlog允許變更和增加。

Sprint backlog是開發團隊下個Sprint需要處理的工作列表。這個列表是產品backlog最上面的需求項衍生出來的，直到開發團隊在這個Sprint中有足夠的工作去做。開發團隊通過問一些問題來完成backlog的選擇，如“我們是不是也能做這個？”。

從概念上講，團隊從優先級最高的Scrum backlog開始畫一條線劃分出優先級較低的項，同時線上面的backlog也是團隊認為他們可以完成的項。在實踐中，團隊通常不會去選擇優先級最高的五項再選擇優先級較低的兩項組合在一起即使它們是互相關聯的。

敏捷開發調查

這項調查發起于2012年8月9日至2012年11月1日之間，由VersionOne贊助的。調查從軟件開發社團的不同渠道中選擇了4048人。數據由Analysis.Net Research分析并總結成報告。

誰知道敏捷開發？

一般情況下，相比業務人員，越接近開發團隊角色的人了解敏捷開發的越多

敏捷開發失敗原因

進一步使用敏捷開發的障礙物

使用敏捷開發最大的擔心

總結

一個好的敏捷團隊會選擇最適合他們的管理與技術實踐。當試著去使用敏捷開發時，會有一萬個借口為什么這行不通。只有那些真正理解敏捷開發優勢并真心實意地想要使用敏捷開發的人們才會有可能成功。那些正在搜索為什么Agile會失敗的人們，他們可能最終會找到答案也可能放棄之前所做的一切努力不再使用敏捷開發。Elisabeth Hendrickson稱這種行為“假敏捷開發”。 為了支持一下我的結論，讓我們引用一些名言(從Robert C. Martin收集):
"In preparing for battle I have always found that plans are useless, but planning is indispensable." - General Dwight David Eisenhower? 在戰斗準備中，我總是發現那些計劃是雞肋，但是制定計劃是不可缺少的。

局限于別人的方法世界里不是可取的，因為公司需求，公司情況，項目都有可能一直在變化著。如果你想你的項目成功，你一定要靈活地應用這些現成的方法去管理項目。任何單一的方法都不是一把尚方寶劍，因此關鍵是看哪種方法適合你并能協調你的方法去滿足你的個人需求。

記住，Scrum和Agile不是一個死產品 ，它是在持續改進的基礎上不斷進行中的一門哲學。
翻譯：http://www.codeproject.com/Articles/604417/Agile-software-development-methodologies-and-how-t 同步：http://blog.csdn.net/leewhoee/article/details/17221919

轉載于:https://www.cnblogs.com/Leewhoee/p/Agile-Development_-Methodologies.html

總結

以上是生活随笔為你收集整理的敏捷开发方法学及应用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。