轉載自LANCEYAN.COM

　　說起敏捷開發，並不是因為敏捷而敏捷。這幾年的敏捷開發已經被很多敏捷諮詢服務商神話了，這個東西並不是神器，實施了就可以解決所有軟體公司的問題，而是要結合自己公司的特點和問題摸索出適合自己的一套模式。

　　大家都知道，創業公司剛開始需要研發出一款產品並且能夠使公司賺錢的產品，不過大部分創業公司沒有那麼容易一下就能做出來，很多公司還沒有成功的產品資金鍊就斷掉了，公司也死掉了。我們公司是這樣一個狀況，有一條產品線可以維持公司開支並僅僅剛夠盈餘，要擴大高速發展還不夠，一直維持就沒有創業的意義。另一條線是做技術創新為未來能夠開發一款人氣爆棚的產品摸索著，但是又不能餓著肚子去開發。我們是如何結合自身的特點實施敏捷開發的呢？一個難題，很大的難題！

　　我們技術團隊人員是這樣的配置：1名技術總監、2名資深開發工程師、1名高階開發工程師、2名潛力開發工程師、1名前端開發、1名測試。技術總監需要處理很多團隊管理、客戶管理的工作，能夠參與專案的時間最多每天二分之一。2名資深開發需要負責給其他工程師做導師，參與新專案開發時間大概有80%。高階工程師要預留專案學習時間，參與專案的時間大概有90%。潛力開發工程師需要有一些時間學習技術和專案，但是基本可以做到70%的時間投入專案。前端開發和測試哪裡有需要就在哪裡革命，屬於機動部隊。

　　現在總共有六個老專案在維護，兩個新專案需要開發。六個專案的維護總共需要每週4人天時間（人天指需要花1個人4天的時間完成一個事情）。其中一個新專案“專案1”大概估計120人天的開發時間，需要1個月之內開發完成。“專案2”大概估計要40人天的開發時間，需要2周開發完成。而現在的人力按照能夠投入的時間算一下，總共資源為 (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人天，這看起來是一個不可完成的任務。

　　不過到最後，我們還是使用敏捷開發完成了這兩個專案，也沒有影響老專案的維護。我們是怎麼操作的？最開始我們兩個開發，這個時候只要兩個人就能夠很好的合作把產品開發出來，不需要什麼模式。隨著人員的擴充，團隊間如何協作按時按質按量完成任務就需要好好思考下了。

　　嘗試一，傳統軟體開發模式。整個過程為 需求分析、系統設計、任務分解計劃安排、開發設計、編碼、測試、交付、驗收、維護。這個模式也是大家最常使用的模式，不過套用在我們公司時我們是這麼操作的。

　　由於公司創業，老闆有一個想法，但並不能很好的描述需求，所以需求分析的任務落在技術總監身上。系統設計和任務分解剛開始是技術總監完成，後面資深開發工程師可以承擔一部分。開發設計可以讓各個開發工程師完成，資深工程師進行把關，再到測試人員測試，最後再交付使用者驗收、技術維護。看起來很好的模式，開發了幾個產品最終有的延時有的產品離使用者的期望差距甚遠，參與專案團隊的人信心受挫。

　　為什麼會失敗呢？後來思考了這些問題：

　　1、技術總監不是產品經理，不能夠承擔產品設計的責任。老闆是信任技術總監能做好產品，就交給他做。但這裡搞混了一個概念，產品經理和專案經理，技術總監應該起到專案經理和架構師的作用。專案經理管控專案進度和計劃、架構師把握整體技術問題。而技術總監接到這個任務又不能不做好，責任所在。說到底，就是機制沒有把產品設計和專案經理區分開，不等於技術實現者就是產品設計者。更多的應該讓老闆或者其他業務人員承擔產品設計的工作。

　　2、需求不穩定，變化後改動代價大。由於創業，需求為了適應市場會經常調整，但是一但調整，很多開發計劃就會受到相應的調整。如果部分功能已經正在開發，調整需求後很多工作要重新開始，嚴重影響了技術同事積極性。業務不調整需求是不可能的，他們是為了滿足使用者的要求，使用者滿意了才能給企業帶來價值。不過如果調整，代價太大，很多程式碼要重寫，大家就會責怪技術總監或者專案負責人沒有把握好需求。

　　3、團隊經常加班，但戰鬥力不強。 核心團隊疲於應對需求、技術開發、老系統維護，沒時間指導新同事技術學習，而新同事技能暫時還沒有發揮出來幹活效率低，任務經常延期，沒有成就感。核心團隊事情很多，沒有時間整理專案文件，新員工沒有文件上手慢。大家每天很多事情，需要加班才能完成，比較疲憊。每個人除了工作還有很多事情需要做，比如回家看看電視、陪陪家人、看看書學習一下等。如果讓一個員工一天二十四小時都是工作，他能同意，他家人也不一定同意。讓大家愉悅的開發，比疲憊的上班效率要高很多。

　　4、交付軟體質量差，離使用者期望差距大。創業時大家的想法都是好的，大幹一番，做一個所有人都愛使用的產品。現實是殘酷的，大家辛辛苦苦做出來的東西，老闆不滿意、使用者不埋單，付出的努力沒有人認可。交付的軟體沒時間自測試，或者自測試不充分，交給測試又是一大堆問題。有些公司還沒有測試，直接出去給使用者，相當危險。這樣交出去的公司不僅僅影響了使用者的使用，還影響了整個公司的口碑。

不是說傳統軟體開發模式不好，只是不太適合我們這種創業公司。開始嘗試其他模式，如果沒有一個很好的體制就不能把大家的最大生產力發揮出來。

　　嘗試二，敏捷開發模式。敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。敏捷方法強調以人為本，專注於交付對客戶有價值的軟體。在高度協作的開環境中，使用迭代式的方式進行增量開發，經常使用反饋進行思考、反省和總結，不停的進行自我調整和完善。

　　敏捷開發的主旨：

　　一：個體及互動比流程與工具更具價值
　　二：可用的軟體比冗長的文件更有價值
　　三：與客戶的協作比合同談判更有價值
　　四：對變化的響應比遵循計劃更有價值

　　而我們之前的問題，交付軟體客戶不滿意、延期、需求更改代價大貌似都可以解決。這麼好的模式趕緊要試試，先看一張敏捷開發的流程圖。

　　敏捷開發簡單流程：

　　1、產品負責人將整個產品設計成產品backlog。產品backlog就是一個個需求列表。（backlog可以理解為需求或者要做的事情）
　　2、召開產品backlog計劃會議，預估每個backlog的時間，確定哪些backlog是需要在第一個sprint中完成的，即sprint的backlog。（sprint可以理解為一個團隊一起開發的一個任務集合）
　　3、把sprint的backlog寫在紙條上貼在任務牆，讓大家認領分配。（任務牆就是把 未完成、正在做、已完成 的工作狀態貼到一個牆上，這樣大家都可以看得到任務的狀態 ）
　　4、舉行每日站立會議，讓大家在每日會議上總結昨天做的事情、遇到什麼困難，今天開展什麼任務。（每日站立會議，是在每天早上定時和大家在任務牆前站立討論，時間控制在15分鐘內）
　　5、繪製燃盡圖，保證任務的概況能夠清晰看到。（燃盡圖把當前的任務總數和日期一起繪製，每天記錄一下，可以看到每天還剩多少個任務，直到任務數為0 ，這個sprint就完成了）
　　6、sprint評審會議是在sprint完成時舉行，要向客戶演示自己完成的軟體產品 。
　　7、最後是sprint總結會議，以輪流發言方式進行，每個人都要發言，總結上一次sprint中遇到的問題、改進和大家分享討論。

　　我們怎麼結合敏捷開發解決現有專案的問題，要記得任何措施都是為了保證按時按質按量把軟體交付給使用者，不要為了敏捷而教條實施敏捷，公司不能產生商業價值，任何先進的理念或者技術都是無意義的。我們做了這些措施：

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

• 首先培養測試小妹學習敏捷開發，後續讓她承擔部分產品責任人和敏捷指導者的角色，原因有：
  a、測試要驗收功能，必須理解業務需求。
  b、測試也是QA質量體系的一塊，學習好了對於軟體質量有個更深的認識。
  c、團隊大部分是男生，女生推廣更有親和力一些。
• 召集所有技術團隊開會準備推廣。開始和測試小妹好好討論下，怎麼給大家說更有效，更容易接受。她要講解一定要自己非常清楚敏捷開發，並且準備充分知識點。開會時先指出我們現在問題，讓大家看看有什麼想法解決問題嗎？現在我們做的產品，客戶不認可、老闆不滿意、自己很累沒有成就感，有什麼辦法解決。在大家討論後，丟擲敏捷開發的優勢，一般情況下大家都會認可的。大家可能會問到如何執行、落地，可以嘗試找一個專案試點，如果實施成功就可以讓大家全面推廣，不成功也隻影響了部分專案。

　　2、搭建敏捷開發環境。大家要實施敏捷開發，需要比較好的基礎條件保證敏捷開發順利進行。主要幾個關鍵的軟體：nexus 搭建倉庫依賴中心、maven 管理工程的依賴、jenkins 持續整合和自動編譯釋出、svn 集中程式碼管理、jira 記錄需求和狀態。具體參考《敏捷開發環境搭建》。

　　3、敏捷專案實施。整個公司建立以業務目標為導向的氛圍。就以“專案1”來說，目的是完成這個專案，需要進行這幾步：

• 先根據各自的能力和意向聚集一批完成這個目標的勇士，不管技術和非技術。如果聚集的人不夠，技術總監可以根據總體專案的投入機動調整資源以支援，不過條件允許的話還是根據大家意願來聚集。最終“專案1”召集了一個技術總監、一個資深開發、兩個潛力開發、一個前端、一個測試，除去大家做其他事情的時間，總共可以算作4個人。
• 充分調動客戶（老闆和業務同事）參與進專案，他們的參與直接決定了專案成功與否。結合之前的經驗，如果他們參與不夠，最終做出來的東西就不是他們要的，或者離他們要的差距很大。他們剛開始加入的時候，很迷茫有時會表現的比較抗拒，這個時候一定要耐心堅持讓大家把第一個sprint開發成功，使大家嚐到甜頭。讓他們全程參與專案也是表示了我們擁抱變化，如果有需求變化，就新增任務到任務牆，大家可以對所有任務的時間有個全面瞭解，如果超過sprint結束時間就需要業務決策哪些功能不在這個sprint週期加入。
• 技術總監安排和客戶溝通，客戶這裡指老闆和業務。測試小妹負責和客戶溝通記錄，技術總監輔助。多次溝通後，嘗試讓測試把需求原型用最簡單的工具繪製出來，技術總監稽核通過後和客戶溝通確認，反覆迭代，直到整個需求大家沒有異議。很多公司這種需求是有一個專門產品負責人來執行，但按照我們目前的人力是沒辦法做到的。這裡沒有讓技術總監做主要是為了避免之前出現的問題，過度技術設計產品。
• 產品設計出來後，召集專案成員分解任務，確定每個任務的時間，可以使用敏捷撲克牌來估計。任務分解儘量控制在1-2天的粒度，這樣大家1-2天就可以做出一個能測試的原型，儘早可以整合測試發現問題。一個sprint的任務集合儘量控制在1-2周，不能太長，也不能太短。太長會出現疲勞，太短的sprint會讓大家覺得工作太多，做完一個又一個。“專案1”估算結果為120人天，總共投入4個人，需要30天4周時間，我們切成了4個sprint，差不多1個月時間完成，滿足業務的時間要求。
• 分階段實施sprint，繪製任務牆，劃分未開始、已計劃、進行中、完成、燃盡圖。把要做的sprint任務上牆，貼到未開始的地方.

• 每日站立會議大家認領任務。包括業務任務、開發設計、開發編碼、前端設計開發、測試等都是一個個任務，統一管理起來。強調的是一個團體，如果有同事請假，其他同事可以頂上完成任務。站立會議總結昨天的任務是否有問題，對於當前的任務有什麼建議，儘量控制在15分鐘內，有效會議。這裡不會像以前業務或者專案經理追著大家屁股要結果，而是團隊驅動，每天大家做的事情都反映在牆上，誰出現了什麼狀況，大家都會幫他想辦法，保證整個專案能夠成功。每一個任務完成，由專案執行者把任務從進行中貼到完成區域。再從未分配區域認領新任務貼到進行中的區域。
• 軟體開發過程。認領任務後，怎麼保證大家開發有質量的程式碼？團隊有資深點的工程師，不需要太多指導，直接可以參與專案的開發。而學習型工程師，需要指導幫助才能一步步做用例、系統分析。技術總監不建議認領太多開發任務，他負責開發團隊的概要設計稽核，沒有稽核通過的設計不能開發，並指導大家分析和設計系統。大家都知道，系統思路有了，剩下就是技術實現的過程，只要技能掌握熟練實現基本難度不大。大家可能會問，敏捷開發不是強調軟體開發的產品是軟體，而不是文件嗎？我們這裡也不是像傳統開發軟體一樣為了文件而文件，只是讓大家把自己的設計思路寫下來，只有經過自己仔細設計後才能把思路清晰的寫下來。大家寫的時候也不需要長篇大論，這樣的文件是不歡迎的，受歡迎的文件只需寫出用例分析，表設計，複雜的邏輯需要畫出流程式列圖。
• 結對程式設計。之前這個程式設計模式被無數人調侃過，其實也不可能讓每一個專案全程都是兩個人結對程式設計。這個不現實也浪費資源。我們的結對是在大家開發一個難點模組時，會給結對的人增加一項任務去配合其他開發一起完成這個任務。其實我們在開發時，很多時候都會結對，比如指導新同事、討論設計模組，而之前這些都沒有算在我們的開發工作量裡。

• 專案演示和總結會議。在專案結束後，讓所有參與專案的成員都參加，一起演示給客戶展示，並解答客戶的問題，充分讓大家感受到收穫的果實。總結會議主要對於這個sprint中大家遇到的問題和經驗分享，併為下一個sprint做準備。

　　經過敏捷實施後，我們的生產力提高了很多，員工的積極性提高了，業務的參與使整體需求把控也很好，大家溝通多了，30天的任務提前了5天完成。我們多出來的時間，讓大家每週有一天或者半天研究自己感興趣的領域，但是這些研究最終必須體現出成果。比如後臺開發想研究一個新技術，最後做完需要寫個ppt給大家分享下。既能讓大家做自己想做的事情，也給大家創造了一個互相學習的氛圍。

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