轉載自LANCEYAN.COM

說起敏捷開發(fā)，并不是因為敏捷而敏捷。這幾年的敏捷開發(fā)已經(jīng)被很多敏捷咨詢服務商神話了幕侠，這個東西并不是神器，實施了就可以解決所有軟件公司的問題碍彭，而是要結合自己公司的特點和問題摸索出適合自己的一套模式晤硕。

大家都知道，創(chuàng)業(yè)公司剛開始需要研發(fā)出一款產(chǎn)品并且能夠使公司賺錢的產(chǎn)品硕旗，不過大部分創(chuàng)業(yè)公司沒有那么容易一下就能做出來窗骑，很多公司還沒有成功的產(chǎn)品資金鏈就斷掉了女责，公司也死掉了漆枚。我們公司是這樣一個狀況，有一條產(chǎn)品線可以維持公司開支并僅僅剛夠盈余抵知，要擴大高速發(fā)展還不夠墙基，一直維持就沒有創(chuàng)業(yè)的意義软族。另一條線是做技術創(chuàng)新為未來能夠開發(fā)一款人氣爆棚的產(chǎn)品摸索著，但是又不能餓著肚子去開發(fā)残制。我們是如何結合自身的特點實施敏捷開發(fā)的呢立砸？一個難題，很大的難題初茶！

我們技術團隊人員是這樣的配置：1名技術總監(jiān)颗祝、2名資深開發(fā)工程師、1名高級開發(fā)工程師恼布、2名潛力開發(fā)工程師螺戳、1名前端開發(fā)、1名測試折汞。技術總監(jiān)需要處理很多團隊管理倔幼、客戶管理的工作，能夠參與項目的時間最多每天二分之一爽待。2名資深開發(fā)需要負責給其他工程師做導師损同，參與新項目開發(fā)時間大概有80%。高級工程師要預留項目學習時間鸟款，參與項目的時間大概有90%膏燃。潛力開發(fā)工程師需要有一些時間學習技術和項目，但是基本可以做到70%的時間投入項目欠雌。前端開發(fā)和測試哪里有需要就在哪里革命蹄梢，屬于機動部隊。

現(xiàn)在總共有六個老項目在維護富俄，兩個新項目需要開發(fā)禁炒。六個項目的維護總共需要每周4人天時間（人天指需要花1個人4天的時間完成一個事情）。其中一個新項目“項目1”大概估計120人天的開發(fā)時間霍比，需要1個月之內(nèi)開發(fā)完成幕袱≌ǘ桑“項目2”大概估計要40人天的開發(fā)時間距潘，需要2周開發(fā)完成鞭达。而現(xiàn)在的人力按照能夠投入的時間算一下税灌，總共資源為 (1 * 1/2 + 2 * 8/10+1 * 9/10+2 * 7/10) 30天 = 132 人天须教，6個老項目每周需要4人天杜耙，一個月4周成榜，需要 4 * 4 = 16人天桐智。項目能夠投入的資源有 132 – 16 = 116人天凌外，而總共需要120 + 40 = 160天辩尊，足足少了44人天，這看起來是一個不可完成的任務康辑。

不過到最后摄欲，我們還是使用敏捷開發(fā)完成了這兩個項目轿亮，也沒有影響老項目的維護。我們是怎么操作的胸墙？最開始我們兩個開發(fā)我注，這個時候只要兩個人就能夠很好的合作把產(chǎn)品開發(fā)出來，不需要什么模式迟隅。隨著人員的擴充但骨，團隊間如何協(xié)作按時按質按量完成任務就需要好好思考下了。

　　嘗試一智袭，傳統(tǒng)軟件開發(fā)模式嗽冒。整個過程為 需求分析、系統(tǒng)設計补履、任務分解計劃安排添坊、開發(fā)設計、編碼箫锤、測試贬蛙、交付、驗收谚攒、維護阳准。這個模式也是大家最常使用的模式，不過套用在我們公司時我們是這么操作的馏臭。

由于公司創(chuàng)業(yè)野蝇，老板有一個想法，但并不能很好的描述需求括儒，所以需求分析的任務落在技術總監(jiān)身上绕沈。系統(tǒng)設計和任務分解剛開始是技術總監(jiān)完成，后面資深開發(fā)工程師可以承擔一部分帮寻。開發(fā)設計可以讓各個開發(fā)工程師完成乍狐，資深工程師進行把關，再到測試人員測試固逗，最后再交付用戶驗收浅蚪、技術維護√陶郑看起來很好的模式惜傲，開發(fā)了幾個產(chǎn)品最終有的延時有的產(chǎn)品離用戶的期望差距甚遠，參與項目團隊的人信心受挫贝攒。

為什么會失敗呢盗誊？后來思考了這些問題：

1、技術總監(jiān)不是產(chǎn)品經(jīng)理，不能夠承擔產(chǎn)品設計的責任浊伙。老板是信任技術總監(jiān)能做好產(chǎn)品，就交給他做嚣鄙。但這里搞混了一個概念串结，產(chǎn)品經(jīng)理和項目經(jīng)理，技術總監(jiān)應該起到項目經(jīng)理和架構師的作用肌割。項目經(jīng)理管控項目進度和計劃卧蜓、架構師把握整體技術問題。而技術總監(jiān)接到這個任務又不能不做好弥奸，責任所在奋早。說到底盛霎，就是機制沒有把產(chǎn)品設計和項目經(jīng)理區(qū)分開，不等于技術實現(xiàn)者就是產(chǎn)品設計者耽装。更多的應該讓老板或者其他業(yè)務人員承擔產(chǎn)品設計的工作愤炸。

2掉奄、需求不穩(wěn)定，變化后改動代價大诞仓。由于創(chuàng)業(yè)速兔，需求為了適應市場會經(jīng)常調整，但是一但調整帜矾，很多開發(fā)計劃就會受到相應的調整屑柔。如果部分功能已經(jīng)正在開發(fā)，調整需求后很多工作要重新開始死陆，嚴重影響了技術同事積極性。業(yè)務不調整需求是不可能的别凤，他們是為了滿足用戶的要求领虹，用戶滿意了才能給企業(yè)帶來價值。不過如果調整诉稍，代價太大最疆，很多代碼要重寫，大家就會責怪技術總監(jiān)或者項目負責人沒有把握好需求服爷。

3获诈、團隊經(jīng)常加班，但戰(zhàn)斗力不強镜会。 核心團隊疲于應對需求终抽、技術開發(fā)、老系統(tǒng)維護匾旭，沒時間指導新同事技術學習圃郊，而新同事技能暫時還沒有發(fā)揮出來干活效率低持舆，任務經(jīng)常延期，沒有成就感逸寓。核心團隊事情很多竹伸，沒有時間整理項目文檔，新員工沒有文檔上手慢吧享。大家每天很多事情，需要加班才能完成钢颂，比較疲憊甸陌。每個人除了工作還有很多事情需要做盐股，比如回家看看電視、陪陪家人牲尺、看看書學習一下等幌蚊。如果讓一個員工一天二十四小時都是工作，他能同意蜒简，他家人也不一定同意漩仙。讓大家愉悅的開發(fā)队他，比疲憊的上班效率要高很多。

4麸折、交付軟件質量差垢啼，離用戶期望差距大。創(chuàng)業(yè)時大家的想法都是好的衬浑，大干一番放刨，做一個所有人都愛使用的產(chǎn)品。現(xiàn)實是殘酷的助币，大家辛辛苦苦做出來的東西，老板不滿意迹栓、用戶不埋單俭缓，付出的努力沒有人認可。交付的軟件沒時間自測試愿吹，或者自測試不充分惜姐，交給測試又是一大堆問題歹袁。有些公司還沒有測試，直接出去給用戶枫耳，相當危險孟抗。這樣交出去的公司不僅僅影響了用戶的使用，還影響了整個公司的口碑仑最。

不是說傳統(tǒng)軟件開發(fā)模式不好帆喇，只是不太適合我們這種創(chuàng)業(yè)公司坯钦。開始嘗試其他模式，如果沒有一個很好的體制就不能把大家的最大生產(chǎn)力發(fā)揮出來吟温。

嘗試二突颊，敏捷開發(fā)模式潘悼。敏捷開發(fā)是一種以人為核心治唤、迭代糙申、循序漸進的開發(fā)方法。敏捷方法強調以人為本缕陕，專注于交付對客戶有價值的軟件疙挺。在高度協(xié)作的開環(huán)境中衔统，使用迭代式的方式進行增量開發(fā)海雪，經(jīng)常使用反饋進行思考、反省和總結险掀，不停的進行自我調整和完善湾宙。

敏捷開發(fā)的主旨：
　　一：個體及交互比流程與工具更具價值
　　二：可用的軟件比冗長的文檔更有價值
　　三：與客戶的協(xié)作比合同談判更有價值
　　四：對變化的響應比遵循計劃更有價值

而我們之前的問題侠鳄，交付軟件客戶不滿意、延期碴开、需求更改代價大貌似都可以解決博秫。這么好的模式趕緊要試試，先看一張敏捷開發(fā)的流程圖巴碗。

敏捷開發(fā)簡單流程：

　　1橡淆、產(chǎn)品負責人將整個產(chǎn)品設計成產(chǎn)品backlog。產(chǎn)品backlog就是一個個需求列表蚣常。（backlog可以理解為需求或者要做的事情）
　　2痊银、召開產(chǎn)品backlog計劃會議溯革，預估每個backlog的時間，確定哪些backlog是需要在第一個sprint中完成的冈闭，即sprint的backlog抖单。（sprint可以理解為一個團隊一起開發(fā)的一個任務集合）
　　3、把sprint的backlog寫在紙條上貼在任務墻耍休，讓大家認領分配羊精。（任務墻就是把 未完成囚玫、正在做、已完成 的工作狀態(tài)貼到一個墻上燃少，這樣大家都可以看得到任務的狀態(tài) ）
　　4铃在、舉行每日站立會議涌穆，讓大家在每日會議上總結昨天做的事情、遇到什么困難趁舀，今天開展什么任務祝沸。（每日站立會議越庇，是在每天早上定時和大家在任務墻前站立討論卤唉，時間控制在15分鐘內(nèi)）
　　5仁期、繪制燃盡圖跛蛋，保證任務的概況能夠清晰看到。（燃盡圖把當前的任務總數(shù)和日期一起繪制押框，每天記錄一下理逊，可以看到每天還剩多少個任務晋被，直到任務數(shù)為0 ，這個sprint就完成了）
　　6道媚、sprint評審會議是在sprint完成時舉行翘县，要向客戶演示自己完成的軟件產(chǎn)品 谴分。
　　7牺蹄、最后是sprint總結會議，以輪流發(fā)言方式進行氓奈，每個人都要發(fā)言鼎天，總結上一次sprint中遇到的問題斋射、改進和大家分享討論但荤。

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

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

• 首先培養(yǎng)測試小妹學習敏捷開發(fā)雾鬼，后續(xù)讓她承擔部分產(chǎn)品責任人和敏捷指導者的角色，原因有：
  a晶疼、測試要驗收功能又憨，必須理解業(yè)務需求蠢莺。
  b、測試也是QA質量體系的一塊蒋情，學習好了對于軟件質量有個更深的認識。
  c辕翰、團隊大部分是男生喜命，女生推廣更有親和力一些河劝。
• 召集所有技術團隊開會準備推廣。開始和測試小妹好好討論下牌里，怎么給大家說更有效牡辽，更容易接受敞临。她要講解一定要自己非常清楚敏捷開發(fā)挺尿，并且準備充分知識點。開會時先指出我們現(xiàn)在問題熟史，讓大家看看有什么想法解決問題嗎洽沟？現(xiàn)在我們做的產(chǎn)品裆操，客戶不認可炉媒、老板不滿意吊骤、自己很累沒有成就感，有什么辦法解決传泊。在大家討論后，拋出敏捷開發(fā)的優(yōu)勢拦盹，一般情況下大家都會認可的普舆。大家可能會問到如何執(zhí)行校读、落地歉秫，可以嘗試找一個項目試點，如果實施成功就可以讓大家全面推廣雅潭，不成功也只影響了部分項目扶供。

2裂明、搭建敏捷開發(fā)環(huán)境闽晦。大家要實施敏捷開發(fā)，需要比較好的基礎條件保證敏捷開發(fā)順利進行笋敞。主要幾個關鍵的軟件：nexus 搭建倉庫依賴中心荠瘪、maven 管理工程的依賴哀墓、jenkins 持續(xù)集成和自動編譯發(fā)布篮绰、svn 集中代碼管理、jira 記錄需求和狀態(tài)臀突。具體參考《敏捷開發(fā)環(huán)境搭建》候学。

3、敏捷項目實施念逞。整個公司建立以業(yè)務目標為導向的氛圍翎承。就以“項目1”來說符匾，目的是完成這個項目，需要進行這幾步：

• 先根據(jù)各自的能力和意向聚集一批完成這個目標的勇士甸各，不管技術和非技術趣倾。如果聚集的人不夠儒恋，技術總監(jiān)可以根據(jù)總體項目的投入機動調整資源以支持黔漂，不過條件允許的話還是根據(jù)大家意愿來聚集炬守。最終“項目1”召集了一個技術總監(jiān)、一個資深開發(fā)酣藻、兩個潛力開發(fā)臊恋、一個前端墓捻、一個測試砖第，除去大家做其他事情的時間，總共可以算作4個人放吩。

• 充分調動客戶（老板和業(yè)務同事）參與進項目渡紫，他們的參與直接決定了項目成功與否考赛。結合之前的經(jīng)驗颜骤，如果他們參與不夠忍抽，最終做出來的東西就不是他們要的八孝，或者離他們要的差距很大。他們剛開始加入的時候鸠项，很迷茫有時會表現(xiàn)的比較抗拒干跛，這個時候一定要耐心堅持讓大家把第一個sprint開發(fā)成功，使大家嘗到甜頭祟绊。讓他們?nèi)虆⑴c項目也是表示了我們擁抱變化驯鳖，如果有需求變化，就添加任務到任務墻久免，大家可以對所有任務的時間有個全面了解浅辙，如果超過sprint結束時間就需要業(yè)務決策哪些功能不在這個sprint周期加入。

• 技術總監(jiān)安排和客戶溝通记舆，客戶這里指老板和業(yè)務。測試小妹負責和客戶溝通記錄呼巴，技術總監(jiān)輔助泽腮。多次溝通后，嘗試讓測試把需求原型用最簡單的工具繪制出來衣赶，技術總監(jiān)審核通過后和客戶溝通確認诊赊，反復迭代，直到整個需求大家沒有異議府瞄。很多公司這種需求是有一個專門產(chǎn)品負責人來執(zhí)行碧磅，但按照我們目前的人力是沒辦法做到的。這里沒有讓技術總監(jiān)做主要是為了避免之前出現(xiàn)的問題，過度技術設計產(chǎn)品鲸郊。

• 產(chǎn)品設計出來后丰榴，召集項目成員分解任務，確定每個任務的時間秆撮，可以使用敏捷撲克牌來估計四濒。任務分解盡量控制在1-2天的粒度，這樣大家1-2天就可以做出一個能測試的原型职辨，盡早可以集成測試發(fā)現(xiàn)問題盗蟆。一個sprint的任務集合盡量控制在1-2周，不能太長舒裤，也不能太短喳资。太長會出現(xiàn)疲勞，太短的sprint會讓大家覺得工作太多惭每，做完一個又一個骨饿。“項目1”估算結果為120人天台腥，總共投入4個人宏赘，需要30天4周時間，我們切成了4個sprint黎侈，差不多1個月時間完成察署，滿足業(yè)務的時間要求。

• 分階段實施sprint峻汉，繪制任務墻贴汪，劃分未開始、已計劃休吠、進行中扳埂、完成、燃盡圖瘤礁。把要做的sprint任務上墻阳懂，貼到未開始的地方.
  

• 每日站立會議大家認領任務。包括業(yè)務任務柜思、開發(fā)設計岩调、開發(fā)編碼、前端設計開發(fā)赡盘、測試等都是一個個任務号枕，統(tǒng)一管理起來。強調的是一個團體陨享，如果有同事請假葱淳，其他同事可以頂上完成任務钝腺。站立會議總結昨天的任務是否有問題，對于當前的任務有什么建議蛙紫，盡量控制在15分鐘內(nèi)拍屑，有效會議途戒。這里不會像以前業(yè)務或者項目經(jīng)理追著大家屁股要結果坑傅，而是團隊驅動，每天大家做的事情都反映在墻上喷斋，誰出現(xiàn)了什么狀況唁毒，大家都會幫他想辦法，保證整個項目能夠成功星爪。每一個任務完成浆西，由項目執(zhí)行者把任務從進行中貼到完成區(qū)域。再從未分配區(qū)域認領新任務貼到進行中的區(qū)域顽腾。

• 軟件開發(fā)過程近零。認領任務后，怎么保證大家開發(fā)有質量的代碼抄肖？團隊有資深點的工程師久信，不需要太多指導，直接可以參與項目的開發(fā)漓摩。而學習型工程師裙士，需要指導幫助才能一步步做用例、系統(tǒng)分析管毙。技術總監(jiān)不建議認領太多開發(fā)任務腿椎，他負責開發(fā)團隊的概要設計審核，沒有審核通過的設計不能開發(fā)夭咬，并指導大家分析和設計系統(tǒng)啃炸。大家都知道，系統(tǒng)思路有了卓舵，剩下就是技術實現(xiàn)的過程南用，只要技能掌握熟練實現(xiàn)基本難度不大。大家可能會問边器，敏捷開發(fā)不是強調軟件開發(fā)的產(chǎn)品是軟件训枢，而不是文檔嗎？我們這里也不是像傳統(tǒng)開發(fā)軟件一樣為了文檔而文檔忘巧，只是讓大家把自己的設計思路寫下來恒界，只有經(jīng)過自己仔細設計后才能把思路清晰的寫下來。大家寫的時候也不需要長篇大論砚嘴，這樣的文檔是不歡迎的十酣，受歡迎的文檔只需寫出用例分析涩拙，表設計，復雜的邏輯需要畫出流程序列圖耸采。

• 結對編程兴泥。之前這個編程模式被無數(shù)人調侃過，其實也不可能讓每一個項目全程都是兩個人結對編程虾宇。這個不現(xiàn)實也浪費資源搓彻。我們的結對是在大家開發(fā)一個難點模塊時，會給結對的人增加一項任務去配合其他開發(fā)一起完成這個任務嘱朽。其實我們在開發(fā)時旭贬，很多時候都會結對，比如指導新同事搪泳、討論設計模塊稀轨，而之前這些都沒有算在我們的開發(fā)工作量里。

• 項目演示和總結會議岸军。在項目結束后奋刽，讓所有參與項目的成員都參加，一起演示給客戶展示艰赞，并解答客戶的問題佣谐，充分讓大家感受到收獲的果實〔粒總結會議主要對于這個sprint中大家遇到的問題和經(jīng)驗分享台谍，并為下一個sprint做準備。

經(jīng)過敏捷實施后吁断，我們的生產(chǎn)力提高了很多趁蕊，員工的積極性提高了，業(yè)務的參與使整體需求把控也很好仔役，大家溝通多了掷伙，30天的任務提前了5天完成。我們多出來的時間又兵，讓大家每周有一天或者半天研究自己感興趣的領域任柜，但是這些研究最終必須體現(xiàn)出成果。比如后臺開發(fā)想研究一個新技術沛厨，最后做完需要寫個ppt給大家分享下宙地。既能讓大家做自己想做的事情，也給大家創(chuàng)造了一個互相學習的氛圍逆皮。

ps：所有的模式都不應該是教條的模式宅粥，先進的模式并不是好的模式，適合自己的才是最好的电谣。套用一句俗話：不管黑貓白貓抓得住耗子的才是好貓秽梅。