敏捷開發(fā)一千零一夜

前言

前些日子，有人在微博上發(fā)文說，現(xiàn)在IT界有三大俗：云計算、大數(shù)據(jù)、敏捷，這從一個側(cè)面反映出了敏捷的熱度！如果你最近一年內(nèi)參加過各類IT過程改進(jìn)大會、測試大會、研發(fā)管理大會、案例研討大會，一定會發(fā)現(xiàn)有很多人在講敏捷、談敏捷，而且占據(jù)的場次越來越多。以前是我們這些所謂的敏捷狂熱分子在講，現(xiàn)在連一些CMMI／PMP死硬分子也加入進(jìn)來講。敏捷讓以前的CMMI／PMP陣營不得不做出調(diào)整，PMP搞了敏捷的認(rèn)證，CMMI新出了1．3版，據(jù)說里面有97處提到了敏捷……這從另外的角度說明敏捷的確已經(jīng)入“俗”。中國人素來講究雅俗共賞，在這個越來越“俗”的過程中，我們該怎么保持那份“雅”呢？希望大家在看熱鬧、參與熱鬧的同時，能夠冷靜地思考，敏捷到底能為我們帶來什么？我們該如何變得敏捷？敏捷又將何去何從？大師們也在思考，2011年，敏捷10年回顧的時候，將“追求技術(shù)卓越”放在了第一的位置；10年之后，敏捷又將如何呢？著名敏捷大師Mike Cohn認(rèn)為：“在接下來的10年，面向?qū)ο笫澜缰邪l(fā)生的事情會再次出現(xiàn)，即我們將不再討論敏捷。不久前我們不再討論對象了，因為它們已經(jīng)勝出，沒有人再會參加針對面向?qū)ο蟮拇笮娃q論。當(dāng)然，還有一些應(yīng)用我們不使用對象，比如有嚴(yán)格性能要求的應(yīng)用，也有些項目是用非OO語言開發(fā)的。但即使在這些案例中，我也懷疑開發(fā)的代碼仍然受到對象的影響。我希望敏捷也能達(dá)到這一點(diǎn)，我們不再討論敏捷，不再說‘敏捷軟件開發(fā)’，我們僅僅說‘軟件開發(fā)’，當(dāng)然一定是敏捷的。沒有人會問我編寫的Ruby代碼是否面向?qū)ο?，因為這毋庸置疑；我希望某一天也沒有人問我項目中是否使用了敏捷，這也將會毋庸置疑。”在過去幾年中，我們給客戶做敏捷培訓(xùn)時，收集到的最多的反饋之一，莫過于學(xué)員想聽到更多的敏捷實施案例。于是，慢慢地就有了收集各類敏捷實施案例的想法，并日漸強(qiáng)烈起來。畢竟，每個人都有偷窺別人隱私的好奇心，不然Twitter、微博也就不會這么火了。同理，正在實施敏捷的人，無論自己做得好的，做得不好的，其實都希望看到同行是怎么做的。馮國馨，作為PMBar IT項目管理公益實踐社區(qū)發(fā)起人，在社區(qū)內(nèi)外的各種敏捷分享和交流過程中，看到大家也非常希望了解、學(xué)習(xí)和探討國內(nèi)不同IT行業(yè)、不同特點(diǎn)IT企業(yè)敏捷開發(fā)的真實案例。加之，2011年8月PMBar社區(qū)推出的第一部實踐案例書籍《IT項目管理那些事兒》在社會上反響熱烈，至今圖書熱賣萬余冊。這些極大地增強(qiáng)了我們進(jìn)一步開展敏捷實踐案例書籍撰寫的信心！于是，在王立杰的協(xié)調(diào)下，PMBar社區(qū)內(nèi)外的十幾位敏捷專家決定共同分享自己的敏捷實踐案例，希望通過出書使行業(yè)內(nèi)的敏捷實踐者或敏捷觀望者有所借鑒和體悟。本書采用的是敘事的風(fēng)格，通過分享每個敏捷實踐者自身的實踐案例，為讀者展現(xiàn)一個個鮮活的敏捷實施過程，展示敏捷團(tuán)隊的成長煩惱和喜悅，從而和讀者達(dá)到共鳴。這是一個百花齊放、精彩紛呈的故事集，就像《一千零一夜》一樣，有十幾位作者，他們中有來自國際著名IT公司的敏捷專家、有來自國內(nèi)著名電商的敏捷教練、有來自大型國有企業(yè)的IT總監(jiān)、有民營高科技企業(yè)技術(shù)管理者，有純粹的敏捷實踐者、也有CMMI／敏捷融合實踐者等，他們以不同的經(jīng)歷、用不同風(fēng)格的言語，為我們描述一個又一個精彩的敏捷開發(fā)故事。感謝本書編委會全體成員（王立杰、馮國馨、許舟平、陳勇、楊立東、張克強(qiáng)、楊瑞、杜偉忠、鄭賀宸、蔡阿彬、胡峰、范佳瑩、馬越、史昀）的共同努力，因為他們的努力才有了這本書的誕生。感謝電子工業(yè)出版社博文視點(diǎn)的張月萍，她的“博文視點(diǎn)除了盈利的任務(wù)外，還承擔(dān)著教育用戶、傳播思想的重任！”一句話為《敏捷開發(fā)一千零一夜》這本書畫龍點(diǎn)睛。我們希望這本書能啟迪正在或者準(zhǔn)備開展敏捷實踐的讀者，如果它幫助你加快了敏捷步伐，那就是我們最大的欣慰。再次，真心感謝曾經(jīng)為此書勞心勞力的各位朋友，愿天下人幸福安康。編者

內(nèi)容概要

本書以多位作者的親身經(jīng)歷，再現(xiàn)真實的敏捷實施過程，描述各個企業(yè)在實施敏捷的過程中，遇到的種種問題、解決的思路及最終得到的經(jīng)驗與教訓(xùn)。這本案例集從不同的視角，為讀者展示從大型互聯(lián)網(wǎng)企業(yè)到初創(chuàng)公司、從大型國企到獨(dú)資外企、從典型的甲方到第三方咨詢公司的敏捷歷程。這里面既有大的組織的敏捷轉(zhuǎn)型，也有一個小團(tuán)隊或個人的敏捷歷程，還涵蓋某個敏捷實踐或工具的應(yīng)用描述。
本書的特色在于由真實實踐提煉，對正在實施敏捷的讀者具有很高的參考價值。

作者簡介

陳勇：在工作的17年間，曾任其程序員、項目經(jīng)理、事業(yè)部總監(jiān)、副總經(jīng)理、咨詢師等各種技術(shù)與管理崗位。開發(fā)中獲得的一線工程經(jīng)驗和CMMI／FPA功能點(diǎn)估算／敏捷開發(fā)等跨領(lǐng)域知識，令其可以更廣的視角來理解敏捷開發(fā)。當(dāng)前他作為產(chǎn)品經(jīng)理、架構(gòu)師帶領(lǐng)一個小型團(tuán)隊，從事“火星人敏捷開發(fā)在線平臺”的研發(fā)工作。很多課程與咨詢中的最佳實踐，均來自于其之前及當(dāng)前參與的實際項目的一線實踐。本書收錄的文章就是他們在實際開發(fā)過程中，同時應(yīng)用敏捷開發(fā)的用戶故事和功能點(diǎn)估算中的功能點(diǎn)時的實際經(jīng)驗總結(jié)。日常工作與培訓(xùn)之余，陳勇在其博客上總結(jié)編寫了300多篇系列文章，點(diǎn)擊量150萬次，其中200篇以上是敏捷開發(fā)相關(guān)的文章，力求逐一解決敏捷開發(fā)中的一些似是而非的問題，為一線工作人員及敏捷推廣者提供完整透徹的應(yīng)用思路和方法。杜偉忠：中國人民大學(xué)管理學(xué)碩士，京東商城敏捷教練，精通Scrum、Kanban、XP等敏捷實踐。10年電信軟件開發(fā)經(jīng)驗，6年敏捷實踐經(jīng)驗，其中有3年教練經(jīng)歷。作為教練指導(dǎo)團(tuán)隊超過200人，目前專注于互聯(lián)網(wǎng)公司敏捷的推廣和實施。馮國馨：網(wǎng)名“谷雨霖”。天津大學(xué)工學(xué)博士、PMP 聯(lián)合永道高級副總裁兼CTOPMBar IT項目管理實踐公益社區(qū)創(chuàng)始人、天津大學(xué)北京校友會秘書長曾任神州數(shù)碼網(wǎng)絡(luò)研發(fā)中心副總經(jīng)理、質(zhì)量管理部總經(jīng)理，現(xiàn)任聯(lián)合永道高級副總裁兼CTO、聯(lián)合創(chuàng)始人。美國項目管理學(xué)會協(xié)會PMI會員、中國國家外專局資深專家、中國系統(tǒng)與軟件過程改進(jìn)協(xié)會主任專家會員、中國計算機(jī)學(xué)會軟件工程師工作委員會專家組成員、國家應(yīng)用軟件產(chǎn)品質(zhì)量監(jiān)督檢驗中心特聘專家。長期從事項目管理、產(chǎn)品研發(fā)、持續(xù)改進(jìn)與團(tuán)隊管理，對教育信息化建設(shè)有一定見解。創(chuàng)辦IT項目管理實踐公益社區(qū)，長期積極活躍在CSPI、CSDN CTO俱樂部、IT168等IT管理社區(qū)，與用友集團(tuán)、阿里巴巴集團(tuán)、盛拓傳媒、搜狐集團(tuán)、安博教育集團(tuán)、神州數(shù)碼集團(tuán)等多家IT單位多次開展沙龍交流活動。王立杰：敏捷愛好者、實踐者，獨(dú)立培訓(xùn)師，專注Scrum與XP。2006年開始探索敏捷，應(yīng)用敏捷，于2009年與許舟平合作出版國內(nèi)第一本小說體敏捷項目管理圖書《敏捷無敵》；2010年進(jìn)入敏捷咨詢培訓(xùn)領(lǐng)域，為諾基亞、北電、愛立信、VMWare、阿爾卡特－朗訊等多家公司提供服務(wù)，曾在AgileChina、ScrumGathering、AgileTour等行業(yè)會議發(fā)表多次主題演講。許舟平：本一北國布衣，求學(xué)于西，工作于都，躬耕于代碼十余載，茍全技術(shù)于IT間，不求聞達(dá)于海內(nèi)。親實踐，遠(yuǎn)空談，此敏捷之所以興隆也；實踐者，敏捷之本。蓋聞流程者莫高于Scrum，實踐者莫高于XP，皆因敏捷而成名。今天下賢者智能，豈特西洋者乎？好友立杰，邀士十余，原始察終，見盛觀衰，論考之行，歷經(jīng)春秋，終成此集。敏捷者，其行雖不軌于瀑布、CMMI等，然其言必信，其行必果，已諾必誠。周易曰：天下一致而百慮，同歸而殊途。竊以為，敏捷之事，內(nèi)立法度，務(wù)實踐，修研發(fā)之具；外連橫而協(xié)客戶，則事可成已。至于XP、Scrum、Lean、Crystal等，各有所用，若欲循觀其大旨，可閱此書。布衣之人，不害于政，不妨百姓，取與以時而行敏捷，僅愿讀者有采焉。楊立東：PMP，美國加州州立大學(xué)富爾頓分校碩士，中歐國際工商學(xué)院EMBA，華中科技大學(xué)特聘教授。北京暴風(fēng)科技股份有限公司董事、首席技術(shù)官。2011年第二批“中關(guān)村高端領(lǐng)軍人才聚集工程”科技創(chuàng)新人才。發(fā)表學(xué)術(shù)論文4篇。曾從事過6年一線Java開發(fā)工作，作為項目經(jīng)理帶領(lǐng)過多個大型軟件項目，2006年開始從事CMMI咨詢和評估工作，服務(wù)過的軟件企業(yè)超過30家，多次舉辦項目管理，軟件度量，敏捷項目管理的公開課，培訓(xùn)人數(shù)超過15000人。2008年開始專注于公司級管理工作，2010年開始總結(jié)自己多年的研發(fā)管理經(jīng)驗，專注于互聯(lián)網(wǎng)公司敏捷項目管理的推廣和實施。楊瑞：個人簡介：廈門英睿信息科技有限公司聯(lián)合創(chuàng)始人，目前致力于敏捷的推廣，研發(fā)管理咨詢、培訓(xùn)及移動開發(fā)。10年軟件工程管理經(jīng)驗，在基于傳統(tǒng)和敏捷的開發(fā)管理方面具有豐富經(jīng)驗。曾任三五互聯(lián)產(chǎn)品技術(shù)中心總監(jiān)、福州網(wǎng)龍程序中心高級經(jīng)理等職位，擅長軟件研發(fā)管理、過程改進(jìn)咨詢、培訓(xùn)及實施，精通CMM、CMMI及Scrum。2011、2012年ScrumGathering分享嘉賓，2011、2012年AgileTour廈門站＆福州站組織者、分享嘉賓，Agile China2013程序委員會專家，廈門敏捷社區(qū)發(fā)起人、技術(shù)社區(qū)積極分子。張克強(qiáng)：思碧睿inspearit高級顧問，高級程序員、系統(tǒng)分析員、IPMP、CSM。本碩畢業(yè)于清華大學(xué)。曾在寶信軟件擔(dān)任過測試經(jīng)理、EPG組長、項目總監(jiān)，曾在Intel擔(dān)任過QA Manager，曾在DNV擔(dān)任過資深咨詢師。在軟件工程／系統(tǒng)工程方面擁有10年多經(jīng)驗，主要經(jīng)歷在組織過程改進(jìn)、質(zhì)量保證和測試方面，幫助組織參照CMM／CMMI／Agile／Scrum等進(jìn)行改進(jìn)，在軟件開發(fā)技術(shù)方法論和流程管理兩方面都積累了豐富的經(jīng)驗，熟悉OOAD，UML，TDD，測試等等。

書籍目錄

第一篇 組 織 篇第1章 暴風(fēng)敏捷項目管理實踐2一、暴風(fēng)的項目危機(jī)2二、組織級的敏捷初體驗3三、再次組織級探索12四、持續(xù)優(yōu)化的力量18五、組織改進(jìn)中人的因素27第2章 淘寶的敏捷實踐與過程改進(jìn)35一、背景介紹35二、不同背景下的解決方案36三、ScrumMaster心得50四、敏捷與過程改進(jìn)51五、工具的支持54第3章 從CMMI5到敏捷57一、案例背景57二、敏捷導(dǎo)入過程60三、敏捷優(yōu)化改進(jìn)過程70四、整體回顧81第4章 從裝甲兵團(tuán)到特種部隊83一、引子83二、實施過程88三、反思95第二篇 產(chǎn) 品 篇第5章 火星人一千零一夜98一、第一個月：一個產(chǎn)品的誕生98二、第二個月：框架優(yōu)先，還是故事群優(yōu)先101三、第三個月：故事樹103四、第四個月：用戶故事的顆粒度（上）105五、第五個月：用戶故事的顆粒度（下）108六、第六個月：用戶故事的分類110七、第七個月：分類語法114八、后記115第6章 從敏捷到精益117一、背景117三、破窗理論121四、敏捷宣言錯了嗎125五、南轅北轍127六、MVP才是王道129七、跨越鴻溝135八、小結(jié)136第三篇 團(tuán) 隊 篇第7章 敏捷英雄傳之火燒赤壁140一、人物介紹140二、故事梗概141三、引子142四、CEO孫權(quán)的故事：計劃永遠(yuǎn)趕不上變化144五、CTO周瑜的故事：究竟是變好，還是變得更爛148六、產(chǎn)品經(jīng)理太史慈的故事：一個大版本經(jīng)理的困惑152七、編碼狂人凌統(tǒng)的故事：主刀，就是能上得天堂，下得地獄的主兒157八、測試經(jīng)理陸遜的故事：敏捷測試，就是明知不可為而為之161九、產(chǎn)品集成主管甘寧的故事：持續(xù)集成的煩惱162十、臭皮匠的話167第8章 打造學(xué)習(xí)型自適應(yīng)團(tuán)隊168一、背景介紹168二、團(tuán)隊實踐過程169三、回顧與反思181第9章 從傳統(tǒng)軟件開發(fā)到敏捷的初體驗183一、背景183二、邁出第一步187三、對第一次迭代的改進(jìn)192四、關(guān)鍵的第三次迭代196五、第四次迭代：低耦合軟件設(shè)計197六、總結(jié)199第10章 敏捷在傳統(tǒng)軟件與互聯(lián)網(wǎng)中的應(yīng)用200一、背景介紹200二、敏捷實施過程201三、回顧與反思207第四篇 實 踐 篇第11章 敏捷無它，唯持續(xù)改進(jìn)210一、背景介紹210二、我與敏捷的第一次親密接觸210三、敏捷原來是這樣的211四、第一個挑戰(zhàn)213五、團(tuán)隊的好奇心213六、更多挑戰(zhàn)214七、團(tuán)隊的慣性215八、鏡子215九、從一開始就要高標(biāo)準(zhǔn)216十、TDD的爭議216十一、“道”與“術(shù)”217十二、程序員文化217十三、程序員與建筑工人218十四、TDD不是目的，“拉”與“推”218十五、Coding Dojo219十六、讓實踐落地219十七、程序員的產(chǎn)出220十八、權(quán)威220十九、認(rèn)同權(quán)的建立：無私，勇于說不知道221二十、成就感：點(diǎn)燃程序員的熱情221二十一、PDD：痛苦驅(qū)動開發(fā)222二十二、排除障礙，創(chuàng)建舒適的技術(shù)環(huán)境223二十三、投資回報率223二十四、讓領(lǐng)域模型裸奔224二十五、架構(gòu)224二十六、你做什么就是什么（You are what you do）225二十七、Scrum是不行的，如果只有Scrum225二十八、做正確的事情 vs 正確地做事情226二十九、問題和解決方案，5-whys226三十、“為什么”227三十一、估算（動詞）很有幫助，但估算（名詞）往往沒有228三十二、守破離228三十三、測試優(yōu)先228三十四、QA vs QC229三十五、分享：Wiki、博客、書籍、技術(shù)討論、編程練習(xí)229三十六、沒有銀彈，只有持續(xù)改進(jìn)230三十七、敏捷宣言230第12章 網(wǎng)龍持續(xù)集成實踐231一、案例背景231二、案例分享232

章節(jié)摘錄

1．展示板和信息系統(tǒng)的巧妙結(jié)合敏捷例會的展示板每個團(tuán)隊都會實施得不一樣。對于進(jìn)度跟蹤，可以采用觀察燃盡圖的趨勢，也可以融合信息系統(tǒng)的做法。只要不苛刻地挑剔，很多工具都支持Scrum敏捷項目管理，從最簡單的白板加Excel，到ScrumWiki、Xplanner、GNATS都能支持Scrum的實施。暴風(fēng)的團(tuán)隊開始就嘗試了Redmine這個缺陷管理工具來配合展示板實施敏捷項目管理。沒有好不好用的系統(tǒng)，只要運(yùn)用合理，抱著極簡的思維去使用工具，就能最低成本地發(fā)揮工具的作用，至于使用信息系統(tǒng)遇到的各種缺陷或者不能滿足管理的功能，還是應(yīng)該報以寬容的態(tài)度。但理想和現(xiàn)實往往經(jīng)常事與愿違，將就用了一段時間后團(tuán)隊終于不能忍受系統(tǒng)功能的不足，于是開發(fā)自己的信息系統(tǒng)的呼聲愈演愈烈，最終還是決定開發(fā)自己的系統(tǒng)。還是本著極簡的思維方式，系統(tǒng)只圍繞包括Sprint任務(wù)導(dǎo)入、任務(wù)完成更新（工時填報）、燃盡圖自動生成、問題的生命周期管理這樣幾個核心功能進(jìn)行開發(fā)。這樣也使得任務(wù)板和信息系統(tǒng)的信息完全一致，障礙（問題）也得到了有效的跟蹤和管理。2．配置管理的敏捷實踐活動對于暴風(fēng)影音的官網(wǎng)版本來說，每個月會有多個官網(wǎng)版本發(fā)布，一種是提供給用戶新特性驗證的β版本，根據(jù)用戶體驗后真實的反饋信息，進(jìn)行后續(xù)產(chǎn)品的優(yōu)化和完善，另外一種是將已經(jīng)完成驗證的功能和新特性合并到穩(wěn)定的官網(wǎng)版本中?；久績芍芫鸵桓兑粋€版本，每個項目都感覺時間緊、任務(wù)重。配置管理在敏捷實踐中起到怎樣的作用呢？暴風(fēng)轉(zhuǎn)碼的敏捷團(tuán)隊在版本V2．1剛剛完成用戶故事的開發(fā)工作，也就是說，產(chǎn)品已經(jīng)能運(yùn)行，系統(tǒng)測試工作還未開展。按照估計測試和修改Bug的周期為一周計算，此一周的時間研發(fā)人員會很不飽和，按照公司對人員使用率的要求，通常會啟動V2．2版本的開發(fā)工作。這樣會提高研發(fā)人員的利用率，但也會帶來兩個甚至多個版本同時開發(fā)的問題，如果沒有好的配置管理，代碼會混亂不堪，很多人同時并行兩個版本的代碼開發(fā)工作，一方面改V2．1版本的Bug，另一方面開發(fā)V2．2版本的新功能。我們通過配置管理工具的代碼分支、代碼合并來解決代碼管理問題。為V2．1開出代碼分支，這樣兩個版本的代碼相互隔離，不會彼此干擾。V2．1版本上的Bug修復(fù)工作，對于V2．2的開發(fā)同樣也適用。這樣實現(xiàn)了版本的交替開發(fā)，提升了開發(fā)人員的使用率。通過代碼的分支與合并也能處理好“新特性開發(fā)”與“產(chǎn)品穩(wěn)定”的關(guān)系。兩種版本經(jīng)常存在交疊。用分支支持交疊，即防止了前者干擾后者，也防止了后者阻滯前者，這樣維持了開發(fā)效率和產(chǎn)品質(zhì)量的平衡關(guān)系。在敏捷開發(fā)過程中，變更是被鼓勵的。而變更一定會體現(xiàn)在代碼中，因此在SVN里，加一些控制以保證開發(fā)人員做且只做該做的事。方法是讓變更集不由開發(fā)人員創(chuàng)建，而是由專門的配置管理員創(chuàng)建，然后指定給相應(yīng)的開發(fā)人員完成。配置管理員會和產(chǎn)品經(jīng)理、開發(fā)負(fù)責(zé)人和測試負(fù)責(zé)人溝通達(dá)成一致，然后在SVN中完成相應(yīng)的設(shè)置。對于一些比較大的任務(wù)，需要多個人協(xié)同完成，可以為此開分支，分支也由配置管理人員創(chuàng)建，然后要求開發(fā)人員在分支上工作，完成相應(yīng)任務(wù)，同時控制修改代碼之后的提交。對于分支版本，只有符合本次版本要求的分支才允許合并到主干。這個工作是配置管理員和敏捷團(tuán)隊協(xié)作完成的。配置管理實踐中最重要的是要摒棄原來所有的控制思想，讓配置管理員作為敏捷項目團(tuán)隊中的一員，和團(tuán)隊共同協(xié)商如何管理代碼、管理變更，而不像實施CMMI過程中有各種控制和審批環(huán)節(jié)。3．敏捷中實施Code Review（代碼走查）技術(shù)評審活動是不管是否實施敏捷項目管理都需要進(jìn)行的一種活動，很多人從來沒有搞清楚什么是技術(shù)評審、什么是管理評審。技術(shù)評審包括需求評審、設(shè)計評審、代碼Review、測試用例評審等和項目直接結(jié)果相關(guān)的工程活動的評審。管理評審指的是敏捷項目管理的三個儀式：Sprint規(guī)劃會、每日例會和Sprint評審會。傳統(tǒng)項目管理中的項目立項評審、里程碑評審和驗收評審也屬于管理評審。簡單地總結(jié)，技術(shù)評審是針對軟件工程活動的評審，其目的是通過缺陷預(yù)防提升軟件的質(zhì)量，管理評審是針對階段活動是否可認(rèn)定為結(jié)束、下階段如何開始，其目的是項目管理活動是否有效，交付的成果是否可接受。如果借助敏捷項目管理的思想“交付可用的軟件”，技術(shù)評審在敏捷活動中顯得尤為重要，從評審的正式程度上劃分，技術(shù)評審分為正式評審、技術(shù)審查和代碼走查三種類型，如下表所示。評審種類計劃準(zhǔn)備會議修正確認(rèn)Inspection（正式評審）有有有有有Technical Reviews（技術(shù)審查）有無有有有Walkthrough（代碼走查）有無有有無正式評審?fù)ǔＳ身椖拷?jīng)理主持，邀請項目的核心成員和外部有經(jīng)驗的專家參加，目的在于定位并消除軟件中的缺陷。技術(shù)審查或稱內(nèi)部評審，通常由技術(shù)負(fù)責(zé)人召集相關(guān)人員參加，一般是在模塊或功能完成時進(jìn)行，目的在于通過對交付模塊或功能的技術(shù)審查，提出改進(jìn)意見。代碼走查又稱代碼走讀，由代碼作者來組織，主要是代碼質(zhì)量分析和編程規(guī)則檢查。一般是在模塊或功能完成的早期進(jìn)行，作者有一定的想法時，希望從其他開發(fā)者那里獲得一些幫助或補(bǔ)充。由作者主持，目的是進(jìn)行缺陷預(yù)防，提高代碼的質(zhì)量，很多公司已經(jīng)成功地實施了Code Review和結(jié)對編程?？偨Y(jié)第一輪實施敏捷的試點(diǎn)項目，并沒有要求實施代碼走查活動，項目負(fù)責(zé)人和開發(fā)人員也沒有意識進(jìn)行Code Review。要么是找借口說進(jìn)度太緊張時間不夠用，要么是不知道如何進(jìn)行代碼走查。第一種純粹是意識問題，要回答不知道怎么進(jìn)行代碼走查的問題則從代碼走查的種類開始著手。代碼走查分為兩種：一種是交叉代碼審查，自己的代碼由他人來檢查，就像檢查作業(yè)一樣；另一種是代碼會審，就是以會議的形式，大家共同審核代碼的質(zhì)量。代碼走查主要審查的內(nèi)容包括：是否符合代碼規(guī)范，確保所有人寫的代碼基本一致并符合代碼規(guī)范；代碼滿足基本用戶故事的要求，檢查代碼的邏輯實現(xiàn)，確認(rèn)能實現(xiàn)用戶故事；代碼滿足性能等非功能性需求，非功能性需求一般需要借助一定的工具和Code Review人員的能力，針對編碼中對于性能影響的瓶頸給出解決方案；代碼簡化，提高代碼的可讀性，能夠用公用的方法和公用API實現(xiàn)，則無須每人定義自己的實現(xiàn)代碼。隨便抽出某開發(fā)人員的1000行代碼檢查的結(jié)果是：代碼注釋不充分，很多實現(xiàn)邏輯的類和方法沒有注釋；有些代碼性能差，頻繁地讀/寫磁盤I/O；有些代碼雖然實現(xiàn)了功能需求，但從邏輯上寫得太死，不便于擴(kuò)展；在約定使用統(tǒng)一代碼的寫日志功能代碼作者定義了自己的代碼來實現(xiàn)。看來為了提高質(zhì)量，代碼走查是實施敏捷項目管理一定要執(zhí)行的工作。4．被修訂的測試報告測試報告是集成測試階段每天都需要測試工程師編寫的一份重要的信息溝通工具，它的目的是讓團(tuán)隊所有成員了解當(dāng)前Sprint交付軟件的質(zhì)量情況，每個開發(fā)人員身上有多少未解決的Bug，以及交付模塊的質(zhì)量情況?；仡櫾圏c(diǎn)項目的項目測試報告，大概是從百度上搜索的模板，冗長而不知所云。報告中什么編寫目的、背景、測試對象、測試概要、測試用例、測試環(huán)境等，光標(biāo)題就會讓人眼花繚亂。從正規(guī)性上講，這樣的測試報告提交給最終用戶無可厚非，但是給團(tuán)隊內(nèi)部看就沒必要這樣講求全面性和規(guī)范性了。再引用敏捷思想“可用的軟件重于完備的文檔”。所以修訂測試報告應(yīng)該是為團(tuán)隊減輕負(fù)擔(dān)、提高溝通效率的一項優(yōu)先級非常高的優(yōu)化活動。問問團(tuán)隊需要什么樣的報告。產(chǎn)品團(tuán)隊回答需要了解當(dāng)前軟件的質(zhì)量來決策是否可發(fā)版，以及有些不好解決的缺陷拿出來讓團(tuán)隊共同來決策Bug的處理策略。研發(fā)團(tuán)隊回答需要了解每個人身上有多少個未解決的缺陷，Bug整體解決情況和各模塊的質(zhì)量。測試團(tuán)隊關(guān)注的是Bug整體解決情況及分解下的按模塊、按人員缺陷情況。統(tǒng)一思想后的測試報告包括一個測試情況的基本總結(jié)和三個部分?；厩闆r總結(jié)是整個測試報告中最重要的部分，應(yīng)該用粗體和紅色來描述。要求盡量用一兩句話描述清楚當(dāng)前測試的總體情況。例如，當(dāng)前測試遇到未解決的嚴(yán)重級別缺陷大于3個，不符合發(fā)版需求，其中組件下載功能如果點(diǎn)擊取消，必崩。第一部分是Bug移除率的統(tǒng)計，其中累計移除率是了解當(dāng)前Bug整體解決情況的最好的說明，如下表所示為2010年9月23日某項目測試統(tǒng)計數(shù)據(jù)。日期當(dāng)前遺留本日新增本日移除本日新增未解累計新增累計移除本日移除率累計移除率9/1412087805831419492．0%61．8%9/1513683675839726180．7%65．7%9/16135818338478343102．5%71．8%9/17105477629525420161．7%80．0%9/1810787844561250596．6%82．5%9/2113973414568554656．2%79．7%9/22137676950752615103．0%81．8%9/2315271495882367169．0%81．5%成功實施敏捷項目管理的團(tuán)隊一定有疑問，為什么實施敏捷后還有集成測試階段，看上面的數(shù)據(jù)為什么質(zhì)量會那么差，似乎和敏捷倡導(dǎo)的交付可用的軟件有沖突。帶著這些“十萬個為什么”不妨思考一下。沒有實施代碼走查導(dǎo)致了大量缺陷，造成的直接結(jié)果是必須有個集中測試的階段來把Bug找出來，每個功能和功能之間并不是獨(dú)立的，開發(fā)人員在開發(fā)過程中并沒有及時溝通導(dǎo)致了接口不一致等諸多Bug，產(chǎn)品人員沒有及時確認(rèn)交付的功能或模塊是否可用甚至提出一些變更也導(dǎo)致了一些缺陷。如此多的原因?qū)е逻@么多缺陷已經(jīng)解釋了上面的為什么，結(jié)論是如果敏捷項目管理實施成這樣，基本上可以界定為是一場“形似而神不似”的失敗的敏捷嘗試了。但也可以肯定的是，這份測試數(shù)據(jù)總結(jié)對團(tuán)隊了解項目當(dāng)前的總體質(zhì)量起到了一目了然的作用。第二部分為Bug人員分布，第三部分為Bug模塊分布，分別是按人員和按功能模塊的缺陷數(shù)據(jù)總結(jié)。按人員的分布可以看出每個人當(dāng)日解決的Bug數(shù)和剩余Bug數(shù)，便于提醒團(tuán)隊及時地解決Bug或者相互協(xié)助。按模塊的Bug數(shù)總結(jié)便于提醒團(tuán)隊哪個模塊的Bug多，除了了解模塊的質(zhì)量外還有助于提示團(tuán)隊及時進(jìn)行代碼走查來徹底解決質(zhì)量問題。5．發(fā)布規(guī)則，絕不讓步經(jīng)過再一輪的組織級探索，讓團(tuán)隊對于敏捷項目管理的基本原則有了更深入的認(rèn)識。軟件開發(fā)的殘酷現(xiàn)實告訴我們，即使在敏捷項目管理框架下，沒有規(guī)則的軟件開發(fā)過程帶來的只可能是無法預(yù)料的結(jié)果。不管是多么有經(jīng)驗的項目團(tuán)隊，在“響應(yīng)變化勝于遵循計劃”一項上都難以做到。一次次失敗的教訓(xùn)告訴我們，我們需要在敏捷框架下設(shè)定一些基本規(guī)則，而在這些基本規(guī)則面前，在保證敏捷思想的前提下不能向規(guī)則讓步。軟件可用規(guī)則：上述的代碼走查和測試數(shù)據(jù)告訴我們，在很多情況下我們交付的用戶故事可用實際上是帶有很多缺陷的，即使強(qiáng)調(diào)了PCT原則，團(tuán)隊交付的功能模塊還是不完全可用，所以嚴(yán)格的方法是在燃盡圖統(tǒng)計時，所有未完成的（即使是P和C狀態(tài)都完成了的功能）都不進(jìn)行統(tǒng)計，這和傳統(tǒng)的“0－100”進(jìn)度統(tǒng)計法則一致。讓任何一個團(tuán)隊成員都知道積極參與，因為每一個功能交付如果說可用就一定要可用。目標(biāo)導(dǎo)向原則：目標(biāo)導(dǎo)向是充分調(diào)動員工工作積極性的最有效的方法，每個目標(biāo)都設(shè)定卓越和及格的標(biāo)準(zhǔn)，在制訂敏捷計劃時，就需要明確項目如何做到卓越，并讓指標(biāo)認(rèn)領(lǐng)到個人。例如，手機(jī)端每個滑屏操作的卓越標(biāo)準(zhǔn)是任意滑動的展現(xiàn)在0．6秒以下全部完成。對于開發(fā)者來說，近期的Sprint目標(biāo)總是比遠(yuǎn)期目標(biāo)來說更容易看到和達(dá)到，這會使每一個Sprint員工的工作效率維持在一個較高的水平。代碼提交原則：很多開發(fā)人員在提交代碼到配置管理系統(tǒng)時往往不注意是否通過了單元測試和自己代碼的質(zhì)量，這樣會給其他人員帶來或多或少的麻煩。所以為了提升團(tuán)隊效率，代碼的提交必須滿足兩個硬條件，其一是提交的代碼必須經(jīng)過自己的單元測試，其二是確保提交代碼后整體代碼可編譯通過。在這個原則的基礎(chǔ)上，如果能自動化完成的工作絕對要減少人工干預(yù)，例如，持續(xù)集成和自動化測試盡量按策略自動完成。有話好好說原則：項目成員理解和贊同用戶故事的范圍、項目目標(biāo)嗎？開發(fā)人員大多數(shù)時間都不喜歡發(fā)表自己的看法和言論，大家不發(fā)表言論意味著他們認(rèn)同項目范圍和目標(biāo)嗎？這一點(diǎn)在項目溝通中極為重要，敏捷教練一定要問每個人，讓每個人表達(dá)自己的觀點(diǎn)，讓大家有話好好說，有話桌面上說，不可認(rèn)為不發(fā)言就認(rèn)為是同意。在對項目目標(biāo)沒有一個共同認(rèn)識的前提下，團(tuán)隊是不可能成功的。文檔極簡原則：敏捷思想并不鼓勵書寫文檔。敏捷宣言也宣告“可用的軟件重于完備的文檔”，但如果一個軟件是長期更新和維護(hù)的，還是需要必要的文檔來將所有有價值的歷史信息記錄下來的。你如果剛加入一個敏捷團(tuán)隊來接手一個已經(jīng)迭代了9個Sprint的軟件，如果什么都沒有你從哪里下手？但是不希望文檔過于龐大，能把用戶故事的關(guān)鍵點(diǎn)、設(shè)計的關(guān)鍵點(diǎn)記錄下來就夠了，特別是代碼每次變更必須用注釋描述清楚。精英團(tuán)隊原則：眾所周知國內(nèi)軟件的成熟度偏低，一個公司能數(shù)出幾個好的產(chǎn)品經(jīng)理？又有多少技術(shù)高手？其實資源很有限。如果實施敏捷項目管理，必須抱著精英團(tuán)隊的原則，不鼓勵團(tuán)隊規(guī)模過大。團(tuán)隊規(guī)模過大，按照n（n 1）/2的溝通渠道計算公式，溝通成本增加，效率極大降低。特別是很多需要技術(shù)難點(diǎn)公關(guān)比較多的項目，人數(shù)多根本解決不了任何問題。總之，在不違背敏捷思想的前提下，一些必要的規(guī)則是保證項目目標(biāo)能夠達(dá)到卓越的必要約束，也是促進(jìn)團(tuán)隊建設(shè)和高效協(xié)作的基礎(chǔ)。

媒體關(guān)注與評論

敏捷是一種方法，更是一種組織能力。那些不懂得敏捷不利用敏捷方法的研發(fā)團(tuán)隊，最終將在快速變化、競爭激烈的互聯(lián)網(wǎng)環(huán)境中落敗。擁抱敏捷吧，從現(xiàn)在開始！——京東商城高級副總裁李大學(xué)這是一本很好的講敏捷的書，本書的作者們并沒有生硬地羅列令人費(fèi)解的理論，而是結(jié)合親身的經(jīng)歷，給讀者生動展現(xiàn)了敏捷在IT行業(yè)的各種應(yīng)用場景，令人受益匪淺，非常值得一看。我們也可以從中了解到，任何一種工具或者方法應(yīng)用到實際工作中時，都不能生搬硬套，而是需要根據(jù)具體所在的行業(yè)、公司的企業(yè)文化以及研發(fā)團(tuán)隊的狀況進(jìn)行適當(dāng)調(diào)整，亦可以稱之為“本土化”——通過在實踐中不斷的解決問題，持續(xù)優(yōu)化，使其更適用，更實用，真正的幫助到團(tuán)隊?！囍褻TO 廖志強(qiáng)

編輯推薦

覆蓋組織轉(zhuǎn)型、產(chǎn)品管理、團(tuán)隊建設(shè)、工程實踐，解析精彩過程，分享經(jīng)驗教訓(xùn)，揭示敏捷背后的奧秘。匯集IBM、淘寶、京東、暴風(fēng)影音等IT名企的敏捷專家經(jīng)驗分享。

圖書封面

圖書標(biāo)簽Tags

無

評論、評分、閱讀與下載

---

    敏捷開發(fā)一千零一夜 PDF格式下載

---