導讀：說起敏捷開發，并不是因為敏捷而敏捷。這幾年的敏捷開發已經被很多敏捷咨詢服務商神話了，這個東西并不是神器，實施了就可以解決所有軟件公司的問題，而是要結合自己公司的特點和問題摸索出適合自己的一套模式。
大家都知道，創業公司剛開始需要研發出一款產品并且能夠使公司賺錢的產品，不過大部分創業公司沒有那么容易一下就能做出來，很多公司還沒有成功的產品資金鏈就斷掉了，公司也死掉了。我們公司是這樣一個狀況，有一條產品線可以維持公司開支并僅僅剛夠盈余，要擴大高速發展還不夠，一直維持就沒有創業的意義。另一條線是做技術創新為未來能夠開發一款人氣爆棚的產品摸索著，但是又不能餓著肚子去開發。我們是如何結合自身的特點實施敏捷開發的呢?一個難題，很大的難題!
我們技術團隊人員是這樣的配置：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就完成了)
想認識全國各地的創業者、創業專家，快來加入“中國創業圈”
|
