敏捷開發(fā)：從宣言到實(shí)戰(zhàn)

敏捷的背景和動(dòng)機(jī)

有數(shù)據(jù)顯示有70%采用瀑布式開發(fā)開發(fā)方法的軟件開發(fā)項(xiàng)目均以失敗告終。軟件項(xiàng)目現(xiàn)在有了新的挑戰(zhàn)：市場(chǎng)的需求瞬息萬(wàn)變，很難實(shí)現(xiàn)項(xiàng)目需求的明確且完整的收集；技術(shù)的發(fā)展也日新月異，對(duì)于所定義功能的可實(shí)現(xiàn)性也面臨著多重不確定性的因素。基于這些新的挑戰(zhàn)，敏捷開發(fā)方法孕育而生。

上圖展示的是一個(gè)敏捷模型和瀑布模型的一個(gè)對(duì)比，瀑布模型是趨于一個(gè)穩(wěn)定的需求范圍，就是在項(xiàng)目前期根據(jù)需求確定人員和開發(fā)時(shí)間，他是一個(gè)規(guī)劃驅(qū)動(dòng)的模型。敏捷開發(fā)是確定時(shí)間，根據(jù)需求不斷迭代來(lái)不斷提高和不斷修正。瀑布模型是以規(guī)劃為導(dǎo)向的，而敏捷模型是以價(jià)值為導(dǎo)向的，價(jià)值作為交換的優(yōu)先級(jí)，價(jià)值作為整個(gè)項(xiàng)目的最終目標(biāo)。

敏捷宣言

2001年初，由于許多公司的軟件開發(fā)團(tuán)隊(duì)陷入了不斷增長(zhǎng)過(guò)程的泥潭，一批業(yè)界專家聚焦在一起概括出一些可以讓軟件開發(fā)團(tuán)隊(duì)具有快速工作、響應(yīng)變化能力的價(jià)值觀和原則。他們稱其為敏捷聯(lián)盟。這個(gè)聯(lián)盟有個(gè)宣言，雖然聽上去可能有些高大上，但卻是很實(shí)際。敏捷的轉(zhuǎn)型不僅僅是方法論的轉(zhuǎn)變，更重要的是公司自上而下整個(gè)架構(gòu)理念的改變。所以理解宣言內(nèi)容是很重要的，第一條是個(gè)體和互動(dòng)高于流動(dòng)和工具。這里強(qiáng)調(diào)的是團(tuán)隊(duì)中個(gè)體和個(gè)體互動(dòng)，大家更積極的去做事情。高于流程和工具，并不是排斥他們，流程和工具本身就是經(jīng)驗(yàn)的總結(jié)，我們?nèi)匀恍枰麄內(nèi)ヒ?guī)范我們的軟件；工作的軟件高于詳盡的文檔，這里的工作軟件指的是我們不斷迭代交互出來(lái)的產(chǎn)品，必須是完整的、獨(dú)立可運(yùn)行的軟件，這里所說(shuō)的高于詳盡的文檔也不是排斥文檔，而是相對(duì)而言，當(dāng)然文檔作為項(xiàng)目的一部分資產(chǎn)，也是比較重要的；客戶合作高于合同談判，強(qiáng)調(diào)的是把客戶引導(dǎo)到我們的軟件開發(fā)環(huán)境，讓他們對(duì)軟件有更詳細(xì)的了解，而不僅僅是把精力全放到合同談判上；響應(yīng)變化高于遵循計(jì)劃，對(duì)于需求的不斷改變，我們要積極的去響應(yīng)，而不能單單的去遵循計(jì)劃。

敏捷開發(fā)的12個(gè)原則

具體內(nèi)容如上圖，在這做簡(jiǎn)單的介紹。我們要盡早地交付有價(jià)值的軟件，對(duì)于客戶來(lái)說(shuō)這無(wú)疑是最重要的。敏捷開發(fā)的優(yōu)點(diǎn)就在于到了后期客戶也可以根據(jù)需要更改需求。業(yè)務(wù)人員和開發(fā)人員天天在一起工作有利于提高人員之間的交互能力。一個(gè)軟件的開發(fā)周期是很長(zhǎng)的，這就需要開發(fā)人員要保持一個(gè)恒定的開發(fā)速度。簡(jiǎn)單化是根本，這體現(xiàn)了軟件開發(fā)的高效性。

敏捷是一種方法論，而敏捷方法是將這些理論應(yīng)用于實(shí)踐。目前敏捷開發(fā)的七種主流方法如下：極限編程、scrum、水晶方法族、特性驅(qū)動(dòng)開發(fā)、自適應(yīng)軟件開發(fā)、動(dòng)態(tài)系統(tǒng)開發(fā)方法和輕量型RUP。大家比較熟悉的是SCRUM，

SCRUM精講

簡(jiǎn)介

它是一個(gè)用于開發(fā)和維持開發(fā)產(chǎn)品的一個(gè)框架，是一個(gè)增量的、迭代的開發(fā)過(guò)程，在這個(gè)框架中，軟件開發(fā)由若干個(gè)短的迭代的周期組成。每個(gè)短的迭代周期被稱為Sprint，每個(gè)sprint的建議長(zhǎng)度為2到4周。

看上圖，會(huì)發(fā)現(xiàn)每個(gè)sprint都由分析、設(shè)計(jì)、測(cè)試、構(gòu)建、集成五部分組成。通過(guò)每個(gè)sprint進(jìn)行回復(fù)和評(píng)審的一個(gè)環(huán)節(jié)，來(lái)達(dá)到一個(gè)反饋，總結(jié)錯(cuò)誤的地方和需要達(dá)到的一個(gè)高度，來(lái)更好的交付我們的軟件成果。在scrum中使用產(chǎn)品Backlog來(lái)管理產(chǎn)品的需求，backlog是按照商業(yè)需求標(biāo)準(zhǔn)來(lái)排序的需求列表，列表體現(xiàn)形式通常是用戶故事。Scrum總是想開發(fā)對(duì)用戶有高價(jià)值的需求。從sprint中的backlog挑選優(yōu)先價(jià)值最高的需求進(jìn)行開發(fā)。在sprint計(jì)劃會(huì)議上我們要進(jìn)行討論、分析和估算得到相應(yīng)的任務(wù)列表，把它當(dāng)作sprint backlog來(lái)搞。

下面的表格是sprint不同迭代周期會(huì)對(duì)scrum產(chǎn)生哪些影響。我們可以看到它影響事務(wù)成本、對(duì)業(yè)務(wù)變化的響應(yīng)、透明性、反饋周期、陷入為瀑布的風(fēng)險(xiǎn)和適配性。

在這里我們建議大家在第一個(gè)甚至第二個(gè)迭代周期的時(shí)候，沿用兩周的迭代周期，恰巧我們可以測(cè)試一系列的因素在我們的項(xiàng)目里是怎樣的一個(gè)反饋，這樣我們?cè)诮酉聛?lái)的迭代周期才會(huì)有一個(gè)更好的改善。

Scrum框架

它包括三個(gè)角色（產(chǎn)品負(fù)責(zé)人、scrum主管、開發(fā)團(tuán)隊(duì)）、四個(gè)儀式（sprint計(jì)劃會(huì)議、每日站會(huì)、sprint評(píng)審會(huì)議、sprint回顧會(huì)議）、三個(gè)工件（產(chǎn)品訂單、沖刺訂單、沖刺燃盡圖）三部分組成。下圖是scrum的流程，可以看到Product Owner從客戶、團(tuán)隊(duì)那里拿到需求來(lái)做成product backlog列表，團(tuán)隊(duì)通過(guò)sprint計(jì)劃會(huì)議建立相關(guān)的沖刺訂單，scrum master通過(guò)每日站會(huì)對(duì)團(tuán)隊(duì)的沖刺訂單進(jìn)行審核，判斷完成情況，在每個(gè)迭代周期的結(jié)束還會(huì)有評(píng)審會(huì)議和回顧會(huì)議。評(píng)審會(huì)議是對(duì)軟件是否合格進(jìn)行審核，回顧會(huì)議對(duì)上一周期的不足等進(jìn)行總結(jié)，以達(dá)到團(tuán)隊(duì)的持續(xù)進(jìn)步。

Scrum中每日會(huì)議，如果條件允許的話，應(yīng)該在同樣的時(shí)間和地點(diǎn)，要求團(tuán)隊(duì)成員站立進(jìn)行會(huì)議。會(huì)議時(shí)間應(yīng)該在早晨，不宜過(guò)長(zhǎng)，控制在15分鐘左右，如果時(shí)間太長(zhǎng)不利于工作效率，有利于團(tuán)隊(duì)成員安排自己的工作，只有團(tuán)隊(duì)成員可以在會(huì)上發(fā)言，其他人可以旁聽，但不可以發(fā)言。會(huì)議由scrum主管來(lái)主持，每個(gè)成員輪流回答下面三個(gè)問(wèn)題：昨天我做了什么、我今天打算做什么，都遇到了哪些問(wèn)題或困難。

Scrum中的sprint回顧會(huì)議就是團(tuán)隊(duì)的自我檢視，發(fā)現(xiàn)什么是好的，什么是不好的。會(huì)議時(shí)間一般控制在15-30分鐘，每個(gè)sprint都需要去做，主管、負(fù)責(zé)人、團(tuán)隊(duì)人員、相關(guān)客戶等全體都要參加。

Scrum中的product backlog分為幾個(gè)元素：Epic、feature、user story、Task。Epic又稱為史詩(shī)故事，規(guī)模和復(fù)雜性非常大，難以估算。Feature代表產(chǎn)品的特性，代表一個(gè)產(chǎn)品可以做什么，可以提供什么樣的服務(wù)。User story 通常都一個(gè)模板，作為一個(gè)角色，采用某種操作，以便能夠完成某種特定的目標(biāo)，它進(jìn)一步拆分就會(huì)拆分成幾個(gè)task。

在敏捷開發(fā)中是通過(guò)用戶故事來(lái)講需求具體化可以迭代開發(fā)的一個(gè)個(gè)現(xiàn)實(shí)的可見的開發(fā)任務(wù)。在用戶故事的劃分中有三個(gè)要素：card、conversation和confirmation。具體格式和例子如下：

作為一個(gè)角色，通過(guò)某項(xiàng)操作以便完成特定的目標(biāo)。

As a < user >, I need to < action > in order to < reason >

作為一個(gè)國(guó)足的球迷，通過(guò)點(diǎn)擊官網(wǎng)的新聞欄，以便能夠了解最新的國(guó)足時(shí)態(tài)。

一個(gè)良好的User-story應(yīng)該包括下面的一些原則：獨(dú)立性、可評(píng)估、可協(xié)商、短小、有價(jià)值、可測(cè)試性。我們需要通過(guò)測(cè)試來(lái)確定軟件是否可正常工作。

還記得上面的那個(gè)博客的例子嗎，我們接下來(lái)用這個(gè)例子來(lái)講一下沖刺訂單。如下圖，通過(guò)十天的迭代周期來(lái)記錄sprint backlog的完成情況。第一天就是所有任務(wù)的一個(gè)初始值，開發(fā)照片上傳需要四個(gè)小時(shí)，我們第一天剩下的工作量就是需要完成的工作量，sprint需要每天更新。在這里我們需要注意的是管理sprint的backlog是團(tuán)隊(duì)人員自己挑選任務(wù)而不是分配任務(wù)，對(duì)于每個(gè)任務(wù)每天都要更新剩余工作量，每個(gè)成員都可以更改sprint backlog。

使用DevCloud實(shí)踐

Product owner負(fù)責(zé)把product backlog的信息隨著項(xiàng)目迭代的進(jìn)行持續(xù)錄入項(xiàng)目規(guī)劃中。在spring plan meeting階段，團(tuán)隊(duì)可以對(duì)story進(jìn)行任務(wù)拆分和估算，在daily standup meeting上，對(duì)相關(guān)信息進(jìn)行更新。這里的‘E’對(duì)應(yīng)的就是主菜單中的epic。文檔提供了項(xiàng)目歸檔和資產(chǎn)管理的項(xiàng)目管理。我們可以把線下的項(xiàng)目文檔都上傳到云端。百科可以實(shí)現(xiàn)對(duì)知識(shí)庫(kù)FAQ的管理，項(xiàng)目?jī)?nèi)的成員可以更好的了解項(xiàng)目的知識(shí)庫(kù)資源。同樣看板也是實(shí)現(xiàn)項(xiàng)目管理的一種，通過(guò)它我們可以對(duì)圖形進(jìn)行更好的設(shè)計(jì)，達(dá)到更好的統(tǒng)計(jì)效果和最終效果。

華為云會(huì)議 Meeting 敏捷開發(fā)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。