軟體專案管理 3.5.敏捷生存期模型
軟體專案管理 3.5.敏捷生存期模型
【公眾號 「專案管理研究所」 將會第一時間更新文章】
歸檔於軟體專案管理初級學習路線
第三章 生存期模型
《初級學習路線合集 》
前言
大家好，這節我們學習敏捷模型，前面介紹的幾種生存期模型在實際應用過程中遇到的一些挑戰，有時不能很好地適應需求的快速變化，為此軟體界比較流行敏捷生命期模型。
一、敏捷模型
《敏捷宣言》價值觀，原則，和通用實踐之間的關係：
敏捷模型符合敏捷宣言，並通過滿足12個原則和實踐體現出來的，敏捷模型結合了迭代和增量方法可以適應更頻繁的變更和更頻繁的交付。
敏捷與傳統模型的區別：
1.傳統軟體開發更傾向於不考慮專案後期需求的變化，在專案開始時預測使用者的需求然後分析需求，制定相應的開發計劃，再按照計劃執行。而計劃與實際間會存在一定的差距。
2.與之形成鮮明對比的的是敏捷軟體開發過程，他是不斷地進行反饋，動態調整需求，最終達成目標，這種自適應性的特徵使得敏捷開發的產品更符合實際的需求。
敏捷的工作模型：
專案需求來自於待開發的功能列表，初始需求可以很粗，但是要有優先順序，每個迭代是按照優先順序來進行，從中選擇部分內容進行迭代。
每個迭代1-4周左右，迭代完成就提交一個可交付的執行成果，然後進行評審，反饋進行下一個迭代。
二、敏捷方法
敏捷模型也在不斷地發展過程中，從經典的Scrum模型到XP極限程式設計發展到持續的交付，以至於到全程敏捷的Devops模型，下面對這幾個模型，方法進行說明：
三、Scrum模型
Scrum模型是敏捷模型的代表，1990年代初，肯·施瓦伯在其公司使用了一種方法
Advanced Development Methods（先進開發方法），這種方法後來發展為Scrum。
這個圖是展示Scrum模型，可以分三個部分分來說明：
1.兩層的專案規劃：
體現為遠期的計劃和近期的計劃，基於遠粗近細的原則，遠期計劃和近期計劃通過產品訂單和衝刺訂單來體現，產品訂單是所有需求的唯一來源，所有的工作都來自於他，開始階段是比較模糊的，隨著時間的推移越來越明確。
最高的優先順序需求就是衝刺訂單，是當前迭代要完成的任務清單。
2.迭代式的軟體開發過程：通過將整個軟體交付的過程分為多個迭代週期，一個週期就是一個Sprint。
每個迭代的週期2-4周，迭代內任務有詳細的分解估算，可以分解到小時。迭代結束時提交一個執行版本。
3.四個管理會議：包括迭代規劃會議，每日站立會議，迭代評審會議，迭代回顧會議。
迭代回顧會議是在每個迭代開始前進行的，要確定任務的目標，理清迭代的需求版本。
每日站立會議是每個迭代的過程當中，每天站著開會，說明昨天做了什麼，今天準備做什麼，有什麼風險。
迭代評審會議是每個迭代結束的時候，團隊都會召開迭代複審會議，展示本迭代的執行版本，既得到反饋資訊，同時決定下一次迭代的內容。
迭代回顧會議是每個迭代完成後，要進行迭代回顧會議，為了持續的過程改進。
四、XP極限程式設計模型
XP(eXtreme Programming)極限程式設計是由Kent Beck提出的一套針對業務需求和軟體開發實踐的規則。
XP由價值觀、原則、實踐和行為四個部分組成，它們彼此相互依賴、關聯， 並通過行為貫穿於整個生命期。
四大價值觀：溝通（Communication）、簡單（Simplicity）、反饋（Feedback）、勇氣（Courage）
五大原則：快速反饋、簡單性假設、逐步修改、提倡更改、優質工作。
極限程式設計13個最佳實踐是通過整體實踐，開發團隊實踐，開發者實踐三個層面來體現。
四個整體實踐：
1.完整團隊（Whole Team）：團隊當中包括客戶，程式設計師，測試員，分析員還有一個上層的經理等等，那麼每個角色是平等的。
2.計劃博弈 ( Planning Game )：體現主要兩個主要計劃，釋出計劃和迭代計劃。
3.小型釋出 ( Small Release )：如果有可能，每天都要釋出一個小版本。
4.現場客戶( Customer Tests)：客戶對每一個需求都定義了一些驗收測試，通過執行驗收測試，開發人員和客戶可以知道開發出來的軟體是否符合需求。
五個開發團隊實踐：
1.集體所有（Collective Ownership）：團隊中的每個成員都擁有對程式碼進行改進的權利，每個人都擁有全部程式碼，也都需要對全部程式碼負責。同時，XP強調程式碼是誰破壞的，就應該由誰來修復。
2.程式碼規範 ( Code Standards )：開發團隊應該擁有一個編碼標準。
3.平穩工作 ( Sustainable Pace )：加班最終會扼殺團隊的積極性，最終導致專案失敗，每週工作40小時是一種順勢行為，是一種規律。
4.系統隱喻 ( System Metaphor )：尋求共識，發明共用詞彙，描述體系結構。隱喻是設計和溝通的輔助手段，使專案成員對於系統的實現方式達成共識。
5.持續整合 ( Continuous Integration )：開發人員堅持隨時進行提交，系統每天一次整合。
四個開發者實踐：
1.簡單設計 ( Simple Design )：用最簡單的方法來實現小的需求，那麼這些設計只要能滿足當下的需求就可以了，而且所有的這些設計都將在後續的開發中被不斷地重整和優化。
2.結對程式設計 ( Pair Programming )：系統的任何一個部分都肯定至少有2個人以上熟悉，好處是程式碼會被100%review，有效地降低程式碼缺陷率。
3.測試驅動開發 ( Test-driven Development)：極限程式設計將測試結合到開發過程中，每次結合程式碼都應該執行一遍所有的測試。
4.程式碼重構 ( Refactoring ) ：時刻對程式碼進行重構，一直保持其良好的結構與可延伸性。集體檢查也是很重要的。
精益（Lean）模型
精益最初是來自於豐田公司的製造工業，其主要的思想是分析所有的流程，刪除沒有必要的流程，不斷提高效率。精益模式提倡持續不斷地改進，減少流程中的浪費。
對於軟體開發而言從開發者和終端使用者的視角來檢查軟體開發過程，消除不利於快速交付的行為，形成精益的軟體開發，這就是精益模型的思路。
持續交付
持續交付是經典的敏捷軟體開發方法的自然延續，能夠以較短的週期完成需求的小顆粒度的頻繁交付。
頻繁的交付週期帶來更迅速的對軟體的反饋，並且在這個過程中，需求分析，設計，測試，開發，運維等角色可以密切的共同作業。
那麼持續交付包括持續整合，持續部署，持續交付。
持續整合是將個人程式碼向整體進行交付，以便更早發現開人開發出現的問題。
持續部署是整合的程式碼儘快向可執行的環境來交付，以便儘早的測試。
持續交付是儘快向客戶交付，以便儘早發現生產環境中存在的問題。
DevOps
那麼由持續交付演變成的DevOps既Development and Operations，他是開發端和運維端一個全程敏捷思維。
開發和運維原本有著不同的目標，那麼開發人員希望儘快提交產品，運維端希望產品的更合理化，高效能高可靠性，減少運維成本。
開發人員與運維人員目標上的差異就叫混亂之想。DevOps融合開發和維護形成了一個統一的敏捷過程，意在幫助那些人員向著一個共同的目標努力。
DevOps是一種方法論，是一組過程，方法與系統的統稱，用於促進開發，技術運營和質量保障（QA）部門之間的溝通，共同作業與整合。
DevOps的工具是多種多樣的，甚至可以由多種工具組成一個DevOps的工具鏈。
總結
總之 無論是最經典的Scrum還是XP模型，還是精益，持續交付，以至於devops等敏捷模型，可以通過一些敏捷實踐靈活應對變更，快速的交付產品。
到這裡，第三章 生存期模型就講解完畢！希望大家對生存期模型有一個全面的認識~
如果您覺得這篇文章有幫助到您的的話不妨點贊支援一下喲~~