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

軟件開發生命週期

SDLC--Software Development Life Cycle.

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

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

敏捷開發

敏捷開發以用戶的需求進化爲核心，持續迭代的方式進行開發。軟件項目在構建初期切分紅多個子項目，各個子項目的成果通過測試均具有可視、可集成和可運行使用的特徵。敏捷的目標是提升開發效率和響應能力。

敏捷開發模型：

敏捷宣言：

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

敏捷原則：　　

　　經過早期和連續型的高價值工做交付知足「客戶」。
　　大工做分紅能夠迅速完成的較小組成部門。
　　識別最好的工做是從自我組織的團隊中出現的，
　　爲積極員工提供他們須要的環境和支持，並相信他們能夠完成工做。
　　建立能夠改善可持續工做的流程。
　　維持完整工做的不變的步調。
　　歡迎改變的需求，即時是在項目後期。
　　在項目期間天天與項目團隊和業務全部者開會。
　　在按期修正期，讓團隊反映如何能高效，而後進行相應地行爲調整。
　　經過完車的工做量計量工做進度。
　　不斷地追求完善。
　　利用調整得到競爭優點。

敏捷名詞一覽：

　　Scrum: 橄欖球運動的一個專業術語，表示"爭球"的動做，把一個開發流程的名字取名爲Scrum，意味着你們要像打橄欖球同樣迅速、富有戰鬥激情、高效的工做。　　
　　Scrum Team: 開發團隊，主要負責軟件產品在Scrum規定流程下進行開發工做，人數控制在5~10人左右，每一個成員可能負責不一樣的技術方面，但要求每一個成員必須有很強的自我管理能力，同時具備必定的表達能力，成員能夠採用任何工做方式，只要能達到Sprint目標。
　　Product Owner: 產品負責人，主要負責肯定產品的功能和達到要求的標準，指定軟件的發佈日期和交付的內容，同時有權力接受或拒絕開發團隊的工做成果
　　Scrum Master: 流程管理員，主要負責整個Scrum流程在項目中的順利實施和進行，以及清除擋在客戶和開發之間的溝通障礙，使得客戶能夠直接驅動開發
　　Sprint burn-down chart：Sprint燃盡圖，它顯示了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，在編程中互相討論可能更快更有效地解決問題。缺點也很明顯，編程人員習慣不一樣引發的麻煩，或對一個問題爭吵不休，若交談內容與工做無關，反而分散注意力致使效率低下等等。

代碼重構：對軟件代碼作任何更動以增長可讀性或簡化結構而不影響輸出結果。重構的目的是：持續性改進設計，幫助發現隱藏的代碼缺陷，提升編程效率。通常重構方法有：封裝成員變量，提取方法，通常化類型，方法重命名等。