敏捷開發團隊成熟度評估參考標準
當一個產品團隊採用敏捷開發模式時,如何來確認這個團隊是否真的已經敏捷了呢?這個是非常重要的,在日常工作過程當中,團隊的工作模式很大程度上會受團隊負責人或者服務性領導的影響,有時候會因為這個負責人的一些個人工作風格,而使團隊的敏捷模式偏離了方向,沒有讓團隊真正的敏捷起來。前面一篇文章也介紹過,在敏捷開發模式團隊內部,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的要求越高,還對團隊成員的要求也逐漸提高。在敏捷開發團隊內部,是一個互相學習,互相進步的過程,可以促進整個團隊的能力和水平的提升,因此對團隊的發展是非常有好處的,特別是團隊內部職場新人比較多的時候,化大成本去培訓、去傳幫帶,還不如讓他們在團隊工作當中去學習和成長,這樣可以更加快速的幫助他們提高,也提高了團隊整體的實力。
作者:朱軍華Ronzhu
推薦閱讀:
※敏捷實際是迭代的瀑布模型的變種,這種觀點對嗎?
※如何看待 PMI 推出的敏捷認證 PMI-ACP?
※持續集成將死
※打造敏捷團隊文化的十項妙計