通常情況下，大家對於敏捷的感受就是：大家一起來開站立晨會啦！然後一大早，大家拿著早餐，圍成一個圈，聽一個人在講話。

在很多公司，決定採用敏捷之後，都會從晨會開始，因為很多人覺得敏捷其它模組都很難學習，就先從最簡單的晨會開始，試行簡單的方法會不會有奇效，抱著這個想法，奇蹟是不會發生的。

很多人不知道的是，許多公司都是從晨會中結束敏捷轉型的，雖然開好晨會不簡單，而且也有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.6 如何打造稱手的武器

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

NO.8 你愛上手機QQ麼

NO.9 天天系列天天見喲

文章來源：微信公眾號“老布談敏捷”(ID：bootagile)

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