ruddyllee

Trail and error程式開發法

2022 年 08 月 05 日2022 年 08 月 05 日 ruddyllee發表留言

身為程式設計師；請問你是怎麼撰寫程式的?

大部分人在開始時；都是採用 Trail and error 的方式來寫程式，一種既簡單又有效率的程式開發法，既好用又比較快這是毫無疑問的，但是你想知道如何進階嗎? 難道你要寫數十年的程式都還只用這一招嗎?

嘗試錯誤Trial and error是解決問題的一種形式。發明人是美國心理學家桑代克先生(Edward Lee Thorndik)在1898年通過大量的動物實驗認為，動物都是經過嘗試錯誤來解決問題的(註1.)。

嘗試錯誤法的問題

首先；嘗試錯誤法是非常單調且乏味的，如果過程中你不進行反思(問自己為什麼這麼做?還有其他作法嗎?)的話，你就可能在寫完了一個功能之後卻沒有學到任何東西。再者；這種方法需要耗費大量的時間(相對於做假設法)，就像化學工程師要找到合用的化學成份一般，往往必須從上萬種有潛在可能性的化學成份中來篩選。很幸運的是寫程式時有大量好用的開發工具可以協助我們，編輯程式時我們可以透過各式各樣的顏色安排，為無趣工作增添一點視覺化的成就感，更棒的是拿一整塊網路上(或自己的庫存)找來的程式碼Copy & Paste上，跑一下就能迅速的知道能用與否了，因此嘗試錯誤法很適合拿來寫程式時使用。但這樣的程式寫法，你有真的學到東西嗎? 工程師珍貴的時間如果就只是拿來交差了事而沒有學到東西(收穫)，不是很可惜嗎?

程式開發其實是一種學習的過程，你不只是在做CPU指令碼的邏輯組合，你是在運用腦力思考如何解題? 大體上來說；要完成任務；首先你得先學會商業行為的Know how，才可能用程式邏輯來解題，解題的過程不論做對與錯你都學到一些東西並朝向完成任務更邁進一步，而經過這些你的專業技能與知識也會變得更成熟了，這才是程式員致力於coding的目的。也就是用持續學習與解題(Build)的方式來讓自己獲得知識與技能上的成長。並將它們轉化成為自己的經驗，用時間跟專案換來擁有更強的開發能力。

純粹的嘗試錯誤法是不會想(試)著去探討為什麼某種解法會成功而這樣作卻不行，目這種方法的目標是只要能成功解決問題就好。也就是程式只要是Work就好的觀念，並不會試著去找出可以被更廣泛應用、拿來解決其他問題的解法 (這個觀念與 Robert C. Martin 在《Clean Architecture》裏頭所說的；好的架構勝過能work卻不容易修改的程式的觀念相同) 。我們通常不會去嘗試找出所有的解法，當然也就不會找出問題的最佳解法(最多只是作作重構，讓程式的長相變好一些)。嘗試錯誤法；是求快速解題的方法，是對問題的相關領域不去作探討，強調好處是只需要擁有少量的知識就能做到解題的工作，後遺症則是相對的收穫也就變少了。

請勇於嘗試進階的作法

想更上層樓，不用擔心；這條coding之路你並不孤獨，有一堆前輩、厲害的人物早就為我們開拓了前進之路，就看我們自己有沒有升級的動力。話說，當你已經有了幾年的coding經驗之後，接下來呢? 你應該試著多運用模式pattern的方式來寫程式了(註 2. 1990 紅極一時的進階coding 方法)。隨著coding經驗的增加，不管你有沒有參考設計模式的正確做法，無形中在你腦子裡就已經累積了不少的 coding pattern形式，有時它會出現在你寫程式時的起手式裡，有時會用在解特定的問題上，你可能不經意也沒有去探討這麼做法是對是錯、有沒又效率，但這就是你所養成的習慣。所以這是一種必然的進階，走向「Pattern 模式」。與其如此；不如刻意去學習設計模式這種優秀的coding 方式。起步是；先去探討自己習慣的coding 方式對了嗎，然後把它變成一種模式，一種適用性較廣而又有著某種特色的模式，接著找個機會介紹給別人使用，報酬是取得回饋來做改善。這樣累積下來的模式’s正是你的程式資產，Coding 越久越多你就越富有了。

假設思維的程式撰寫法

在開始coding之前，你可能已經想很久了、也蒐集了很多的相關資料，先作假設然後在動手的方式，可以幫你過濾掉那些暫時還用不到的訊息，它們對目前的思考解題而言是雜訊，雜訊太多對你現階段的思考解題反而是一種阻礙 (註4.思考的工具箱by愛德華·德·波諾Edward de Bono)。業界流行的測試開發法或是領域驅動開發法，都屬於這種先做假設然後接著用程式來驗證的科學解題法。如果你還沒試過；一定要試試，它不見得適合應用在你的開發環境裡，但它確實可以讓你在coding的過程裡收獲得更多。

小結

用嘗試錯誤法(Trail and error)撰寫程式是很自然的撰寫程式的方式，因為它需要知道的相關知識最少、寫起來最省力。它讓起步變得容易許多，只要一路試下去等錯誤都被解完了就搞定了。但這是一種追求程式只要WORK就好的想法，如果讓你選擇，一個是WORK但未來可能很難修改或是幾乎沒有延伸能力的程式功能，還是寫一個具有架構思維、容易修改維護，但目前功能不足的程式碼。你會挑哪一個呢? Robert C. Martin 在《Clean Architecture》第二章裡頭探討了這個議題，如果你還沒看過，一定要看一下並拿這個議題跟團隊一起探討一下，然後傳給你的主管作參考，這裡我們不做贅述。

我想換個角度來探討工程師怎麼作可以學到最多? 二個角度來看這個問題；一個是甚麼是真正的學習? 另一個是最有效的學習方式是甚麼?先來談甚麼是真正的學習。

真正的學習；我們在體驗之後；一定要透過反思；然後再透過抽象化的過程作整理，最後才是形成新的想法(上圖左側經驗學習環上的四個重點)。嘗試錯誤後如果不做思考只是用試錯的方式求解，動作雖快，但是很難真正的學到東西，除了開發時一些痛苦回憶之外，一下子你就忘光了(我們在專案做完後，很快就不記得是怎麼做的了，就是這麼回事)。敏捷開發能幫忙學習，再 Review meeting 時你就有機會取得回饋、經過反思(present自己負責的功能)作出簡報(進行抽象化思維)，然後接著在回顧會議後透過團隊回顧來產生新構想、新創意。這是敏捷開發在學習上的助益。

有效的學習；先要能夠離開舒適區，讓感覺落入學習區作辛苦的思考解題之後跨越所謂的最接近發展區(ZPD，Zone of Proximal Development)，學習到原本你所不會的知識或技能，然後得到回饋，讓自己知道哪裡做錯了、哪裡做對了，透過有效的學習，能力增強後自然舒適區擴大了再繼續開發作業。透過這種有效的學習讓自己的能力變強，讓工作變得更有意義(這才是R&D面對工作應有的態度)。

開發模式(design pattern)與假設思維法(Hypothesis Thinking)都是一種刻意學習的方式，是敏捷開發隱藏並未彰顯出來的功能之一。如果我們試著讓學習變得可視化，例如在開發流程中，我們刻意的加入學習的工作單，讓學習的過程能夠呈現出來(在看板上流動)，學習自然而然的被刻意的落實了，這將是工程師在開發過程中最大的收穫。這一點；在緊迫的開發作業下並不容易做到，但退後一步想；工程師讓自己的程式撰寫模式進階為假設思維法的方式，需要的是自己願意透過好奇心來驅動自己一種進階，嘗試看看就能做到的開發技能提升方式。

【 刻意學習】

有明確目標的學習。
對學習(工作)成果有發表的機會。
尋找、觸發積極學習的動機，以追求成就。
給予成長型的回饋和表揚。
Mentor制教學相長。

註1. 美國心理學家(Edward Lee Thorndik)桑代克發明嘗試錯誤法trial and error

他設計了一種問題箱實驗，將一隻貓關在其中。它若用爪去撓門閂而使門打開，得以逃出，便能得到食物，今後被關時便會用爪去撥動門閂；若繞別處，門打不開，便得到不愉快的經驗，今後抓繞其他地方的行為就會減少。於是，其行為與後果之間形成了一種聯繫，為學習提供了強化。

註 2. 設計模式 Design Pattern

由瑞士人Eric Gamma 埃里希·伽瑪為首著作了《設計模式：可復用物件導向軟體的基礎》的四個共同作者之一，此書對於軟體工程領域有重大影響力。

註 3. 測試驅動開發TDD Test-Driven Development

是一種軟體開發過程中的應用方法，極限編程XP 中所倡導，也就是「先寫測試程式，然後編碼實現其功能」因此得名。測試驅動開發始於20世紀90年代。測試驅動開發的目的是取得快速回饋並使用「illustrate the main line」方法來構建程序。

註4. 思考的工具箱 by愛德華·德·波諾Edward de Bono

他在1960年代末期提出「水平思考」方式，是一種創意思考，對我的思考幫助很大。在1980年代中期提出的「6 Thinking Hats」（六頂思考帽子）思考法至今仍被廣泛採用。六頂思考帽子對團隊一起進行腦力思考時非常的有用。他強調複雜是思考的最大敵人，所以我們進行思考時一次戴一頂帽子，朝一個方向去思考，效能會更好尤其適用在團隊一起做頭腦風暴時採用。

註5. 最接近發展區的理論，就是鷹架理論；近代大量被健身教練所採用。你可以在教練的指導下一直向上提升你的體能，這是因為他們每次都要求你做到超過比現下自己能力多一點點的付出，也就是跨過最接近發展區(ZPD)，它很有效，是一種最有效率的學習方法之一。

工程師的邏輯思維

2022 年 07 月 22 日2022 年 08 月 03 日 ruddyllee發表留言

偵錯和做簡報是工程師最討厭的二件事。偵錯Bug總是來得莫名其妙，誰會料到在這個時間點會出這種問題呢? 而作簡報又不是寫程式，為什麼大家都把規格訂得那麼高，非得花那麼多時間改來改去? 話說回來；偵錯的時候你需要弄清楚系統的因果關係，才看得出來哪裡出錯了。而作簡報則是要讓聽的人士弄清楚系統的因果關係。一則是對內一則是對外；想要作好這二件事；你最需要的就是好的邏輯思維。我們今天就來談談這二件事背後的結構化解題方法。

當系統表現出來的績效突然有了偏離，原本應該表現在應當的地方，但實際上卻有了偏差。一定是有某種變化的發生了造成系統的改變。在我們開始解題時，其實我們不知道這一變化包括了甚麼? 或是甚麼時候會發生? 我們處於所謂的無知狀態(也就是不知道我們不知道些甚麼的情境)，需要從後續取得的訊息中逐步的形成對問題的概念，然後藉由概念去構想可能產生變化的原由，作出種種有可能的假設，然後再去驗證它(分析來的假設)並找到解答。

對系統偵錯解題的方法

偵錯就是問題分析與決策，你需要盡快地解決眼前的問題，該怎麼作呢? 這裡有五個步驟的解題法；由問題的定義做起，乍看起來很費時，其實練熟了以後你的邏輯思維自然會快捷起來。首先是:

第一步；正確的描述你所面臨的問題。

第二步；問題的情境確認、發生地點、時間及影響範圍確定。

第三步；從第二步蒐集到的關鍵資料，綜合出可能的原因。

第四步；列出可能原因，由上而下進行檢驗，找出最可能的原因。

第五步；証明真正的原因。

正確的描述你所面臨的問題

發現系統有異常的人士，針對自己所看見的現象作出了陳述，這是問題的第一件外衣，它是依據現場狀態所做出來的描述。作為解題的人我們需要透過問題所表現出來的種種現象，層層的剝去那些外在的表癥，逐步的確認問題的正確描述才不會因為沒看到問題的核心原因而弄錯了方向。在還沒確認正確的問題陳述時就斷然作成的處置，有可能誤打誤撞的讓問題的現象消失了，但事實上，我們也可能將真正的問題隱藏到更深的地方去了，就等待下一次的再爆發。這一點；就是我們常常聽到的:『我也不知道為什麼? 它就是不在出現了，系統變好了。』倉促而盲目的解題；是也。此時也只能做好紀錄，留待後人參考囉!

對於寫程式時的偵錯而言；這一步就要明確多了，我們可以透過能否重複製造相同的錯誤來作確認問題是不是我們所描述的樣子，然後用試錯法來解題。

由四方面描述問題: 問題確認、發生地點、時間以及問題的範圍和嚴重性

運用科學辦案的基本步驟，有了正確的問題陳述之後，我們就可以開始蒐集相關的資料，雖然四個方面的資料蒐集，不見得都有用，但為了避免遺漏或更有把握的判斷可能的原因，還是應該把現象的人事地物描述清楚為要。

問題確認；指的是我們所試圖要解釋的是什麼?
地點: 在何處觀察到的。
時間: 甚麼時候發生的。
問題的廣度: 有多嚴重?範圍有多廣。

找出正確的資料可以讓問題更加具體化，可以協助我們作正確的判斷分析。

從問題四方面抽取關鍵資料，以便綜合出可能的原因

「有何不同?」由尋找差異在哪裡，開始搜尋與正常現象不一樣的地方，也就是重要的線索。然後我們才能依據這項重要的線索追下去。讓線索跟變化連成一線，也就是線索能夠呈現造成變化的關聯性。這裡很有柯南的味道!

如果所有與問題有關的資料，都已經包括在內的話，運用線索來解釋問題發生的原因，就能夠形成對真正原因的假想了，也就是發現可能產生變化的假設，通常會同時擁有幾種可能的假設出現，而我們需要的是一個最能令人滿意的假設。

找出最可能的原因

運用驗證假設的技巧，透過試驗、觀察來驗證假設是否正確，找到最為可能的原因。然後反問自己:『如果這是真正的原因，如何用它來回答問題的每一個陳述呢?』因為真正的原因有一個必要條件，就是能夠針對每個質疑並給出一個適當的解答。

証明真正的原因

讓系統恢復正常運作是我們進行這一連串邏輯思維的最終目的，但有時候系統恢復正常運作了，而我們卻無法證明它就是真正的原因，那要怎麼結案呢? 再進行檢驗；這便是嚴謹的邏輯所能帶來的好處。

再來談談做簡報

作簡報

作簡報；定義是指就一個主題向聽眾陳述內容、傳達訊息或觀點的說明過程。這一過程中所展示的圖片、文字說明就稱為簡報。簡報是用來溝通的一種方式。因此首先要弄清楚為何而做、聽眾是誰、他們來聽簡報的目的是什麼?為什麼要聽我的簡報而不是其他成員的說明? 弄清楚了再開始準備就不會弄錯方向了。

簡報要精簡

既然是溝通，就應該是一種精簡而漸進的過程，如果是做工作說明，精簡；應該就沒問題。但如果是做新專案的審核報告；團隊已經作了好幾周了，是時候必需要做提案報告供主管們做取捨時，內容多了時間就會自然變長些，想要簡短扼要就會變得很難取捨了。做為負責報告的人士，我們往往會想把這幾周來自己所經歷或發掘的一切，都鉅細靡遺的報告出來，讓主管能夠感受到這一切是怎麼回事。但回過頭來看簡報一定要精簡的忠告，想要刪減簡報的頁次時再很難取捨。主講者常常會落入「如果他們不知道這個原因，又怎麼會曉得結果是這樣形成」的疑惑中而不知道如何取捨那些資料應該展示。

提案失敗的原因，往往不在於分析問題的能力，而在於解決問題的能力。

下面這些步驟對你來說一定很眼熟，是的這就是結構化思維。整個過程正是科學研究方法的簡化版本：過程是；

「你首先從一系列調查入手，假設實驗中可能發生的情況，然後進行實驗及收集數據，確定你的假設是被證明還是被推翻，最後寫出結果並分享你的實驗報告。」

作簡報時要從答案開始(以終為始)講起，隨後用所收集到的數據來證明或推翻它。中間用故事把他們穿接起來，目的是成功的形成聽眾的概念，講故事是引導他們認同的路徑，而數據則是證明。

這與許多機構所奉行(習慣)的作法恰好相反，他們先忙著蒐集及處理大量數據，然後才再在分析中尋找答案。也就是做探索式的分析，但是結構化思維有許多探索式分析所不能替代的優勢，尤其是當你在尋找有效的解題時，務必先有假設再去進行數據蒐集，也就是有目的的進行數據收集，而不是被用來驗證假設的其他數據，自然就可以過濾掉而不用收集了，這個做法可以大量的減少需要收集的數據。

形成概念是工程師面臨問題時最重要的一環

在概念形成中，人們以感覺、知覺和表象為基礎(就是綜合自己所取得的各種訊息)，通過分析整合、抽象概括等思維活動，從個別到整體，從具體到抽象，逐步把握這一類事物的本質。也就是在腦子裡；先讓認知抽象化，然後進行分類，最終達成客觀的辨識而形成概念。

這個過程實質上就是一個學習過程，也是一種思維活動。

概念是解題的關鍵要素。

小結

工程師一旦對問題產生概念後，或可以說成是對這件事情有了概念以後；有關這個問題的一切信息，就都變得不哪麼陌生了，因此簡報能在第一時間讓聽眾形成正向的概念，將是成功的關鍵。怎麼做到呢，這就要事前先與主管或是關鍵人士進行面談，交換彼此對專案的概念才是王道。

圖中，節錄了結構化思維進行簡報時的九個步驟(註2.)，旨在幫助工程師作好簡報工作。我個人屬於專業的講師，簡報則是我用來學習與進行溝通的工具。這九個步驟；讓人覺得好多步驟喔! 我實際實踐的時候，是挑選最不容易做到的部分，也就是讓聽者產生印象形成正向概念的部分，正是「創建故事」的步驟，這一段也是講者們最重視的一段。

但在公司內做簡報就不容易這麼做了，因為要聽你做簡報的主管們；大概都對這個主題早已有了自己的概念，因此想要臨場改變別人的概念很難，但有解法；就是事前先去溝通過。這是隱藏在你運用結構化思維解題背後的成功祕訣，在事前先形成共識擁有相似的概念，簡報自然容易被接受。

我們總以為自己從頭到尾都那麼用功在工作，作簡報時只要據實說明就夠了，這是工程師思維而不是成功作好簡報者應該有的思維。講故事是最佳的溝通技巧，也是達成簡報任務的最佳工具。而作簡報或是進行演講故事往往是最容易撼動人心的，在會議上要取得對任務作法一致的認同，重點在概念，概念一致了做法自然就不會太離譜了。

註 1. 參考《問題分析與決策》，作者: Charles H. Kepner & Benjamin B. Tregoe

第二章、問題分析 ，五步解題法

註 2. 參考《極簡思考》，作者: Mike Figliuolo

結構化解題的九個步驟

如何將開發者體驗運用在實際的開發作業上

2022 年 06 月 22 日2022 年 06 月 24 日 ruddyllee發表留言

投入研究開發者體驗(DX)的初衷是為了減少工程師在開發程式時所遭遇到的痛苦(註1.)。這種痛是沒寫過程式的人很難體驗的。但與其說是痛；實際上更像是一種焦慮的感覺，一種無法順利解題而心生疑惑轉而形成的極大焦慮感。想要徹底地克服它的這種想法好像很不實際，想想在創作的過程中怎能少了這一味呢，因此便改為思考如何透過設計(刻意學習)來協助開發人員減少開發作業中的種種障礙的方式，讓他們能夠順暢而高品質的完成任務。以下是針對敏捷開發所加入的DX設計，運用的是可視化學習的理念，請參考。

軟體開發是一種學習的過程，而 DX(Developer eXperience開發者體驗)正是一種體驗式學習。在上圖中；我們試圖將學習的行為變得可視化，運用在 Scrum 的開發流程中插入了學習的行為，它們可能是一場演講教學，也可能是個人的學習工單。理由是有關「學習」這一點是我們長期以來；在開發過程中認為理所當然而經常會忽略的部分(隱藏的工時)，好像工程師就是要無所不能，只要需求提出來的程式員就得做得到，但實質上我們都知道，沒有經過學習的過程，我們怎麼會知道相關領域的專業知識呢? 而有時候；面對嶄新的需求時，我們更可能處於完全無知的境界(無知；指的是我們不知道自己需要知道些甚麼)。因此前期的學習幾乎是不可忽略的，當然每個人需要學習的東西不見得一樣，而學習的起始點也不竟相同。

估算是對未來的一種猜測，如果你對問題完全沒有感覺，就應該多花一些時間做研究、分析，先做好學習後再做估算。可以避免過大的誤差值。

① 讓產品負責人與團隊對問題擁有一致的認知

產品負責人PO是負責將需求寫成文件，然後對著團隊進行說明講解的人，也是工程師對於需求的開發完成與否的驗收人，是面對問題思考如何解題的第一人，他(她)是開啟專案學習、思考的第一人。早在團隊開工前，PO早已經走在這一條路上了，所以如何讓PO的Know how 轉移到工程師身上，讓團隊變成與PO一樣對問題有一致的認知就變成了一個開發過程中的重要門檻了，如下圖的DOR(Definition of Ready)點。

② 針對需求評估「認知差距」

首先要識別由初學者到足以完成任務的專家之間的「差距」，並思考如何跨越此差距。

我們將差距分類為: 知識、技能、動機與態度、習慣、環境、溝通等項目，如上圖所示，運用雷達圖來抽象的識別差距。目的是讓團隊成員能夠交互學習(註 3. 介於專家與初學者的六種差異學習因素 )。

③ 在梳理會議時；團隊有機會估算個人的「認知差距」

識別是否需要大量學習抑或是可以快速補上不足知識/技能的方法。是團隊思考識別是否採用Mentor指導方式；運用鷹架理論(註4.)來克服個人學習上的不足。

④ 運用每日站立會議，團隊有機會分享/回饋擴大學習知識圈

可視化團隊學習成果，也是交互分享學(彼此回饋)分享學習成果的機會。

運行Mentor 制: 它的精神是認為每個人都負有將自己所開發的功能教導他人使用的責任。

⑤ 在回顧會議時，可以適時刻意的調整學習難易度的設計

視學習者的回饋(能力)適度的調整學習門檻，以獲得更好的學習效果。

⑥ 整合發布

持續整合與發佈至雲端或其他環境

小結

開發者體驗即學習；我們可以將DX設計視為製作學習教材(API；註2.)以幫助開發者進行學習的方式，來協助開發者能夠順暢的學得開發作業上所必需的知識及技能。當然我們可以運用架構設計的方式來加以區隔，讓開發者始終在自己熟悉的領域裡進行開發工作，但我們不應該設限團隊的學習區間，讓他們平白喪失了在工作上學習成長的機會。

在開發流程上刻意地讓學習的行為可視化出來，不再將學習視為工程師理所當然應該會的東西(傳統上，工程師如果不會就應該用自己時間去自學吧的錯誤觀念)。所以在專案開始之初，我們可以辦一場與開發內容相關聯的講座，讓團隊成員對目標有著比較一致的認知(進行團隊學習)。然後也可以藉此判斷自己需要多少學習才能成為專家的差距。這個差距指的是開發作業上所需要的知識、技能、動機與態度、習慣、環境、溝通等項目。這是一種認知的設計，當然學習得越好開發德自然也就越好。

在開始進行開發學習之初，先知道自己與專家之間的距離(也就是知道自己在哪裡)，這是一種做系統思維的起手勢。讓團隊先知道自己所面臨的挑戰，並擬定學習的計畫設定學習目標，然後再充實的進行開發作業而非盲目的進行各自學習(參考開發者體驗及學習)。並藉由Scrum的團隊會議做到即時的回饋與檢討調適。

目標只有一個，就是讓團隊隨著開發作業而學習成長。讓專案開發造就一個團隊的學習成長，讓我們的開發團隊成為一個更強大的團隊。

開發者體驗的目的是順暢而高品質的產出有價值的服務或產品。

註 1. 程式開發的旅程 by Erik Trautman

註 2. API 在這裡將參考DX的狹義定義，也就是泛指開發作業上可能運用到的應用程式庫、服務和組件及如何通信的契約。

註 3. 《怎樣有效學習：創造一流學習體驗》作者：朱莉·德克森 Julie Dirksen. 介於專家與初學者的六種差異學習因素。

註4. 鷹架理論 Scaffolding 為蘇聯心理學家維高斯基(Lev S. Vygotsky, 1896～1934)對認知發展所提出的一種理論。他倡議的近側發展區(Zone of Proximal Development, ZPD)。所謂「近側發展區」指介於學習者自己獨自表現所能達到的能力水準，與經由別人(Mentor)給予協助後可能達到的能力水準，此二種水準之間的一段差距。

強調在開發過程中 Mentor與團隊成員的互動歷程中，Mentor扮演著社會支持者的角色，猶如蓋房子時鷹架的作用一樣。換言之，Mentor把開發學習所得的經驗抽象的陳述給團隊成員知道，進行問答。但是，當大家漸漸了解之後，社會支持就逐漸減少，而將學習的責任漸漸轉移到團隊成員自己身上，如同房子蓋好後，要把鷹架逐漸移開。因此，維高斯基的社會建構論的主張有時可稱為鷹架理論。

開發者體驗即學習與解題 -學習篇

2022 年 05 月 16 日2022 年 07 月 01 日 ruddyllee發表留言

我花了三年的時間，繞了好大一圈才意識到開發者體驗DX實際上就是一種學習體驗與問題解決的過程(工程師的工作就是先學會相關領域的知識，然後用程式去實踐它)，而且與所學習的內容沒什麼關係，反而與學習的方式有關(這裡只討論學習的部分)。事實上同一專案運用不同的方式進行開發，也會有截然不同的體驗。

學習與解決問題都是一種嘗試錯誤的過程，與神祕的思維和推理無關。

– 美國心理家 桑代克(E.L. Thorndike)

其實解題的策略很多，但工程師卻把大部分的時間花在試誤法上，直到他成為越成熟的工程師後，便會逐漸的運用到其他方法，例如: 提問法(posing question)、情境分析法(analyzing situations)、結果轉述法(translating results)、繪製圖表法(drawing diagrams)、最後才是試誤法(using trial-and-error)。

那麼，體驗為什麼會如此不同呢? 因為；有效的學習體驗讓你從實務中獲得嶄新的能力或提高了原有的能力。所以開發者體驗設計就是要設法來達成這個目標。而不是只是讓工程師能順利的把專案作完或過的很爽罷了，更重要的是讓開發者能夠透過專案的歷程學習到更多經驗，並能夠將它轉化為未來開發工作上的技能。

「學習風格」是個體致力於學習任務時，經由其行為和人格之交互作用而表現出來之穩定特徵。就是個人所喜愛的學習方式，其影響個體如何接受刺激、記憶、思考和解決問題。

工程師個人的學習風格成就了他的開發者體驗。

我發現；大部分的工程師是靠自我學習的方式來解決問題的，這會限制學習成果的擴展性(註1. 請參考鷹架理論的ZPD區間)，本文中所謂的「刻意學習」正是想透過DX的設計由外在的力量來協助開發者的學習歷程，讓開發者不是爽爽地度過開發週期的體驗，而是透過刻意的學習吸收成長，成為更優秀的工程師，透過團隊協作共同學習而成為更強大的團隊。這才是開發者體驗設計的真正目的。

軟體開發就是一種學習的過程

開發人員首先要學會欲開發領域的專業知識，然後將它們轉變為程式邏輯，過程中我們不斷地運用嘗試錯誤的開發方式來撰寫程式，直到程式可以正確無誤的執行起來，然後通過測試的考驗後交付到客戶手上，然後正確的運行著。

開發者自我評測，是給予 DX設計是否有效的回饋行為。

有經驗的程式設計師和初學者有甚麼差別?

高手比初學者，有著更成熟的心智特徵(也就是心智所能處理訊息的內在描述)，

心智特徵mental representation是一種假設的內部認知符號，它代表外部現實，或者是利用這種符號的心理過程：“用於明確某些實體或信息類型的正式系統，以及系統如何執行此操作的規範”。(註2. 參考《刻意學習》by Anders Ericsson)，高手對那些符號的意義詮釋讓他能夠記憶得更多更好，說穿了；其實就是一種心智結構，運用模式的記憶對照串聯起一系列的具體地或抽象事物。高手比初學者，有著更佳的心智表徵；表現出記憶了更佳的質與量的差異。而高手跟初學者之間的差距，正是DX設計者所想要透過設計來協助開發者克服的差距(gap)。

我們想要的正是發展出這種提升效率的心智特徵，讓你可以運用在開發作業的技能上表現得更有效率。例如: 高手與初學者看同一份程式列表例如在進行code review時，初學者看到的是一行行的指令，而高手看的則是相對應的模式(pattern)所表現的意義。還有；高手記憶了較多的設計模式(design pattern)，而這些模式的觀念可以幫助他在閱讀程式時有著更好的理解。

認知心理學(cognitive psychology)中一個基本假設是：我們應當把人類心智Mind當作是一個處理信息information processing的機器來研究。

刻意學習

所謂的「刻意學習」指的是；學習要在有目的、有人指導之下進行，才會事半功倍。因為軟體開發實際上包含了大量的學習過程，但在開發流程上我們卻看不見它的蹤影，很少看到開發流程中有刻意標出進行學習階段或計畫，在流程看板上更是不會有具體顯示出它所存在的位置。開發團隊經常是選擇自動忽略(因為學習本來就是工程師個人的事)，心裡想的總是它會自動完成。

但其實工程師要能寫出正確的程式；如果沒有對專業領域的知識學習到一定的程度，撰寫出來的程式是不可能執行正確的(幫客戶解決真正的問題的)。因此我們需要的是刻意的去學習。換句話說；是針對該領域的技能刻意的去學習模仿 (心智特徵的特性是針對特殊領域的技能所發展出來的) 。我們不能完全放任工程師自己一個人去進行摸索式的自我學習方式，反之；應該借重有經驗的開發者(開發者體驗設計師)的投入，針對整個專案開發週期去刻意的設計開發歷程中的學習路徑，讓開發者可以更快更有效的進行學習的工作，減少無謂的浪費活動。

基本上；就是要針對開發者的心思結構；以我們對它的看法，以及希望其他人如何看待它，構思出一個新的、更完善的心智特徵(參考註1.刻意學習)。以利個人或是團隊進行開發時的學習工作。

我個人最喜歡也常用的提問的方式，有時是對著個人、有時是對著團隊甚至有時是在演講的時候對著聽眾提問，因為提問也是一種刻意學習。「人是一種會因爲別人的發問而改變自己的想法和行動的生物」(參考自《優秀的人都是提問高手》,作者: 櫻井弘)

刻意學習的目的是在針對學習者，快速地發展出有效的心智特徵。

為什麼採用刻意學習這個字眼呢? 因為我們習慣的學習方式會左右我們去挑選甚麼該學、放棄甚麼不去學習，因此若不去改變自己學習的習慣，工程師會總是依據自己的習慣(偏好)而損失掉去學習到許多更便利、更好用的工具或平台。

刻意學習另一項想克服的是鷹架理論中所謂的 ZPD 區間(註2. 主管不能不懂的 – 鷹架理論)，就是工程師自行學習著克服問題所不容易跨越的區間，而藉由透過專家(DX 設計師)的刻意指導來跨越學習差異的區間(ZPD；Zone of Proximal Development最接近發展空間)。

了解工程師的學習風格

瞭解開發者是甚麼樣的「學習者」是設計優良開發者體驗的一部分。首先是掌握一些基本訊息，這是不能或缺的(年齡、性別、負責工作或角色)部分。如果你不能充分瞭解開發者是甚麼類型的學習者，又如何能夠在他的開發歷程中給予適當的協助呢?!

除此之外；我們需要評估開發者達到完成任務的階段，他所需要擁有的知識及技能之間的差距，然後設法予以協助來克服這個差距，團隊協作也能夠產生相當的互補效應，有時甚至是改變開發者學習風格的最佳方式(sprint中的回顧會議就是其一)。

我們需要調整自己的學習風格來適應多變的時代，做到有效真正的學習。

如何運用認知學習進行DX設計

學習體驗就像是經歷一段旅程。這段旅程的起點是學習者現階段的位置，終點則是他們在學習上的成功。這個講法與UX設計使用者旅程有些相似。下圖是開發者由新手(對開發領域專業知識的不足)一直到成為這門領域專家的學習旅程。為了提供良好的刻意學習；必須在開始時觸發開發者產生相當的興趣，產生這種內在的渴望可以避免遭受學習初期因為不熟悉所遭遇的挫折打擊。

一種適用於學生學習新事物的方法，它不僅僅適用於家庭也適用在這裡，它是一種學習四步曲: 產生興趣、變得認真、全力投入與開拓創新。

首先要激發他對問題的興趣，當他開始對相關领域產生興趣時，下一步便是讓開發者能夠專注的去學習，在它達到全力投入之間，能夠找到好的學習管道或是指導導師，都是克服學習旅程中各種坑坑洞洞的重要資源，可以減少行走大量的冤旺路。最後才是期待開發者達到熟能生巧的境界，所謂的開拓創新，一種青出於藍的想法總是不能避免的期許。有時候它會行程一種壓力，我們應該適當評估這種壓力是否能勾成為助力，還是一種外在的認知負荷(請參考了解工程師的負荷)。

開發者體驗即學習；

它絕非在開發時的看板上加入幾張學習的工單就可以搞定的。我們需要在開發流程上可視化學習並讓團隊成員能夠在對解題方案的認知上取得一致的見解。所謂的"一致性“；指的是避免在開發設計時誤植了過度複雜的情境，例如: UX近乎理想的設計，可能造成程式設計人員需要花上大量又複雜的程式開發才可能達成的現象。

透過在開發流程上運行學習的可視化；讓刻意學習來提升程式員的學習效果。並用團隊學習的方式來約束並形成良好的學習者風格。

小結

開發者體驗設計的目的是想要協助工程師透過刻意學習的方式去順利及高品質的交付專案所賦予的任務之餘，還能夠將開發過程的體驗轉換成未來進行開發時有用的知識與技能。因此；我們想以刻意學習的方式協助工程師跨越在進行自我學習時所不易克服的區間(ZPD 區間)，具體作法是去分析開發作業所需要的知識與技能，評估如何克服之間的差距，並給予知識、技能上的協助，甚至在開發者的動機、工作環境以及必須改變的習慣予以設計與協助。運用DX設計的方式針對刻意設計的教學與教材來提升學習的效果。

這裡我們只討論到學習的部分，至於解題的部分則留待下回再說 …

DX 設計的目標不只是完成任務，更重要的是增加開發者、開發團隊的能力。

註.「認知」；是指透過思想、經驗和感官獲得知識和理解的心理行為或過程。

註 1. 鷹架理論中所謂的 ZPD(Zone of Proximal Development) 區間

情境理論 Situational theory : 該理論認為，領導是一個動態的過程，領導者、被領導者、群體狀況、組織結構等因素都會影響領導的有效性，因而不存在一種固定不變的最佳領導模式，就是因人適任。
鷹架理論 Scaffolding theory: 是指學生在學習一項新的概念或技能時，透過提供足夠的支援，讓學生從已知事物類比新知識，來提升學生學習能力的教學準備，即因材施教。

在敏捷學習中，參與者可能會獲得新的能力，與傳統的正規教育不同，這些能力與他們的工作環境直接相關。在追求個人解決問題以及與團隊學習和教練交流的過程中，他們的能力提升成為他們自己的認可，因此未來也可以利用成功的學習策略。這種方法的主要潛力在於獲得的能力的實際相關性以及以需求為導向的內容、技術和技能的交流。

與任何以專案為導向的教學/學習方法一樣，當目標是系統地覆蓋預定義的課程時，敏捷學習就達到了極限。教學示範性的學習方式無法確保這一點。對於特別重視學習內容完整性的學科領域（例如工作安全或防火），首選經典的繼續教育形式。在那裡，敏捷學習項目只能通過轉移支持在日常工作生活中可持續實施學習內容來補充培訓。

註2. 《刻意練習》by Anders Ericsson & Robert Pool原書名為:

Peak: Secrets from the new science of expertise. 書中談到；何謂心智特徵?(chap 3)

所謂的「心智特徵」是一種與我們大腦正在思考的某個物體、某個觀點、某些信息或者其他任何事物相對應的心理結構，或具體或抽象。

而刻意練習，指的是在構建良好心智特徵的前提下，運用大腦適應能力，既有目的，又獲得指導的持續練習。關鍵詞是「有目的」和「有指導」。

註 3. KOLB 的學習風格說明(工程師的開發風格沿至於他的學習風格並形成他的個人習慣)，參考《體驗式學習》 by 凱·彼得森 Kay Peterson, 戴維·庫伯David A. Kolb.

開發者體驗設計

2022 年 04 月 29 日2022 年 05 月 05 日 ruddyllee發表留言

當我回顧過去時，我非常欣慰在我們的生命中存有一個信念，即生命中所發生的一切事物，或好或壞，都是學習體驗。如果你把這些都當作學習體驗，那麼你可以將所有糟糕的事情變為積極正面的事情。

—— 尼夫· 坎貝爾

開發者體驗設計有幾個面向可以依循: 其一、我們可以直接對開發者進行訪談，然後就訪談結果；也就是針對工程師所說出來的痛點或是困擾，設法協助改善。這是針對開發者個人所感受到的痛點，直接記錄取得可以改善的事項。對團隊開發而言；應該考量到整個專案的開發週期及各種不同角色所擁有的不同任務的困難性(註1.)，

需求訪談；尤其是公司內部相互支援或改寫舊有程式架構的專案。大都忽略了需求訪談的重要性。架構師通常做自己最熟悉的架構設計，工程師則把程式寫成自己認為最簡解的樣子，而忽略了訪談的真正意義:

「理解、發現以及釐清真正的業務問題」

然而訪談應該包含適時地說服、創新的溝通及從客戶端接收的訊息(傳達部分事實)讓我們足以用來推敲他內心真實的需求，所以不應該是一次性的溝通，敏捷則把它設計成每個Sprint都給客戶看到我們的進度並獲得反饋的機會。

其二、依據影響開發速度的Speed Model(註2.) 對影響較大的因素進行分析，然後客觀的與相關人員合作，進行改善措施。其三、針對開發者在接受到任務後所產生的認知負荷(註3. 認知負荷與解決方法: 認知設計與體驗式學習)，進行分析找出可以協助減少負荷的方法。

開發者體驗設計三個可依循的面向:

訪談；對開發者進行訪談，直接針對他所遭遇到的問題或困擾進行協助改善。
Software Development Speed Model；依據影響開發速度的Speed Model 針對開發團隊的開發人員與環境進行分析改善。

(參考: 團對優先Team First、開發者效能剖析)

學習效能；針對開發者在接受到任務後的認知負荷給予協助。(參考: 了解工程師的負荷)

註1. 針對整個專案的開發週期及各種不同角色所擁有的不同任務的困難性進行訪談。可將此DX體驗，視為以狹義的API體驗為出發點。

註2. 參考Michael Dubakov的 Software Development Speed Model

註3. 參考 John Sweller 的認知負荷理論 Cognitive Load theory, CLT

消除認知負荷的方法: 運用 <認知設計> 與 <體驗式學習> 。

註. 工程師的五大痛點

了解工程師的負荷

2022 年 04 月 25 日2022 年 07 月 15 日 ruddyllee2 則迴響

開發者體驗設計首先要問的是:『工程師你的痛點在哪裡?』

問工程師你的痛點在哪裡?

有人說公司給的機器太慢、環境太吵雜、任務太多、會議太多、系統太複雜不容易加入新功能、系統的技術債太多又沒有給足夠的時間進行重構 …。這些都是值得改善的地方，但在這裡我想探討的是工程師內心所承受的壓力。也就是；開發者在接受任務之後的學習、處理與運用的過程，稱為「認知負荷」。

「認知負荷」Cognitive load

是指學習者接受、處理與運用的過程。因為資訊內容(數量、質量、脈絡等)、學習環境、傳輸環境與互動方式等因素，超越學習者所能知覺的認知能力，會造成學習者在「心理」與「生理」上所引起的負擔、重擔、苦惱與憂慮，甚至失敗與挫折的後設概念。

「後設認知」；認為是個人對認知活動的理解、意識與監控的歷程。又稱之為自我察覺。

開發者體驗DX與認知負荷

軟體的開發是一種學習的過程，對開發目標所必須具備的相關知識，工程師只有在學到了某一個程度之後(適當地學會了，例如: 80分)，才可能做出正確的軟體來，因此每一個專案對工程師而言；因為有期限的壓力，幾乎都是一種開啟快速學習的過程，因此開發者會產生如學生一般的學習壓力，也就是Sweller (John Sweller為認知負荷發明人)所謂的認知負荷(Cognitive Load)。對應到DX而言；認知負荷理論對學習與教學及過程設計的重要性，也必定會形成開發者的一種體驗，進而攸關產出程式的品質與開發時程的長短。

我是基於「程式開發的過程就是一個學習的過程，當我們學得越好越順暢時程式也相對的越有機會表現得越好一些。」在這個理念之下，才想要深入了解開發者在學習過程(開發過程)中到底承受了怎麼樣的壓力。

參考 : Life of a User Story by Ken.Power(左側是可能的模組化開發過程)

上圖中，呈現山峰形狀的團隊開發過程是一條工程團隊對於需求認知的曲線，主要在描述工程師藉由開始學習解題所需要的專業知識，再轉化成程式邏輯後達到開發完成的整個階段，也就是綠色橢圓(Definition of Ready)至紅色橢圓區域(Definition of Done)之間的曲線。當山峰呈現越尖銳時則表示開發人員學習得越快越好，也就是在較短的時間內吸收了較大訊息量的知識，也就是在短時間內承受了較大的認知負荷。Sweller將認知負荷的來源分成三類:

認知負荷的來源細分為三類：

一、任務(環境特性)task/environment characteristics：包含任務結構、任務新穎性(task novelty)、獎賞類型、時間壓力、噪音、溫度等，屬於容易變動的因子。

二、主體(學習者特性)subject characteristics：因人而異的屬性，包括認知能力、認知型態(cognitive style)、先備知識與經驗等，屬於較穩定的因子。

三、任務與學習者的交互作用 interactions：如績效、動機、激勵等因子亦會影響認知負荷。

個體從事特定工作所產生的認知負荷量的多寡，受到工作的難易程度與個體本身所具備的專門知能兩方面的影響。例如，工作性質越簡單，個體的認知負荷量越少；個體具有較豐富的專門知識，個體的認知負荷量也會較少。

認知型態 cognitive style

所謂認知型態(cognitive style)是指人們「從事訊息處理時恆常一致的潛在傾向」(Messick, 1984, p.61)，它反應個體「接收、組織、記憶訊息時所偏好的方式，這些方式具有持久一致的特性。」(Keefe, 1987, p.7)。認知型態具有恆常與穩定 (consistency and stability)的特質，個人的認知型態不會因時間或情境而有重大轉變(Keefe, 1987; Jonassen & Grabowski, 1993)。

認知型態表現出個人處理訊息時的風格或傾向(tendency)，它與智力無關，而與偏好(propensity or preference)有關，因此，認知型態並不含「優劣、高下」的價值評斷，僅陳述個體對特定訊息環境的喜好狀態。

DX設計能夠做些甚麼?

認知負荷是一種壓力，適當的壓力能成為學習時的推手，而超載的壓力則會是一種酷刑，做不好不但令人難過對於職業生涯也是一種衝擊，應該極力去避免。以下收集了一些可行的措施，大家參考:

把任務指派給團隊而非個人

不論是在軟體的設計、交付和運維的全部領域裡，我們都應該從團隊開始入手，越是複雜的工作就應該交付給團隊一起來承擔，這麼做不但可以減少個人的壓力更能擬聚團隊的向心力，可以獲得更好的結果。

獎勵團隊而非個人

因為我們把任務指派給團隊而非個人，所以首先應該獎勵的是團隊，其次才是個人。對於品質管理也是如此；所謂的要求團隊的品質，即以團隊為基礎的品質決策才能夠達到持續的改善。

適當約束團隊職責以匹配團隊的認知負荷

在現代軟體交付中，最不為人熟知的增加摩擦的要素就是團隊不得不處理越來越大而複雜的程式系統。這給團隊帶來了龐大的認知負荷。它也是開發效能不彰的最大因素之一。

認知負荷也適用於不以開發為主的部門或是任務執行較多的團隊，比如傳統的運維或基礎設施團隊。他們同樣會遭受過度的認知負荷，尤其是在他們的職責範圍內，例如運維的工作站數量，或是虛擬資源、雲端資源等需要管理的工具面上。

採用團隊優先 Team First 的思維，檢核團隊的職責與團隊所能處理的認知負荷是否相吻合的。這所帶來的積極影響能夠改變團隊的設計方式，以及在組織內部如何與其他團隊交互的方法。

對於軟體交付團隊來說，在認知負荷方面，團隊優先方法意味著要限制軟體系統的大小，從而匹配團隊的期望工作狀態。也就是說，組織不應該允許一個軟體子系統成長為超出團隊所負責的軟體的認知負荷。這種觀點強烈和深刻地影響了軟體系統的架構和形態，這一點請參考這篇文章: 團隊優先。

認知負荷 Cognitive Load : 是指工作中記憶資源的使用量。

1988年，心理學家 John Sweller 將認知負荷定義為”工作記憶中使用的腦力勞動的總量”。Sweller 定義了三種不同的認知負荷: 固有、額外及相關(增生)的認知負荷。

核心思想是：減少個人在完成任務時需要的精力並提高個人的任務完成效率，優化任務流程的設計和任務信息的呈現方式。

使用相關領域複雜度來衡量認知負荷

評估認知負荷的一個簡單而快速的方法就是以一種非評判的方式問團隊：『你加班嗎? 你覺得你的工作效率高嗎? 你能及時回應那些交給你的工作嗎？』

正式的方式；是記錄下每次開發衝刺的表現(能夠完成多少故事點?)，同時參考加班時數與非生產活動時數在作成參考紀錄。其實；品質一直是認知負荷的一項重要指標，只要觀察團隊產出的品質就能意識到團隊最近所承受的壓力變化大小了。

教學設計可用於減少學習者的認知負荷。 -John Sweller

小結

“不可能的”、“一定是環境的問題”、“在我的電腦上明明是好的”，這些我們經常聽到的話，證明程式員都是比較有自信的，總是覺得自己的程式肯定沒問題的。其實；這是一種「認知失調」Cognitive dissonance的表現。

程式就是程式員的自我延伸(語出溫伯格《程式開發心理學》)，人們花了幾個小時甚至幾天時間所寫出來的結果，到最後交卷的時候它會以“正確無誤”的形象崁入你的意識中，你自然不會輕易相信別人能找出什么紕漏來，即便找出什么紕漏了，自己也意識到了可能的“不足”，感情上還是很難接受，所以大部分人都會習慣性的“辯護”，甚至試圖找一些迂迴的手段來證明自己是對的。其實只要稍稍冷靜下來，跳出自我守護的那一絲絲的自尊，我們就會很輕易的發現：「我的確可能錯了」。

　這是一種很常見的心理現象。在我們由設計到完成程式撰寫的過程中，我們會在心理上逐步的建立自己對程式的相信。再到程式的 Code review階段或測試階段，總會有人指出其中有那些不完美之處，於是出現了二種觀念的衝擊，也就造成了「認知失調」，所以我們會習慣性的“辯護”。在開發團隊中，要形成良好的氛圍，首先要克服認知失調現象，提高程式員的認知是比較重要的。程式員寫完程式後越快收到錯誤的回報越好，因為此時頑固的認知並沒有那麼強烈，以至於更能夠接受意見並產生自我反省。站立會議或是每天下班前團隊的聚集討論會議都是一個好的時機點，但是進行的方式；絕對不能是以 code review的方式來進行，這樣做是對程式員的一種不信任會造成反效果，取代的方式是閱讀程式碼；是的；像閱讀文章的方式去閱讀程式碼。以指定mentor的方式或是技術領導人養成習慣的去閱讀程式員一天所寫下來的程式碼，每天讀一點可以分散閱讀者的負荷，漸進的方式也能增加各種認知的效應。

程式員在壓力之下的產物 : “認知失調Cognitive dissonance”

是指在一個人的認知系統裡即將出現新的認知與就舊有的認知(舊的信念，自我已有的理念) 產生衝突時所引起的心理上的不適感，為了調節這種感覺，一方面為舊的認知辯護，另一方面希望在新的認知和舊的認知上找到共存的平衡。

更好、更智慧的學習環境；智慧學習環境是一種能夠感知學習情景、識別學習者特徵、提供合適的學習資源與便利的互動工具、自動記錄學習過程和評測學習成果，以促進學習者有效學習的場所或活動空間。打造智慧學習環境的主要目的是促進學習者開展有效的學習，具體表現在促進學習者對海量知識信息進行提煉、內化並將其遷移應用於複雜情境，從而促進學習者的智慧發展。

程式撰寫就是一種學習的過程，所以如果我們可以針對開發者去設計學習的場景或是教材，一定也能對學習產生提升的效果。思考如何降低無效的負荷，增加有效的負荷，參考 Sweller對於學習與教材的設計建議，在開發時應該考量的學習設計的七點原則：

1. 開放目標效應goal-free effect，避免固定答案的解題設計，這是使用者故事可以發揮的地方，讓團隊成員盡可能應用已有認知；採用多去推論或提出不同的解法，多重表達可以增強自己的思考過程。

2. 範例效應worked example effect，提供其他公司的解題方法、步驟，讓團隊成員透過相對的學習和引導來掌握學習內容，建構出較完整的解題模型。例如: 設計API時多參考業界領先者或是標準。善用設計模式來解題。

3. 完成問題效應completion effect，研究敵對廠商的做法，並空出一些步驟讓團隊思考適合自己完成的步驟，促使對示例作較仔細的研討，團隊成員的交互討論可能是一個最好的方式，可以增加參與度或讓團隊投入更多感情。

4. 分散注意力效應split-attention effect，有效的整合不同的訊息，讓團隊透過圖形或多媒體的方式(工作坊)進行研究討論。

5. 冗餘效應redundancy effect，要注意冗餘效應，同一個概念若同時使用多種表徵呈現，工作記憶因為同時湧入大量訊息，反而造成更多的認知負擔，對理解造成干擾。適度地進行行動學習可以減少反覆說明時所造成的過度複雜。

6. 專家反轉效應expertise reversal effect，專案開始之初邀請專家進行演講或研討會。對於已經具備一定程度的學習者，工作記憶能很快與先備經驗發生聯繫，從而加速學習，若此時教學設計強迫必須完成深層工作記憶的運作，反而增加學習者的認知超載，形成反向效果；反之，若學習者尚未建立一定的認知基礎，沒有經過深層工作記憶的加工，也難以轉化為長期記憶。例如，範例對初學者是有助益的，然而，當學習者了解或熟悉該領域知識後，這些基礎性的資訊或說明反而成為冗餘，阻礙了更進一步的學習。

7. 動態稍縱即逝，學習的效果沒有靜態設計來得好，針對這一點我的解讀是，講解者要善於運用肢體動作(human movement)來降低學員的認知負荷。

參考自: 國家教育研究院的國際認知負荷理論，七項教材設計的降低無效的負荷(套用了這七條規範，或許應該找個單位來做實驗，證明是否有效，這裡只做假設了)。

認知負荷CLT的核心理念正好與 DX設計的理念不謀而合:

認知負荷的核心思想是：減少個人在完成任務時需要的精力並提高個人的任務完成效率，優化任務流程的設計和任務信息的呈現方式。

註. 參考自溫伯格《程式開發心理學》

註. 軟體大師溫伯格先生認為以下的思維方式都能解決開發人員的認知失調。

無私式程式開發: 也就是程式開發時少了自我的一種單獨開發者的意識，將自己歸屬到團隊開發中，自己必須與他人協作才可能完成開發任務的一種思維模式。

民主化的開發團隊: 類似敏捷開發的自組織團隊，由團隊自行依技能相互要求程式開發品質的，互助式開發的模式。

註. 了解工程師的認知負荷之後便是依據負荷，針對認知的差距來做有效的DX設計。請參考《認知設計》

要讓工程師有能力做更多的事，就要培養他們有完成工作的知識與技能。

團隊優先 Team first

2022 年 04 月 19 日2022 年 04 月 20 日 ruddyllee2 則迴響

現代複雜系統需要高效能團隊

特別是對那些需要大量資訊的知識密集型、問題解決型任務來說，一個有凝聚力的團隊的表現要遠遠超出個人的集合。軟體開發正是這麼回事；現代的軟體組成越來越複雜; 越來越依賴分工。我們開發軟體時總是在銜接別人所做出來的軟體(程式)，然後進行修改或是加上新功能，接著在傳遞給下一個人。當然我們不會你等我我等你的進行順序式的開發方式，經常是說好了怎麼做然後就各自開工，採取並行開發的方式，一直到大家都做完了，然後在完整的整合起來。

銜接別人程式的時候；你是使用者。交接程式給別人的時候；你是開發者。對於團隊開發而言，你就是一邊扮演使用者另一邊則扮演開發者的角色，就像是在跑大隊接力賽跑一樣，你只是整個團隊開發作業中的一個環節。所以相互之間的默契跟你的感受將決定過程的成就，我們稱這種體驗為開發者體驗Developer experience，簡稱 DX。

當我們關注於團隊開發效能時，DX的好壞明顯的是一個很重要的環節，一旦開發者擁有良好的體驗時，產品也就擁有順暢而高品質的產出，因此設計DX的目的便成為了；追求順暢與高品質的產出有價值的產品。

DX 開發者體驗不是只針對個人

依賴某個人來理解和有效地處理建構與創建現代化的軟體；所需要的訊息量和資訊都相當的巨大，本質上是不應該依靠一個人獨自完成的。事實上，許多大企業在針對他們自己團隊的研究中發現，團隊是否有足夠的活力遠比誰在團隊中更為重要，也就是團隊協作勝於個人的知識程度。因此在衡量績效的時候，團隊比個體更為重要。當們希望擁有像實踐 DEVOPS一般高效能的軟體交付時，就必須從團隊入手。反之；個人的團隊認知與他在團隊中與其他成員之間的協作能力將決定團隊表現出來的效能。這也正是廣義的DX的定義。

廣義的DX定義

視開發者為 End user，將工作過程的技術協作與團隊互動看做是產品與服務，關注developer在使用中的感知與反應；致力於消除這些產品與服務所帶來的摩擦力，進而能夠快速交付價值並獲得回饋。也就是在軟體發展生命週期中，所有參與工程人員的體驗的總和。

所謂的團隊優先Team First的思維方式。敏捷對「團隊」有一個非常具體的定義。敏捷所說的團隊，是指一個由5～9個人組成的穩定小組，作為一個整體朝著共同的目標努力。我們將團隊視為組織中最小的交付實體。因此，團隊似乎永遠不應該把工作指派給個人，而應該指派給團隊。在軟體設計、交付和運維的 DEVOPS領域裡，我們也都是從團隊開始入手。以亞馬遜著名的“two pizzas”團隊為例，他們的軟體團隊規模是只需要兩張比薩餅就能餵飽全體成員。這一人數限制也是 Scrum 所推薦的。這是源於對群體認知和信任的進化限制，也就是我們所熟知的鄧巴數字（註1. 以人類學家羅賓·鄧巴命名）。鄧巴發現15人是一個人可以信任人數的極限，而其中只有 5個人最佳，能獲得深入瞭解和信任。

增進團隊績效的二個方向

方向一；是針對個人及單一團隊，方向二；是針對多個開發團隊。

是針對個人或單一團隊；圖左側參考Michael Dubakov 的 Software Development Speed Model。主要影響開發效能的因素為 (1).開發者的專注度(正向因素).及負向因素的 (2).系統的複雜度。(3). 浪費資源在非增值的活動。

針對組織中多個開發團隊時；圖右側參考Matthew Skelton / Manuel Pais所著的《高效能團隊模式》(註2.)，以重新編組的 Feature Team方式來解決傳統Product Team 所造成穀倉效應，以增加團隊之間的信任度與追求有效的溝通來進行編組的方式(主要考量是鄧巴數目-人與人之間的信任因素考量，與符合康威定律-溝通因素考量 )。

對開發者體驗設計而言；一個是針對人與程式之間的體驗，另一為團隊與團隊之間的互動模式。一個是開發團隊自行檢討就能改善增進效能的模式，另一則為組織管理者需要介入調整配合的重組組織結構轉變的模式，也就是常常聽到的組織轉型。

小結

想要提升團隊績效，就要以團隊優先 Team First為考量。針對小規模 5~9人的團隊，培養團隊成員之間的信任與讓它們能夠專注地進行開發工作，這是提升效能的基本方法。要考量的是降低系統的複雜度與調整排序需求的精實作法(減少開發團隊去作對產品沒有增值的工作，可參考開發者效能剖析)。針對多團隊的開發模式，則需要參考組織的結構，此時需要考量到康威定律或是反康威定律的作法。

團隊優先的人數考量

在快速變化和具有挑戰性的環境中，團隊比個人小組更有效。但依據鄧巴數對團體人數的限制。組織群組需要符合鄧巴數字，從差不多5個人(或者8個人的軟體團隊) 逐步增長到15個人、50個人、150個人、500個人等人數。團隊就會需要更多的時間磨合才能夠實現高效。通常團隊需要花費 2周到 3個月或甚至更長的時間來形成一個有凝聚力的團體。當團隊進入這種特殊狀態時，它所帶來的工作效率將遠超過個人。如果一個團隊需要3個月才能變得高效，那麼我們需要能夠提供團隊內外部的穩定性的時間也要相對的加長，所花費的成本也會因而增加(參考自鄧巴數)。

鄧巴數字的限制意味著不同業務線或工作流的人數同樣應該明確受到限制，尤其是部門人數超過50人的時候(150人或者500人)，同內外部的團隊互動也會發生變化。這也進一步要求軟體架構作配合(設計)進行調整以適配新的團隊組織，以便團隊能夠繼續有效地管理架構(康威定律)。這是我們習慣稱之為“團隊優先架構”的一個範例。

團隊優先的思維

讓小而美的團隊能夠維持長久與穩定，並形成標準。一種有趣的現象是當你放任團隊規模超過 7～9 這個魔法數字時，將危及團隊建構軟體的力量，因為人數變多了以後，信任度將開始下降(註3.)，不合宜的決策也會隨之而來(團隊自組織的決策品質下降)。為了信任度的下降，我們必須以下降開發的負荷來相匹配。否則士氣與品質也會開始下降。解決方法；是運用 “API First” 的協作方式來促進團隊的擴展與協作，或用心設計工作環境來促進團隊協作。同時要讓團隊有更好的促進信任、認知和學習的環境。而這也是設計開發者體驗時所必須考量的範疇。

為何鄧巴數哪麼重要?

因為團隊需要信任來維持高效運作，但是如果團隊規模變得太大，以至於難於維持必要的信任水準，那麼組織就不能像之前小團隊那樣高效了。因此，在一個建構和運行軟體系統的組織中，有意識地根據鄧巴數來控制團隊的規模，對於達成預期行為和團隊內部交互是至關重要的。

註1. 鄧巴數；以羅賓·鄧巴命名

人類學家羅賓.鄧巴(Robin Dunbar)是一位英國人類學家和演化心理學家，專攻靈長類的行為，於提出知名的鄧巴數(2004/03)。給出一個數字和一個假設：150人，其中關係最密切的不超過5人。所指的是人與人能夠維持緊密人際關係的人數上限。

團隊規模的限制和鄧巴數字可以拓展到團隊、部門、工作流、業務線等領域。除了鄧巴數字，人類學研究表明人與人之間的關係類型和深度存在明顯的限制：

大約只有 5個人，我們能與之保持密切的個人關係和工作記憶。
大約只有 15個人，我們能與之產生深度信任。
大約只有 50個人，我們能與之建立互信。
大約只有150個人，我們能記得他們。

註2. 《高效能團隊模式》Team Topologies: Organizing Business and Technology Teams for Fast Flow. 作者: Matthew Skelton / Manuel Pais.

註 3. 在一個為期 6個月的專案結束後，團隊剛剛開始展露高效，這時候將人員分配到不同的團隊將不是一個明智的選擇。正如 Fred Brooks在他的經典著作《人月神話》Mythical Man-Month中所指出的那樣，給一個團隊添加新成員並不會立即提升團隊的產能(著名的布魯克斯定律)。

開發者效能剖析

2022 年 04 月 11 日2022 年 04 月 18 日 ruddyllee2 則迴響

團隊開發就像運動會時在跑大隊接力一般，團隊協作越佳開發速度就越快，團隊學習到越多東西開發品質跟能力就會更上層樓(註1. 接力賽 1+1> 2)。至於開發速度可以快到甚麼樣的程度呢? 則好比跑 Marathon 慢跑一般，你可以用全力做快節奏衝刺，但你也知道這樣的衝刺速度只可能維持短暫的時間不可能持續太久，很快你就會力氣放盡累得喘不過氣來，然後就很難在維持下去了。所以跑 Marathon 的選手都知道要以盡可能快的速度跑很長的距離也就是節制速度地跑，而團隊的開發作業也是如此，但要考量的可能就更多了。下圖以目標、學習與狀態結果為考量。

大多數人傾向於跟著公司的節奏要求來調整自己的頻率，趕著出貨時就加班否則就正常上下班。但如果我們只針對開發速度來做分析。有兩種非常不同類型的速度：短距離速度(快節奏衝刺)和長距離速度(Marathon式)。針對團隊的開發效能運用短跑與馬拉松來做類比很是恰當。在軟體開發中，你不能兩者兼得。假設；在衝刺模式下全速工作，您每月可完成100個以上的故事點，但你無法在很長的產品開發時程上都保持 Sprint 的快衝步伐。或許您可以在 3-6 個月內保持 100 點/月的速度，但您幾乎不可能在一年內都做到這一點。除此之外，伴隨著高速開發的後坐力顯然是累積待爆發的(隱藏著的體能上限)，總有一天你會後悔這麼做的。

新創團隊的第二、三年的屏障

我參加過許多新創團隊，初期大家都在興趣高昂的情況下進行著全力開發的衝刺模式，但就在產品稍有眉目，也就是做出了20%~30%百分比的產品，然後在市場開始稍稍變得清晰時，團隊已經開始露出疲態了。按上圖來看就是採用了短跑式的開發模式每天工作12小時以上，然後漸漸地感到體力不支，這便是新創團隊最容易發生的第二、三年的屏障，跨過的方式就只能讓開發步調慢下來一點，讓大家喘口氣。但新創團隊很難採用Marathon式的開發模式，這種長距離緩慢前進的方式(沒有投資者能忍受這種開發模式，再說這樣就不算新創了)，因此就出現一種間歇式的緩衝方式(Intervals區間式)的出現，用週期性快慢快慢地間歇節奏，等疲憊狀態恢復之後再做下一次的衝刺。這種運用快慢的間奏方式來調節速度與產能便應運而生，如下圖:(位於中等衝刺二側的區間式開發模式)

中等衝刺

原則上；取中等速度進行衝刺，可兼顧家庭和事業，是很合情合理的一種開發方式，但這種方式容易讓學習趨緩，個人的競爭力下降，當然生產力也就跟著下降，尤其在競爭激烈的情境下弊多於利。

Intervals區間式開發

採用3個月進行快節奏衝刺式開發作業，然後接著做1個月的 Marathon式慢跑式的開發(採用放松周或橘色星期五等方式來緩和緊張的開發作業)，隨後再回復到3個月的快節奏衝刺式開發作業。如此就有反覆有節奏的開發模式，稱之為Intervals區間式的開發方式。敏捷開發所謂的開發節奏就是這個意思，只是沒有明確把它定義出來。上圖中有二種模式(位於中等衝刺二側的區間式開發模式)；都屬於區間式開發方式，區別只是在節奏的快慢，至於何時採用它呢? 我個人對於剛剛成立的團隊喜歡採用紅色框框裡的緩慢式模式，等到團隊的默契培養起來之後，則會轉向較快節奏的里程碑開發方式。有時候或許視任務的困難度做選擇會更好一些。

橘色星期五

組織於每個星期五都致力於個人專案相關知識的學習或各種學習課程。讓成員自由參加社群課程、閱讀技術文章、檢查新技術。

影響開發速度的因素

APPTIO公司(註2.)的Michael Dubakov 在 2019年畫了一張展示甚麼因素影響了開發速度的多元素示意圖(稱為: Software Development Speed Model)如下圖所示，綠色區塊為能夠增加開發速度的因素，黃色區塊: 為有限制值的因素，不能夠做太多，太多反而會得到反效果(例如: 重構的動作，做多了對系統複雜度的下降有限，反而會浪費時間)，紅色區塊 則為主要會減緩開發效能的因素。綠色箭頭表示效果增加，紅色箭頭表示減少效果。

方框上面的A、B字元是我加上去的，原因是便利大家看出區塊大小的影響階層，另外；值得稱讚的一點是作者採取開放給大家自行修改的態度，歡迎大家視自己的環境、文化自行對該圖示做調整修改沒有版權限制。這張圖示我已經用三年了，經常會因為針對不同的開發團隊或是不同的公司開發環境而作必要的修正。

標示A的紅色區塊有二個；分別是「系統複雜度」與「浪費非增值的活動」。
標示A的綠色區塊只有一個是開發工程師的「專注度」。
標示A的黃色區塊只有一個是更多的開發團隊參與開發作業。

對上面圖示，進行抽象化:

{這是一場受限於30~35分鐘的演講，所以談得簡單了些，請參考演講資料 )

小結

三個影響開發速度的主要因素分別是會造成開發速度下降的系統複雜度與讓開發團隊浪費在非增值的開發活動及能夠提升開發速度的開發工程師能專注的進行開發作業。至於我們經常以為很重要的開發技能和開發經驗。其實只佔一小部分。這一點可以在John WhitMore 的《高績效教練》一書裡頭得到驗證，也就是工程師的績效表現大部分是來自專注、熱情與信念要大於他的專業知識程度與經驗。(註3. 績效輪)

讓我們以開發者體驗DX的觀點來思考如何加快開發效能的方法，則是在過程中盡量屏除那些會讓他們分心的附屬工作(與開發功能沒有直接關係的活動)，協助工程師能夠順暢又高品質的完成他的開發作業，就是找到進行開發作業的最短路徑。

以上討論的是個人效能受環境與系統的影響，我們參考了由Michael Dubakov所提供的 Speed model ，這個圖形模式雖然並不完整，但是讀者可以視自己的團隊特質與工作環境自行去調整，以改善自己或是團隊的效能。但是如果你考量的是組織抑或是跨團隊合作模式的效能優化，則你的考量因素可能要由個人的效能表現轉移到多個團隊的溝通模式上頭，也就是康威定律所謂的"設計系統的架構將受制於產生這些設計的組織的溝通結構"，然後效能的表現則依附在溝通效能之上。(註 4. 參考高效能團隊模式)

註1. 接力賽 1+1> 2

人類100米賽跑的極限是9.58秒，但400米接力賽跑時卻可以跑出 36.84秒的紀錄，也就是400米接力時每個人都跑出了朝越人類極限的速度 36.84/4= 9.21 秒 < 9.58 秒.

註 2. APPTIO公司文章: About Software Development Speed Model

註3. 《高績效教練》的 績效輪 Performance wheel

註 4. 請參考由Matthew Skelton 與 Manuel Pais 所著的《高效能團隊模式》；討論組織的拓樸結構對團隊效能的影響。

回饋 Feedback 與開發者體驗

2022 年 04 月 01 日2022 年 04 月 12 日 ruddyllee發表留言

程式開發的過程中會有二種回饋；一種來自程式，另一種來自人類。

來自程式的回饋經常是錯誤的訊息，避免的方式是在開發的過程中就多做測試，追求高品質的程式碼。還有來自DevOps指標的回饋，來自對Log的分析是一種科學化的回饋。

來自他人的回饋則是使用者的體驗，用戶因為使用了我們的程式服務產生了相當的感觸所做出的回應。它可能是正面的肯定，也可能是負面的評語，負評；就是客戶要求改善，要避免這種負面的評語，就是排出時間來進行改善。負評是客戶的善意是客戶給的禮物；是產品發展中的助力放過了是一種損失。

良好的回饋文化是開發者體驗的成敗關鍵。

弄清楚問題在哪裡是改善開發者體驗的第一要務，而做法只有一個就是「問就對了」，而問就是交流，就是尋求回饋。

誰會給你回饋

我經常Email給自己，依靠時間差讓未來的自己給先前的自己一點意見。這個動作經常發生在早晨上班搭捷運的路上，因為我喜歡在車廂內思考問題，一旦想到解答就回立刻拿起手機來寄信給自己。我的email 設定的 tagname 是「自我回饋」，只要打開mail 就能看到給自己的一堆回答。常常是長長的的一串listing；有些是對同一個問題的連續思考，有些是不同主題的解答，光光打開來就會感到很有成就感，若是從頭到尾再走上一回，有些訊息就能記得更牢靠些，收穫也就更豐盛了。

我用大量的回顧給自己做 Mentor，當然看書時書裡面的各種理念也是，常常為了怕記不住，就刻意急著寄信給自己，以便看信的時候能多看它幾回，這樣做常常會有意外的收穫。

一種更好的方式是你應該找到一個(或多個)可以給能你回饋的mentor，或許是親人；這樣就可以做面對面的回饋。或許是社群中的友人還是職場上的前輩，能聽聽別人的意見總是一種收穫。在Slack 或社群中我經常會花時間去回答一些朋友的問題，有時候能很直覺的說上一堆道理，自己也很驚訝，有時候則必須再借助 Google 一下來充實內容，雖然很花時間但虛擬的連線方式，在時間上自己可以控制，有時候也不急著要立刻回覆，就能多思考一下再回，回完之後的成就感也算是一種小小的收穫。

在不自在的環境下，自在地學習著。

-開發者體驗

團隊的回饋文化由站立會議開始

站立會議；按道理應該是促進團隊互動，培養團隊回饋文化的好時機。但大部分的團隊在沒有 Scrum Master 的角色下，執行起來效果就會大打折扣，加上現在大部分團隊採用電子看板的方式，在會議室裡開站立會議。由於聚焦的效果不佳即便團隊的自組織程度不錯，回饋的形式便由於少了層次感而容易流於形式，經常就是隨口說說自己的工作，少了彼此關懷的互動性，很是可惜。

其實；站立會議是進行 SBI(狀況、行為、影響，註1.)資訊收集的好時機點。

如果你要給他人好的回饋；做好SBI是不可或缺的動作，尤其你是在做考核或1對1的訪談，或是做主管工作時更是不可或缺的本職學能。

建立回饋文化

建立「回饋周」的團隊共同工作(Tasks)任務，在回顧會議上提出來討論，擬定簡單規範，例如每人每個 Sprint 要提供他人二次以上的回饋。把它寫成Tasks, 每個人都要認領。今天作到了明天就可以移動task到完成欄了。然後經常性地作SBI的紀錄練習(可以將SBI寫在Task 單據的背面)，就更能作好更棒的回饋了。

回饋被忽視的成長力

孩子學習效果的好壞在他(她)對該項目感興趣程度的深淺。而這一點往往是藉由他人所造成的，當我們給孩子們一個有好的、正面的回饋時，自然可以加強他們的學習效果，當然前提是他有聽進去。孩子們往往會重視我們所重視的。因此；如果我們表現得積機些，自然他也會用心一些，而更有效的回饋還是要能夠掌握回饋的時機、情境與場景。(請參考《好好說話》)

提出回饋跟接受回饋都很難，但它卻攸關著我們學習的效果。

因此要；培養主動尋求回饋的習慣

人們做出改變的第一步是發掘自己需要改變。在我們尋求他人給予回饋的時候，要先做好準備讓對方感受到:『我準備好要做出改變了。』是一種雙贏的接受回饋方式。

科學化的回饋；來自自動化的數據衡量。

實施 DevOps 流程上所收集的四大指標，分別是: 變更的提前期、變更失敗率、部署頻率、平均恢復時間MTTR等，就是一種科學化的回饋方式。它是一種衡量指標，有了它我們才能做到持續改善。(註 2. DevOps四大指標)

最無關痛癢的回饋: 每一季都要填寫的安全性問卷，是一種最無關痛癢的回饋。

小結

談論回饋的著作很多，但大半偏向人的部分(註 4. 良好的回饋流程)，開發者體驗DX則多出了我們必須處裡的程式所給我們的回饋部分。無論是哪一種；我們都應該熟悉SBI的紀錄方式，因為它讓回饋變得充實而有效。

取得回饋的最簡單方法是；直接去問。 問: 開發者最喜歡的回饋方式:「最好是在我犯錯之後，還沒有任何人知道之前就得到回饋了，如此我便可以在還沒有被任何人發現前就改正了。」我稱之為即時修正錯誤。其實對開發者而言最好的回饋是沒有錯誤的回饋，也就是經過設計的開發環境，如果環境設計得當，開發者基本上就不會有犯錯的機會。這就是開發者體驗設計的終極目標(這是一種理想，因為適當的犯錯有時候反而更有益於學習，DevOps 三步工作法第三步、嘗試與學習)，針對不同的開發項目設計不同的開發環境，而這一點正好與架構設計的本質相通，也就是說我們可以運用架構設計，運用分隔工作層設計的方式作區隔(例如三層layer的設計，data 層)，讓它們彼此之間不會相互干擾，也讓開發者更可以在設計好的環境中盡情的發揮而沒有多餘的顧慮。

由於我們透過回饋可以讓我們學得更好，所以科學化的自動回饋，也很重要。這一點就好比學校裡常用的電腦模擬考卷一般，我們可以一作在作，也不用擔心會被別人譏笑，然後就可以高效而專注的去學習了。這是改善學習環境便可以獲得更好學習效應的證明，所以開發者經由科學(自動)化的協助方式，例如: 提供自動化測試，對於提升開發效能也有著莫大的幫助。

發現自己的盲區
考取駕照後的第一課題就是要小心盲區。盲區指的是通過後視鏡也看不到的道路兩側的區域，在行車過程中，危險就隱藏其間。不論是對於人還是工作，我們都會存在盲區。我經常在課程開始之前要求學員要「看見全貌」，但你又怎麼能夠確定自己已經看到了事態的全貌了呢? 其實；有的時候我們更需要刻意的去關注那些可能躲進視線盲區的問題。

.《簡報資料》

註1. SBI是: 狀況Situation、行為Behavior、影響Impact

是一種回饋的前置作業，經常用在1 對1的訪談之前的資料收集，是良好回饋的基本要求，它記錄著:

狀況 Situation；是在何種狀況下，哪一種情形下發生的。
行為 Behavior；行為或舉動
影響 Impact；對周遭或該項目產生甚麼影響? 是對還是不對?

記錄得越是具體越能夠提供好的反省。

註 2. 四大 DevOps 指標

變更的提前期

需要跟蹤的關鍵 DevOps 指標之一是變更的提前期。請勿與週期時間混淆，變更的提前期是指代碼變更提交到主幹分支與進入可部署狀態之間的時長。例如，當程式碼通過所有必要的預發佈測試時。

變更失敗率

變更失敗率是指生產後需要熱修復或其他補救措施的代碼變更百分比。它不衡量在部署代碼之前通過測試所捕獲和修復的故障。

部署頻率

瞭解將新代碼部署到生產環節的頻率對於瞭解 DevOps 的成功至關重要。很多從業人員使用“交付”一詞來表示發佈到預生產階段環境中的代碼變更，並保留“部署”一詞來表示發佈到生產環節的代碼變更。

平均恢復時間

平均恢復時間 (MTTR) 衡量從部分服務中斷或完全故障中恢復所需的時間。無論中斷是由最近的部署還是孤立的系統故障所造成，它都是要跟蹤的重要指標。

註3. DevOps 三步工作法

第一步，實現開發到運維的工作快速地從左向右流動。

第二步，在從右向左的每個階段中，應用持續、快速的工作回饋機制。

第三步，建立具有創意和高可信度的企業文化，支援動態的、嚴格的、科學的實驗。

註 4. 良好的回饋流程 (參考自《Feedback回饋的技術》)

註 5. 精準回饋必須考慮到的原則:

Mentor 與開發者體驗DX

2022 年 03 月 25 日2022 年 03 月 30 日 ruddyllee發表留言

你一定做過mentor，就是在職場上負責協助新入加入團隊的mentor工作。但你可能不知道不是只有帶人的時候才是在做mentor。當你設計一個功能而大家都對它很陌生需要你來教導如何使用時，你就是在做mentor的工作了。話說回來；你評估過自己當mentor時，做得如何嗎? 要怎麼做才算及格呢?(註 4. MENTOR 與回饋)

Mentor這個字係源自古希臘神話人物 Mentor的姓名。Mentor受朋友 Oddesseus所托照顧他的兒子 Telemachus。隨後便被引申為: 「為較少經驗的同伴傳授智慧與分享知識」的意思。

(奧德修斯Oddesseus又稱；尤利西斯，是特洛伊戰爭製作木馬的伊塔卡的國王)

Mentor與開發者體驗DX

Mentor 的意義是為較少經驗的同伴傳授智慧與分享知識。所以它的範圍並不會侷限於開發上的技術，從新人的角度來看；就變成他在這段時間裡經歷的所有體驗的總和(DX)。而這正是廣義的DX開發者體驗的定義。這說明了職場導師mentor的重要性，在團隊中，你的工作有承接自其他工程師或是必須傳遞給其他工程師的東西，例如: 我們可能做了一個新功能必須教會大家(這一刻我們是導師)而下一刻又向團隊的其他成員學習新技術，這時候我們便又變成學員了，這便是團隊持續進行教與學的循環，所以當做導師時我們必須是值得信賴的，是帶領不熟悉這件事的(新進)人員能夠快速到位的領航員。(註 3. Mentor 要負責引導學員，由無知過渡到知道的學習過程)

社會上；還有一種長期的mentor，他可能是我們整個職業生涯的導師，是足以效法的人士，但這個話題就離DX較遠了，可能緣分更為重要。

依據mentor 的定義: 「為較少經驗的同伴傳授智慧與分享知識」。

負責製作API 的一方必須扮演 Mentor 的角色，負責帶領大家進行學習。

Mentor的責任是引導，而引導就是提問

這裡要推薦《高績效教練》書中的教練引導模式GROW教練模式。

GROW教練模式是一種模式，是人與人溝通的設計模式。既然我稱它為設計模式，我就來用認識設計模式的方法認識它:

依照設計模式的說明方式:

名稱	GROW教練模式。源自《高績效教練》
問題	解決新進人員的適應問題
解決方案	運用對話方式，勾勒出目標(職責)，現狀說明(環境分析)，做法選擇(引導新進人員思考對策)，擬定執行方案，然後付諸行動。
適用性	針對新環境或加入新團隊的適應問題
影響	建立Mentor 與新進人員的良好互動
範例	學員問教練我接下來要做什麼?

範例: 學員問教練我接下來要做什麼?

學員: 教練我接下來要做什麼?

◆ Goal｜釐清目標、以終為始

教練: 你覺得現在你最想完成的目標是甚麼?
如果達成了；你覺得這代表的意義為何？
(視目標的狀態，引出短、中期目標)

◆ Reality｜對現狀的了解

教練: 可以說說看你目前的狀況嗎？
學員: …
(觸發當事者反省，切勿替他人反省)

◆ Option｜有哪些可能的方案

教練: 說說看；怎麼做可以解決這個問題？
學員: …
(適度調整眼界，越具體越好)

說說看: (適度的將OKR 的0.5 、0.7、1.0 的關鍵結果融入談話中，這便是激勵、目標、訓練、分享，請不要直接去設定關鍵指標，而是以達成成果的不同程度來做尚未發生的結果的驗證)

如果你稍稍努力一下，可以做到甚麼地步?
用盡全力去做又能夠做到甚麼地步?
說說看；比你厲害的選手能做到甚麼地步?

(不要用數字，用它的意義來描述它，會更有效)

◆ Way forward｜前進方式

教練: 這些方法你覺得哪一個最有效呢? 你打算什麼時候開始做呢？
有誰可以幫你？遇到障礙時你會怎麼做？準備事項會有幫助嗎？
(儘量讓學員自己處理，小小的挫折能留下更深刻的記憶)

教練關注未來的可能性，而不是過去的錯誤。

《簡明牛津詞典》

起步；假設是四個階段都必須依順序進行一回，請記得一次解決一個問題，不要混淆這會破壞效果。然而，如果一項任務已經在進行中或者曾經討論過了，就可以直接由教練運用詢問的方式作推進。在這種情況下，教練可以由任何一個階段做開始或做結束。

先討論目標，在談現況

一個看似不合理的地方；現狀分析必須緊跟著目標設定之後，在現狀分析之前就設定目標可能看起來有些奇怪。乍看之下的邏輯正好相反，因為我們當然需要在我們設定目標之前瞭解現狀，實際上並非如此，只基於現狀的目標容易傾向於負面，也可能只是變成了對問題的反應，容易被局限。如果就這樣做了簡單的推斷反而缺少(損失)了創新，腳步跨小了只能實現小小的增長而不是追求應該有的成就，這一點甚至會影響生產力。有時候；短期的固定目標甚至會讓我們遠離長期的目標。在確認了理想的長期解決方案後決定實現該理想的現實步驟。這種先討論目標，後談現況的方式，所形成的目標通常更令人鼓舞、更有創意和更激勵人。因此建議在大多數情況下，依序使用上述四個步驟。因為是進行對話，所以覺察力和責任感，反而遠比 GROW模型重要得多。

對DX開發者體驗而言；Mentor要能夠盡可能的讓新人在感覺順暢之下去適應環境，並盡快發揮他的能力去完成屬於他的職責。(註2. 學習的最佳方式)

當學員融入團隊之後；團隊成員彼此之間的信任度，便能夠使你:

在不自在的情境下，自在地工作著。

小結

做好Mentor是開發者體中很重要的一環。從狹義的定義來看；開發者對自己所產出的功能、服務或應用介面程式，都必須背負教學、引導的責任。從廣義的定義來看；新進人員與團隊之間的互動體驗的好壞十分依賴於mentor的表現。

Mentor的目標是幫助學員適應新工作並加快學習曲線。為了要有好的效果或許你可以親自示範帶著做一回。請注意；因材施教才是重點，最好的方式是引導他，讓他自己做，即便受到挫折也只要在正確的方向上鼓勵他，至於結果如何，就有如上面這張圖一樣，在對話中引導學員去設定關鍵結果，這種事前設定程度(分數)區段的方法，跟學校老師用考試成績來分析學習效果一樣，可以藉由結果就能適當的回饋給當事人了，讓人們知道自己的能力然後自發的受激勵願意去嘗試更好的成績。因此能不能達成目標是當事人自己的責任，但是Mentor最重要的是: 激勵、啟發和支持，以及適當引導的行為。

同理他人：透過外在觀察、解讀與他人同理連結。

例如: 剛剛你在分享A/B計畫時，語速有點急促、聲音比較高亢、臉部表情有些糾結，感覺你有些情緒，可以跟我分享一下嗎？

又如:

你在分享達成目標時，臉部出現了微笑、聲音比較輕鬆與自在，是嗎？發生什麼轉變嗎？

同理自己：透過我訊息，分享自己的觀察、感受與觀點

例如: 當我聽到你提B計畫時，我突然覺得有一點擔心也覺得可惜，擔心團隊成員會覺得公司變來變去的、同時，對同仁在Ａ計畫投入與付出覺得可惜。

GROW對話模式的流程能加速決定速度，幫助減少干擾、釐清思緒、並將挑戰劃分成較小、可行的任務，幫助屬下釋放信念、熱情以及專注，並讓他們能夠自由地使用所擁有的資訊。

同理他人與自己是mentor的基本觀念，它能強化人與人之間有溫度的連結，激發團隊協作的力量。

教練必須讓球員意識到內心的障礙通常比對面的敵人更可怕。

我們並沒有談到Mentor 到底要做些甚麼? 而只是介紹了 GROW的教練模式，如果你會因此而感到不安的話，補一張圖示做參考。

<< 資料檔 >>

註1.《高績效教練》

高績效教練：有效帶人、激發潛力的教練原理與實務（25週年紀念增訂版） 作者：約翰．惠特默爵士 ( Sir John Whitmore)。強調在職場上，許多主管都有個疑問：當初面試進來的員工，明明資質不錯，為什麼表現不如預期？其實，激發員工的潛力，正是身為主管的責任。而教練（Coaching）就是要解放人們的潛能，引領他們做出好表現。

註2. 學習任何東西的最佳方式；費曼技巧: Richard Feynman

(考慮到新進人員要學的東西太多又太雜，所以對很重要的事，務必深入學習)

有四個步驟：

一、研究/學習一項新的主題
二、教別人(試著教孩子)
三、找出別人不懂的地方(識別差距)並重新回頭再學習。
四、回顧簡化表達的語言，確定已經能夠融會貫通了。

– 檢測知識最終的途徑是你有能力把它傳播給另一個人。

註3. 專案開發過程: Mentor 要負責引導學員，由無知到知道的學習過程

註 4. Mentor 與回饋

Mentor最重要的職責是回饋。而回饋可能是影響學習成果的最有力的因素之一。大部分Mentor 傾向認為自己提供了大量有用的回饋，但學員通常認為自己沒有收到回饋，也不清楚如何根據回饋採取行動。因此如何精準的回饋變成了我們做mentor 時重要的技能。我們將談到二種溝通的模式(pattern)將, 分別是ORID的焦點討論模式及 GROW的教練模式。這二種對話的都可以終生受用。