隨着敏捷開發方法越來越流行，如何衡量一個團隊的敏捷程度變成了老板和經理們看重的一個東西，那么，我們如何衡量一個團隊的敏捷程度呢？
“守 破 離”源自於日本劍道學習方法，后發展到其他武術與其它行業。這是百度百科上的一句話，同樣，“守 破 離”也適用於敏捷的衡量標准，讓我們看看守破離在敏捷上的運用。
守， 即團隊是否能按照scrum的流程去實施敏捷，如團隊中是否有三個角色，團隊是否能按照敏捷的方法去開四會（早會，計划會，檢視會，回顧會）等等。
破， 即團隊是否能根據團隊自己的狀況，去突破敏捷原有的部分規則，去到更高的層次，比如是否根據敏捷的價值觀去增加其它的一些東西，例如代碼審查會議。
離， 即團隊的成員已經非常熟悉敏捷的流程和規范，團隊成員已經能對敏捷的價值觀駕輕就熟，團隊根據自己的狀況自己制定相關的實踐，但所有的實踐都是符合敏捷的價值觀的。
看完上面的東西，是不是覺得很虛，很空幻？來點干的吧，談談我自己對衡量敏捷程度的看法。
1. 團隊是否自組織？
一個團隊的敏捷程度，我個人認為此項標准是最高要求，即如果SM或者Team Leader不在的話，團隊是否能保質保量的開四會;如果TL或者SM不在的時候，是否有人去關注質量？
請看“一個成功敏捷團隊的失敗歷程”這篇文章，這是一個相當典型的失敗案例。當有成員不按照之前的實踐走的時候，是否會有成員站出來提醒。比如開發任務的DOD是要寫junit test的，但有一次因為production 有defect,有幾個同事去救場去了，導致junit test沒有寫，在開檢視會的時候，團隊是否堅持原來的DOD（SM和TL都不在），尤其是當這種苗頭出現的時候，是否有團隊站出來提醒要堅持DOD？
2. 團隊是否有持續改進？持續改進，我覺得可以從以下幾個方面着手。
1）我們production上面的bug數量是否在逐漸減少?
2) 我們的測試覆蓋率是否在逐漸增加？
3）我們開會的效率和質量是否有提高，就是開會的時長是否比以前短了（更高效了）。
4） devops的能力是否在逐漸增強，比如原先沒有自動部署的，現在有自動部署了，原先沒有自動化測試的，現在有了。
3. 團隊是否具備周發布，日發布，隨時發布的能力？
具備這樣的能力，不代表一定要每天發布，這個可以根據每個公司和項目的具體情況，但只要用戶或者公司允許，團隊是否可以隨時發布客戶要求的更改。
4. 團隊成員的能力是否有提高？
以前我一直覺得，玩敏捷就是讓團隊變得更忙，教練來了之后，讓我對敏捷的看法有所改觀，敏捷能讓我們的生產率提高，就是我們干的活多了，但並不意味着團隊要加班，反而是團隊在單位時間內干的話多了，只要不是重復的工作，團隊的能力一定會有提高。所以實施敏捷后，可以看看團隊成員的能力是否有提高，從技術方面，學的技術是不是多了，解決問題的能力是不是快了， 這有時也會成為敏捷團隊績效考核的一個指標。
5. 團隊成員每天的工作是否大都工作在一件事情上？
在敏捷里，我們提倡每一位成員只干一個任務，因為這樣成員可以將更多的精力關注一個任務上，而且這樣更高效。
怎么樣？你的團隊敏捷嗎？我的團隊還在敏捷的路上.