軟體開發-敏捷方法論

2001年在軟體工程界首次出現“敏捷”這個名詞，17個過程方法學家舉行了一個討論會。發現他們的“輕量級”的方法有很多共同的地方，因此一致同意把這些方法統稱為“敏捷”的方法。並且成立了個叫敏捷聯盟的組織，還定下了所謂的“敏捷宣言”。從此，越來越多的人瞭解到敏捷方法。

敏捷方法有一些共同的特徵。其中有兩個最主要的特徵是：輕量和簡單。敏捷方法論包含最少的流程和文件，減少正式性。目的是做眼前能做的事情，而不去預測太遠的未來，首先完成緊迫的事情。快速的、增量的開發能更快地交付客戶使用，更快得到反饋。開發方法要稱之為敏捷，需要具備4個基本特徵：增量的、協作的、直接的、適應性強的。

1.SCRUM(橄欖球裡的爭球)方法論
關鍵詞：30天迭代粒度，每日站立會議，進度透明，客戶參與

Scrum是一種迭代式增量軟體開發過程，通常用於敏捷軟體開發。Scrum在英語的意思是橄欖球裡的爭球。雖然Scrum是為管理軟體開發專案而開發的，它同樣可以用於執行軟體維護團隊，或者作為計劃管理方法。在SCRUM方法論中其核心仍然迭代和增量，首先對於產品需求會劃分為多個迭代或增量，每個迭代都需要在1個月能夠交付，而一個月即是一次衝刺，而一個迭代版本又需要轉化到每天的進度跟蹤和問題解決，這就是每天的15分鐘會議(每日站立會議)，在會議上必須回答當天的進度，明天的計劃和是否存在問題。

Scrum是一個包括了一系列實踐和預定義角色的過程骨架。Scrum中的主要角色包括同專案經理類似的Scrum主管角色負責維護過程和任務，產品負責人代表利益所有者，開發團隊包括了所有開發人員。管理Scrum過程有很多實施方法，從白板上的即時貼到軟體包。Scrum最大的好處是它非常容易學習，而且應用Scrum不需要太多的投入。

每一個衝刺完成後，都會舉行一次衝刺回顧會議，在會議上所有團隊成員都要反思這個衝刺。舉行衝刺回顧會議是為了進行持續過程改進。會議的時間限制在4小時。Scrum提倡所有團隊成員坐在一起工作，進行口頭交流，以及強調專案有關的規範（disciplines），這些有助於創造自我組織的團隊。

Scrum的一個關鍵原則是承認客戶可以在專案過程中改變主意，變更他們的需求，而預測式和計劃式的方法並不能輕易地解決這種不可預見的需求變化。同樣，Scrum採用了經驗方法– 承認問題無法完全理解或定義，而是關注於如何使得開發團隊快速推出和響應不斷出現的需求的能力最大化。其實踐主要包括:

• 客戶成為開發團隊中的一部分。 (例如客戶肯定對開發的結果真正感興趣。)
• 頻繁的包含可以工作的功能的中間可交付成果。
• 頻繁的風險和緩解計劃是由開發團隊自己制定。
• 計劃和模組開發的透明 – 讓每一個人知道誰負責什麼，以及什麼時候完成。
• 頻繁的利益所有人會議，以跟蹤專案進展
• 平衡的 (釋出，客戶，員工，過程) 儀表板更新 – 擁有預警機制提前瞭解可能的延遲或偏差。
• 沒有問題會被藏在地毯下。認識到或說出任何沒有預見到的問題並不會受到懲罰。
• 在工作場所和工作時間內必須全身心投入。– 完成更多的工作並不意味著需要工作更長時間。

2.FDD(Feature-Driven Development)-特徵驅動開發
關鍵詞：Feature，客戶價值，兩週迭代粒度，Domain Model

Feature-Driven本質上還是Model Driven，是先規劃出整套的Domain Model，做為系統起始的核心。 接下來就是依據Model，開始找出所有的Feature。而Feature = 可以為客戶產生價值的最小開發單位。群集後的Feature稱之為Feature Set。而系統的某一個主題領域就是組合了很多Feature Set。接下來，專案經理就是依據Feature來規畫開發的週期，書上建議每次的週期是兩週，所以每個Feature必然不可以超過兩週，會超過兩週的Feature必須再予以細分。所謂兩週內的工作，包含為這個Feature設計、開發、測試、佈置。所謂兩週內的工作，包含為這個Feature設計、開發、測試、佈置。

在RUP中強調的是用例驅動，通過用例進行需求的分析和建模，再過渡到架構設計和後續的開發中。而在FDD中強調特徵驅動，特徵是比用例更加小的粒度單位，而且特徵更加能夠體現客戶價值。在傳統的瀑布模型中我們往往在後續編碼完成後才能夠看到交付的功能，而FDD本身也是一種迭代的思路，只是迭代的單位是Feature，而這些Feature將貫徹從需求到編碼測試的全過程，只到每個功能都能夠滿足一個客戶價值的實現。因此通過特徵和特徵集將傳統的瀑布方法進行了橫切，一切軟體開發活動包括專案計劃都是以特徵為單位和特徵驅動。在FDD中主要包括5步流程，具體如下：

• Develop an Overall Model (開發一個主域模型)
• Build a Features List (通過主域模型分解特徵集合)
• Plan By Feature (根據特徵制定專案計劃和編排進度)
• Design By Feature (根據特徵進行設計,開始迭代)
• Build By Feature (根據特徵進行編碼，測試和構建)

3.DSDM-動態系統開發方法，也稱業務中心框架開發方法
關鍵詞：業務為中心 使用者參與 迭代 快速交付 團隊協作和溝通



DSDM（動態系統開發方法，也稱業務中心框架開發方法）是眾多敏捷開發方法中的一種，它倡導以業務為核心，快速而有效的進行系統開發。我們可以把DSDM看成一種控制框架，重點在於快速交付、並補充如何應用這些控制的指導原則的框架。

DSDM是一整套的方法論，不僅僅包括軟體開發內容和實踐，也包括了組織結構，專案管理，估算，工具環境，測試，配置管理，風險管理，重用等各個方面的內容。

DSDM 的基本觀點是，任何事情都不可能一次性的圓滿完成，應該用20%的時間完成80%的有用功能，以適合商業目的為準。實施的思路是，在時間進度和可用資源預先固定的情況下，力爭的最大化滿足業務需求（傳統方法一般是需求固定，時間和資源可變），交付所需要的系統。對於交付的系統，必須達到足夠的穩定程度以在實際環境中執行；對於業務方面的某些緊急需求，也要求能夠在短時間內得到滿足，然後在以後迭代階段中對功能進行進一步完善。對於DSDM主要包括以下9條基本原則:

• 使用者必須持續參與
• 必須授予DSDM團隊制定決策的權力
• 注重產品的經常交付
• 滿足業務用途是接受交付品的主要依據
• 迭代和增量式開發對得到正確的業務解決方案是必不可少的
• 開發過程中的所有變化可逆
• 在高層次上制定需求的基線
• 測試自始自終貫穿於開發週期之中
• 所有專案涉眾間的通力合作是不可或缺的

4.Crystal Methods-水晶方法族
關鍵詞：協作 角色 文件 迭代 風險管理

水晶方法論由Alistair Cockburn在20實際90年代末提出。之所以是個系列，是因為他相信不同型別的專案需要不同的方法。雖然水晶系列不如XP那樣的產出效率，但會有更多的人能夠接受並遵循它。

水晶方法把開發看作是一系列的協作遊戲，而寫文件的目標就是隻要能幫助團隊在下一個遊戲中取得勝利就行了。水晶方法的工作產品包括用例、風險列表、迭代計劃、核心領域模型，以及記錄了一些選擇結果的設計註釋。水晶方法也為這些產品定義了相應的角色。然而，值得注意的是，這些文件沒有模板，描述也可不拘小節，但其目標一定要清晰，那就是滿足下次遊戲就可以了。我總是將這些思想以下面的方式向我的團隊成員表達：通過它們，你只要瞭解你明天加入這個團隊所要知道的內容就行了。

對於水晶方法論，根據方法論的輕重可以分為透明水晶和橙色水晶等。透明水晶一般是輕量級的團隊適用。不管是哪種水晶，都會對團隊的角色，團隊的工件和產出，核心實踐，支援過程等進行定義。

5. XP（極限程式設計）
關鍵詞：UserStory 測試驅動 結對程式設計 持續整合 重構 小版本釋出 溝通


ExtremeProgramming（極限程式設計，簡稱XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期與 WardCunningham共事時，就一直共同探索著新的軟體開發方法，希望能使軟體開發更加簡單而有效。Kent仔細地觀察和分析了各種簡化軟體開發的前提條件、可能行以及面臨的困難。1996年三月，Kent終於在為DaimlerChrysler所做的一個專案中引入了新的軟體開發觀念

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15027599/viewspace-551935/，如需轉載，請註明出處，否則將追究法律責任。