通常情況下，大家對於敏捷的感受就是：大家一起來開站立晨會啦！然後一大早，大家拿著早餐，圍成乙個圈，聽乙個人在講話。
在很多公司，決定採用敏捷之後，都會從晨會開始，因為很多人覺得敏捷其它模組都很難學習，就先從最簡單的晨會開始，試行簡單的方法會不會有奇效，抱著這個想法，奇蹟是不會發生的。
很多人不知道的是，許多公司都是從晨會中結束敏捷轉型的，雖然開好晨會不簡單，而且也有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 天天系列天天見喲
如何敏捷轉型
敏捷開發 agile development 是目前眾多大小網際網路企業廣泛採用或者嘗試轉型的一套提公升工作效率和質量的方式，以適應it行業快節奏帶來的不確定性。敏捷開發是先將產品做出來，交付或者上線，在實際應用場景中彌補需求的不足，快速修復後發布新版本。特點 可快速交付 迭代 以人為本 小版本 特...
敏捷轉型 團隊如何變敏捷？
敏捷的原則傾向於一些常識和一系列艱苦的工作，通常，我們會聽到很多關於敏捷的資訊，比如敏捷轉型是團隊嘗試成為敏捷的一種流行方式。很多團隊會聘請敏捷顧問，花幾個月的時間幫助團隊進行敏捷轉型，這個過程只需要支付一筆錢。最後整個團隊真的就轉型成敏捷了嗎？像這樣的轉變有意義嗎？其實，實現敏捷的方法不僅是轉型，...
騰訊敏捷轉型NO 1 敏捷是什麼鬼？
敏捷是什麼鬼 我之所以敢說出這句話，僅僅因為大家的狀態和我2006年末的時候並無二致。一 初識敏捷 2006年年末的時候，鵝廠決定開始引進 敏捷 對於當時大部分公司的小夥伴來說，既完全搞不清楚這個概念，也不理解為什麼要做這個事情，更不可能想象到這件事對於鵝廠未來的深遠意義。當時我已經開始從事質量管理...