【騰訊敏捷轉型No.6】如何打造稱手的敏捷工具

一般狀況下，你們對於敏捷的感覺就是：你們一塊兒來開站立晨會啦！而後一大早，你們拿着早餐，圍成一個圈，聽一我的在講話。

在不少公司，決定採用敏捷以後，都會從晨會開始，由於不少人以爲敏捷其它模塊都很難學習，就先從最簡單的晨會開始，試行簡單的方法會不會有奇效，抱着這個想法，奇蹟是不會發生的。

不少人不知道的是，許多公司都是從晨會中結束敏捷轉型的，雖然開好晨會不簡單，並且也有Know-how。

工具和管理方法實現價值最大化

你們會有一個問題：老布，既然只作晨會不行，那作敏捷有沒有其餘衡量指標呢？

我能夠很確定的回答你：有，若是有且只有一個的話，衡量團隊的敏捷指標就是一個月內該團隊寫給本身團隊的代碼佔總代碼中的百分比。

爲了解決團隊目前工做質量或工做效率的問題而開發的一些工具的代碼，佔據全部代碼的百分比，就是團隊的敏捷指標。敏捷的本質是尋找價值，妨礙團隊高效尋找價值的障礙都是「問題」，因此須要利用管理方法和工具來解決問題。經過不斷髮現團隊的短板，用管理方法調整或者編寫工具來解決短板，從而釋放團隊每一個成員空間，實現我的價值最大化。

假設人工發佈的時間須要2個小時，每四次發佈有1次要回滾，每週發佈一次，請問團隊中誰願意反覆作這件事？再假設發佈從每週改成每週兩次呢？你會發現，這樣的團隊成員壓力都很大，容易犯錯，這裏就是一個短板。因此團隊頗有必要花費兩週的時間開發一個自動發佈的系統，將以往每次發佈兩小時改成成兩分鐘並且支持回滾。

這部分的代碼就是團隊寫給團隊本身的代碼，咱們但願持續經過編寫代碼來改進團隊短板。

 

（圖一：騰訊敏捷工具模塊）

如圖一，爲了發展敏捷研發，通過多年的建設，終於構建這麼多工具來支撐敏捷實踐。包括CE（Customer Engagement）、需求管理、代碼管理、測試過程管理、發佈管理、缺陷跟蹤管理、持續集成管理、項目過程管理、任務管理等。

不少人會有誤解，認爲鵝廠規模這麼大，人數這麼多，隨便擠出一些人均可以完善這些工具。其實這些工具的早期版本都不是專門團隊來完成的，而是業務團隊根據本身的須要逐步開發完善的。

例如，自動發佈模塊，就是網站業務團隊最早作的，由於相比較公司內其餘業務，網站業務的自動發佈比較容易實現，按照版本發佈到Server上，就能夠對外提供服務了。在當時，絕大多數的客戶端業務的自動發佈就沒有那麼容易實現了，可是當網站業務團隊的自動發佈實踐取得效果後，有了標杆，其它業務團隊都勇於嘗試了。

很快有團隊將自動發佈進化爲灰度發佈工具，自從有了灰度發佈工具，不少團隊就發現巨大的好處。在沒有使用灰度發佈工具前，當時的業務常常須要切換上線，爲了避免影響客戶，都須要在凌晨四點左右完成切換。那時候，我還特地買了一個睡袋，在切換上線的時候，前一天晚上10點睡覺，凌晨3點起來操做腳本停掉舊版，而後編譯，啓動新版。觀察一個小時的日誌，看看業務是否正常運做。若是不正常就趕忙幹掉新版，回覆舊版，等次日白天修改問題以後，晚上再次切換上線。

自從有了灰度發佈後，能夠在白天黑夜隨時發佈上線，逐步切換一小部分用戶使用新版本，若是有任何問題，就能夠當即切換全部用戶用回舊版。同時開始查找問題，等修改調整好了之後，再次切換一小部分用戶試用，而後持續觀察用戶的表現和反饋，直至成功全部用戶成功切換使用新版本。

每一個業務都會挑選合適本身的重要工具進行開發，取得必定成效後，公司就鼓勵你們互相分享工具，通過三年時間「發酵」，這些工具已經逐步完備，最終騰訊公司敏捷實踐的效率在這些工具的支撐下愈來愈高。

不少學員會問我，老布你有沒有好的工具直接推薦給咱們用啊？我認爲，由於每一個團隊的性質不同，用的工具和腳上穿的鞋子同樣，別人穿着很舒服，可是不必定適合你，只有合適纔是最好的。

因此我始終建議團隊根據本身切身狀況開發的工具是最好的，可是如今你們比十年前的咱們幸福多了，如今Github上有不少Open Source工程，都是用來增強敏捷實踐的工具（如圖二）。

 

 

（圖二：開源敏捷實踐工具）   

因此如今你們只須要找到一個合適的好工具，以爲適合本身團隊就持續使用，發現問題就本身動手修改，這樣的工具纔是最適合團隊所在的行業、業務和團隊特色的，效率纔是最高的。

 

【案例】CPD檢查你的代碼

十年前，我和個人團隊想作靜態代碼掃描的時候，當時只能使用價格昂貴的Pclint工具，很是鬱悶的是它只能掃描C語言的代碼，C++代碼暫時還不支持。當時咱們經過缺陷審計，發現一個現象——不少程序員每日提交到SVN的代碼佔比至關高，都是從其餘代碼裏Copy-paste過來的，根本沒有修改，直接編譯運行了。只要功能正常，就提交。在面嚮對象語言的時候，Code高度抽象，就算只有5行代碼均可能新建了某個對象而後這個對象初始化的代碼裏還啓動一個線程池，被Copy的代碼在某個地方關閉了線程池。他們在抄代碼的時候根本沒有分析清楚，因此這樣的代碼隱患很是大。

因而個人團隊使用靜態掃描功能就最早開發了一個「CPD」功能（Copy-Paste·Detector）。天天晚上把當天提交的代碼以人爲單位進行分析，次日早上8點前會有一封郵件發送給全部人，郵件標題爲《TOP10·CPD·Programmer》，郵件的內容是人名、CPD率、上榜時長。把昨天的代碼裏Copy-Paste後並不修改源代碼，CPD率Top10的人列出來，提醒他們當天必須把代碼逐行檢查調整後再提交。若是有人連續兩天上榜，就會額外有一份郵件發送給那我的的直屬Leader，請他幫助解決這個entity，經過這個簡單的方式，團隊千行Bug率大大降低。CPD工具的原理說出來簡單得不能再簡單，可是效果很是好，因此建議敏捷工具根據須要本身開發，這樣纔是稱手的敏捷工具。

 

 

系列文章#

第一輯：我親歷的鵝廠敏捷轉型

 

NO.1 敏捷是什麼鬼

NO.2 帥哥，來多少的敏捷

NO.3 Scrum有什麼好

NO.4 爲何敏捷團隊不要超過15人

NO.5 需求沒作完能夠發佈嘛

NO.6 如何打造稱手的武器

NO.7 QQ郵箱怎麼成爲行業第一的

NO.8 你愛上手機QQ麼

NO.9 每天系列每天見喲

 

文章來源：微信公衆號「老布談敏捷」(ID：bootagile)

做者：薛軍/Boots，現任：深圳市一塊兒六企業管理有限公司創始人，騰訊大學外聘高級講師，業問特聘騰訊之道講師。曾任騰訊項目管理通道委員會會長，騰訊項目管理P4專家，敏捷教練，騰訊LBS總監

本文由@薛軍 原創發佈於博客園，未經許可禁止轉載。