\\\\\\\
在過去的4到5年中，我一直擔任軟體開發教練，幫助組織改進他們的技術實踐。
\\ 我也是偶然中發現自己正在承擔教練的角色。一開始，我有點驚慌失措，因為之前從未做過這樣的事情。我曾經組織過tdd和軟體設計方面的活動會議，但從未按照某種邏輯順序來組織它們。
\\ 我的第乙個挑戰是選擇活動主題。
\\\\
經過幾次迭代，我開始專注於xp實踐，特別是tdd、結對程式設計、重構和簡單設計。
\\ 隨著經驗的增長，我能夠將這些練習分解為更細粒度的主題。
\\ 我的目標是找到盡可能平滑的路徑，避免出現大的學習跳躍。另乙個目標是找到具有程式語言無關性的主題。由於我工作的大多數組織都使用物件導向正規化，所以一些主題偏向了物件導向。以下是我目前的主題分類：\\
結對程式設計備忘單
\\\\
多年來，我一直按照一定的主題順序開展實驗，並根據得到的反饋做出調整，現在已經不需要再做出任何重大的調整了。
\\ 這並不意味著我總是嚴格地按照這個順序進行。我發現，在某些情況下，對順序進行即時調整是有好處的。有時候，人們需要了解物件導向概念，有時候又需要用到設計模式，還有一些是關於領域驅動設計的。
\\ 我努力嘗試找出乙個不會造成學習大跳躍的順序，同時又能避免新增不會在後續「模組」中使用的教材。
\\ 因此，測試替身被排到了比較靠後的位置，而這個專案之前通常排在最前面。
\\ 以下是我目前的主題順序：
\\ 物件導向的基礎（可選的前導會話）。\\t
結對程式設計。\\t
經典tdd。\\t
轉換優先順序前提。\\t
物件健美操。\\t
重構技術。\\t
**的味道。\\t
遺留**。\\t
簡單設計四要素。\\t
solid原則。\\t
測試替身。\\t
從外到內tdd。\\t
設計模式（可選）。\\t
領域驅動設計介紹（可選）。\
在確定了主題順序後，下乙個目標就是為人們制定練習內容。練習是至關重要的。資訊本身並不是很有用，學會應用知識等於掌握了知識，而刻意練習是成功的關鍵。
\\\\
「重複造就了我們。因此，卓越不是一種行為，而是一種習慣。」——亞里斯多德
\\ 在我執教的早期階段，我嘗試讓人們結對完成他們的工作。我發現人們對這種方式感到沮喪，因為他們會跟不上速度，而且並非所有任務都適合使用結對的工作方式。
\\ 為了解決這種挫敗感，我試圖採用常用的**kata。這樣做效果更好，但由於在工作區域結對，經常被打斷是個大問題。我的解決方案是帶他們到乙個安靜的遠離辦公桌的地方，並和我一起練習。
\\ 後來，我嘗試與一對開發人員合作，而不是進行一對一指導。我發現這種方式的效果更好，可能是因為人們可以相互學習，而不僅僅是從教練那裡學習。後來，我嘗試混合不同團隊的人來建立結對。我試著看看這種方式是否會改善團隊之間的溝通，結果比預期更好。
\\ 我過去曾經使用過很多種練習，有些可行，有些不可行。在下面的**中，我提出了一些在實踐中可行的專案。
\\ 結對程式設計
沒有（在後續的所有練習中使用結對程式設計技術）
1經典tdd
fizzbuzz、閏年、fibonacci數列、字串計算器
2轉換優先順序前提
羅馬數字、質因數、保齡球
2物件健美操
tictactoe、生命週期遊戲
2重構技術
重構高爾夫、網球遊戲
1**的味道
我使用了自己設計的練習，計畫在適當的時候公開
1遺留**
鑲金玫瑰、冷知識
2簡單設計四要素
火星車（從外部開始你的測試）
2solid原則
我使用了自己設計的練習，計畫在適當的時候公開
1測試替身
字元複製程式
1從外到內tdd
銀行、購物車
2設計模式（可選）
使用命令模式、策略模式和狀態模式來重構火星車
2領域驅動設計（可選）
討論他們的銀行和購物車方案
1我只在有多餘的時間並且我認為結對的人已經做好準備的情況下才會使用可選的會話。至於序言，我只會在有必要的時候才使用它。
\\ 在與另一位教練討論時，他向我介紹了bloom分類學。這是一種用在教學中的模型，根據複雜程度設定學習目標。
\\ 這個模型定義了六個級別的目標：記住、理解、應用、分析、評估、創造。我將這個模型應用於技術實踐，並且為確定人們至少可以達到應用級別。
\\ 我總是停留在某個主題，直到人們感覺可以應用特定的練習。僅僅記住和理解一種做法是不夠的。我試著讓人們不斷突破學習等級，只有他們能夠應用學到的東西時才算真正學會了。
\\\\
在我擔任教練的工作中，我需要面臨一系列挑戰。在本節中，我將介紹最常見的場景以及我是如何處理它們的。
\\\\
我通常會從高階的開發者那裡聽到這句話。如果他們認為自己還沒有準備好參加教練課程，我不會推他們。指導應該是一種拉而不是推。我選擇和渴望學習並與我合作的人一起工作。隨著時間的推移，他們開始傳播他們所學到的東西，不那麼渴望參與的人也開始變得積極起來。這個策略對我來說非常有效。
\\\\
我非常堅信，不通過實踐獲得的資訊是沒有價值的。如果有人專注於資訊但卻拒絕練習，我就不再繼續。不過我從來沒有真正做得這麼極端。在某些時候，人們會意識到刻意練習的重要性。有時我會質問他們，他們究竟可以用新資訊來做些什麼。另乙個辦法是開始練習並讓他們逐漸找到興趣所在。
\\\\
這通常是因為害怕暴露乙個人的弱點。作為一名教練，我需要想辦法克服他們的恐懼。我要讓他們相信這裡是乙個安全的學習環境。通常，我會故意犯一些愚蠢的錯誤或暴露我對某個主題的無知，讓其他人在暴露他們的技術弱點時感到不那麼拘謹。
\\ 作為教練，我也想辦法建立小組。我嘗試避免結對的人力量分配不均，所以我通常從不同的團隊中選擇成員進行結對，並嘗試讓具有同等經驗水平的人進行結對。我發現與陌生人結對更容易。
\\\\
我對這個問題的通常回答是：你如何衡量質量？這完全是主觀的。
\\ 即使在短期內無法衡量，在中期仍然會起到一定作用：
\\ 完成課程的人與職位晉公升之間存在關聯;\\t
團隊中的噪音水平增加;\\t
在完成課程之後，團隊討論的數量、長度和重點都在增加;\\t
討論更側重於設計，而不是新技術、產品和玩具;\\t
人們開始關心和分享得更多。\
有一些人對學習這些實踐很感興趣，但他們不是軟體工程師，或者很久以前寫過**但忘得差不多了。在這種情況下，我自己進行練習，確保他們能夠逐步理解我正在做的事情。到最後，有些人可以開始參與練習，也有些人沒有參與進來，但是所有人都對教學內容有了更深入的理解。
\\\\
這種技術有奇蹟般的效果。我要求結對人員在沒有我的幫助的情況下自己做練習，我只負責澄清要求，並且告訴他們我不會檢視結果。
\\\\
作為一名教練，我努力實現退出策略，讓我指導的人不再需要我。
\\ 隨著課程的進展，我提供的幫助越來越少，但我總是在場，以避免錯誤變成壞習慣。我讓人們犯錯，然後提出建議。
\\ 在剛開始的課程中，我充當反饋迴圈。在以後的課程中，人們應該自己形成內部的反饋迴圈。
\\ 在最後，我通常讓他們自己來，在練習時不提供任何幫助。我只在練習完成後提供反饋，通常是向他們問題。
\\\\
我曾經用過幾種形式：
\\ \\t
如果我能克服這些障礙，這可能是最有效的行式。\\t
在小組中進行結對，每對一周進行兩次90分鐘的練習。\\t
將小組分成兩對，每週練習120分鐘。\
\\ 在本節中，我將為軟體教練提供一些一般性的建議：
\\ \\t
理想情況下，使用結對。\\t
\\t變通。如果使用小組的形式，則可以稍微變通下規則。\\t
不斷努力創造乙個非常安全的學習環境。\\t
考慮使用拉模型而不是推模型。\\t
向人們解釋學的目標是什麼，並讓他們專注於這些目標。\\t
確保不要讓人依賴你。隨著課程的進展，給予他們越來越多的空間。\\t
作為教練，你需要承擔三種角色。通常按以下順序進行：\\t
老師。在剛開始時，你大部分時間都在教學，填補知識方面的空白。\\t\t
導師。隨著課程的進行，你將擔任導師的角色，僅在需要時提供建議。\\t\t
教練。放手讓人們自己去練習，嘗試在適當的時候提問，但不提供解決方案。\\t
\\t多年來，我發現缺乏最多的是軟體設計技能。\\t
沒有良好的設計技能，所有的實踐和準則都沒有意義。\\t
\\t\\t人們應該在其敏捷開發/文化中包含所有其他xp實踐。\\t
團隊不應該停止xp實踐。\\t
他們是怎樣找出要構建的內容的（需求）？\\t
他們在巨集觀設計（架構）中使用了哪些實踐？\\t
他們是怎樣進行團隊活動的（scrum/看板）？\\t
他們是怎樣發布軟體的（devops文化）？\\t
放輕鬆，有耐心。\\t
祝好運。\
我正在寫一本更深入的關於敏捷技術實踐的書。可以在twitter上關注我，以便了解該書的進展情況（@pedromsantos）。
在軟體開發方面擁有超過25年的經驗。近年來，他一直專注於教育和激勵其他開發人員。他花了數百個小時做結對練習、指導開發人員。他曾與開發人員合作過程式設計基礎知識、物件導向設計、重構遺留**、測試實踐、架構決策和職業發展選擇。
\\檢視英文原文：coaching technical practices
技術指導實踐指南
在過去的4到5年中，我一直擔任軟體開發教練，幫助組織改進他們的技術實踐。我也是偶然中發現自己正在承擔教練的角色。一開始，我有點驚慌失措，因為之前從未做過這樣的事情。我曾經組織過tdd和軟體設計方面的活動會議，但從未按照某種邏輯順序來組織它們。我的第乙個挑戰是選擇活動主題。經過幾次迭代，我開始專注於x...
技術指導實踐指南
在過去的4到5年中，我一直擔任軟體開發教練，幫助組織改進他們的技術實踐。我也是偶然中發現自己正在承擔教練的角色。一開始，我有點驚慌失措，因為之前從未做過這樣的事情。我曾經組織過tdd和軟體設計方面的活動會議，但從未按照某種邏輯順序來組織它們。我的第乙個挑戰是選擇活動主題。經過幾次迭代，我開始專注於x...
技術指導實踐指南
在過去的4到5年中，我一直擔任軟體開發教練，幫助組織改進他們的技術實踐。我也是偶然中發現自己正在承擔教練的角色。一開始，我有點驚慌失措，因為之前從未做過這樣的事情。我曾經組織過tdd和軟體設計方面的活動會議，但從未按照某種邏輯順序來組織它們。我的第乙個挑戰是選擇活動主題。經過幾次迭代，我開始專注於x...