6、sprint評審會議是在sprint完成時舉行，要向客戶演示自己完成的軟件產品 。
7、最后是sprint總結會議，以輪流發言方式進行，每個人都要發言，總結上一次sprint中遇到的問題、改進和大家分享討論。
我們怎么結合敏捷開發解決現有項目的問題，要記得任何措施都是為了保證按時按質按量把軟件交付給用戶，不要為了敏捷而教條實施敏捷，公司不能產生商業價值，任何先進的理念或者技術都是無意義的。我們做了這些措施：
1、推廣敏捷開發理念。不管是大公司還是小公司強制推行一項制度效果一般都不怎么好。要能推行下去的任何東西一定要大家接受的，才能被認可。
首先培養測試小妹學習敏捷開發，后續讓她承擔部分產品責任人和敏捷指導者的角色，原因有：
a、測試要驗收功能，必須理解業務需求。
b、測試也是QA質量體系的一塊，學習好了對于軟件質量有個更深的認識。
c、團隊大部分是男生，女生推廣更有親和力一些。
召集所有技術團隊開會準備推廣。開始和測試小妹好好討論下，怎么給大家說更有效，更容易接受。她要講解一定要自己非常清楚敏捷開發，并且準備充分知識點。開會時先指出我們現在問題，讓大家看看有什么想法解決問題嗎?現在我們做的產品，客戶不認可、老板不滿意、自己很累沒有成就感，有什么辦法解決。在大家討論后，拋出敏捷開發的優勢，一般情況下大家都會認可的。大家可能會問到如何執行、落地，可以嘗試找一個項目試點，如果實施成功就可以讓大家全面推廣，不成功也只影響了部分項目。
2、搭建敏捷開發環境。大家要實施敏捷開發，需要比較好的基礎條件保證敏捷開發順利進行。主要幾個關鍵的軟件：nexus 搭建倉庫依賴中心、maven 管理工程的依賴、jenkins 持續集成和自動編譯發布、svn 集中代碼管理、jira 記錄需求和狀態。具體參考《敏捷開發環境搭建》。
3、敏捷項目實施。整個公司建立以業務目標為導向的氛圍。就以“項目1”來說，目的是完成這個項目，需要進行這幾步：
先根據各自的能力和意向聚集一批完成這個目標的勇士，不管技術和非技術。如果聚集的人不夠，技術總監可以根據總體項目的投入機動調整資源以支持，不過條件允許的話還是根據大家意愿來聚集。最終“項目1”召集了一個技術總監、一個資深開發、兩個潛力開發、一個前端、一個測試，除去大家做其他事情的時間，總共可以算作4個人。
充分調動客戶(老板和業務同事)參與進項目，他們的參與直接決定了項目成功與否。結合之前的經驗，如果他們參與不夠，最終做出來的東西就不是他們要的，或者離他們要的差距很大。他們剛開始加入的時候，很迷茫有時會表現的比較抗拒，這個時候一定要耐心堅持讓大家把第一個sprint開發成功，使大家嘗到甜頭。讓他們全程參與項目也是表示了我們擁抱變化，如果有需求變化，就添加任務到任務墻，大家可以對所有任務的時間有個全面了解，如果超過sprint結束時間就需要業務決策哪些功能不在這個sprint周期加入Cye.com.cn。
技術總監安排和客戶溝通，客戶這里指老板和業務。測試小妹負責和客戶溝通記錄，技術總監輔助。多次溝通后，嘗試讓測試把需求原型用最簡單的工具繪制出來，技術總監審核通過后和客戶溝通確認，反復迭代，直到整個需求大家沒有異議。很多公司這種需求是有一個專門產品負責人來執行，但按照我們目前的人力是沒辦法做到的。這里沒有讓技術總監做主要是為了避免之前出現的問題，過度技術設計產品。
產品設計出來后，召集項目成員分解任務，確定每個任務的時間，可以使用敏捷撲克牌來估計。任務分解盡量控制在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：所有的模式都不應該是教條的模式，先進的模式并不是好的模式，適合自己的才是最好的。套用一句俗話：不管黑貓白貓抓得住耗子的才是好貓。
想認識全國各地的創業者、創業專家，快來加入“中國創業圈”
|
