最近一周犯了一個常見的錯誤，操之過急和揠苗助長。也與我一向宣導(dǎo)的原則相違背。在這里分享出來，一是引以為戒；二是幫助ScrumMaster們避免掉進(jìn)相同的坑。
公司基于業(yè)務(wù)方面和技術(shù)層面考慮，決定啟動一個新項(xiàng)目。
業(yè)務(wù)方面的目標(biāo): 通過這個項(xiàng)目把一個業(yè)務(wù)產(chǎn)品化，用于支持多個產(chǎn)品的某一個共同的關(guān)鍵業(yè)務(wù)，提升交付能力和減少重復(fù)工作。
技術(shù)方面的目標(biāo): 希望為公司的技術(shù)架構(gòu)探索一個新的方向，微服務(wù)化，提升公司的架構(gòu)水平；為其他團(tuán)隊(duì)提供一個有單元測試、一致代碼規(guī)范、良好的工作過程實(shí)踐的范例。
兩個目標(biāo)都達(dá)成方能算是真正的成功。
這個項(xiàng)目成立了一個Scrum團(tuán)隊(duì)，團(tuán)隊(duì)內(nèi)部的人員要求由我擔(dān)任ScrumMaster來引導(dǎo)他們。團(tuán)隊(duì)的成員之前已經(jīng)在另一個團(tuán)隊(duì)與我有過一段時間的合作(這一點(diǎn)恰恰是我自己坑自己地方)。
正式啟動之前，我都會幫助團(tuán)隊(duì)認(rèn)識，什么是ScrumMaster，ScrumMaster不做什么，做什么。Scrum中的各項(xiàng)工作，是哪些角色的范圍。讓大家達(dá)成一致的認(rèn)知：
- ScrumMaster是沒有權(quán)力的角色。
- ScrumMaster不是保姆，什么都干。
- 交付是團(tuán)隊(duì)的范圍，不是ScrumMaster的。
- 質(zhì)量是團(tuán)隊(duì)的范圍，不是ScrumMaster的。
- 會議是團(tuán)隊(duì)的范圍，不是ScrumMaster的。
.....
為了限制強(qiáng)技術(shù)背景型ScrumMaster(我)，不自覺的干涉團(tuán)隊(duì)，我給團(tuán)隊(duì)一個重要約定, 也是對自己的一個緊箍咒:
- 團(tuán)隊(duì)有權(quán)決定做什么，ScrumMaster無權(quán)強(qiáng)迫與干預(yù)的團(tuán)隊(duì)決定。
- ScrumMaster可以給出建議，團(tuán)隊(duì)決定是否采納，甚至可以當(dāng)場懟回ScrumMaster "你在胡說八道, 回去喝茶吧"。
- ScrumMaster 承諾為項(xiàng)目過程中的一切技術(shù)實(shí)踐問題提供幫助和培訓(xùn)和解決。
- 如果團(tuán)隊(duì)采納ScrumMaster的某項(xiàng)建議，ScrumMaster 必須負(fù)責(zé)兜底。
- ScrumMaster 負(fù)責(zé)給團(tuán)隊(duì)提供一個安全的空間，擋住各種干擾。
- 團(tuán)隊(duì)對項(xiàng)目的結(jié)果負(fù)責(zé)。
接下來便是和團(tuán)隊(duì)形成工作約定, 并且確保每一條都當(dāng)場認(rèn)可的。
團(tuán)隊(duì)達(dá)成如下工作約定
PO 編寫用戶故事
團(tuán)隊(duì)編寫驗(yàn)收標(biāo)準(zhǔn)，PO負(fù)責(zé)審核
用戶故事滿足DoR方可進(jìn)入Sprint
DoR:
- 故事粒度滿足 INVEST, 可實(shí)現(xiàn)故事
- 故事已經(jīng)拆解AC，并通過PO審核確認(rèn)
- 必要時，附上原型圖，設(shè)計(jì)圖
團(tuán)隊(duì)交付必須滿足 DoD
DoD:
- 故事的每一個AC都必須已實(shí)現(xiàn)，并驗(yàn)證通過。開發(fā)人員為首要驗(yàn)證人員。
- 至少在API級別提供相應(yīng)的測試用例代碼
Sprint 1的開始時間為下個星期一 (如果我記錯，請糾正)
Sprint 周期為兩周，10個工作日。
Stand Meeting 為每日上午 10:20
團(tuán)隊(duì)嘗試采用物理白板來可視化狀況
團(tuán)隊(duì)的速率(Velocity), 用 AC 數(shù)量進(jìn)行度量
團(tuán)隊(duì)作為一個整體進(jìn)行考核，不單獨(dú)考核某個個體。團(tuán)隊(duì)需要的是內(nèi)部合作，而不是內(nèi)部競爭。
代碼提交必須采用 Pull Request 方式, 測試代碼是提交內(nèi)容的重要部分之一。
提交的PR, 必須滿足 ESLint 的檢測，和測試用例的通過，方可合并。
陷阱之一:
約定是否能遵守，取決于成員的認(rèn)知水平、能力、廉恥程度。
不會的可以問、可以學(xué)，不明白的可以動手嘗試。
但是對于面對一點(diǎn)困難就各種理由各種現(xiàn)實(shí)客觀因素的，告訴你這"不可能" 那"做不到"，又不愿承認(rèn)自己做不到并不代表其他人也做不到，就屬于廉恥問題了。
教練能解決認(rèn)知、能力。解決不了廉恥問題，也不建議費(fèi)力去解決。
團(tuán)隊(duì)的單一個體，有一些經(jīng)驗(yàn)和技術(shù)，在公司中算不錯，按照我的標(biāo)準(zhǔn)(我的標(biāo)準(zhǔn)較高)，還達(dá)不到優(yōu)秀的程度。但作為一個整體運(yùn)作，卻屬于比較初級。
由于上面提到的，這個項(xiàng)目除了有交付的目標(biāo)，還有技術(shù)實(shí)踐的目標(biāo)。
團(tuán)隊(duì)連微服務(wù)的本質(zhì)都不甚了解，還只是浮于從網(wǎng)上獲取的表面的認(rèn)識。DDD, Bounded Context, Aggregate, Hexagonal Architecture 是什么鬼？
由于各方的這個項(xiàng)目有著過高的期望。作為ScrumMaster，太過于想要確保這個團(tuán)隊(duì)能成功，因此發(fā)出太多聲音。
如何需求拆解成一個個獨(dú)立的可交付故事，如何再從一個個獨(dú)立的故事中，識別出完成整個完整的業(yè)務(wù)流程的最小化故事，如何繼續(xù)從最小化故事中，識別出驗(yàn)收標(biāo)準(zhǔn)，并通過驗(yàn)收標(biāo)準(zhǔn)來指定Sprint規(guī)劃。確保每個sprint都能交付完整流程的交付。
圖片取自 Scrum中文網(wǎng) 資料庫中的 玩轉(zhuǎn)MVP不要錯過這四個案例
PO比較nice, 按照引導(dǎo)調(diào)整做事方式，識別出Sprint1的最小完整流程的故事與驗(yàn)收標(biāo)準(zhǔn)。
團(tuán)隊(duì)也接受編寫驗(yàn)收標(biāo)準(zhǔn)，一開始能寫的多好不是最關(guān)鍵的，從零到壹已經(jīng)是一個值得贊揚(yáng)的進(jìn)步，這也為馬上要做的自動化驗(yàn)收標(biāo)準(zhǔn)測試提供了基礎(chǔ)。
但是在技術(shù)實(shí)踐方面
-
開發(fā)團(tuán)隊(duì)對需求還是不夠重視，還是以舊有的習(xí)慣，做到哪再理解到哪。
-
領(lǐng)域模型都還沒整理清楚，急于交付，就投入到細(xì)節(jié)實(shí)現(xiàn)。
-
拿著個MVC框架就當(dāng)是微服務(wù)。
-
認(rèn)為質(zhì)量就是測試人員的事。
-
單元測試屬于不現(xiàn)實(shí)，甚至連接口級別的測試都不愿意寫，認(rèn)為這些都是屬于測試人員該干的事情。
-
對 Pull Request 的作用與價值和基本使用方法不愿去了解。
-
壓根不用考慮什么 Code Review。
.....
(注: 我發(fā)現(xiàn)許多人還不明白Pull Request為何在團(tuán)隊(duì)協(xié)作中非常重要、價值之大。既然如此，我也不打算免費(fèi)教大家了，未來我會設(shè)計(jì)一個付費(fèi)課程，專門解讀 Pull Ruquest 的作用和價值，以及在工作如何用它來如虎添翼。)
作為ScrumMaster，應(yīng)當(dāng)引導(dǎo)團(tuán)隊(duì)自己去學(xué)會釣魚，安安靜靜的喝茶，靜待團(tuán)隊(duì)慢慢的改變。
我違背了這個原則，發(fā)現(xiàn)他們學(xué)不會釣魚，操之過急，便直接給魚他們。
人的差別在于認(rèn)知高度的不同，當(dāng)團(tuán)隊(duì)缺乏相應(yīng)的高度，又不愿意不敢面對這一點(diǎn)的時候，直接建議他們該如何做，是沒有效果的，并且會得到反彈。
幸好，我在一開始，給自己上了一個緊箍咒、保險：
我只能建議，不能強(qiáng)迫；團(tuán)隊(duì)可以決定不聽，堅(jiān)持自己的做法。
如果團(tuán)隊(duì)認(rèn)為SM的一些做法，是給團(tuán)隊(duì)制造障礙，SM必須立刻停止。
盡管我一再強(qiáng)調(diào)，我只給建議，不是要求，更不是命令，不需要感到有壓力，甚至可以不理會。對于不認(rèn)同的，只需公開說，"我不認(rèn)同", 便不會繼續(xù)。
但隨著我的建議越多，團(tuán)隊(duì)依然感到壓力越大，卻不敢公開表達(dá) (勇氣何在？)。正得益于上面的"保險"，一周左右，終于反彈，不承認(rèn)一開始的那些約定，理由：“不現(xiàn)實(shí)", "不可能"。
這便造成，操之過急，揠苗助長的想把團(tuán)隊(duì)提升一個level，違背團(tuán)隊(duì)意愿的"車禍"。
出現(xiàn)狀況，作為SM
1. 主動向團(tuán)隊(duì)認(rèn)錯，改變做法。除非團(tuán)隊(duì)主動求助，否則，不再直接給任何建議與解決方案。
嚴(yán)格遵守賦予團(tuán)隊(duì)的權(quán)力。團(tuán)隊(duì)甚至可以要求 SM 離開團(tuán)隊(duì)。
2. 允許并鼓勵團(tuán)隊(duì)修訂約定，把認(rèn)為是障礙的約定項(xiàng)，統(tǒng)統(tǒng)刪除。
有意思的是，居然沒有一個成員敢于在這個項(xiàng)目組里，說出要移除哪些約定項(xiàng)。
好吧，既然PR是個無用的，拿掉，所有人直接push代碼；
API級別測試用不愿做，拿掉，反正我是不做任何要求；
但是，有一點(diǎn)，只要大家沒有把"團(tuán)隊(duì)寫驗(yàn)收標(biāo)準(zhǔn)"這一條拿掉，我便強(qiáng)要求做
"自動化驗(yàn)收標(biāo)準(zhǔn)測試", 因?yàn)檫@個是我和測試人員做，不是開放團(tuán)隊(duì)做。
3. 同CTO與PO進(jìn)行溝通，把情況說明，降低與平衡好期望。
能MVC這把刀耍好就不錯了，不要奢望一步到位的微服務(wù)。
4. 分離職責(zé)：交付的要求與期望，歸PO承擔(dān)，PO對交付結(jié)果負(fù)責(zé)；技術(shù)實(shí)踐要求和指標(biāo)，歸CTO； SM不需要再承擔(dān)交付于技術(shù)實(shí)踐的要求，回歸SM的領(lǐng)域，對過程負(fù)責(zé)，對團(tuán)隊(duì)愿意改進(jìn)的部分提供支持。
SM之所以操之過急的一個根源，也是因?yàn)镾M承擔(dān)的職責(zé)過多。
這也是團(tuán)隊(duì)發(fā)展的四個階段中一個階段，震蕩期(或叫沖突期)，實(shí)際上，也正是通過這個時期，才能形成真正的規(guī)范與行為。
團(tuán)隊(duì)的行為模式背后有一個嚴(yán)重的根源: 主要成員認(rèn)為 Scrum 就是競爭，成員與成員之間的交付競爭，比誰產(chǎn)出多，產(chǎn)出最少的，有給干掉的風(fēng)險。所以，怎么快怎么整。
這個問題一開始就存在，我問過他們，為何有這種理解，他們說他們以前經(jīng)歷的Scrum團(tuán)隊(duì)，就是競爭模式。 即使我一再強(qiáng)調(diào)我們要的是協(xié)作而不是競爭，甚至專門在工作約定中單獨(dú)寫明這一點(diǎn)，并承諾在公司層面確保這一點(diǎn)。依然沒能很好的消除他們心里的擔(dān)憂。
團(tuán)隊(duì)與團(tuán)隊(duì)之間，可以有競爭。但是，團(tuán)隊(duì)內(nèi)部競爭，只會是災(zāi)難。
回顧:
1. SM可以引導(dǎo)團(tuán)隊(duì)的節(jié)奏，但不可以試圖掌控團(tuán)隊(duì)的節(jié)奏。
2. SM盡量避免直接給魚。
3. SM不要太過于想要為團(tuán)隊(duì)保駕護(hù)航。要根據(jù)團(tuán)隊(duì)的個性來定，團(tuán)隊(duì)作死，就看著他們死。
4. SM避免去過多承擔(dān)團(tuán)隊(duì)的職責(zé)，過度保護(hù)。
5. SM要因人而異，對于認(rèn)知層級低且固執(zhí)的人，不要試圖去改變他。
6. 知識與經(jīng)驗(yàn)是有價的，主動免費(fèi)提供，反而不受重視。
7. 牛不喝水，你按不下它的頭。強(qiáng)按，當(dāng)心牛角。
8. 保持更多的耐心，安心喝茶，靜待花開。
9. SM也會犯錯, 發(fā)現(xiàn)了，必須第一時間公開承認(rèn)錯誤，并糾正。不要太在意面子，越追求面子，越容易被打臉。
下一步，我會以實(shí)踐的經(jīng)驗(yàn)，設(shè)計(jì)一個付費(fèi) Scrum的分解系列課程，幫助更多的人從零到入門，從原理到如何實(shí)際操作。
