當一個產品團隊採用敏捷開發模式時，如何來確認這個團隊是否真的已經敏捷了呢？這個是非常重要的，在日常工作過程當中，團隊的工作模式很大程度上會受團隊負責人或者服務性領導的影響，有時候會因為這個負責人的一些個人工作風格，而使團隊的敏捷模式偏離了方向，沒有讓團隊真正的敏捷起來。前面一篇文章也介紹過，在敏捷開發模式團隊內部，Product Owner和Scrum Master這兩個角色非常重要，他們是帶領整個團隊前進的，下面的評估參考標準其實基本上是圍繞這兩個角色展開的。

一個團隊花了很多錢請來了外部的培訓師和教練，同時僱傭5個員工組成“敏捷辦公室”為新的Scrum團隊提供建議和幫助。他們失敗是因為他們認為實施Scrum僅限於開發團隊。發起敏捷轉型的管理層認為，只給開發人員提供培訓和支援就足夠了。他們沒有考慮到Scrum對產品經理、測試人員、UED等人員的工作帶來的影響。如果這些地方沒有改變，組織惰性會把整個團隊帶回原點。

Scrum簡單但並不容易，原因如下：

1、成功的變革不是完全的自上而下或者自下而上；

2、結束狀態是不可預知的，Scrum需要持續的改進；

3、Scrum在整個組織中是無處不在的；

4、Scrum和傳統培訓/教育是截然不同的；

5、變化來的比以往更快；

6、最佳實踐是危險的，要找到適合自身的方法；

Scrum不僅是技術層面的轉型，更意味著理念的革新，整個團隊都要參與進來

1、團隊要學會在沒有大而全的計劃的情況下開始工作；

2、團隊要學會在沒有詳細需求文件的情況下，通過使用者故事和交流分析和理解需求，開始設計和程式設計；

3、團隊要習慣於頻繁遞交程式碼和持續整合；

4、團隊是在高度透明的環境下工作，每個人的進展被所有人都瞭如指掌；

5、團隊需要進行結對程式設計，需要頻繁的溝通和討論；

初級敏捷團隊

1、Team內PO角色清楚，PO負責管理Product Backlog；

2、PO是需求的主要來源，並負責並從各方收集需求，並對需求負責；

3、PO負責Product Backlog優先順序的確定，當變動發生時也是如此；

4、Team中有一個人可以承擔Scrum Master這個角色的工作，基本上由此人長期承擔Scrum Master的工作；

5、基本能夠協調Team解決在Sprint內遇到的問題。但是對跨Domain的問題解決推動能力弱；

6、由Scrum Master協助團隊成員進行維護Sprint Backlog，並培養團隊成員自行維護Sprint Backlog的習慣；

7、Scrum Master負責主導和主持站會，站會在固定地點和固定時間，在標準時長內結束，Scrum Master對團隊每個成員的工作內容都很清楚，可以通過站會發現大部分問題和風險；

8、Scrum Master負責各種會議的如期進行，如plan meeting、總結會議、PRD reivew、ERD review、Code review、Case review等等；

9、Scrum Master負責主導和主持plan meeting，給出工時的評估方式，給出本次sprint的計劃內容和優先級別，引導大家進行sprint內容的拆分，引導大家完成工時的評估；

10、Scrum Master負責主導和主持總結會議，主要由Scrum Master負責總結本次迭代的優點和缺點，並針對缺點制定出改進措施並進行跟進；

11、Scrum Master負責監控風險和進度，並能知會給利益相關人；

12、Team大部分情況下能夠完成對DOD的承若；

中級敏捷團隊

1、PO負責管理Product Backlog，Team認可Product Backlog內容；

2、Team會協助PO收集需求，也會積極提出需求，Team認可需求並對需求負責；

3、PO協助Team進行Product Backlog優先順序的確定，當變動發生時也是如此；

4、Team中Scrum Master這個角色的工作有Backup，當Scrum Master不在時，Backup可完全承擔該角色的工作；

5、完全能夠協調Team解決在Sprint內遇到的問題。對跨Domain的問題解決推動能力較強，但對跨部門的問題解決推動能力較弱；

6、團隊成員自行維護Sprint Backlog的習慣已形成，Scrum Master只需監督和提醒；

7、Scrum Master協助站會有效進行，站會在固定地點和固定時間，在標準時長內結束，團隊成員對於其他成員的工作內容都很清楚，團隊成員可以協助Scrum Master發現一些問題和風險，大部分問題和風險還是由Scrum Master發現；

8、Scrum Master協助各種會議的有效進行，如plan meeting、總結會議、PRD reivew、ERD review、Code review、Case review等等；

9、Scrum Master協助plan meeting有效進行，和團隊成員共同商討確定工時的評估方式、本次sprint的計劃內容和優先級別，進而共同完成sprint內容的拆分和工時的評估；

10、Scrum Master協助總結會議有效進行，和團隊成員共同商討總結本次迭代的優點和不足，能夠針對不足制定出有效的改進措施並進行有效的改進，而優點能夠繼續保持；

11、Scrum Master主導，團隊成員參與監控風險和進度，並能定期通知給利益相關人；

12、Team共同完成對DOD的承若；

高階敏捷團隊

1、Product Backlog由PO發起管理，由Team共同參與討論完善；

2、Team共同提出和收集需求，共同對產品負責；

3、Team共同對Product Backlog優先順序進行確定並負責，當變動發生時也是如此；

4、Team中任何一個人都可以承擔Scrum Master這個角色的工作；

5、可以幫助Team跨越Sprint中遇到的一切障礙，對跨Domain和跨部門的問題解決推動能力均較強，保障DoD按約定完成；

6、團隊成員自覺維護Sprint Backlog，Scrum Master定期檢查團隊成員維護Sprint Backlog的情況；

7、團隊成員積極地參加站會，站會高效地效進行，站會在固定地點和固定時間，在標準時長內結束，團隊成員對於其他成員的工作內容都很清楚，團隊成員積極提出問題與風險，和Scrum Master共同發現所有問題和風險；

8、Scrum Master輔助，團隊成員主導各種會議的有效進行，如plan meeting、總結會議、PRD reivew、ERD review、Code review、Case review等等；

9、Scrum Master輔助，團隊成員主導plan meeting，Team共同對工時評估的結果，本次sprint的計劃內容及拆分結果，優先級別確認結果負責；

10、Scrum Master輔助，團隊成員主導總結會議，Team共同對本次迭代的結果負責，能夠共同認識到不足的根本原因所在，後期所有團隊成員都積極有效的改進，將不足逐漸轉變為優點，而優點能夠越做越好；

11、Team共同積極監控風險和進度，並能及時通知給利益相關人；

12、Team從專注功能實現專為專注產品實現，Team有能力識別產品的正確路線，共同促使產品不斷被完善；

同樣都是十二條參考評估標準，越成熟的敏捷團隊，不光對PO和SM的要求越高，還對團隊成員的要求也逐漸提高。在敏捷開發團隊內部，是一個互相學習，互相進步的過程，可以促進整個團隊的能力和水平的提升，因此對團隊的發展是非常有好處的，特別是團隊內部職場新人比較多的時候，化大成本去培訓、去傳幫帶，還不如讓他們在團隊工作當中去學習和成長，這樣可以更加快速的幫助他們提高，也提高了團隊整體的實力。

本文轉自：《IT民工 or IT精英》

原文連結：http://www.itfarmer.com.cn/1787.html