6、sprint評審會議是在sprint完成時舉行，要向客戶演示自己完成的軟件產(chǎn)品 。
7、最后是sprint總結(jié)會議，以輪流發(fā)言方式進行，每個人都要發(fā)言，總結(jié)上一次sprint中遇到的問題、改進和大家分享討論。
我們怎么結(jié)合敏捷開發(fā)解決現(xiàn)有項目的問題，要記得任何措施都是為了保證按時按質(zhì)按量把軟件交付給用戶，不要為了敏捷而教條實施敏捷，公司不能產(chǎn)生商業(yè)價值，任何先進的理念或者技術(shù)都是無意義的。我們做了這些措施：
1、推廣敏捷開發(fā)理念。不管是大公司還是小公司強制推行一項制度效果一般都不怎么好。要能推行下去的任何東西一定要大家接受的，才能被認(rèn)可。
首先培養(yǎng)測試小妹學(xué)習(xí)敏捷開發(fā)，后續(xù)讓她承擔(dān)部分產(chǎn)品責(zé)任人和敏捷指導(dǎo)者的角色，原因有：
a、測試要驗收功能，必須理解業(yè)務(wù)需求。
b、測試也是QA質(zhì)量體系的一塊，學(xué)習(xí)好了對于軟件質(zhì)量有個更深的認(rèn)識。
c、團隊大部分是男生，女生推廣更有親和力一些。
召集所有技術(shù)團隊開會準(zhǔn)備推廣。開始和測試小妹好好討論下，怎么給大家說更有效，更容易接受。她要講解一定要自己非常清楚敏捷開發(fā)，并且準(zhǔn)備充分知識點。開會時先指出我們現(xiàn)在問題，讓大家看看有什么想法解決問題嗎?現(xiàn)在我們做的產(chǎn)品，客戶不認(rèn)可、老板不滿意、自己很累沒有成就感，有什么辦法解決。在大家討論后，拋出敏捷開發(fā)的優(yōu)勢，一般情況下大家都會認(rèn)可的。大家可能會問到如何執(zhí)行、落地，可以嘗試找一個項目試點，如果實施成功就可以讓大家全面推廣，不成功也只影響了部分項目。
2、搭建敏捷開發(fā)環(huán)境。大家要實施敏捷開發(fā)，需要比較好的基礎(chǔ)條件保證敏捷開發(fā)順利進行。主要幾個關(guān)鍵的軟件：nexus 搭建倉庫依賴中心、maven 管理工程的依賴、jenkins 持續(xù)集成和自動編譯發(fā)布、svn 集中代碼管理、jira 記錄需求和狀態(tài)。具體參考《敏捷開發(fā)環(huán)境搭建》。
3、敏捷項目實施。整個公司建立以業(yè)務(wù)目標(biāo)為導(dǎo)向的氛圍。就以“項目1”來說，目的是完成這個項目，需要進行這幾步：
先根據(jù)各自的能力和意向聚集一批完成這個目標(biāo)的勇士，不管技術(shù)和非技術(shù)。如果聚集的人不夠，技術(shù)總監(jiān)可以根據(jù)總體項目的投入機動調(diào)整資源以支持，不過條件允許的話還是根據(jù)大家意愿來聚集。最終“項目1”召集了一個技術(shù)總監(jiān)、一個資深開發(fā)、兩個潛力開發(fā)、一個前端、一個測試，除去大家做其他事情的時間，總共可以算作4個人。
充分調(diào)動客戶(老板和業(yè)務(wù)同事)參與進項目，他們的參與直接決定了項目成功與否。結(jié)合之前的經(jīng)驗，如果他們參與不夠，最終做出來的東西就不是他們要的，或者離他們要的差距很大。他們剛開始加入的時候，很迷茫有時會表現(xiàn)的比較抗拒，這個時候一定要耐心堅持讓大家把第一個sprint開發(fā)成功，使大家嘗到甜頭。讓他們?nèi)虆⑴c項目也是表示了我們擁抱變化，如果有需求變化，就添加任務(wù)到任務(wù)墻，大家可以對所有任務(wù)的時間有個全面了解，如果超過sprint結(jié)束時間就需要業(yè)務(wù)決策哪些功能不在這個sprint周期加入Cye.com.cn。
技術(shù)總監(jiān)安排和客戶溝通，客戶這里指老板和業(yè)務(wù)。測試小妹負(fù)責(zé)和客戶溝通記錄，技術(shù)總監(jiān)輔助。多次溝通后，嘗試讓測試把需求原型用最簡單的工具繪制出來，技術(shù)總監(jiān)審核通過后和客戶溝通確認(rèn)，反復(fù)迭代，直到整個需求大家沒有異議。很多公司這種需求是有一個專門產(chǎn)品負(fù)責(zé)人來執(zhí)行，但按照我們目前的人力是沒辦法做到的。這里沒有讓技術(shù)總監(jiān)做主要是為了避免之前出現(xiàn)的問題，過度技術(shù)設(shè)計產(chǎn)品。
產(chǎn)品設(shè)計出來后，召集項目成員分解任務(wù)，確定每個任務(wù)的時間，可以使用敏捷撲克牌來估計。任務(wù)分解盡量控制在1-2天的粒度，這樣大家1-2天就可以做出一個能測試的原型，盡早可以集成測試發(fā)現(xiàn)問題。一個sprint的任務(wù)集合盡量控制在1-2周，不能太長，也不能太短。太長會出現(xiàn)疲勞，太短的sprint會讓大家覺得工作太多，做完一個又一個。“項目1”估算結(jié)果為120人天，總共投入4個人，需要30天4周時間，我們切成了4個sprint，差不多1個月時間完成，滿足業(yè)務(wù)的時間要求。
分階段實施sprint，繪制任務(wù)墻，劃分未開始、已計劃、進行中、完成、燃盡圖。把要做的sprint任務(wù)上墻，貼到未開始的地方。
創(chuàng)業(yè)公司敏捷開發(fā)任務(wù)墻
每日站立會議大家認(rèn)領(lǐng)任務(wù)。包括業(yè)務(wù)任務(wù)、開發(fā)設(shè)計、開發(fā)編碼、前端設(shè)計開發(fā)、測試等都是一個個任務(wù)，統(tǒng)一管理起來。強調(diào)的是一個團體，如果有同事請假，其他同事可以頂上完成任務(wù)。站立會議總結(jié)昨天的任務(wù)是否有問題，對于當(dāng)前的任務(wù)有什么建議，盡量控制在15分鐘內(nèi)，有效會議。這里不會像以前業(yè)務(wù)或者項目經(jīng)理追著大家屁股要結(jié)果，而是團隊驅(qū)動，每天大家做的事情都反映在墻上，誰出現(xiàn)了什么狀況，大家都會幫他想辦法，保證整個項目能夠成功。每一個任務(wù)完成，由項目執(zhí)行者把任務(wù)從進行中貼到完成區(qū)域。再從未分配區(qū)域認(rèn)領(lǐng)新任務(wù)貼到進行中的區(qū)域。
軟件開發(fā)過程。認(rèn)領(lǐng)任務(wù)后，怎么保證大家開發(fā)有質(zhì)量的代碼?團隊有資深點的工程師，不需要太多指導(dǎo)，直接可以參與項目的開發(fā)。而學(xué)習(xí)型工程師，需要指導(dǎo)幫助才能一步步做用例、系統(tǒng)分析。技術(shù)總監(jiān)不建議認(rèn)領(lǐng)太多開發(fā)任務(wù)，他負(fù)責(zé)開發(fā)團隊的概要設(shè)計審核，沒有審核通過的設(shè)計不能開發(fā)，并指導(dǎo)大家分析和設(shè)計系統(tǒng)。大家都知道，系統(tǒng)思路有了，剩下就是技術(shù)實現(xiàn)的過程，只要技能掌握熟練實現(xiàn)基本難度不大。大家可能會問，敏捷開發(fā)不是強調(diào)軟件開發(fā)的產(chǎn)品是軟件，而不是文檔嗎?我們這里也不是像傳統(tǒng)開發(fā)軟件一樣為了文檔而文檔，只是讓大家把自己的設(shè)計思路寫下來，只有經(jīng)過自己仔細(xì)設(shè)計后才能把思路清晰的寫下來。大家寫的時候也不需要長篇大論，這樣的文檔是不歡迎的，受歡迎的文檔只需寫出用例分析，表設(shè)計，復(fù)雜的邏輯需要畫出流程序列圖。
結(jié)對編程。之前這個編程模式被無數(shù)人調(diào)侃過，其實也不可能讓每一個項目全程都是兩個人結(jié)對編程。這個不現(xiàn)實也浪費資源。我們的結(jié)對是在大家開發(fā)一個難點模塊時，會給結(jié)對的人增加一項任務(wù)去配合其他開發(fā)一起完成這個任務(wù)。其實我們在開發(fā)時，很多時候都會結(jié)對，比如指導(dǎo)新同事、討論設(shè)計模塊，而之前這些都沒有算在我們的開發(fā)工作量里。
創(chuàng)業(yè)公司敏捷開發(fā)結(jié)對編程
項目演示和總結(jié)會議。在項目結(jié)束后，讓所有參與項目的成員都參加，一起演示給客戶展示，并解答客戶的問題，充分讓大家感受到收獲的果實。總結(jié)會議主要對于這個sprint中大家遇到的問題和經(jīng)驗分享，并為下一個sprint做準(zhǔn)備。
經(jīng)過敏捷實施后，我們的生產(chǎn)力提高了很多，員工的積極性提高了，業(yè)務(wù)的參與使整體需求把控也很好，大家溝通多了，30天的任務(wù)提前了5天完成。我們多出來的時間，讓大家每周有一天或者半天研究自己感興趣的領(lǐng)域，但是這些研究最終必須體現(xiàn)出成果。比如后臺開發(fā)想研究一個新技術(shù)，最后做完需要寫個ppt給大家分享下。既能讓大家做自己想做的事情，也給大家創(chuàng)造了一個互相學(xué)習(xí)的氛圍。
ps：所有的模式都不應(yīng)該是教條的模式，先進的模式并不是好的模式，適合自己的才是最好的。套用一句俗話：不管黑貓白貓抓得住耗子的才是好貓。
想認(rèn)識全國各地的創(chuàng)業(yè)者、創(chuàng)業(yè)專家，快來加入“中國創(chuàng)業(yè)圈”
|
