軟件項(xiàng)目管理 3.5.敏捷生存期模型

【公眾號(hào) “項(xiàng)目管理研究所” 將會(huì)第一時(shí)間更新文章】
歸檔于軟件項(xiàng)目管理初級(jí)學(xué)習(xí)路線
第三章 生存期模型
《初級(jí)學(xué)習(xí)路線合集 》

前言

大家好，這節(jié)我們學(xué)習(xí)敏捷模型，前面介紹的幾種生存期模型在實(shí)際應(yīng)用過程中遇到的一些挑戰(zhàn)，有時(shí)不能很好地適應(yīng)需求的快速變化，為此軟件界比較流行敏捷生命期模型。

一、敏捷模型

《敏捷宣言》價(jià)值觀，原則，和通用實(shí)踐之間的關(guān)系：敏捷模型符合敏捷宣言，并通過滿足12個(gè)原則和實(shí)踐體現(xiàn)出來的，敏捷模型結(jié)合了迭代和增量方法可以適應(yīng)更頻繁的變更和更頻繁的交付。

1.傳統(tǒng)軟件開發(fā)更傾向于不考慮項(xiàng)目后期需求的變化，在項(xiàng)目開始時(shí)預(yù)測(cè)用戶的需求然后分析需求，制定相應(yīng)的開發(fā)計(jì)劃，再按照計(jì)劃執(zhí)行。而計(jì)劃與實(shí)際間會(huì)存在一定的差距。

2.與之形成鮮明對(duì)比的的是敏捷軟件開發(fā)過程，他是不斷地進(jìn)行反饋，動(dòng)態(tài)調(diào)整需求，最終達(dá)成目標(biāo)，這種自適應(yīng)性的特征使得敏捷開發(fā)的產(chǎn)品更符合實(shí)際的需求。

敏捷的工作模型：

項(xiàng)目需求來自于待開發(fā)的功能列表，初始需求可以很粗，但是要有優(yōu)先級(jí)，每個(gè)迭代是按照優(yōu)先級(jí)來進(jìn)行，從中選擇部分內(nèi)容進(jìn)行迭代。

每個(gè)迭代1-4周左右，迭代完成就提交一個(gè)可交付的運(yùn)行成果，然后進(jìn)行評(píng)審，反饋進(jìn)行下一個(gè)迭代。

二、敏捷方法

三、Scrum模型

Scrum模型是敏捷模型的代表，1990年代初，肯·施瓦伯在其公司使用了一種方法Advanced Development Methods（先進(jìn)開發(fā)方法），這種方法后來發(fā)展為Scrum。

這個(gè)圖是展示Scrum模型，可以分三個(gè)部分分來說明：

最高的優(yōu)先級(jí)需求就是沖刺訂單，是當(dāng)前迭代要完成的任務(wù)清單。

2.迭代式的軟件開發(fā)過程：通過將整個(gè)軟件交付的過程分為多個(gè)迭代周期，一個(gè)周期就是一個(gè)Sprint。

每個(gè)迭代的周期2-4周，迭代內(nèi)任務(wù)有詳細(xì)的分解估算，可以分解到小時(shí)。迭代結(jié)束時(shí)提交一個(gè)運(yùn)行版本。

3.四個(gè)管理會(huì)議：包括迭代規(guī)劃會(huì)議，每日站立會(huì)議，迭代評(píng)審會(huì)議，迭代回顧會(huì)議。

迭代回顧會(huì)議是在每個(gè)迭代開始前進(jìn)行的，要確定任務(wù)的目標(biāo)，理清迭代的需求版本。

每日站立會(huì)議是每個(gè)迭代的過程當(dāng)中，每天站著開會(huì)，說明昨天做了什么，今天準(zhǔn)備做什么，有什么風(fēng)險(xiǎn)。

迭代評(píng)審會(huì)議是每個(gè)迭代結(jié)束的時(shí)候，團(tuán)隊(duì)都會(huì)召開迭代復(fù)審會(huì)議，展示本迭代的運(yùn)行版本，既得到反饋信息，同時(shí)決定下一次迭代的內(nèi)容。

迭代回顧會(huì)議是每個(gè)迭代完成后，要進(jìn)行迭代回顧會(huì)議，為了持續(xù)的過程改進(jìn)。

四、XP極限編程模型

XP(eXtreme Programming)極限編程是由Kent Beck提出的一套針對(duì)業(yè)務(wù)需求和軟件開發(fā)實(shí)踐的規(guī)則。

XP由價(jià)值觀、原則、實(shí)踐和行為四個(gè)部分組成，它們彼此相互依賴、關(guān)聯(lián)， 并通過行為貫穿于整個(gè)生命期。

四大價(jià)值觀：溝通（Communication）、簡(jiǎn)單（Simplicity）、反饋（Feedback）、勇氣（Courage）

五大原則：快速反饋、簡(jiǎn)單性假設(shè)、逐步修改、提倡更改、優(yōu)質(zhì)工作。

極限編程13個(gè)最佳實(shí)踐是通過整體實(shí)踐，開發(fā)團(tuán)隊(duì)實(shí)踐，開發(fā)者實(shí)踐三個(gè)層面來體現(xiàn)。

四個(gè)整體實(shí)踐：

1.完整團(tuán)隊(duì)（Whole Team）：團(tuán)隊(duì)當(dāng)中包括客戶，程序員，測(cè)試員，分析員還有一個(gè)上層的經(jīng)理等等，那么每個(gè)角色是平等的。

2.計(jì)劃博弈 ( Planning Game )：體現(xiàn)主要兩個(gè)主要計(jì)劃，發(fā)布計(jì)劃和迭代計(jì)劃。

3.小型發(fā)布 ( Small Release )：如果有可能，每天都要發(fā)布一個(gè)小版本。

4.現(xiàn)場(chǎng)客戶( Customer Tests)：客戶對(duì)每一個(gè)需求都定義了一些驗(yàn)收測(cè)試，通過運(yùn)行驗(yàn)收測(cè)試，開發(fā)人員和客戶可以知道開發(fā)出來的軟件是否符合需求。

五個(gè)開發(fā)團(tuán)隊(duì)實(shí)踐：

1.集體所有（Collective Ownership）：團(tuán)隊(duì)中的每個(gè)成員都擁有對(duì)代碼進(jìn)行改進(jìn)的權(quán)利，每個(gè)人都擁有全部代碼，也都需要對(duì)全部代碼負(fù)責(zé)。同時(shí)，XP強(qiáng)調(diào)代碼是誰(shuí)破壞的，就應(yīng)該由誰(shuí)來修復(fù)。

2.代碼規(guī)范 ( Code Standards )：開發(fā)團(tuán)隊(duì)?wèi)?yīng)該擁有一個(gè)編碼標(biāo)準(zhǔn)。

3.平穩(wěn)工作 ( Sustainable Pace )：加班最終會(huì)扼殺團(tuán)隊(duì)的積極性，最終導(dǎo)致項(xiàng)目失敗，每周工作40小時(shí)是一種順勢(shì)行為，是一種規(guī)律。

4.系統(tǒng)隱喻 ( System Metaphor )：尋求共識(shí)，發(fā)明共享詞匯，描述體系結(jié)構(gòu)。隱喻是設(shè)計(jì)和溝通的輔助手段，使項(xiàng)目成員對(duì)于系統(tǒng)的實(shí)現(xiàn)方式達(dá)成共識(shí)。

5.持續(xù)集成 ( Continuous Integration )：開發(fā)人員堅(jiān)持隨時(shí)進(jìn)行提交，系統(tǒng)每天一次集成。

四個(gè)開發(fā)者實(shí)踐：

1.簡(jiǎn)單設(shè)計(jì) ( Simple Design )：用最簡(jiǎn)單的方法來實(shí)現(xiàn)小的需求，那么這些設(shè)計(jì)只要能滿足當(dāng)下的需求就可以了，而且所有的這些設(shè)計(jì)都將在后續(xù)的開發(fā)中被不斷地重整和優(yōu)化。

2.結(jié)對(duì)編程 ( Pair Programming )：系統(tǒng)的任何一個(gè)部分都肯定至少有2個(gè)人以上熟悉，好處是代碼會(huì)被100%review，有效地降低代碼缺陷率。

3.測(cè)試驅(qū)動(dòng)開發(fā) ( Test-driven Development)：極限編程將測(cè)試結(jié)合到開發(fā)過程中，每次結(jié)合代碼都應(yīng)該運(yùn)行一遍所有的測(cè)試。

4.代碼重構(gòu) ( Refactoring ) ：時(shí)刻對(duì)代碼進(jìn)行重構(gòu)，一直保持其良好的結(jié)構(gòu)與可擴(kuò)展性。集體檢查也是很重要的。

精益（Lean）模型

精益最初是來自于豐田公司的制造工業(yè)，其主要的思想是分析所有的流程，刪除沒有必要的流程，不斷提高效率。精益模式提倡持續(xù)不斷地改進(jìn)，減少流程中的浪費(fèi)。

對(duì)于軟件開發(fā)而言從開發(fā)者和最終用戶的視角來檢查軟件開發(fā)過程，消除不利于快速交付的行為，形成精益的軟件開發(fā)，這就是精益模型的思路。

持續(xù)交付

持續(xù)交付是經(jīng)典的敏捷軟件開發(fā)方法的自然延續(xù)，能夠以較短的周期完成需求的小顆粒度的頻繁交付。

頻繁的交付周期帶來更迅速的對(duì)軟件的反饋，并且在這個(gè)過程中，需求分析，設(shè)計(jì)，測(cè)試，開發(fā)，運(yùn)維等角色可以密切的協(xié)作。

那么持續(xù)交付包括持續(xù)集成，持續(xù)部署，持續(xù)交付。

持續(xù)集成是將個(gè)人代碼向整體進(jìn)行交付，以便更早發(fā)現(xiàn)開人開發(fā)出現(xiàn)的問題。

持續(xù)部署是集成的代碼盡快向可運(yùn)行的環(huán)境來交付，以便盡早的測(cè)試。

持續(xù)交付是盡快向客戶交付，以便盡早發(fā)現(xiàn)生產(chǎn)環(huán)境中存在的問題。

DevOps

那么由持續(xù)交付演變成的DevOps既Development and Operations，他是開發(fā)端和運(yùn)維端一個(gè)全程敏捷思維。

開發(fā)和運(yùn)維原本有著不同的目標(biāo)，那么開發(fā)人員希望盡快提交產(chǎn)品，運(yùn)維端希望產(chǎn)品的更合理化，高性能高可靠性，減少運(yùn)維成本。

開發(fā)人員與運(yùn)維人員目標(biāo)上的差異就叫混亂之想。DevOps融合開發(fā)和維護(hù)形成了一個(gè)統(tǒng)一的敏捷過程，意在幫助那些人員向著一個(gè)共同的目標(biāo)努力。

DevOps是一種方法論，是一組過程，方法與系統(tǒng)的統(tǒng)稱，用于促進(jìn)開發(fā)，技術(shù)運(yùn)營(yíng)和質(zhì)量保障（QA）部門之間的溝通，協(xié)作與整合。

DevOps的工具是多種多樣的，甚至可以由多種工具組成一個(gè)DevOps的工具鏈。

總結(jié)

總之 無(wú)論是最經(jīng)典的Scrum還是XP模型，還是精益，持續(xù)交付，以至于devops等敏捷模型，可以通過一些敏捷實(shí)踐靈活應(yīng)對(duì)變更，快速的交付產(chǎn)品。

到這里，第三章 生存期模型就講解完畢！希望大家對(duì)生存期模型有一個(gè)全面的認(rèn)識(shí)~

如果您覺得這篇文章有幫助到您的的話不妨點(diǎn)贊支持一下喲~~??

后續(xù)將持續(xù)更新【軟件項(xiàng)目管理初級(jí)學(xué)習(xí)路線】的全知識(shí)點(diǎn)，大家感興趣的多多關(guān)注博主喲~————————————————