原型法和敏捷開發

[快速]原型法

就是按照客戶寫的demo。

分類
1. 拋棄型原型 - demo的需求客戶確認後就拋棄。

      a）探索性 - 為了確認需求；

      b）實驗型 - 為了確認規格說明是否可靠。

2. 進化型原型 - 先構造一個功能簡單而且質量bugatti的模型作為核心，然後不斷擴充修改，最後發展為最終系統。

優點：

1. 由於有使用者的直接參與，系統更加貼近實際；

2. 系統開發循序漸進，反覆修改，確保較好的使用者滿意度；

3. 開發週期短，費用相對少；

缺點：

1. 不適合大規模系統的開發；

2. 開發過程管理要求高，整個開發過程要經過“修改—評價—再修改”的多次反覆；

3. 使用者過早看到系統原型，誤認為系統就是這個模樣，易使使用者失去信心；

4. 開發人員易將原型取代系統分析；

5. 缺乏規範化的文件資料

適用範圍：

1. 使用者需求不清，需求經常變化
2. 規模小，不太複雜
3. 使用者介面

、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

敏捷開發的核心思想

•以人為本
     敏捷方法認為，人是軟體開發中最重要的因素。敏捷開發的理念是充分的信任開發團隊能夠很好的完成任務，這是管理的中心主題。

•適應變化
     傳統的軟體開發強調的是，足夠清晰的需求，制定詳細的文件，按照預定的計劃逐一進行開發、測試。這樣的方式在制定好計劃之後拒絕變化，無法應對客戶對需求的實時更改，後續的維護必將會付出巨大的代價。
     而敏捷方法則是以最簡的方式來迎接變化，客戶在整個開發過程中都是參與者，開發團隊能夠在最短的時間內得到客戶的反饋，不斷適應需求的變更，從而使得最終的產品能夠充分的符合客戶的要求。

、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

敏捷開發 - XP極限程式設計

極限程式設計（eXtreme Programming）。

“Extreme”（極限）是指，對比傳統的專案開發方式，XP強調把它列出的每個方法和思想做到極限、做到最好；其它XP所不提倡的，則一概忽略（如開發前期的整體設計等）。極限程式設計強調程式設計團隊與業務專家之間的緊密協作、面對面的溝通（比書面的文件更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好的適應需求變化的程式碼編寫和團隊組織方法，更注重軟體開發中人的作用。

核心價值觀
•溝通（Communication）
     開發人員和設計人員、設計人員和客戶的溝通。
•簡單（Simplicity）
     開發前期的整體設計、相容等直接忽略，專注於最小化解決方案。
•反饋（Feedback）
     儘快獲得使用者的反饋。
•勇氣（Courage）
     擁抱變化。

12個實踐原則
•規劃策略
     以業務優先順序和技術估計為基礎，決定下一版本釋出的範圍。
•結對程式設計
     結對者是全職合作者，輪流執行鍵入和監視；這提供了持續的設計和程式碼評審。
•測試先行
     在編碼開始之前，首先將測試寫好，而後再進行編碼，直至所有的測試都得以通過。
•重構
     改進軟體的設計，重構幫助重新組織程式碼，重新清晰地體現結構和進一步改進設計。
•簡單設計
     系統應設計得儘可能簡單。
•程式碼集體所有權
     程式碼集體所有權強調的是整個團隊，而非個人。
•持續整合
   持續整合的思想是任何時候只有一項任務完成，就整合新程式碼，構造系統並測試。
•現場客戶
     客戶是Team成員，在開發現場和開發人員一起工作。
•小型釋出
     可以保證頻繁地反饋和交流，保證客戶有足夠的依據調控開發過程，降低開發風險。 
•每週40小時工作制
    XP要求專案團隊人員每週工作時間不能超過40小時，否則反而會影響生產率。
•編碼規範
     編碼規範代替不必要的文件。型別包括：格式、程式碼結構、命名約定、錯誤處理、註釋。 
•系統隱喻
     系統隱喻是將整個系統聯絡起來的全域性檢視，每個迭代的隱喻都會演化擴充套件。


適用範圍
XP適合規模小、進度緊、需求變化大、質量要求嚴的專案。它希望以最高的效率和質量來解決使用者目前的問題，以最大的靈活性和最小的 代價來滿足使用者未來的需求，XP在平衡短期和長期利益之間做了巧妙的選擇。

、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

敏捷開發 - FDD特徵驅動開發

8個實踐原則
·領域物件建模
構造類圖。系統設計提供了一種整體框架，把物件分解為類，使得系統可以按照特徵迭代增量地進行開發。
·按照特徵開發
使用者眼中最小的、有用的功能進行開發並跟蹤過程。 
·類（程式碼）擁有權
每一個類都有一個指定的人/角色負責類程式碼的一致性、效能和概念的完整性。
·特徵小組
特徵分配給一個確定的開發者，一個特徵的實現會涉及到多個類及其所有者，因此，特徵的所有者（特徵組長）需要協調多個開發人員的工作。特徵小組與開發小組類似。但有一個重要的區別：特徵小組的組長更像是教練而不是超級程式設計師。
·審查
檢查軟體錯誤的複審方法，這是FDD確保軟體設計和程式碼質量的一個關鍵技術。
·定期構建
定期地取出已完成功能的程式碼，組成完整的可以執行的系統。可以使客戶觀察到系統開發的進度和實現的功能是否是需要的。
·配置管理
最新版本的確認和歷史追蹤。
·可視性進度報告
專案成員應該根據完成的工作向各級管理報告工作進度。

XP極限模式和FDD驅動模式的區別

·隱寓和模型
XP是隱喻，即每個人（設計人員，開發人員、客戶）都能講出系統如何工作的。
FDD是模型，一個全面的領域物件模型，以便特徵小組對每一組特徵產生更好的設計。
·開發團隊
XP通常不超過10人；FDD的理想團隊成員數在16~20人。
·程式碼擁有權
XP任何人都擁有程式碼，任何人都可以在需要時新增或修改程式碼。
FDD整個開發團隊擁有程式碼，類所有者與特徵小組修改。
·審查
XP利用雙人結對程式設計來不斷地在設計和程式碼層執行走查和非形式化審查。
FDD則提倡採用結構化的形式化審查技術。
·測試
XP中的正確性是由執行單元和功能測試來定義的。
FDD中單元測試是“按照功能構建”過程的一個部分，由主程式設計師決定做什麼更適合。
·專案追蹤
XP讓專案經理決定專案追蹤方法，鼓勵減少資料蒐集的工作量，鼓勵使用大型圖表。
FDD中的按特徵追蹤專案的方法，描述了工作量小、準確度量專案進度的手段，提供進度圖表。

、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

敏捷開發 - Crystal水晶方法

透明水晶方法，適合於一個小團隊來進行敏捷開發，人數在6人以下為宜。

七大體系特徵
·經常交付
  專案主辦者根據團隊的工作進展獲得重要反饋；使用者有機會發現他們原來的需求是否是他們真正想要的，也有機會將觀察結果反饋到開發當中。
·反思改進
  如果我們能夠經常在迭代會中及時的反思和改進，技術難題應該是不會發生的，或者說發生了，也能夠很快的找到解決方案去應對它。
·滲透式交流
  若其中一名成員提出問題，工作室內的其他成員可以選擇關注或不關注的態度，可以加入到這個問題的討論當中來，也可以繼續忙自己的工作。
·個人安全
  個人安全指的是當您指出困擾您的問題時，您不用擔心受到報復。個人安全非常重要，有了它，團隊可以發現和改正自身的缺點。沒有它，團隊成員們知而不言，缺點則愈發嚴重以致於損害整個團隊。個人安全是邁向信任的第一步。有了信任，團隊協作才能真正的實施，開發效率也就會直線上升的。
·焦點
  所謂“焦點”，就是確定首先要做什麼，然後安排時間，以平和的心態開展工作。
·與專家使用者建立方便的聯絡
  與專家使用者持續建立方便的聯絡能夠給團隊提供：對經常交付進行配置以及測試的地方，關於成品質量的快速反饋，關於設計理念的快速反饋，最新的（使用者）需求。
·配有自動測試（auto-test）、配置管理（git）和經常整合功能的技術環境（git）
  自動測試：程式碼修改後自動測試，並反饋結果。提高效率。
  配置管理：提交的程式碼可選擇某個節點發布和還原。
  經常整合：開發人員可以一天多次合入本地版本到伺服器版本，加快發現錯誤。

、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

敏捷開發 - RUP統一軟體開發過程

RUP（Rational Unified Process），統一軟體開發過程，統一軟體過程)是一個面向物件且基於網路的程式開發方法論。根據Rational的說法，RUP就好像一個線上的指導者，他可以為所有方面和層次的程式開發提供指導方針、模板以及事例支援。
六個特點
·迭代式開發
迭代式開發允許在每次迭代過程中需求可能有變化，通過不斷細化來加深對問題的理解。
·管理需求
確定系統的需求是一個連續的過程，開發人員在開發系統之前不可能完全詳細的說明一個系統的真正需求。RUP描述瞭如何提取、組織系統的功能和約束條件並將其文件化，用例和指令碼的使用以證明是捕獲功能性需求的有效方法。
·基於元件的體系結構
元件使重用性成為可能，系統可以由元件組成。基於獨立的、可替換的、模組化元件的體系結構有助於管理複雜性，提高重用率。RUP描述瞭如何設計一個有彈性的、能適應變化的、易於理解的、有助於重用的軟體體系結構。
·視覺化建模
RUP往往和UML聯絡在一起，對軟體系統建立視覺化模型，幫助人們提供管理軟體複雜性的能力。RUP告訴我們如何視覺化地對軟體系統建模，獲取有關體系結構和元件的結構和行為資訊。
·驗證軟體質量
在RUP中軟體質量評估是內建於過程中的所有活動，這樣可以及早發現軟體中的缺陷。
·控制軟體變更
RUP通過軟體開發過程中的製造出的產品，隔離來自其他工作空間的變更，以此為每個開發人員建立安全的工作空間。迭代式開發中如果沒有嚴格的控制和協調，整個軟體開發過程很快就陷入混亂之中，RUP描述瞭如何控制、跟蹤、監控、修改以確保成功的迭代開發。

、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

敏捷開發 - SCRUM迭代式增量軟體開發過程

Scrum是一種靈活的軟體管理過程，它可以幫助駕馭迭代、遞增的軟體開發過程，主要用於產品開發或工作管理。

Sprint（迭代）
    Scrum的專案過程由一系列的Sprint組成
    Sprint的長度一般控制在2~4周
    通過固定的週期保持良好的節奏
    產品的設計、開發、測試都在Sprint期間完成
    Sprint結束時交付可以工作的軟體
    在Sprint過程中不允許發生變更

敏捷方法之極限程式設計(XP)和 Scrum區別
區別之一： 迭代長度的不同
XP的一個Sprint的迭代長度大致為1~2周；
Scrum的迭代長度一般為 2~ 4周。
區別之二: 在迭代中, 是否允許修改需求
XP在一個迭代中，如果一個User Story(使用者素材, 也就是一個需求)還沒有實現， 則可以考慮用另外的需求將其替換， 替換的原則是需求實現的時間量是相等的。
Scrum是不允許這樣做的，一旦迭代開工會完畢, 任何需求都不允許新增進來，並有Scrum Master嚴格把關，不允許開發團隊受到干擾。
區別之三: 在迭代中，User Story是否嚴格按照優先級別來實現
XP是務必要遵守優先級別的。
但Scrum在這點做得很靈活，可以不按照優先級別來做。Scrum這樣處理的理由是：(1)如果優先問題的解決者，由於其它事情耽擱，那麼整個進度就耽誤了。(2)如果按優先順序排序的User Story #6和#10，雖然#6優先順序高，但是如果#6的實現要依賴於#10，則不得不優先做#10。
區別之四:軟體的實施過程中，是否採用嚴格的工程方法，保證進度或者質量
Scrum沒有對軟體的整個實施過程開出工程實踐的處方，要求開發者自覺保證。
XP對整個流程方法定義非常嚴格，規定需要採用TDD、自動測試、結對程式設計、簡單設計、重構等約束團隊的行為。

參考連結：

原型法

敏捷開發