創業公司如何實施敏捷開發(轉載)

　　 轉載自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人天，這看起來是一個不可完成的任務。

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

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

 

　　

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

　　爲何會失敗呢？後來思考了這些問題：

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

　　二、需求不穩定，變化後改動代價大。因爲創業，需求爲了適應市場會常常調整，可是一但調整，不少開發計劃就會受到相應的調整。若是部分功能已經正在開發，調整需求後不少工做要從新開始，嚴重影響了技術同事積極性。業務不調整需求是不可能的，他們是爲了知足用戶的要求，用戶滿意了才能給企業帶來價值。不過若是調整，代價太大，不少代碼要重寫，你們就會責怪技術總監或者項目負責人沒有把握好需求。

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

　　四、交付軟件質量差，離用戶指望差距大。創業時你們的想法都是好的，大幹一番，作一個全部人都愛使用的產品。現實是殘酷的，你們辛辛苦苦作出來的東西，老闆不滿意、用戶不埋單，付出的努力沒有人承認。交付的軟件沒時間自測試，或者自測試不充分，交給測試又是一大堆問題。有些公司尚未測試，直接出去給用戶，至關危險。這樣交出去的公司不只僅影響了用戶的使用，還影響了整個公司的口碑。

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

　　嘗試二，敏捷開發模式。敏捷開發是一種以人爲核心、迭代、按部就班的開發方法。敏捷方法強調以人爲本，專一於交付對客戶有價值的軟件。在高度協做的開環境中，使用迭代式的方式進行增量開發，常用反饋進行思考、檢討和總結，不停的進行自我調整和完善。

　　敏捷開發的主旨：

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

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

　　

　　敏捷開發簡單流程：

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

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

　　一、推廣敏捷開發理念。無論是大公司仍是小公司強制推行一項制度效果通常都不怎麼好。要能推行下去的任何東西必定要你們接受的，才能被承認。

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

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

　　三、敏捷項目實施。整個公司創建以業務目標爲導向的氛圍。就以「項目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：全部的模式都不該該是教條的模式，先進的模式並非好的模式，適合本身的纔是最好的。套用一句俗話：無論黑貓白貓抓得住耗子的纔是好貓。