軟體開發概述--敏捷模式

標籤：

軟體開發生命週期

SDLC--Software Development Life Cycle.

傳統的軟體開發生命週期有：

　　瀑布模型：順序進行，只有完成上一個階段才能開啟下一個階段，將軟體生命週期分為：制定計劃、需求分析、軟體設計、編寫程式、軟體測試及運行維護六個基本活動。優點是為項目提供了按階段劃分的檢查點及關注點，必須為其提供模板來使分析、設計、編碼、測試、支援有一個共同的指導。缺點是各個階段劃分固定，其間產生大量文檔，極大地增加了工作量，使用者只有等到整個過程的末期才能看到開發成果，增加了開發風險，不適應使用者需求的變化。
　　原型模型：建立樣品，逐步求精，又稱為樣品模型，借用已有系統或構建樣品作為原型模型，通過對樣品的改進滿足客戶的需求。其優點是可以讓開發和使用者在原型上達成一致，減少設計中的錯誤和開發中的風險，縮短開發週期，降低成本。缺點是客戶與開發人員對原型的理解有差異不適合準確的原型設計，也限制了開發人員的創新。
　　螺旋模型：一般系統級應用使用螺旋模型，其引入了風險分析。它是一種演化軟體開發過程模型，兼顧了原型模型的迭代和瀑布模型的系統化及嚴格監控。優點是設計上的靈活性更易於適應客戶的需求變化，客戶有效互動保證了項目的正確方向及可控性。缺點是需要具備相當豐富的風險評估經驗及專門的知識，而過多的迭代會增加開發成本，延遲交付時間。

敏捷開發

敏捷開發以使用者的需求進化為核心，持續迭代的方式進行開發。軟體項目在構建初期切分成多個子項目，各個子項目的成果經過測試均具備可視、可整合和可運行使用的特徵。敏捷的目標是提高開發效率和響應能力。

敏捷開發模型：

敏捷宣言：

　　個體互動高於流程和工具
　　可工作軟體高於理解文檔
　　客戶協作高於合約協商
　　響應變化高於遵循計劃

敏捷原則：　　

　　通過早期和連續型的高價值工作交付滿足“客戶”。
　　大工作分成可以迅速完成的較小組成部門。
　　識別最好的工作是從自我組織的團隊中出現的，
　　為積極員工提供他們需要的環境和支援，並相信他們可以完成工作。
　　建立可以改善可持續工作的流程。
　　維持完整工作的不變的步調。
　　歡迎改變的需求，即時是在項目後期。
　　在項目期間每天與項目團隊和業務所有者開會。
　　在定期修正期，讓團隊反映如何能高效，然後進行相應地行為調整。
　　通過完車的工作量計量工作進度。
　　不斷地追求完善。
　　利用調整獲得競爭優勢。

敏捷名詞一覽：

　　Scrum: 橄欖球運動的一個專業術語，表示"爭球"的動作，把一個開發流程的名字取名為Scrum，意味著大家要像打橄欖球一樣迅速、富有戰鬥激情、高效的工作。　　
　　Scrum Team: Team Dev，主要負責軟體產品在Scrum規定流程下進行開發工作，人數控制在5~10人左右，每個成員可能負責不同的技術方面，但要求每個成員必須有很強的自我管理能力，同時具有一定的表達能力，成員可以採用任何工作方式，只要能達到Sprint目標。
　　Product Owner: 產品負責人，主要負責確定產品的功能和達到要求的標準，指定軟體的發布日期和交付的內容，同時有權力接受或拒絕Team Dev的工作成果
　　Scrum Master: 流程管理員，主要負責整個Scrum流程在項目中的順利實施和進行，以及清除擋在客戶和開發之間的溝通障礙，使得客戶可以直接驅動開發
　　Sprint burn-down chart：Sprint燃盡圖 (burndown chart)，它顯示了Sprint中累積剩餘的工作量，它是一個反映工作量完成狀況的趨勢圖。
　　Product backlog list：產品待辦列表，指一個產品或項目期望的、排列好優先順序的功能列表。
　　Sprint backlog list：Sprint待辦列表，Sprint任務清單，從Product backlog list中拉取出來的一部分。
　　Sprint：短距離賽跑的意思，這裡指一次迭代，周期為2周到1個月時間，即，我們把一次迭代的開發內容以最快的速度完成的過程稱為Sprint。
　　User story：使用者故事，從使用者的角度來描述使用者渴望得到的功能。

敏捷實踐

TDD--測試驅動開發：Test Drive Development,即從測試的角度來檢驗整個項目。其原理是在開發功能代碼之前，先編寫單元測試用例代碼，測試代碼確定需要編寫什麼產品代碼。其基本思路是通過測試來推動整個開發的進行，它是將需求分析、設計、品質控制量化的過程。TDD過程：明確需要完成的功能，針對該功能編寫測試案例，編譯不通過的測試代碼，編寫相應的功能代碼，執行測試代碼直到測試通過，對代碼進行重構並保證測試通過，迴圈完成所有功能的開發。即 不可運行---可運行---重構。TDD原則：獨立測試、測試清單、測試驅動、先寫斷言、可測試性、及時重構、小步前進。

BDD--行為驅動開發：Behavior Drive Development, 是對TDD的一種補充，或者說是TDD的一個分支，與測試概念相比，行為是一種更自然的開發驅動因素，考慮行為會自然而然地促使你先編寫規範類，成為一個非常有效實現驅動因素。測試驅動開發讓我們明白測試先行的道理，但是並沒有明確告訴我們測試什麼，你寫出一個測試，但它們不會告訴你應該發生什麼也不會告訴你實際預期是什麼，它不清楚需求到底是什麼。而行為驅動開發旨在協助開發人員確定應該測試什麼。而且行為驅動開發提供了一種通用語言來避免客戶與開發之間的不一致，從而實現設計與測試相結合來開發產品。

結對程式設計：兩個程式員在一個電腦上共同工作，一個人輸入代碼，另一個人審查他輸入的每一行代碼。優點是程式員互幫互助，可以得到能力上的互補且讓編程環境有效貫徹設計及增強代碼和產品品質，並有效減少bug，在編程中互相討論可能更快更有效地解決問題。缺點也很明顯，編程人員習慣不同引起的麻煩，或對一個問題爭吵不休，若交談內容與工作無關，反而分散注意力導致效率低下等等。

代碼重構：對軟體代碼做任何更動以增加可讀性或簡化結構而不影響輸出結果。重構的目的是：持久性改進設計，協助發現隱藏的代碼缺陷，提高編程效率。一般重構方法有：封裝成員變數，提取方法，一般化類型，方法重新命名等。

軟體開發概述--敏捷模式