Scrum是一場創業
1993年，Jeff和Ken開創了Scrum，至今已經有25年之久。如今敏捷開發也不是什麼流行詞兒，不少IT組織已經走在敏捷轉型的路上，還有一部分組織則剛痛下決心拋棄瀑布式計劃型開發模型，試圖採納敏捷開發框架（比如Scrum）。但大部分組織即便拼得遍體鱗傷，仍然無法按期交付卓越的軟件，最後要麼放棄，要麼就醫 – 引入專業敏捷諮詢師，ThoughtWorks已幫助業界諸多大型組織成功地敏捷轉型。
在瀑布模型的IT組織中，試點團隊一旦決定採納Scrum，就如同開啓創業。對於創業，我們喜聞樂見的是：有人有想法、有抱負、有激情也有行動力去推動變革，做不一樣的事情，此時，Ta或者Ta們會試圖去尋找志同道合的人，寄希望於通過團隊來提高成功的機率。
就好比軟件永遠無法甩掉業務不確定的天然屬性，Scrum團隊自然也脫離不了創業團隊的屬性，而這些屬性我認爲最核心兩個是：自省和志同。
用雙刃武裝團隊
如果將敏捷劃分成三個層次 – 道、法、術，敏捷樹的根部就是對應的道，它是敏捷的根本，比如敏捷宣言以及敏捷宣言中所體現的價值觀。樹的枝幹對應了敏捷原則，樹葉則是一些敏捷的框架、實踐和工具。
而敏捷的精髓在於敏捷樹的根部，是敏捷提倡的那套尊重、溝通、專注、承諾、勇氣、反饋、開放，價值觀不像實踐那麼具體看得見摸得着，但它值得團隊在實踐中持續不斷地通過自省的方式來打造高效團隊，構建統一願景和目標。
Jeff在他的*《敏捷革命》*中提到兩個例子來突出團隊的力量：
- 耶魯大學的喬爾•斯波爾斯基研究一位教授的最難學課程，最後發現該課程得分爲A的最快的學生和最慢的學生的時間比是1/10，
- 大量研究表明，同等質量完成一份工作，最快的團隊用了1周，最慢的用了2000周。
1986年，*《哈弗商業評論》上一篇題爲《新產品開發新遊戲》*的論文對Scrum起着啓發性的影響，該論文描述了世界上最優秀的公司最卓越的團隊具備以下三個特質：
- 超越尋常，即追求卓越
- 自主性，即自組織團隊
- 多功能，即全功能團隊
任何嘗試敏捷的團隊都值得付出努力讓自己具備上述三種特質，用自省和志同雙刃來武裝團隊無疑是一個明智的決策。
自省是持續改進的基本原則
在術的層面，我們不缺乏工具和知識框架，Scrum和XP就是很好的指導框架（《Scrum精髓》）。很多團隊即便豐富的知識框架的指導下，依然效果不甚理想，總感覺心有餘而力不足。仔細觀察他們的日常"敏捷實踐"，你會發現一起有趣的現象：規劃會開成談判會、站會開成彙報會、衝刺搞成鬥牛場，回顧會開成吐槽大會。
這裏面很大的原因是團隊把關注點放在術的層面，而忽略了這些術背後道和法，每當遇到阻礙時，團隊需要停下步伐去思考和反省，跳出術的視野，不要着急去懷疑依樣畫葫蘆卻仍然失敗的實踐，更多去探索在實踐過程中有沒有違背核心價值觀。比如，站會效果差，是不是團隊不夠包容，指責文化重，大家沒有勇氣去暴露問題。再比如，大家不願意參加回顧會，是不是團隊存在隱形政治，團隊成員不敢發表自己的觀點，互相不信任。而衝刺質量低，是不是大家不能好好專注於目標，或者團隊目標不明確，等等，這些都是值得我們不斷去思考和反思的，持續做出調整和改進，在團隊建設上更是刻不容緩。
志同是高效協作的核心保障
傳統瀑布計劃型開發模型將軟件開發週期分成了幾個大的階段，每個階段由不同的職能團隊負責，各自只對自己的環節負責，缺乏全局的視野和統一的目標，很難培養出共同的責任感和使命感，進而無法保障團隊與團隊之間信任的建立。
Scrum核心目標之一就是要克服團隊協作的障礙，Scrum創始人借用這個橄欖球運動的專業術語，它的原本意思是：團隊通力合作，在場地內傳球。這個過程需要團隊認真配合、信念一致和目標明確。所以一個成熟的Scrum團隊，團隊成員都應該保證目標一致且互相信任的。在這個基礎上，成員各個身懷絕技，並且具備較強的責任感和自我管理的能力，在毫無自上而下發令的前提下，自下而上的自發協作完成工作，且積極主動承擔更多的挑戰。
打造一支這樣的團隊並非容易的事情，過程中也離不開不斷地自省改進。*《Scrum精髓》*中描述了Scrum中優秀的開發團隊的應該具備的十種特徵：
- 規模規模適中
- 自組織
- 跨職能的多樣化和全面化
- 團隊成員穩定
- 專注、有責任感
- 火槍手態度：人人爲我，我爲人人
- T型技能
- 透明溝通
- 高帶寬溝通
- 工作節奏可持續
以上十種特徵分別從團隊組成（1，2，3，4）、團隊成員（5，6，7）、團隊文化（8，9，10）三個視角提供了很好的參考，你也可以在你的團隊中，經常檢視團隊有沒有具備這些特徵以及如何能夠培養這些特徵，並付諸行動。
敏捷真的很難嗎？
當我嬰兒學步的時候，我走路中遇到障礙物摔倒後，我不會立即爬起來就跑，而是會在摔跤地好奇的掃幾眼（可能哭着看），然後才爬起來繼續，而且還會時不時回頭撇幾眼摔跤點（不是爲了記恨它）。
當我在備戰高考的時候，每週一小考，每月一大考，期中期末上巨考，這些考試都是在頻繁地檢查我在該階段的學習成果（暫且不討論學習方法科學與否），每次我都會根據考試成績，做出針對性調整，而且不斷地在重複這個循環。
除了這些習以爲常的事情，比如質量管理界著名的PDCA戴明環[1]，軍事界的著名的博伊德OODA環[2]，無不在凸顯很重要的兩點：檢視、調整，這兩點加上透明構成了Scrum的三大支柱。
就連大部分IT組織正在進行傳統的瀑布開發模型，借用極限編程的思想理念[3]：我們可以把整個軟件開發週期階段引入到每個版本規劃中，進而引入到每個衝刺規劃中，最後引入到每個用戶故事[4]中，也就被扣上了敏捷帽子。
敏捷其實一直都在，不管你是在意還是不在意。而對於Scrum方法更簡單 – 無論你什麼時候啓動一個項目，爲什麼不經常檢驗一下自己在做的事情：
- 團隊現在前進的方向對不對？
- 當前結果是不是大家真正希望看到的？
- 是否有什麼辦法能改善目前正在做的事情？
- 如何才能做的更快更好？
- 未來會存在那些潛在的障礙和風險？
對着你的團隊不斷地發問，縮短檢視和調整的週期，敏捷終有一天會成爲你碗中菜。
守術、破法、離道
對應敏捷的道、法、術，守、破、離是一個好的前進方式。新團隊，先守術，比如逐步在團隊中引入Scrum框架中的實踐，守的過程肯定會不斷遇到問題，始終手持雙刃，通過不斷地自省，持續改進，沉澱團隊的敏捷文化。應對守術過程中的問題遊刃有餘之後，再嘗試去破法，根據團隊自身情況嘗試一些不一樣的實踐，找到跟團隊更匹配的實踐。當團隊都深深理解敏捷價值觀了，敏捷就猶如一個開源框架，團隊可以隨心所欲的做出取捨和創新，只要不違背敏捷價值觀，它都可以是敏捷實踐，這樣你栽培的敏捷樹將枝葉繁茂。
註釋
- PDCA戴明環，Plan-Do-Check-Act，由美國質量管理專家休哈特博士首先提出的，由戴明採納、宣傳，獲得普及，所以又稱戴明環
- OODA循環，Observe-Orient-Decide-Act，是美國空軍上校約翰•博伊德根據人腦決策過程建立的一種空戰理論
- 極限編程理念：將我們認同的有效軟件開發原理和實踐應用到極限
- 用戶故事極限編程的一項實踐，它是在迭代中指導開發的業務需求單元載體
Posted by 袁慎建@ThoughtWorks
版權聲明：自由轉載•非商用•非衍生•保持署名 | Creative Commons BY-NC-ND 4.0