文章來(lái)源:i黑馬 作者: 嚴瀾

導讀：說(shuō)起敏捷開(kāi)發(fā)，并不是因為敏捷而敏捷。這幾年的敏捷開(kāi)發(fā)已經(jīng)被很多敏捷咨詢(xún)服務(wù)商神話(huà)了，這個(gè)東西并不是神器，實(shí)施了就可以解決所有軟件公司的問(wèn)題，而是要結合自己公司的特點(diǎn)和問(wèn)題摸索出適合自己的一套模式。

大家都知道，創(chuàng )業(yè)公司剛開(kāi)始需要研發(fā)出一款產(chǎn)品并且能夠使公司賺錢(qián)的產(chǎn)品，不過(guò)大部分創(chuàng )業(yè)公司沒(méi)有那么容易一下就能做出來(lái)，很多公司還沒(méi)有成功的產(chǎn)品資金鏈就斷掉了，公司也死掉了。我們公司是這樣一個(gè)狀況，有一條產(chǎn)品線(xiàn)可以維持公司開(kāi)支并僅僅剛夠盈余，要擴大高速發(fā)展還不夠，一直維持就沒(méi)有創(chuàng )業(yè)的意義。另一條線(xiàn)是做技術(shù)創(chuàng )新為未來(lái)能夠開(kāi)發(fā)一款人氣爆棚的產(chǎn)品摸索著(zhù)，但是又不能餓著(zhù)肚子去開(kāi)發(fā)。我們是如何結合自身的特點(diǎn)實(shí)施敏捷開(kāi)發(fā)的呢?一個(gè)難題，很大的難題!

我們技術(shù)團隊人員是這樣的配置：1名技術(shù)總監、2名資深開(kāi)發(fā)工程師、1名高級開(kāi)發(fā)工程師、2名潛力開(kāi)發(fā)工程師、1名前端開(kāi)發(fā)、1名測試。技術(shù)總監需要處理很多團隊管理、客戶(hù)管理的工作，能夠參與項目的時(shí)間最多每天二分之一。2名資深開(kāi)發(fā)需要負責給其他工程師做導師，參與新項目開(kāi)發(fā)時(shí)間大概有80%。高級工程師要預留項目學(xué)習時(shí)間，參與項目的時(shí)間大概有90%。潛力開(kāi)發(fā)工程師需要有一些時(shí)間學(xué)習技術(shù)和項目，但是基本可以做到70%的時(shí)間投入項目。前端開(kāi)發(fā)和測試哪里有需要就在哪里革命，屬于機動(dòng)部隊。

現在總共有六個(gè)老項目在維護，兩個(gè)新項目需要開(kāi)發(fā)。六個(gè)項目的維護總共需要每周4人天時(shí)間(人天指需要花1個(gè)人4天的時(shí)間完成一個(gè)事情)。其中一個(gè)新項目“項目1”大概估計120人天的開(kāi)發(fā)時(shí)間，需要1個(gè)月之內開(kāi)發(fā)完成?！绊椖?”大概估計要40人天的開(kāi)發(fā)時(shí)間，需要2周開(kāi)發(fā)完成。而現在的人力按照能夠投入的時(shí)間算一下，總共資源為 (1 * 1/2 + 2 * 8/10+1 * 9/10+2 * 7/10) 30天 = 132 人天，6個(gè)老項目每周需要4人天，一個(gè)月4周，需要 4 * 4 = 16人天。項目能夠投入的資源有 132 – 16 = 116人天，而總共需要120 + 40 = 160天，足足少了44人天，這看起來(lái)是一個(gè)不可完成的任務(wù)。

不過(guò)到最后，我們還是使用敏捷開(kāi)發(fā)完成了這兩個(gè)項目，也沒(méi)有影響老項目的維護。我們是怎么操作的?最開(kāi)始我們兩個(gè)開(kāi)發(fā)，這個(gè)時(shí)候只要兩個(gè)人就能夠很好的合作把產(chǎn)品開(kāi)發(fā)出來(lái)，不需要什么模式。隨著(zhù)人員的擴充，團隊間如何協(xié)作按時(shí)按質(zhì)按量完成任務(wù)就需要好好思考下了。

嘗試一，傳統軟件開(kāi)發(fā)模式。整個(gè)過(guò)程為 需求分析、系統設計、任務(wù)分解計劃安排、開(kāi)發(fā)設計、編碼、測試、交付、驗收、維護。這個(gè)模式也是大家最常使用的模式，不過(guò)套用在我們公司時(shí)我們是這么操作的。

傳統開(kāi)發(fā)過(guò)程

由于公司創(chuàng )業(yè)，老板有一個(gè)想法，但并不能很好的描述需求，所以需求分析的任務(wù)落在技術(shù)總監身上。系統設計和任務(wù)分解剛開(kāi)始是技術(shù)總監完成，后面資深開(kāi)發(fā)工程師可以承擔一部分。開(kāi)發(fā)設計可以讓各個(gè)開(kāi)發(fā)工程師完成，資深工程師進(jìn)行把關(guān)，再到測試人員測試，最后再交付用戶(hù)驗收、技術(shù)維護?？雌饋?lái)很好的模式，開(kāi)發(fā)了幾個(gè)產(chǎn)品最終有的延時(shí)有的產(chǎn)品離用戶(hù)的期望差距甚遠，參與項目團隊的人信心受挫。

為什么會(huì )失敗呢?后來(lái)思考了這些問(wèn)題：

1、技術(shù)總監不是產(chǎn)品經(jīng)理，不能夠承擔產(chǎn)品設計的責任。老板是信任技術(shù)總監能做好產(chǎn)品，就交給他做。但這里搞混了一個(gè)概念，產(chǎn)品經(jīng)理和項目經(jīng)理，技術(shù)總監應該起到項目經(jīng)理和架構師的作用。項目經(jīng)理管控項目進(jìn)度和計劃、架構師把握整體技術(shù)問(wèn)題。而技術(shù)總監接到這個(gè)任務(wù)又不能不做好，責任所在。說(shuō)到底，就是機制沒(méi)有把產(chǎn)品設計和項目經(jīng)理區分開(kāi)，不等于技術(shù)實(shí)現者就是產(chǎn)品設計者。更多的應該讓老板或者其他業(yè)務(wù)人員承擔產(chǎn)品設計的工作。

2、需求不穩定，變化后改動(dòng)代價(jià)大。由于創(chuàng )業(yè)，需求為了適應市場(chǎng)會(huì )經(jīng)常調整，但是一但調整，很多開(kāi)發(fā)計劃就會(huì )受到相應的調整。如果部分功能已經(jīng)正在開(kāi)發(fā)，調整需求后很多工作要重新開(kāi)始，嚴重影響了技術(shù)同事積極性。業(yè)務(wù)不調整需求是不可能的，他們是為了滿(mǎn)足用戶(hù)的要求，用戶(hù)滿(mǎn)意了才能給企業(yè)帶來(lái)價(jià)值。不過(guò)如果調整，代價(jià)太大，很多代碼要重寫(xiě)，大家就會(huì )責怪技術(shù)總監或者項目負責人沒(méi)有把握好需求。

3、團隊經(jīng)常加班，但戰斗力不強。 核心團隊疲于應對需求、技術(shù)開(kāi)發(fā)、老系統維護，沒(méi)時(shí)間指導新同事技術(shù)學(xué)習，而新同事技能暫時(shí)還沒(méi)有發(fā)揮出來(lái)干活效率低，任務(wù)經(jīng)常延期，沒(méi)有成就感。核心團隊事情很多，沒(méi)有時(shí)間整理項目文檔，新員工沒(méi)有文檔上手慢。大家每天很多事情，需要加班才能完成，比較疲憊。每個(gè)人除了工作還有很多事情需要做，比如回家看看電視、陪陪家人、看看書(shū)學(xué)習一下等。如果讓一個(gè)員工一天二十四小時(shí)都是工作，他能同意，他家人也不一定同意。讓大家愉悅的開(kāi)發(fā)，比疲憊的上班效率要高很多。

4、交付軟件質(zhì)量差，離用戶(hù)期望差距大。創(chuàng )業(yè)時(shí)大家的想法都是好的，大干一番，做一個(gè)所有人都愛(ài)使用的產(chǎn)品?，F實(shí)是殘酷的，大家辛辛苦苦做出來(lái)的東西，老板不滿(mǎn)意、用戶(hù)不埋單，付出的努力沒(méi)有人認可。交付的軟件沒(méi)時(shí)間自測試，或者自測試不充分，交給測試又是一大堆問(wèn)題。有些公司還沒(méi)有測試，直接出去給用戶(hù)，相當危險。這樣交出去的公司不僅僅影響了用戶(hù)的使用，還影響了整個(gè)公司的口碑。

不是說(shuō)傳統軟件開(kāi)發(fā)模式不好，只是不太適合我們這種創(chuàng )業(yè)公司。開(kāi)始嘗試其他模式，如果沒(méi)有一個(gè)很好的體制就不能把大家的最大生產(chǎn)力發(fā)揮出來(lái)。

嘗試二，敏捷開(kāi)發(fā)模式。敏捷開(kāi)發(fā)是一種以人為核心、迭代、循序漸進(jìn)的開(kāi)發(fā)方法。敏捷方法強調以人為本，專(zhuān)注于交付對客戶(hù)有價(jià)值的軟件。在高度協(xié)作的開(kāi)環(huán)境中，使用迭代式的方式進(jìn)行增量開(kāi)發(fā)，經(jīng)常使用反饋進(jìn)行思考、反省和總結，不停的進(jìn)行自我調整和完善。

敏捷開(kāi)發(fā)的主旨：

一：個(gè)體及交互比流程與工具更具價(jià)值

二：可用的軟件比冗長(cháng)的文檔更有價(jià)值

三：與客戶(hù)的協(xié)作比合同談判更有價(jià)值

四：對變化的響應比遵循計劃更有價(jià)值

而我們之前的問(wèn)題，交付軟件客戶(hù)不滿(mǎn)意、延期、需求更改代價(jià)大貌似都可以解決。這么好的模式趕緊要試試，先看一張敏捷開(kāi)發(fā)的流程圖。

創(chuàng )業(yè)公司敏捷開(kāi)發(fā)敏捷流程化

敏捷開(kāi)發(fā)簡(jiǎn)單流程：

1、產(chǎn)品負責人將整個(gè)產(chǎn)品設計成產(chǎn)品backlog。產(chǎn)品backlog就是一個(gè)個(gè)需求列表。(backlog可以理解為需求或者要做的事情)

2、召開(kāi)產(chǎn)品backlog計劃會(huì )議，預估每個(gè)backlog的時(shí)間，確定哪些backlog是需要在第一個(gè)sprint中完成的，即sprint的backlog。(sprint可以理解為一個(gè)團隊一起開(kāi)發(fā)的一個(gè)任務(wù)集合)

3、把sprint的backlog寫(xiě)在紙條上貼在任務(wù)墻，讓大家認領(lǐng)分配。(任務(wù)墻就是把 未完成、正在做、已完成 的工作狀態(tài)貼到一個(gè)墻上，這樣大家都可以看得到任務(wù)的狀態(tài) )

4、舉行每日站立會(huì )議，讓大家在每日會(huì )議上總結昨天做的事情、遇到什么困難，今天開(kāi)展什么任務(wù)。(每日站立會(huì )議，是在每天早上定時(shí)和大家在任務(wù)墻前站立討論，時(shí)間控制在15分鐘內)

5、繪制燃盡圖，保證任務(wù)的概況能夠清晰看到。(燃盡圖把當前的任務(wù)總數和日期一起繪制，每天記錄一下，可以看到每天還剩多少個(gè)任務(wù)，直到任務(wù)數為0 ，這個(gè)sprint就完成了)

6、sprint評審會(huì )議是在sprint完成時(shí)舉行，要向客戶(hù)演示自己完成的軟件產(chǎn)品 。

7、最后是sprint總結會(huì )議，以輪流發(fā)言方式進(jìn)行，每個(gè)人都要發(fā)言，總結上一次sprint中遇到的問(wèn)題、改進(jìn)和大家分享討論。

我們怎么結合敏捷開(kāi)發(fā)解決現有項目的問(wèn)題，要記得任何措施都是為了保證按時(shí)按質(zhì)按量把軟件交付給用戶(hù)，不要為了敏捷而教條實(shí)施敏捷，公司不能產(chǎn)生商業(yè)價(jià)值，任何先進(jìn)的理念或者技術(shù)都是無(wú)意義的。我們做了這些措施：

1、推廣敏捷開(kāi)發(fā)理念。不管是大公司還是小公司強制推行一項制度效果一般都不怎么好。要能推行下去的任何東西一定要大家接受的，才能被認可。

首先培養測試小妹學(xué)習敏捷開(kāi)發(fā)，后續讓她承擔部分產(chǎn)品責任人和敏捷指導者的角色，原因有：

a、測試要驗收功能，必須理解業(yè)務(wù)需求。

b、測試也是QA質(zhì)量體系的一塊，學(xué)習好了對于軟件質(zhì)量有個(gè)更深的認識。

c、團隊大部分是男生，女生推廣更有親和力一些。

召集所有技術(shù)團隊開(kāi)會(huì )準備推廣。開(kāi)始和測試小妹好好討論下，怎么給大家說(shuō)更有效，更容易接受。她要講解一定要自己非常清楚敏捷開(kāi)發(fā)，并且準備充分知識點(diǎn)。開(kāi)會(huì )時(shí)先指出我們現在問(wèn)題，讓大家看看有什么想法解決問(wèn)題嗎?現在我們做的產(chǎn)品，客戶(hù)不認可、老板不滿(mǎn)意、自己很累沒(méi)有成就感，有什么辦法解決。在大家討論后，拋出敏捷開(kāi)發(fā)的優(yōu)勢，一般情況下大家都會(huì )認可的。大家可能會(huì )問(wèn)到如何執行、落地，可以嘗試找一個(gè)項目試點(diǎn)，如果實(shí)施成功就可以讓大家全面推廣，不成功也只影響了部分項目。

2、搭建敏捷開(kāi)發(fā)環(huán)境。大家要實(shí)施敏捷開(kāi)發(fā)，需要比較好的基礎條件保證敏捷開(kāi)發(fā)順利進(jìn)行。主要幾個(gè)關(guān)鍵的軟件：nexus 搭建倉庫依賴(lài)中心、maven 管理工程的依賴(lài)、jenkins 持續集成和自動(dòng)編譯發(fā)布、svn 集中代碼管理、jira 記錄需求和狀態(tài)。具體參考《敏捷開(kāi)發(fā)環(huán)境搭建》。

3、敏捷項目實(shí)施。整個(gè)公司建立以業(yè)務(wù)目標為導向的氛圍。就以“項目1”來(lái)說(shuō)，目的是完成這個(gè)項目，需要進(jìn)行這幾步：

先根據各自的能力和意向聚集一批完成這個(gè)目標的勇士，不管技術(shù)和非技術(shù)。如果聚集的人不夠，技術(shù)總監可以根據總體項目的投入機動(dòng)調整資源以支持，不過(guò)條件允許的話(huà)還是根據大家意愿來(lái)聚集。最終“項目1”召集了一個(gè)技術(shù)總監、一個(gè)資深開(kāi)發(fā)、兩個(gè)潛力開(kāi)發(fā)、一個(gè)前端、一個(gè)測試，除去大家做其他事情的時(shí)間，總共可以算作4個(gè)人。

充分調動(dòng)客戶(hù)(老板和業(yè)務(wù)同事)參與進(jìn)項目，他們的參與直接決定了項目成功與否。結合之前的經(jīng)驗，如果他們參與不夠，最終做出來(lái)的東西就不是他們要的，或者離他們要的差距很大。他們剛開(kāi)始加入的時(shí)候，很迷茫有時(shí)會(huì )表現的比較抗拒，這個(gè)時(shí)候一定要耐心堅持讓大家把第一個(gè)sprint開(kāi)發(fā)成功，使大家嘗到甜頭。讓他們全程參與項目也是表示了我們擁抱變化，如果有需求變化，就添加任務(wù)到任務(wù)墻，大家可以對所有任務(wù)的時(shí)間有個(gè)全面了解，如果超過(guò)sprint結束時(shí)間就需要業(yè)務(wù)決策哪些功能不在這個(gè)sprint周期加入。

技術(shù)總監安排和客戶(hù)溝通，客戶(hù)這里指老板和業(yè)務(wù)。測試小妹負責和客戶(hù)溝通記錄，技術(shù)總監輔助。多次溝通后，嘗試讓測試把需求原型用最簡(jiǎn)單的工具繪制出來(lái)，技術(shù)總監審核通過(guò)后和客戶(hù)溝通確認，反復迭代，直到整個(gè)需求大家沒(méi)有異議。很多公司這種需求是有一個(gè)專(zhuān)門(mén)產(chǎn)品負責人來(lái)執行，但按照我們目前的人力是沒(méi)辦法做到的。這里沒(méi)有讓技術(shù)總監做主要是為了避免之前出現的問(wèn)題，過(guò)度技術(shù)設計產(chǎn)品。

產(chǎn)品設計出來(lái)后，召集項目成員分解任務(wù)，確定每個(gè)任務(wù)的時(shí)間，可以使用敏捷撲克牌來(lái)估計。任務(wù)分解盡量控制在1-2天的粒度，這樣大家1-2天就可以做出一個(gè)能測試的原型，盡早可以集成測試發(fā)現問(wèn)題。一個(gè)sprint的任務(wù)集合盡量控制在1-2周，不能太長(cháng)，也不能太短。太長(cháng)會(huì )出現疲勞，太短的sprint會(huì )讓大家覺(jué)得工作太多，做完一個(gè)又一個(gè)?！绊椖?”估算結果為120人天，總共投入4個(gè)人，需要30天4周時(shí)間，我們切成了4個(gè)sprint，差不多1個(gè)月時(shí)間完成，滿(mǎn)足業(yè)務(wù)的時(shí)間要求。

分階段實(shí)施sprint，繪制任務(wù)墻，劃分未開(kāi)始、已計劃、進(jìn)行中、完成、燃盡圖。把要做的sprint任務(wù)上墻，貼到未開(kāi)始的地方。

創(chuàng )業(yè)公司敏捷開(kāi)發(fā)任務(wù)墻

每日站立會(huì )議大家認領(lǐng)任務(wù)。包括業(yè)務(wù)任務(wù)、開(kāi)發(fā)設計、開(kāi)發(fā)編碼、前端設計開(kāi)發(fā)、測試等都是一個(gè)個(gè)任務(wù)，統一管理起來(lái)。強調的是一個(gè)團體，如果有同事請假，其他同事可以頂上完成任務(wù)。站立會(huì )議總結昨天的任務(wù)是否有問(wèn)題，對于當前的任務(wù)有什么建議，盡量控制在15分鐘內，有效會(huì )議。這里不會(huì )像以前業(yè)務(wù)或者項目經(jīng)理追著(zhù)大家屁股要結果，而是團隊驅動(dòng)，每天大家做的事情都反映在墻上，誰(shuí)出現了什么狀況，大家都會(huì )幫他想辦法，保證整個(gè)項目能夠成功。每一個(gè)任務(wù)完成，由項目執行者把任務(wù)從進(jìn)行中貼到完成區域。再從未分配區域認領(lǐng)新任務(wù)貼到進(jìn)行中的區域。

軟件開(kāi)發(fā)過(guò)程。認領(lǐng)任務(wù)后，怎么保證大家開(kāi)發(fā)有質(zhì)量的代碼?團隊有資深點(diǎn)的工程師，不需要太多指導，直接可以參與項目的開(kāi)發(fā)。而學(xué)習型工程師，需要指導幫助才能一步步做用例、系統分析。技術(shù)總監不建議認領(lǐng)太多開(kāi)發(fā)任務(wù)，他負責開(kāi)發(fā)團隊的概要設計審核，沒(méi)有審核通過(guò)的設計不能開(kāi)發(fā)，并指導大家分析和設計系統。大家都知道，系統思路有了，剩下就是技術(shù)實(shí)現的過(guò)程，只要技能掌握熟練實(shí)現基本難度不大。大家可能會(huì )問(wèn)，敏捷開(kāi)發(fā)不是強調軟件開(kāi)發(fā)的產(chǎn)品是軟件，而不是文檔嗎?我們這里也不是像傳統開(kāi)發(fā)軟件一樣為了文檔而文檔，只是讓大家把自己的設計思路寫(xiě)下來(lái)，只有經(jīng)過(guò)自己仔細設計后才能把思路清晰的寫(xiě)下來(lái)。大家寫(xiě)的時(shí)候也不需要長(cháng)篇大論，這樣的文檔是不歡迎的，受歡迎的文檔只需寫(xiě)出用例分析，表設計，復雜的邏輯需要畫(huà)出流程序列圖。

結對編程。之前這個(gè)編程模式被無(wú)數人調侃過(guò)，其實(shí)也不可能讓每一個(gè)項目全程都是兩個(gè)人結對編程。這個(gè)不現實(shí)也浪費資源。我們的結對是在大家開(kāi)發(fā)一個(gè)難點(diǎn)模塊時(shí)，會(huì )給結對的人增加一項任務(wù)去配合其他開(kāi)發(fā)一起完成這個(gè)任務(wù)。其實(shí)我們在開(kāi)發(fā)時(shí)，很多時(shí)候都會(huì )結對，比如指導新同事、討論設計模塊，而之前這些都沒(méi)有算在我們的開(kāi)發(fā)工作量里。

創(chuàng )業(yè)公司敏捷開(kāi)發(fā)結對編程

項目演示和總結會(huì )議。在項目結束后，讓所有參與項目的成員都參加，一起演示給客戶(hù)展示，并解答客戶(hù)的問(wèn)題，充分讓大家感受到收獲的果實(shí)?？偨Y會(huì )議主要對于這個(gè)sprint中大家遇到的問(wèn)題和經(jīng)驗分享，并為下一個(gè)sprint做準備。

經(jīng)過(guò)敏捷實(shí)施后，我們的生產(chǎn)力提高了很多，員工的積極性提高了，業(yè)務(wù)的參與使整體需求把控也很好，大家溝通多了，30天的任務(wù)提前了5天完成。我們多出來(lái)的時(shí)間，讓大家每周有一天或者半天研究自己感興趣的領(lǐng)域，但是這些研究最終必須體現出成果。比如后臺開(kāi)發(fā)想研究一個(gè)新技術(shù)，最后做完需要寫(xiě)個(gè)ppt給大家分享下。既能讓大家做自己想做的事情，也給大家創(chuàng )造了一個(gè)互相學(xué)習的氛圍。

ps：所有的模式都不應該是教條的模式，先進(jìn)的模式并不是好的模式，適合自己的才是最好的。套用一句俗話(huà)：不管黑貓白貓抓得住耗子的才是好貓。