本書經過真實的例子,介紹如何輔導團隊平穩度過整個敏捷轉型生命期,如何打造一個自立、自覺的敏捷團隊。針對敏捷實踐的工做機理和如何激發團隊的成長有深刻的思考,可幫助讀者瞭解如何高效召開各類敏捷會議,及如何指導團隊創建良好的工做流程和工做習慣。總結了在敏捷轉型過程當中教練和團隊可能面對的障礙及應對方案,不少都是咱們實際敏捷推廣過程當中遇到過的問題,對於剛開始推行敏捷轉型的敏捷教練、團隊仍是頗有指導意義的。單元測試
後面幾章是講具體的敏捷實踐,在不少書籍都有介紹過,就沒有仔細去看了。學習
第一章教練的職責測試
1.1敏捷教練的職責優化
1.2教練角色開發
• 給出建議,讓團隊本身決策而不是由你指定方向文檔
• 以團隊外援的身份履行教練角色,優點在於可以和團隊親歷問題,而不是旁觀。團隊知道你是從親身體驗的角度看問題時,會把你視爲本身人。工作流
• 敏捷教練並不須要知道全部的答案,有時候沒有答案反而更好,非專家定位有助於你和問題保持必要的距離,還能從局外人的角度看待問題,幫助團隊總體優化。書籍
• 能夠引導討論,也能夠引入組織內外其餘敏捷團隊嘗試的經驗。循環
• 團隊境況愈來愈好的時候,教練應該功成身退,讓團隊自我教導,本身想辦法找答案。im
1.3幾個重要的習慣
• 以身做則:從本身作起,讓團隊看到真實的例子
• 平衡心態:別讓團隊的反應亂了陣腳
• 按部就班:耐心,逐步改進
• 謹言慎行:注意言辭,說話要基於團隊的立場
• 邊走邊學:嘗試,反思,從錯誤中學習
1.4教導前應澄清的問題
1.5PrOpER教導循環
• 問題:選擇一個問題着手解決,觀察團隊的工做方式,哪些方面須要改進?
• 選項:考慮可選方案,哪些能推進項目向好的方向發展,列出至少三個選項。
• 試驗:選擇其中一個進行闡釋
• 檢驗:檢查結果,是否有所改善?是否有經驗教訓?
1.6考慮可選方案的方式
• 暴露問題:讓團隊看到問題
• 公開討論問題:和團隊討論這個問題
• 靜觀其變:擱置問題,若是狀況變得更糟糕,團隊也許本身會發現問題
• 暗度陳倉:說服團隊內或團隊以外的其餘人認識到問題
• 根因分析:尋找問題的根本緣由
• 教育團隊:提供更多信息幫助團隊找到解決辦法
• 予人權責:將此職責轉交給團隊或某個團隊成員
• 在受阻時,能夠想象其餘教練面臨一樣的情形時所採起的措施。
1.7醃黃瓜現象
• 黃瓜在鹽水灌裏泡久了,會變成醃黃瓜。
• 若是咱們跟同一個團隊,甚至同一家公司長達幾個月之久,會失去咱們的新鮮視角。咱們會看不出之前一眼就能察覺出來的問題,思想逐漸大衆化,「咱們這裏就這樣作事」。
• 若是發現本身正在變成醃菜,試着向外人解釋你所面對的團隊流程及挑戰。解釋過程當中,也許能再度發現流程中的問題、隱藏的假設以及「房間裏的大象」。
• 房間裏的大象:指那些觸目驚心地存在卻被明目張膽地忽略甚至否認的事實或者感覺。
1.8敏捷攔路石
• 當團隊碰上嚴重障礙沒法走向敏捷時,建議先移除障礙,再啓動敏捷。否則人們會將失敗歸咎於敏捷。
• 好比正在進行組織結構調整,人們會更關注如何保住本身的工做,而無暇顧及敏捷。
第二章 與人合做
2.1傾聽
• 先傾聽再提建議:
– 傾聽最難的在於剋制本身的衝動,例如過早給出建議,或者把話題轉到本身的類似經歷。
– 你也許對所發生的事情有不一樣的見解,但在查清事實真相以前,先花時間聽完對方的說法。
– 談話順利,能夠要求澄清問題,以便不帶偏見地理清事情的前因後果,並體現出你的意圖在於澄清事實,而非對他們的行爲進行盤問或批評。
– 參與集體會議時,若是你發現他們誤解了一些東西,好比:「咱們已經敏捷了,因此不須要寫版本發佈文檔」,此時能夠暫停會議檢查團隊對這一點的理解。
– 你們說什麼詞,你就用什麼詞,不要把你的理解強加於人,大膽問他們並確認是否已準確理解他們的要點。
• 言外之意:
– 尋求支持,仍是找認同感,仍是但願你幫助解決他所描述的問題
– 設身處地爲他人着想,想象他們對現狀的感覺
• 維繫信任關係:
– 結束談話時,總結聽到的關鍵點,並和對方確認,你是否理解他們的須要?
– 講話者和你分享信息老是有緣由的,但若是談話後不繼續跟進,他們可能會不再會這樣作了。問題暴露出來後,須要深刻調查後再承諾,不要勉強本身當即作出承諾。
– 不要泄密,確認談話內容是須要保密,仍是能夠和團隊分享他們的擔心。
• 背景傾聽
– 引導會議的時候,關注每一位發言者,等他們說完後再要求澄清。能夠複述他們所講的內容,這有助於你檢驗本身的理解。
• 給予反饋
– 談談從你的視角看到的數據,給出你曾經耳聞目擊的具體實例,而不是你的詮釋。
2.2化解矛盾
• 有時團隊會遇到一些衝突,教練可能會被捲入其中,若是發現團隊內潛藏的矛盾,就多花點時間聽聽團隊內有哪些見解,瞭解它的前因後果。
• 在扮演仲裁者角色時,不能偏袒任何一方,聆聽各自對問題的描述,並用本身的話複述問題,代表你理解他們說的內容。接下來剝離個體緣由,從團隊的角度從新描述問題,告訴你們你發現一些環境因子對局勢是有影響的。好比團隊承受着交付壓力,致使你們都工做到很晚。或者畫畫因果圖,查明有哪些影響力。
• 團隊內部化解紛爭,有助於中止各自爲政的行爲。經過聆聽,瞭解團隊面臨的問題,創建互信。
• 給反饋時,要區分所見所聞跟感覺。講觀察結果時,要用實際的例子,而不是泛泛的建議。先講述耳聞目擊的例子,再問問他們的看法,接着你們一塊兒討論下次如何應對相似的狀況。
• 如爆發衝突,確保衝突各方都有機會陳述各自的觀點。
2.3達成共識
• 引入新實踐的時候有助於搞清楚是否全部團隊成員都買你的賬。
• 梯度級別投票,將贊同的級別分紅從力挺到力阻。
• 共識很重要,由於在有人不認同某措施的時候,他們不大可能全身心的投入。有時候你得作出決定,即便沒有達成共識,也值得去作。經過一段時間的變動,團隊在回顧會議上從新評估其成效。但若是梯度級別顯示有不少反對聲音,就得努力尋找全部人都能接受的方案。
• 相反的有贊成階梯,即在你們贊成作某一件事的前提下,針對具體細節作投票。
第三章 領導變革
3.1引入變革
• 身爲敏捷教練,你的工做有時是引入新的敏捷實踐,有時則是幫助團隊優化工做流程。無論是哪一種,都須要領導團隊實現變革。這並非告訴你們該作什麼這麼簡單。人們須要先知道爲何要這麼作,才能全身心投入其中。
• 不能太快推進團隊實現變革,開始變革前,團隊須要時間討論一下,認識到本身如今須要作哪些調整。
• 授人以漁
– 僅僅說服團隊必須變革還不夠,還須要告訴他們怎麼起步。假設你給某團隊的建議是寫單元測試,說這能夠幫助減小缺陷泄露,你會發現全部人都點頭贊同,但就是不真正動手寫測試。千萬不要驚訝,他們須要再支持以實現變革。
– 有如下辦法能夠試試
• 教育團隊:安排內訓課,幫助你們學習如何寫單元測試
• 演示:和開發人員結對,親自示範如何寫單元測試
• 公示:幫助團隊達成共識,天天都寫必定數量的單元測試;在團隊白板上追蹤目標的進展。
• 兜售問題
– 不要急着發表本身的觀點,先準備好能夠驅動變革的問題兜售出去。團隊若是不改變,最可能的結果是什麼,要把這幅景象清晰的描繪出來。讓你們都明白,「不變」是有問題的。
– 變革的確須要花更多的時間、金錢,可能還會有不少困難。跟你們解釋,爲何你還認爲變革是個好主意,帶來的收益大於付出。
– 例如:先走查,然後才遷入代碼,這意味着實現用戶故事須要更長時間,但這一樣意味着,從長遠看代碼更容易維護。
– 若是能找到支撐觀點的證據,兜售問題就更有說服力。上述例子,若是能分享一些代碼在發佈前被頻繁退回返工的數據給你們看,再提出預測就會頗有效。但不要批評團隊當前的工做方式,教練的關注點是流程改進,不是個體績效。
– 在理想狀況下,你會發現大把的問題和改進機會,可是若是一個不漏的數落全部問題,就會給人留下負面印象,人們很快就不會再聽你的。
– 若是要人們接受你的領導,能夠「從小的變化開始,每次只作一件事,和團隊集中精力解決它,其餘的稍後慢慢來」。
3.2提問
• 向別人提問的行爲代表你尊重他們的意見,並且對他們的回答感興趣。儘可能採用有啓發性的問題,好比:
– 要讓這個缺陷再也不出現,咱們能作什麼?
– 咱們怎樣才能作到按時發貨?
• 使用「爲何」這類問題要格外當心,這聽起來像是批評,雖然你並沒有此意。好比:「你爲何要那樣作?」聽起來就像指責,而「你有試過…作嗎?」聽起來友好一些。也儘可能不要使用「大家」這種字眼,讓人感受居高臨下。
• 問什麼
– 求助型問題:不要在團隊會議上問,那是通常的作法,要選擇一對一的時間問他們。
– 思考型問題:經過思考型問題引導團隊思考。好比:
• 這個問題你考慮多久了?
• 針對這件事情所作的考慮,你本身滿意嗎?
• 你有哪些看法?
3.3鼓勵學習
• 鼓勵團隊在計劃裏留出一些時間,例如,若是團隊想要試試測試驅動開發這樣的新實踐,他們須要有時間事先學一學怎麼作,然後纔開始實施。
• 不要讓團隊對你產生依賴,把你做爲他們惟一的敏捷知識來源,要鼓勵他們本身主動學習相關知識。
• 安排時間讓組織裏的其餘人分析他們的敏捷經驗,這能爲你的同事創造機會,展現他所學的東西。
3.4引導會議
• 爲團隊引進新實踐時,須要展現具體作法。例如回顧會,主動請纓引導會議,向團隊展現具體作法。在會議進行時,把遵循的流程解釋給團隊聽,讓他們學習如何自主引導這些會議。
• 下次會議前,協助會議的引導者規劃會議議程,然後在會議中退居次席。但也要實時發表評論,向團隊展現你的思考過程。
• 總結要點:結束會議時,把全部要點記錄在白板上以前,複述你的理解,檢查並確認本身真的理解了這些要點。
後面幾章都是講具體的敏捷實踐,在不少書籍都有介紹過,就沒有仔細去看了。