Ruddy Lee 分享空間

啟動工程師創意-開發左移

2023 年 01 月 12 日2023 年 01 月 13 日 ruddyllee發表留言

開發為什麼要左移?

藉由開發者提前介入問題的討論來啟發創意。

-工程師的創意

這裡所謂的「開發左移」指的是Developing Shift-Left，讓開發者提前在問題尚未被寫成需求之前，就參與問題的討論與剖析 (而不是將網頁應用程式 web application由前端執行大部分的邏輯運算，改從由後端執行的Shift-Left Development)。當我們遇到棘手難解的問題時，可以運用開發左移來增進創意。又稱之為「Ask your developer?」。

創意始於對問題的深入了解

我們經常期望工程師能夠有發揮創意的表現，但卻總是把規格已經定好的需求交給他們，這時候他們唯一能做的事也就是對既定的需求進行拆解罷了，那來創意! 雖然敏捷開發要求工程師在看到需求時，一定要先問Why? 不要在不知為何而作的情境下就一頭鑽入開發工作。但這樣做並不能夠換來創意，若是我們能夠在問題尚未被寫成需求之前，就讓負責開發的工程師能夠參與問題的討論與剖析，不但能夠確認工程師充分的了解問題所在，更能夠讓他有機會參與需求的討論與撰寫，也實踐了「向開發人員提出問題，而不是解決方案。」(註1. 參考自《Ask Your Developer》)

分配問題而非任務

開發左移；我們應該給出詳盡描述的問題，而不是任務導向的片段需求。對於工程師而言；我們應該要藉此觸發他們頭腦裡的智慧和想像力，而不僅僅是要求撰寫程式的技能。讓他們直接的面對問題而非需求文件；此時他們將面對的是無盡的機會，而那是“一個不缺目標的環境”。這是一種充滿創意的思維，也是一種最佳的開發者體驗。

如果我們給的是問題而不是一塊片狀的需求，讓工程師自行去剖析問題，而創意就是這樣會發生的。創意與解題就發生在這種新的工作方式，它讓員工感到快樂，並使他們能夠在工作中充分施展能力，並獲得成就感。(我覺得對孩子們也該是這個樣子)

擁有工程師的背景，看到問題就能即刻去做

LinkedIn 的創始人數只有五人，而且全部都是工程師。Facebook 的創始人數只有2人而且他們只是學生，是後來才成為工程師的。傳奇的亞馬遜創始人傑夫.貝索斯是電機工程以及電腦科學學士。更別提微軟的比爾·蓋茲與保羅·艾倫二位工程師了，當然我們也不能漏掉已故的史蒂夫·賈伯斯更是偉大的創意者。遇到真正想要解決的問題，然後發揮創意努力不懈的思考解題，正是上面這些工程師的寫照，值得後人效法。我們不該扼殺工程師真正面對問題的機會，哪種思維與創意是無價的，雖然創意往往不會在一夕之間就誕生，但如果沒有開始哪來期待呢?

讓工程師介入問題討論

現象可能是: 我們會對一個團隊直接說，『這只是個很初步的想法，這個樣子；大致是我們期待得到的結果或是想要建構的東西。麻煩一下，請把它搞清楚這是你需要承擔的責任』。然後由他們決定如何解決問題。我們可能還需要與他們來來回回地進行多次討論，但(必須明確化)說明這個專案是他們的。

讓開發人員能夠深入了解真正的問題，然後讓他們滿足它，這就是提出問題的意義所在。因此我們應該在問題出現之初，在過程的早期，在定義需要解決的問題時，就將工程師包括在內。所以PO的動作應該是，向工程師或團隊提出問題，並要求工程師根據現有系統(數據結構、程式碼架構)的資料傳遞方式，幫忙找出解決問題的最快方法，而不是向工程師提供已經定義好的解決方案，然後跟他們說甚麼時候要。其中的差異不言而喻，只有擁有解題的充分動機才會有精妙的創意解題。

傑出軟體來自對問題的初期創意

這裡所謂的創意；指的是「對一個問題不僅可以很好地解決它，而且還能高效的解決它。」想獲得它；要怎麼作呢? 描述如下:

把怎麼作交付工程師，也就是把責任交給了工程師

結論變成我們向工程師提出問題，問題：「我們會對一個團隊直接說，”這只是一個想法，大致上是我們期待得到的結果長成的樣子。麻煩你把它搞清楚，一切就交給你了”。然後由他們決定如何解決問題。」當然；我們可能得來來回回地多幾次討論，但這個專案的解題方案是他們的了。當他想出了解題的方法時權力也就跟著誕生了，工程師對自己所想出來的辦法，當然會視同是自己的責任，而我們只要確認他能有足夠的權力去完成它便是了。動機才是真正推動他盡心竭力完成任務的來源。那些充滿創意的傢伙(被我們稱頌的技術大牛們)，在事後接受訪問時，通常都會直接陳述:『為了克服難題，那是一種瘋狂的行為，我實在不知道自己是如何做到的，但下不為例。』

【說明】

頭腦風暴法(Brain Storming，BS法)、或自由思考法、集思廣益法。是一種腦力激盪的方式，目的是集思廣益；希望藉由群體的智慧，對問題能夠獲得更好的解答。想要開好腦力激盪的會議，需要依據一些規則跟精心的規劃(註2.)。所謂的開發左移；是指在問題出現的初期，讓開發者(或是在額外的邀請專家來參與)與PO(負責撰寫需求的人)一起坐下來思考、討論如何解題。此時PO以提問的方式(客觀引導)來讓工程師能以專家的立場(由形成概念到產出構想，請參考水平思考)一同參與思考解題。這裡列一下讓開發者參與頭腦風暴會議的優缺點，值得多加注意:

【優點】

可以即時提供技術專業知識:可以為討論增加實用性和深度。
系統思考: 工程師通常具有系統思考的概念, 可以從整體和長遠的角度思考問題。
創新思維: 可以提供新鮮和創新的想法。
解決問題能力: 可以為討論提供更實際的解決方案。

【缺點】

專業術語的困擾: 工程師喜好使用專業術語, 可能會使其他參與者感到困惑。
過分技術導向: 工程師容易更專注於技術層面, 可能忽略要解決的是商業問題。
專注自己的技術: 工程師可能因為本身具有某種技術, 可能會忽略採用其他技術的優點。
時間限制 : 工程師本身經常處於高壓下工作，開會時可能不會全心參與(覺得在浪費時間)效果自然不佳(沒有專注，就不會有創意)。
商業領域知識不足: 工程師在問題領域可能缺乏專業知識，會造成阻礙。
溝通問題: 工程師一般不習慣在人多的會議中溝通或表達自己的想法。
過於專注於實現: 工程師可能更專注於實現需求(因為過往都是收到需求就開工)，而非思考可能的選項或創新的解決方案，需要有人進行引導的動作。

小結

遇到棘手的問題時，請去問你的工程師。你可能只需要在一旁靜候就能獲得有創意的見解，或許有時需要你推波助瀾一下，有時候你還需要提供一些支援。而這便是機會，一種藉由改變流程的方式，讓「開發左移」的做法，給予工程師有著創意解題的機會，讓工程師有機會充分發揮他們的聰明才智。而不是僅僅要求他們有足夠的程式開發技能就夠了。這二種方式比較起來；一個只要接收需求，再按需求解題就達成了(技能)。另一個則充滿挑戰，工程師需要自己去面對問題，想出屬於自己的解答(創意+技能)，當然要具體完成任務可能還需要團隊其他成員的協助。雖然他有可能是(技術)獨角獸，但團隊的力量更能產出輝煌的成就。

人們總是會喜歡自己的想法，無論它是好是壞。要讓工程師們產生主人翁的責任感，還有什麼比讓他們自己想出解決方案更好的方法呢？當我們這樣做的時候，他們會勢不可擋地向前衝。這是開發者左移的想法來源。而你真正應該在意的是開發人員是否真正了解客戶問題，還是他們只是被要求實現某種解決方案。

註1. 參考自《Ask Your Developer》by Jeff Lawson 第四章 代碼之中有創意

節錄一段強調工程師的創意本能

在2020年春，特維利奧調查了全世界大約1000名開發人員，詢問他們和他們的經理如何看待他們在公司中的角色。調查的結果很說明問題。超過66%的開發人員認為他們的創造力高於平均水平，但只有50%的人表示，他們的工作需要高於平均水平的創造力。唔! 這難道不值得深思嗎。那麼開發人員是如何使用他們過剩的創造力呢？許多人在工作之外找到了出路：48%的人說自己的愛好以設計為中心 (如建築、家具、網絡)，32%的人說自己在業餘時間創作美術作品 (繪畫、雕塑、陶瓷)。哦，還有另一個打破刻板印象的結果：開發人員非常熱愛運動！36%的人愛跑步，33%的人愛騎行，28%的人愛打籃球，還有25%的人是徒步旅行者！

對於這樣的開發人員來說，交給他們一份“產品需求文件”，詳細說明要構建什麼將是對他們巨大潛力的浪費。這就是為什麼我們應該：

向開發人員提出問題，而不是解決方案。

註2. 如何開好腦力激盪會議

敏捷開發有需多工具都適合進行腦力激盪，例如使用者故事地圖、影響地圖。一般都交由Scrum master 來主持。但它真正需要依據你的團隊特性，再遵循一些規則才可能做得好。

確定會議目的: 確保所有參與者都明白會議的目的和期望的成果。
邀請適當的參與者: 確保邀請的人能夠對會議的議題有所貢獻。
安排會議時間: 選擇適當的時間, 以確保參與者能夠參加會議。
安排會議地點: 選擇適當的地點，確保會議順利進行。
準備好討論議題: 準備好一些議題，讓大家有東西討論。
使用一些激盪會議技巧: 如使用思考時間, 隨機匹配小組, 提問等方式激發思考.
確保記錄會議結果: 確保會議結果被正確記錄並整理，以便後續跟進。

而讓開發左移則是另一種獲得創意的方法。

水平思考Lateral thinking

2022 年 12 月 30 日2023 年 01 月 06 日 ruddyllee1 則迴響

敏捷開發經常要求工程師，遇到講解需求的時候，第一件要做的事就是提出疑問(Why?)，一定要先質疑，然後透過討論來釐清需求真正的面目是甚麼?拿此來避免誤解和遺漏。但我們卻沒有教工程師要如何去問? 要他們自己發揮，而這需要創意，而水平思考的工具箱(註2.)正可以拿來彌補這塊空缺，以避免限制工程師的開發能力。

圖中右側顯示的是垂直思考，是有邏輯性的思考方式，又稱為「邏輯思考」，右側的金字塔圖示，顯示它主要是以演繹及歸納的方式來進行(請參考如何問出好問題)，因此各個格子之間具有關聯並表現得嚴謹而有序，過程呈現線性的關係，又可稱為有序性的思考或是螺旋性思考。左邊的九宮格呈現的是水平思考，是愛德華先生為了與垂直思考相對應，所以取名為「水平思考」。是運用自由聯想的方式所產出的發散性思維，在九宮格中你可以無序的填入與問題相關聯的種種聯想，向四周呈放射的方向射出，意思就是「你想到什麼就填上去」。沒有一定的填寫順序，主要的思考方式是發散性的思維。這種發散的思考方式會延伸你的思考到達你平時較少觸及的地方，進而孵化出過去沒想過的選項或答案。因此又可稱為創造性思維方式，它經常可以協助我們找到問題的最佳解。

要怎麼開始呢? 你可以依循左側的三個指標，分別是質疑、替代方案及刺激來做為思考的方向。就是；想到甚麼替代方案就把它填到九宮格中，想提出甚麼質疑，也可以把它填到九宮格中，這便是水平思考了。這些與主題之間有著自由關聯的主題，都是你運用水平思考所獲得的題目，你可以接著再個別運用有序的邏輯思考來做進一步規劃及探索細化的構想。它說明了水平思考與垂直思考是相輔相成的。也就是說；水平思考適合由不同的思考方向來產生新的概念，而垂直思考則適合由既有的概念來產生細化可實踐的構想。

程式設計師擅長邏輯思考，但不能沒有水平思考

是的，工程師不能不會水平思考(Lateral thinking)。水平思考是指對問題進行解決時，能夠從多個不同的方向、角度去思考，而不是僅僅停留在一個單一的解決方案。因為有許多工程問題都十分複雜，涉及到多個不同的系統和技術。因此，工程師需要能夠從不同的角度去思考問題，以便找出最佳的解決方案。

人類的思考方式分為兩個階段：第一階段為“知覺篩選”(perceptual choice)，即先在腦中將信息分門別類，再將感知到的事物互相結合，產生各種概念與想法之後便進入第二階段，運用邏輯有效地處理，驗證想法的正確性與可能性。

-愛德華·德諾

此外，水平思考也有助於工程師更好地理解問題的根本原因，並從中學習新知識和技能。同時，水平思考也能幫助工程師更好地溝通和協作，因為他們能夠更好地理解其他人對問題的看法，並從中獲得新的靈感，找出最佳解決方案。

當工程師面對問題時，能夠採用水平思考的方法有許多好處。它能夠提高解決問題的效率。透過從不同的角度去思考問題，工程師可以更快地找出最佳的解決方案。

寫程式就是邏輯思維的表現

寫程式就是在做邏輯思維的表達，它完全依賴我們的創意設計，我們要先對需求產生概念之後，才可能進行拆解成更細部我們可以實作的功能組件，而寫程式的目的就是要完成各個組件的功能實踐，最終再將他們合併起來形成具體的服務。它完全符合二階段的思考模式，先是進行知覺篩選，然後是運用邏輯有效地處理，來驗證這種想法的正確性。前半段我們需要的是發散的思維，後半段則是嚴謹的邏輯思維。因此水平思考與邏輯思考的關係是相輔相成的，而我們一般卻只強調邏輯思維，而輕忽了起步時的方向是否正確，這正是敏捷開發為何要求工程師在遇到PO講解需求的時候，一定要提問的原因。

水平思考 vs 垂直思考

運用垂直思考，我們可以通過一系列合理步驟得出結論。因為步驟正確，人們對結果的正確性有一種盲目的自信。但無論路徑多正確，出發點都是某種感性的東西，這一出發點影響了過程中所使用的基本概念。例如；想看電影時，合理的邏輯思維是先找到想看的電影，再挑選電影院，然後決定怎麼去。這時候電影院給你的印象可能會左右你的選擇，造成你挑選了距離比較遠的電影院。這便是感性的影響，它是垂直思考所觸擊不到的思維。

在作水平思考時，人們不是因為信息本身而使用信息，而是因為信息能帶來的結果去使用它們。在過程中，我們可能需要在某個階段故意犯錯，才能得到正確的方案；而在垂直思考 (邏輯或數學)中，這種情況是不可能發生的。水平思考正好能夠觸及這種感性的東西。它能夠動搖對刻板結論的盲目自信, 不管得出結論的方式看起來有多麼可靠。這便是水平思考的好處，因此人們經常在考慮到風險時，會運用替代方案或是逆向思考的方式來尋求突破盲目的自信。例如；想看電影時，水平思考可能聯想到"爆米花"、"3D立體螢幕"、"烤雞腿" …，等發散聯想，這時候你可能就更容易選擇到理想的電影院了。

所以敏捷開發要求工程師，遇到需求的第一刻，就要先提出質疑(先問Why?)。

質疑性的提問容易讓人產生不悅

水平思考可分成三類: 質疑、替代方案與刺激(註4.《Serious Creativity》)。這裡所謂的質疑，指的是拒絕接受現行做法必然是最佳解的做法，是一種科學的求真精神，讓思考能夠繼續去尋找可行的替代方案。因此它是針對自己內心的思維所提出的質疑，並不是言語對話上的質疑。真正在與人溝通時你必須考慮得更周詳一些(請參考卡普曼戲劇三角)。

尋求替代方案的思維(註1. )，我經常使用的是可視化概念的方法，概念扇和影響地圖(Impact mapping)我都很常用。當人是最大的影響因素時；我會選擇用影響地圖。其它時候我會用概念扇(請參考水平思考的工具)，而且經常是在會議進行當中，因為它能讓你在概念跟構想之間反覆推敲，動態的加深了你思考的廣度和深度。

另外，思考提出替代方案時，你還需要考慮現實的狀態，例如:資金、技術、人力資源、支持和培訓等。

【水平思考的工具】

六頂思考帽、創造性暫停、隨機輸入法、概念扇、簡單聚焦、替代方案、替代方案、概念、抽絲法、設定刺激、 …。

-水平思考的運用工具

從哪裡開始?

想要運用水平思考，要從”刺激”開始，我的習慣是反向思考，透過與常識相反的思考，找出新創意的切入點，它是一種刻意的思緒，能夠促進我們不受常識或定論局限的一種靈活思考(這麼做主要是想擺脫自以為是的想法)，直接質疑根本的原因，是探究真理的假設思維。因為我們通常會以過去作為基準來推論事情的原委，結果就是在腦子裡強行關聯過去的結論跟未來尚未發生的事件，這完全是一種自以為是的想法，因此我以為要秉棄這種先入為主的想法，最直接的方式就是朝相反的方向去思考。而這麼做會直接刺激我們既成的思維，讓我們更容易看到主題的本質。

當問題的方向凌亂的時候，我以為”理想化”也會是一個好的刺激，就是不要去看那些林林總總的問題，把過程理想化，然後再反過來看是不是我們真的想多了。這時候採用「左手欄」(註3.)將思維可視化的方式，也經常可以澄清是不是我們考慮太多的原因。

如果正門進不去，就尋找側門，假使計畫行不通，就改變作法。
翻轉危局的解答並不一定在前方，而在你的每一個「想不到」裡。

-《逆思維》，亞當．格蘭特

小結

創意往往讓人意想不到，也就是說它不合乎邏輯，因此我們不能只是用邏輯思維來思考問題，因此我們需要讓思維發散才有機會產生創意。而水平思考就是一種創意思考。你可能會有疑問，為什麼我需要有創意? 不是只有追求新創的公司才需要創意的嗎?

這裡的創意是指向人們在思考、解決問題、或創造新的東西時，所表現出的能力。它可以幫助我們在競爭激烈的環境中脫穎而出，並在不斷變化的世界中保持競爭力。在現今的世界，創意越來越受到重視，因為它可以幫助人們在職場中更加成功。創意可以讓人們想出新的、有價值的想法，從而在工作中更加有效率。此外，創意也可以幫助人們應對變化，並在遇到困難時想出解決方案。

因此，不論是在工作中還是在日常生活中，都有許多原因需要人人都要有創意。創意可以幫助人們在競爭激烈的環境中脫穎而出，也可以讓人們在不斷變化的世界中保持競爭力。更別說天天都在解題的工程師了，我們更需要它。

工程師可以透過以下方式來提升自己的水平思考能力：

學習新的知識和技能：隨著工作經驗、概念的增加我們就自然地更能夠增廣自己的認知，因此透過不斷學習累積更多的知識，充實的專業知識可以增加自己從中獲得更多的靈感。
接受任務的挑戰：挑戰是一種刺激，當接受新的挑戰時，它有助於工程師學習如何從不同的角度去思考問題。
尋求多樣化的經驗：透過多去接觸不同領域和技術可以自然的幫助我們增加對問題的理解。
與他人分享想法：透過參與團隊或社群的討論與他人分享自己的想法能夠幫助我們從別人的觀點來思考問題。
尋找新的解決方案：透過不斷尋找新的解決方案(替代方案)，工程師可以增強自己的水平思考能力，總是要思索；解題的方法一定不只一個。
打破常規：逆向思考，透過不斷試驗新的方法和思路能夠幫助我們從不同的角度來思考問題，試想今天嘗試走不一樣的路回家看看。
尋求跨領域的合作：與不同領域的專家合作能夠幫助我們增加對問題的理解。
實踐解決問題的方法：不斷實踐解決問題的方法能夠幫助自己增強水平思考的能力。
尋求不同的資源：使用不同的資源，如研究論文、專家訪談等，能夠提共不同的角度來思考問題。
找出問題的根本原因：透過找出問題的根本原因，可以更好地理解問題，並從中獲得新的靈感。

我們可以經由不斷學習和挑戰自己，以提升自己的思考能力，從而善用水平思考來更好地解決問題。有時候我把水平思考看做是假設思維，做一個假設然後試著去驗證它，對了就給自己獎勵，可以讓日子更好過一些。有時候我把它當成旅遊閒逛一般，將心情暫且放輕鬆下來，在細微的事件上悠哉地進行探索，而忽略成果。其實就是獲得概念、培養概念，有概念候後再來進行學習。

藉由實踐來激發創意

愛德華以為『我們經常在有了一個好的構想時，就以為它太了不起了，人人都會喜歡它、支持它，但現實中幾乎沒有這種事情。』一個構想要成功，一定是有人努力去推動它，有人透過實際的實踐讓大家看見它的價值，所以我們身為工程師，唯有踏實的使構想能夠落實下來，才能彰顯出它的價值來。

水平思考與開發者體驗的聯想

水平思考 (Lateral thinking) 是一種創造性思維方式，它強調尋找各種不同的解決方案，而不是只停留在一種解決方案之上。水平思考通常被用於解決複雜的問題，並且需要在多個領域之間進行探索和思考。
開發者體驗 (developer experience, DX) 是指軟體開發者在使用軟體工具、框架和平台時的體驗。它旨在提供給開發者一個順暢、高效、使用起來感覺舒適的工作環境，以便他們能夠專注於軟體開發的核心任務，而不必花費大量的時間在系統管理和配置方面。

雖然水平思考和開發者體驗之間沒有直接的聯繫，但是水平思考的創造性思維方式可能有助於開發者在使用軟體工具、框架和平台時找到最佳的解決方案。此外，開發者體驗也可以促進水平思考，因為如果開發者有一個舒適的工作環境，他們就有更多的時間和精力去思考和解決問題。

註1. 尋求替代方案你可以這麼做(我最喜歡用的是影響地圖，因為它以人為出發點，容易做成故事的情節及場景，很有啟發性。再來就是水平思考的概念扇，它們二者都以概念可視化的方式來協助我們進行思考解題)。

要經常去關注最新發展：訂閱行業新聞、去參加社群聚會、或者加入相關的線上社群，都可以讓你增加對新技術的瞭解、新產品和服務，從而為你的任務尋找替代方案。
整理你的需求：透過整理文件是創造基本概念的最踏實做法，但它比較花時間。如果能明確定義你的需求，包括你的目標、預算、時間表、以及最終產品或服務的功能和性能標準。這樣就可以省去不少時間，並且更容易地找到符合你要求的替代方案。
比較評估你的選擇：研究各種替代方案，並評估它們如何符合你的需求。運用列表來整理及比較各種方案的優缺點，以便你能夠做出明智的決策。
測試和驗證：在選擇最終方案之前，建議你實際測試或驗證替代方案的可行性和性能。這可以確保你選擇的方案符合你的需求，並且能夠在實際應用中取得成功。
考慮風險：在尋找替代方案時，要優先考慮風險。因為風險就伴隨著你的策略而來。每個方案都可能有它的優缺點，因此你需要評估選擇哪種方案所帶來的風險。例如，如果你正在尋找新的軟體供應商，你需要考慮選擇新公司所帶來的風險，因為它可能沒有像老牌公司那樣的資源和經驗。
尋找專家幫助：如果你在尋找替代方案時遇到困難，你可以尋找專家幫助。
維持彈性：最後，在尋找替代方案時，要保持彈性。即使你已經找到了一個看起來很好的方案，也要持續檢查其他可能的選擇，以確保你的公司始終保持競爭力。

註2. 水平思考方式的運用工具(參考自《誰說輪胎不能是方形？》)：

六頂思考帽：一次只用一種角度看事情，能夠避免爭辯,更有效地進行討論。
創造性暫停：打斷例行思考的流程，停下來；才能注意到被疏忽的事物。
隨機輸入法：用來打破僵局，當毫無靈感、不知從何下手處理當前狀況時。
概念扇：藉由一連串的定點或提供新焦點，尋找理想的方案及構想。
聚焦：聚焦在沒有人願意思考的問題上，即使是小創意，也能產生驚人成果。
質疑：拒絕接受現行做法必然是最佳做法，繼續尋找可行的替代方案。
刺激：藉由設定踏腳石，扭轉現行的方式思考，找出真正的新興做法。

六頂思考帽
- 白色思考帽：考慮資料問題
  - 象徵中立而客觀、代表客觀的事實訊息、數據及資料。(不允許表達自己的意見，但允許報導他人的意見)。
  紅色思考帽：直覺和感覺
  - 象徵憤怒、狂暴與情感。代表情緒上的感覺(感情)，還有預感和直覺。不需要為自己的感覺辯解，或提出邏輯的根據。
  黑色思考帽：警戒和符合邏輯的負面看法
  - 象徵陰沉與負面。代表邏輯上的否定層面，屬負面思考，指出為什麼行不通的批判。所扮演的是「反證僧官」的角色。
  黃色思考帽：符合邏輯的正面看法
  - 象徵陽光、明亮、樂觀，肯定、建設性、和機會。代表邏輯上的肯定層面，包含著希望及積極肯定的正面思考。一方面重視邏輯與實際，另一方面兼具夢想、幻想與希望。
  綠色思考帽：創意思考，追求創見
  - 象徵生意盎然，肥沃豐美。代表創意、新的想法與冒險。思考者要以「前進」代替「判斷」，向前尋找新的主意、新觀念及新思維。
- 藍色思考帽：控制思考的過程
  - 象徵冷靜和控制。代表思考過程的控制與組織，思考解決問題所需的思考方式。思考者可以自己組織思考，指揮其他思考帽的運用，監督思考過程，並確保人人遵守遊戲規則。
創造性暫停
刻意暫停眼前進行的發想過程，考慮是否有替代方案或另一種做法，以檢視先前流暢的思考討論過程中，是否有疏漏
隨機輸入法
如果從一個不同的點出發，將有較大機會開啟不一樣的型態。可透過隨機詞輸入法，亦能借助物件、圖片、閱讀資料和展覽等。
概念扇
利用概念層層推出更多替代方案。從思考的目的出發，倒推至達成目的需要仰賴的廣義概念；也就是方向，再從方向倒推至概念，也就是朝該方向前進的「方法」。
簡單聚焦
通常只有問題困難會被思考與檢視，如果能夠注意他人都忽略的東西，或許可以想出非常有力的創見。簡單聚焦並非嘗試產生新構想，而是將某個點視為潛在創見焦點來檢視
創造性質疑
思考「這是為一個可行作法嗎」、「為什麼非得這麼想不可」，對於主導概念、假設、界限、必要因素、迴避因素、非此即彼的兩極觀念、持續性進行檢視，是否有其他方式，包含: 忽略型持續性(沒人想過的)、鎖定型持續性(需要配合某些事)、自滿型持續性(因為成功而未重新思考)、時序型持續性(受自身經驗的時序束縛)。
刺激
透過刺激來跨越型態，為一種主動的運作，而非暫停判斷。刺激來源分為：
- 自行出現的刺激：任何陳述、評論或事件都能當作刺激，被判定為不可靠甚至荒謬的構想都能用來刺激思考，幫助推出有用的構想。在這種狀況下，刺激可說是自行出現，而非刻意設定的逃脫型刺激法：刻意設定的刺激；選擇當前被視為正常的任何一點，然後嘗試「逃脫」他，可能為否定、取消、捨棄或不再仰賴
- 踏腳石刺激法：利用刻意的方法設定刺激，包含：
  - 反向操作：將正常操作的方向顛倒誇張：將尺寸設定在大幅高於或低於正常的水準扭曲：隨意改變事物間的關係或順序
  - 如意算盤：提出幻想的美好情況
移動
從某個構想移動到另一個新構想，包含：
- 提取原則：從刺激想法中提取某個原則、概念、特色或方面，然後試圖圍繞提取出的東西建立新構想。注意差異：刺激想法和正常情況有何不同，以該差異為焦點尋求新構想。想像每一步：想像刺激想法付諸實行的情況，並在其每一步得出有用的新構想。正面思考：注意刺激想法中正面的地方，藉以建立有用的構想。思索適用情況：尋找刺激想法可以提供若干直接價值的特殊情況，並藉以建立新構想
語層
將關於某個情況、互不相關的N個句子放在一起，構成一個語層，看看會產生什麼新構想。
替代方案
即使有合理的下一步，也能夠停下來尋找更多替代方案。設想新的情況來設計新替方案，而不僅滿足於分析特定情況。因此為替代方案界定「定點」很重要，定點可以是目的、組別、相似或概念，我們通常能為一種情況界定幾個定點，然後為每個定點再去尋找替代方案。
概念
做事的通用方法或方式，以籠統、模糊、非具體的方式作表達。每個概念都需要某個具體的「構想」付諸實踐，我們也能從任何構想「往返」到概念的層面，這種往返往往能激發更多概念。
抽絲法
圍繞一個創造力焦點，寫下替焦點設計時的基本要求，接著逐項檢視這些要求，但完全忽略創造力焦點的實際脈絡並提出「細絲」，也就是滿足該要求的各種方法。並選擇若干細絲，設法將他們組織起來，藉此得到一個新構想。

註 3. 左手欄 The Left-Hand Column

是由組織學習大師克利斯．阿吉里斯(Chris Argyris)與熊恩(Donald A. Schõn)所發展出來的工具。經過彼得.聖吉等人的改良，在《第五項修練．實踐篇》中有了較完整的練習方法。

註 4. 《Serious Creativity》中文書名《誰說輪胎不能是方形？：從「水平思考」到「六頂思考帽」，有效收割點子的發想技巧》為 Edward de Bono 在2015年的創作，是目前最完整的水平思考工具書。

敏捷教學甚麼有用?

2022 年 12 月 19 日2022 年 12 月 20 日 ruddyllee發表留言

開發者進行開發作業總是由學習開始的，但我們卻很少去正視它。敏捷開發強調要透明、檢核與調適。因此不應該忽視學習，學習時間不應該平白的讓學習者自行吸收而沒能進行檢核與調適，我們應該設法讓學習變得可視化，學習者變得可見的學習者(註2.)，以便讓開發作業變得更敏捷。這裡參考了愛德華·德·波諾先生 (Edward de Bono)所推廣的可見的學習（Visible Learning），我們藉由學習的行為將水平思考(Lateral thinking) 引用在敏捷開發上頭，其中「六頂思考帽」可以運用在重要的頭腦風暴會議，「概念扇」則可以協助我們橫向的捕抓更多構想，而這裡想要強調的「可見的學習」則可以提供我們適時更快速地回饋，讓開發作業與團隊的運作能夠變得更為敏捷。

本文想藉助約翰.哈蒂先生(John Hattie)的實驗數據，讓我們在可視化學習後，可以據此判斷如何改善或是提出怎麼樣的行為讓學習的效果更為有用。

可見的學習（Visible Learning）是指通過可視化的方式，把學習過程中的各種信息、數據和結果展示出來，便於教學之間能更好地理解學習情況，並為學習提供直接回饋。

-Edward de Bono

上圖中，我節錄了《可見的學習與深度學習》中作者的實驗結果，加以排序之後赫然發現，前二項高效的措施正是OKR 關鍵目標設定法的核心觀念，它也正好解釋了實行OKR會如此有效的原因。

O 表示目標，KR 表示關鍵結果

目標；就是指你想做甚麼事。關鍵結果；就是指如何確認你做到了這件事。

如果你是老師，你一定想會知道我這樣教能有多少效果? 紐西蘭的John hattie為了解開這個疑問，他對不同因素對教育成果的影響作了定量測量進行了有史以來最大規模的元分析綜合，從而促成了他的著作《可見的學習》。

雖然這些理論未經嚴格的檢驗純屬統計分析的結果，但書中仍有許多見解，值得我們在學習的過程中變得更為敏捷，值得參考。

OKR 為何有用?

讓團隊成員自己設定指標(Key Result)，自己衡量具體達成目標的期望值(註1. 0.7的魔術數字)，這是一種自我衡量、自我期許的行為，由Hattie 先生的實驗數據可以看出這二種方式的效果最佳，高居教學效果的前二位。而這也解釋了OKR為何有效的原因。人們對自我衡量、自我期許最能收到激勵的效果。由敏捷的角度來看這二種措施，它屬於自組織體系下的自主行為，帶來的是個人價值與目標的對齊，它的效果甚至比回饋所能帶來的效應量(0.73)更好。感覺上OKR給了我們一個實踐自組織時讓價值對齊和自我衡量的好辦法。

如何形成學習者自我衡量與自我期許?

許多家長可能都為了孩子門的成績傷透了腦筋。但實際上；你只要請孩子們列出現在他最想要做的三件事(只要有一個能跟學業有關就好了，不要要求太多)，然後在針對這些事每一條列出達成的三個關鍵指標，再針對做的有多好來給出0.0 到 1.0之間的評分，就可以了。當然你還要在接下來的時間裡經常提醒他做了哪些項目，進度如何? 能在早餐桌上進行檢核最好，但晚餐或睡前來做也行。這就是效果強大的OKR了。

內在動機的激勵

我們都知道在學習的過程中，運用觸發內在動機的激勵方式能夠造就最佳的學習效果，而OKR正是居於團隊成員對自我期許的效應而來的一種激勵方式。它用簡單的數字來觸發個人的內在動機。運用的方式是讓你自己設定正常工作下可以獲得 0.3的分數，稍微努力一下用功一些可以取得0.5的分數，如果能夠克服困難達成目標便可以得到0.7的分數，表示我們能夠期待他未來會有更好的表現。而1.0是表彰那些成就非凡超過預期效果人士的分數，通常指的是超過自己能力的極限表現。

士氣是設計的關鍵因素

-Paul Graham

敏捷教學應該要以務實為主

上圖中Hattie先生以0.4 為出發點，陳列了多項對學習具有影響力的措施，將0.4設定為中等的效果，凡是高於0.4的表示這種措施是值得去做嘗試的，它是有利於提升學習效果的行為，值得我們採用。換句話說；它想說明的是甚麼樣的教學措施才更有用?

教學的清晰度對學員學習的影響力大小為0.75。從實質上來探討，教師能夠言之有物而且條理清晰是上課時最重要的事。我們把它衍生到開發作業上，則是mentor 與 technical leader 所提供的協助與資料。再來就是相對地「需求」是否清晰而明確了。因為它是開發者最想要攻克的目標，它成了開發者進行學習時的最大目標，也驅動了他的學習方向。

》回饋的效應量為 0.73。

回饋；我們都想知道我們表現得如何，特別是當我們想要掌握一個新的概念或技能時。例如舞者會看著鏡子試圖找到自己的缺點，就是一種自我回饋的方式，依靠的是自我察(awareness)的能力。但更好的則是來自專家、有經驗者更落實的回饋。

回饋方式的不同也會帶來不一樣的效果，不好的回饋可能會讓我們產生戒心打擊我們的信心，破壞我們的學習情境，好的回饋則會推動我們達到新的理解水準，擊發我們持續改善的動能。回饋的三種時機:

前置回饋: 回饋發生在前置的時間，也就是事情尚未發生之前，我們稱之為前置回饋，通常又被稱為忠告或是建議。它大半來自有經驗者或是專家的建議。
即時回饋: 過程中的回饋，一般來自夥伴或客戶。
後置回饋: 事後的檢討，如Scrum的回顧會議。

前二種回饋因為事件尚未發生，還來得及進行修正，所以更有價值，但卻是我們經常忽略的(聽不進去常常是因為我們過於有自信)。後置回饋(敏捷開發的回饋指的幾乎都屬於此類)；雖然於事無補但卻能有助於學習，因此失敗的專案若能好好的檢討，通常比成功的專案學到更多，例如:新創失敗時，通常我不會說他失敗了，而是說他這次創業學到了甚麼。

回饋是非常值得重視的，特別是當回饋做得好的時候，這也是回顧會議成為敏捷開發裡最重要的一個會議的原因。從本質上講，回饋意見是“及時、刻意為我所提供的資訊，這些資訊在給出後能發揮最大意義”。回饋不應該僅限於團隊成員，還可以來自家人、同伴和自我 (請參考: 自我回饋)。

對應到回饋的敏捷學習工具

前置學習；策略與梳理會議是敏捷學習的前置行為，影響地圖則是屬於策略層面的工具，它讓使用者看見概念，是可視化概念的繪製工具。梳理會議則是發生在前一個衝刺開發(Sprint)的邁向未來的會議，它給了團隊成員預先知道的機會，是形成工程師概念的前置學習時機。

》具有挑戰性的作業的效應量為 0.57~ 0.72

不是當學生時才會有作業嗎? 開發專案時也要有作業嗎?

好的作業可以牽引我們好的學習效果。如果工程師對新開發作業缺乏相關的經驗時，我們可以藉由做作業的形式引導團隊由淺入深的逐步完成團隊成員對專案學習的深度(例如欲發展微服務架構時，就可以用開發模組功能的API 做為作業，進行練習)，因此好的作業練習可以用來開拓團隊成員的技術與相關知識，所以在專案開始之初，進行教育訓練並以要求作業的形式來落實教育訓練，可以有效的提升團隊成員的開發效能(尤其是Queue 或排序的技術或理論，事前的作業探索都非常有價值)。

》通過設定目標來激發學習的自發性和自主性，效應量為 0.56

通過設定目標來激發學習的自發性和自主性是自組織團隊的交互信任程度的一種表現，它有著正面積極的影響。它意味著團隊擁有共同的目標，而不是簡單的說“全力以赴”或者是將目標集中在完成任務上就有用的(無效的激勵)。相反的，是將目標集中在學習上，而不僅是集中在做上。當開發的工作淪為要完成無休止的一系列任務時，學習會受到不可估量的負面影響，正如目標被簡化為一系列待辦事項，以便從任務清單中劃掉。藉由讓團隊分享自己所設定的具有挑戰性的學習目標時的承諾(Key result就做這件事)，這些目標便更有可能實現。敏捷團隊的檢核(review)會議，強調要由負責的開發人員講解自己開發的那一部分功能程式，並一定開發者自己進行操作的方式來做展示，就是自主性的應用(規定不能交給測試人員來操做也是這個目的)。

》教師對學生的期望，影響力大小是 0.43

組織展現對團隊的期望，效應量為 0.43。所有的組織都會對團隊抱有期望。更好的問題是“組織的期望是否被錯誤解讀或者被誤導了”(它是一個不擅長表達的主管就能輕易造成的不幸損失) 教師的期望對學生學習的影響力大小是0.43。讓我們用另一種方式來說明：如果教師希望自己的學生在一年的時間裡能學習到一年的（或更多的）內容，他們可能會怎麼做…。這些期望每天都在傳達給學生，從行為舉止到任務挑戰。當教師計畫學習單元並讓學生參與高品質的學習體驗時，期望需要首先得到考慮。它無形中形成了學習環境裡的一種有利於學習的氛圍。

“弱即是強"指的是一種軟體傳播的模式

軟體設計思想的各個方面，其中的一個重要結論就是軟體功能的增加並不必然帶來質量的提高。有時候，更少的功能 ”弱" 反而是更好的選擇 ”強” 化，因為這會使得軟體的可用性提高。相比那些體積龐大、功能全面、較難上手的軟體，一種功能有限但易於使用的軟體可能對用戶有著更大的吸引力。

-Richard P. Gabriel

小結

要拿甚麼來做判斷的依據呢? 這麼做的效果好嗎? 是否值得投入更多時間、資源? 我們可以參考約翰.哈蒂先生(John Hattie)的實驗數據(如圖一)。

時間到了! 會議就一定要結束嗎?

敏捷的會議大都是採用時間盒(time boxing)的方式，也就是時間到了就結束的方式。目的是避免冗長會議所帶來的浪費與勞累。

這造成了團隊經常會害怕超時(當提問過多或是回答佔去太多時間時)，請問: 會議到底該不該繼續開下去? 如何抉擇呢? 是斷然地結束會議(符合時間盒的規範)，但這麼做可能會造成決策議題的延滯，下次會議又要重新來過的現象，是一種平白浪費的損失。然而；要延長多久時間呢? 延長多久才夠；這和會議想要獲得甚麼樣的結論才應該結束，必須相匹配，正確的做法是挑最重要的一項議題，討論完畢後就結束。相同的道理，敏捷教學甚麼有用? 我們可以依據「約翰·哈蒂的教學實驗數據」評估它的效應量來做為資源投入的標準。

甚麼教學策略是最有效的?

圖一列舉了，作哪些事情比做其他事情更能確保開發者的學習效果。參考它可以確保我們的行動更具效益，而且還能夠因此而避免了許多的問題。但是在你決定怎麼做之前，還是應該視當時的情境為主。例如: 在專案時間不夠的情形下，這時候實施 OKR關鍵目標設定法，雖然可以聚焦，但顯然團隊學要先學會如何設定個人目標? 學習所花去的前置時間就可能過長了，必然會延誤到正常開發作業。所以需要以工程師當前的需求為優先考量。

註1. OKR設定分數的意義，表示的是個人對自己的期許。Google 以0.7為考核及格的標準。

註2. 可視化學習者的特徵

可視化學習對敏捷教學至為重要，因為開發作業總是時間那麼趕，往往讓工程師一個接著一個的趕著做專案，平白的花了時間在做專案卻沒有落實的學到太多東西，實在有點可惜。工程師若能夠出現下面的特徵，則表示可視化學習的效果成功了，它可以作為敏捷開發時的檢核借鏡。

可以成為他們自己的老師；
可以清楚地表述他們正在學習的內容和原因；
可以談論他們如何學習——他們正在使用的學習策略；
可以闡明他們計畫的學習步驟；
可以使用自我管理策略；
尋求挑戰，有復原能力，並且渴望挑戰；
可以設定掌握目標；
將錯誤視為機會，並且很自在地說自己不知道和/或需要幫助；
積極支持同伴的學習；
當他們不知道該怎麼做時，會知道自己如何改進；
積極尋求回饋；
元認知技能，並且可以談論這些技能。

概念扇

2022 年 12 月 15 日2023 年 01 月 05 日 ruddyllee1 則迴響

為教學、演講進行敘畫的最佳工具 – 概念扇。

.(註2. )

我認為工程師在開發過程中的學習，形成概念應該是最重要的一環。有概念之後你便可以開始思考架構、進行初步設計、甚至做估算。這些屬於高度不確定性的工作，在在都依靠你對開發作業的概念，有了概念之後你才能肯定自己接下來要走的方向，也才能開始大步的朝目標邁進。

開發者體驗即學習，而形成概念是學習新事物的第一步。開發者在概念形成的過程中進行學習，通過聽與看的輸入來進行分析綜合、抽象概括等思維活動，從個別到一般，從具體到抽象，逐步把握這一類事物的本質並產生概念。然後才是瞄準問題進行解題。它實質上就是一個學習的過程，也是開發作業中至為重要的思維活動。

在尋找如何快速形成概念的過程裡，我重溫了艾德華先生的概念扇，再一次體會到它的威力，也讓人聯想到Gojko Adzic的《影響地圖》Impact Mapping, 它們有著異曲同工的外觀及內涵，都能協助我們迅速對問題產生概念，是運行DX時的好用工具，在這裡介紹給大家。

製作概念扇，原則上是從目標開始，然後抓出幾個方向，得出幾個概念，最後想出許多構想。概念扇提供一個框架幫助我們產生更多構想。是一種水平思考而不只是一般的描述或分析。

愛德華．狄波諾(Edward de bono)先生於 1967年提出了水平思考（Lateral thinking）是一種「嘗試以非傳統或看似不合邏輯的方法來解題」的思考方式，愛德華先生強調「看似不合邏輯」的水平思考，不是只能靠天馬行空。就如同數學有各種執行數學運算的具體方法，水平思考也能有系統地產生新想法和新觀念的具體技巧與工具，是一種創意思維，而概念扇正是其一(註1.)。

會議之初，第一要務應該是把「概念」説清楚。

人們總是急切的想付諸行動而忽略了概念的重要性，造成了許多與會者沒能進入狀況，沒能跟上討論和作意見發表，白白的浪費時間而只能作壁上觀。人們總以為這些含糊、不切實際和不必要的東西，會耽擱或誤導開發作業的時程及方向，平白的損失了有價值的回饋及創意。

–水平思考 Edward de bono.

概念扇拓展分析的方向

趕時間時；如果跑錯了方向，不管你跑得有多快，只會距離目標越來越遠。人們犯錯時大多是因為自以為是所造成的，也就是事前沒有進行分析作業或是分析時只朝有限的範圍去思考。然而分析時的正確行為第一個應該是確定目標，而分析後的第一件事則是擬定具體的行動方案。這正是概念扇的特色，它著眼的是如何成就某件事，或是描述成如何從更多角度來思考完成目標的各種構想。它是一個可以幫助我們看見全貌的簡單框架，透過尋求不同的方向(水平思考)來分析達成目標的諸多可行概念，然後再透過概念來思考解題的構想。此時或許有些構想太過理想難以實踐，這個時候你便可以運用概念扇再反推向目標方向而形成新的概念，如此反覆推論的方式，可以協助你展開視野而不會一廂情願地自已為是，限制了自己的思考範圍。這正是概念扇好用的地方 -透過反覆推論產生新概念。

製作概念扇

製作概念扇時；原則上應該從「目的」開始，然後層層往下推，你要自問: 『我要怎麽到來到這一點? 』，從目的向下推至「方向」，再推至「概念」，最後依據這個概念來想出許多可行的「構想」，這正是這項作業的目的。這裡的方向就是水平思考的運用，對同一目的用不同的方向去思考，這裡的方向可以看成是更廣義的概念，概念種類有大有小也有模糊不明的，要落實它們需要在構想與概念之間反覆推論，逐步的將概念扇可視化出來。

概念扇看起來條理分明但是我們的大腦不見得會喜歡這種順序而有條理的做法，在製作概念扇時，大腦往往會一下子就跳到一個實際構想上，而經常形成一種反覆跳躍的思維方式，這是建構概念扇時經常出現的方式，不用擔心；它不但無害反而更能牽引出不同的想法。(如下圖中的虛線部分)

【概念扇的三個層次】

方向：你所能想到的最廣義概念，就是你的方向。
概念：做某件事的非具體方法(對工程師而言模型就是這一概念)。
構想：實踐概念的具體方法。構想必須很明確，而且可以直接實行。

概念扇的運用，對主管而言

在會議前、後進行概念扇的水平分析。如果你已經是那種運用會議來進行管理的人士。每天開著種種的會議，然後總是在會議之初，努力的釐清概念，然後在會議結束前思考如何快速做成總結的辛苦人士。則運用概念扇可以協助你提升能力又能做好回顧的工作。你只要按照概念扇的層次(方向、概念、構想)，首先要確認目標，接著判斷方向(這個時候可以直接詢問報告者他所設定的方向，然後與概念扇做比對)，先避免去思考細節，先形成一種解題的虛擬路徑，就是概念。最後才是就每個概念形成解題的構想。把原本存在自己腦海裡的種種想法用紙跟筆的方式形成視覺化的紀錄，它是專屬於你的概念扇，它可以協助你在進行說明時更有說服力，也可以拿來做事後回顧讓自己檢討如何做得更好，當然也可以做為分析指導用，如果會議的性質是腦力激盪時，適當的引導報告者，提出不同的問題可進一步觸發新概念或是釐清觀念，當然也可以將概念扇直接畫在白板上，讓團隊一起進行推論，可能會花掉一些時間，但這麼作能夠協助團隊看清事件的全貌。

概念扇的運用，對工程師而言

工程師最怕沒有概念跟只有一種概念。沒有概念就甚麼都不能做；當主管要求我們對專案進行估算時(當主管詢問你準備怎麼做的時候)，沒有概念就完全無法作估算了(雖然一樣是在作猜測)。但不要總是依靠經驗，應該先進行學習，直到對開發領域產生概念之後才能作估算(依靠經驗作估算經常是一種陷阱，因為沒有二個專案會長得一模一樣的)。工程師在只有一種概念之下開始開發作業，應該要避免一開始就大量投入工時進行深入的設計或開發，應該先作概念性的驗證，例如: 作產品雛形prototype的方式。這個步驟就是概念扇上的方向判斷層(替代方案)。先作廣義上的思維，正是所謂的；解題的方法絕對不會只有一種，因此就應該先作驗證，先作好壞的取捨，然後才是深入的設計與進行開發。經常看到工程師為理念上的不同而產生爭執，大部分都是盲目的依附著一種概念，就開始深入地進行設計，自然在耗去大量時的時間和精力之後，選擇不妥協的態度，這是形成概念時沒有進行水平思考所致，若能在專案初期先進行概念扇的思維，結果就容易宏觀多了。

※如果你遭遇到工程師意見起衝突時，建議你參考限制理論的衝突圖來化解。

有關概念

「人們可以像科學家一樣」：運用構念(constructive)來預測事情，所有的人如同科學家試圖預測並控制事件的發生一樣。我們也想了解周遭的世界，以便能夠預測並控制發生在我們身上的事。如果科學家用不同理論預測不同事件，那麼人們也能以此來望向未來(註)。

-George Kelly

小結

如果思緒總是能夠順暢的如流水般的連綿不斷哪該有多好，但很不幸的是我們經常在想要弄清楚大方向時，思緒突然冒出了如何具體解題的細部構想，跳躍式的思維讓我們的思緒無法連貫，此時你便可以運用概念扇的層次結構，把突然湧現的做法先放進構想層，然後再來倒推這個做法(構想)是居於甚麼樣的概念所產生的，屬於怎樣的解題方向? 概念就是這樣被呈現出來的它變得可視化，而可視化的概念就變得容易整理多了。

由完全沒有概念的初學者，到進階為擁有多種解題方向的專家。這不是短時間能夠達成的，但你可以在學習的過程裡持續的補充各種概念(充實基礎知識)，例如: 對於參加了一個自己完全沒也概念的會議(註6)，一個好的開始方式是，從補足相關知識入手，就是把那些聽不懂或是不了解的專有名詞先查詢一遍，然後在把他們拼湊起來，還有問題就提出來討論釐清解題的方向與構想，藉由方向或構想的串聯來看見概念。這是藉由概念扇的三個層面來探索解題的動作是否符合我們的目標的一種方式。

一般在概念的層面作業是十分困難的，你不能跟鋪路的工人講你希望用路人能夠在經過這段道路時因為有柏油路面而感到滿足，你必須將概念再延伸到構想的層面才行，也就是具體的講出要鋪設的柏油路從哪裡到哪裡、有多長多寬。此時便可以概念扇的思維方式向上或是向下反覆推論(註5)方式得到概念與構想的連線，用來獲得具體的結論。

如圖二所示，我們用虛線的方式來連接突如其來的想法。無論是概念或是構想，我們可以運用往上一層的提問「這有什麼用?」，或是往下一層「可以怎麼做?」來形成連續的脈絡，促發思緒的反覆激盪，以此來獲得更豐富的解題思維。除此之外概念扇能夠:

一、協助我們擁有替代方案。
二、強化概念。
三、順利地改變概念。

如同影響地圖(註4.)一般，概念扇將概念可視化並顯示出替代方案，由原本凌亂的個別點子，拓展成有方向有概念的連線，讓達成目標的路徑擴展為多個解題的路徑。我們可以在觀察概念扇的時候，評估每條路經的難易程度及可行性。這便是看見解題的全貌，一種視覺化概念的工具，概念扇(concept fan)。

範例: 運用概念扇來規劃新的軟體架構，目的是降低系統複雜度

註1. 愛德華先生所創的水平思考的技巧，包括: 六頂思考帽、創造性暫停、聚焦、創造性挑戰、替代方案、概念扇及概念。

「創造力不是只有某些人才能擁有、某些人只能羨慕的神祕天賦。水平思考是每個人都可以學習、練習和應用的一種創意思考方式。就像任何技能一樣，只是有些人比較出色罷了。水平思考無法讓每個人都變成天才，但是可以讓你在既有的思考能力之外，增添產生新點子的寶貴能力。」

─愛德華．狄波諾

註2. 實踐敘畫時運用概念扇的思維，由於概念被可視化了，因此事後在欣賞畫作時，便容易捕抓到講者所想表達的內容。

講者一邊演講，敘畫畫家在聆聽課程的同時將內容抽象的以繪畫的方式表達出來，若能夠運用概念扇的形式作畫(目標-方向-概念-構想)。例如: 以課程的主題為目標逐步地展開，方向就是大綱，一路到如何實踐也就是構想，事後的觀賞者將更容易由淺入深的進行聯想與吸收。

註 3. George Kelly的 個人建構論。他認為：人存活的目的就如同科學家一般，在於對未來的事件 (events) 進行預測和控制，以減少生活的不確定性(追求美好)。他甚至認為，每個人均擁有一套屬於自己的理論，且不斷的測試該理論中的假設，獲得實驗證據，藉以形成或修正自己對事件的概念或建構，使其能有效的瞭解、控制和預測未來的事件，獲得明朗化的生活。一種十分適合拿來描述工程師思維的理論(它完全不考慮人的情緒影響)。

註4. 影響地圖 為Gojko Adzic 2012年所發明的讓概念可視化的工具。

影響地圖 (Impact mapping) 說明了如何把「概念視覺化」，提供一種 讓需求視覺化的能力，透過簡單的 Why-Who-How-What 的分析方法，搭配結構化的顯示方式，讓工程師能夠看見辛苦開發出來的功能是對應到哪一個業務的目標上。

註5. 反覆推論是概念扇最有價值得一面

有時候因為概念過於籠統或含糊，便很難形成具體的構想，我們要運用可行務實面與抽象的概念之間進行反覆的推論，讓概念逐步的明確化，越是明確越能形成具體的構想。

註6. 如果你在會議中完全沒有概念，最好的辦法是請求其他參與者(旁邊的人士)給你一個簡單的總結，或是請求主持人為你解釋目前討論的內容。你也可以嘗試自己專心聆聽，迅速用手機做查詢相關名詞的意義，然後提出問題澄清你的觀念是否正確，以便理解正在討論的議題。如果你還是沒有掌握會議內容，可以請求接下來的會議提供更多背景資料或先行資料，以便讓你有更好地理解。

開發者體驗設計，由動機出發

2022 年 12 月 06 日2023 年 01 月 13 日 ruddyllee發表留言

DX設計師不像顧問一般只提供建議，他更像ScrumＭaster一樣，更專注於引導。

開發者體驗牽扯甚廣，這是一篇談開發者體驗的文章(註1. 相關文章)，出發點是動機，藉由學習者擁有良好的學習動機，以獲得DX設計的良好效果。我認為開發人員也只是普通人，但他充滿了學習和成長的雄心壯志，擁有將工作做到極致的動力，並希望不斷實踐他們掌握的各種技能。

第一次看到愛德華先生的自我決定論(SDT,Self-Determination Theory)，感覺上比馬斯洛先生的需求理論還要更接近敏捷一點。團隊的三個需求都與敏捷習習相關: 「自主」；讓團隊擁有自己的決定權形成自己的團隊文化。「勝任」；讓小增量與多次運作的衝刺方式逐步的增強開發者的學習能力。「歸屬感」；建立團隊成員之間的互相信任感，以共同學習克服障礙來達成任務。相對的；這三者也是促成團隊自組織不可或缺的元素。讓我們又找到一個可以促成團隊自組織的路徑，並足以相輔相成。

居於DX的設計理念，我們可以致力於設計良好的開發環境，讓開發者能夠順暢的進行他們的開發工作。但一個不作激勵的開發團隊，就只是任由工程師們以最低限度的努力來朝著企業的生產目標邁進(愛德華.L.德西)。DX或許可以用引導的方式來協助開發者進行學習，也可以透過Mentor的方式讓教學相長來強化個人的學習效果，但這些都是外在的力量，而真正最有效的方式，應該是來自開發團隊成員的自我激勵(內在動機)效果應該最為顯著。所以好的開發者體驗設計應該藉由團隊自我激勵開始，本文要談的正是如何觸發開發者的學習動機?

外在動機與內在動機

外在動機往往是基於外部所給予的誘因、獎賞所觸發，如上圖，內部動機則居於開發者內心的追求了解(想知道自己工作上的相關知識)、去達成(正視自己所努力的目標、意義)與尋求工作上的動力(刺激)。而我們很大一部分的動機都是由內在及外在原因，以一定程度的比例組合而成。而外在動機；例如獎勵，往往會削弱內在動機，尤其是在獎勵被停止的時候，唯有持續加強內在動機才能持續激勵自己，保持對學習和工作的興趣，過上真正自主的生活。而DX設計；正是要學會如何用支援自主的方式來激勵開發者給出有益的啟示和建議。這裡針對這二問題做解答:

一、如何來激發人們的內在動機?
二、如何轉化外在動機成為內在動機?

激發人們的內在動機

激勵需要人們看到他們的行為與期望的結果之間的聯繫，而工具性(instrumental) 允許人們看到這些行為與結果的聯繫(註3. 見《內在動機》ch5.)這裡的工具性指的是組織或體系上的不明確所致，或是處於上位優勢者個人的錯誤管理)。人們必須相信他們的行為將會產生某種結果，否則就沒有動機去做事。這種動機，往往受制於曖昧不明確的組織管理，這是為何外在動機容易實踐但很少能持續表現出高效率行為的原因。(獎勵措施原本是針對低成就動機的有物質需求者的激勵，為什麼反而失效了呢？因為外在獎勵會削弱人們的內在動機)

滿足內在動機的三種需求: 自主、勝任與聯結

自主：激發內在動機的第一個心理需要

人們需要感受到他們的行為是他們自己選擇的，而不是由某些外部來源強加的(行為的緣由)，存在於他們自身內部，而不存在於某些外部控制之中。覺得自主；是讓支持自主與設定規則共存，愛德華先生的立場是反對依賴獎賞、要求、威脅、監視、競爭和批判性評估來激勵人們做出行為，但是，他也不反對與強調絕不能放棄規範(規範能帶來一定的紀律)。

勝任：激發內在動機的第二個心理需要

雖然工具性(instrumental，讓人們看到因果，也就是行為與結果的聯繫)對激勵極為重要，但僅靠工具性，還不足以確保人們高水準地參與社會生產。人們還必須對工具性的行為感到勝任，此時工具性才能成為有效的激勵因素。詹姆斯·康奈爾(James Connell) 和艾倫·斯金納 (Ellen Skinner) 總結了這些觀點，他們認為，人們需要具備獲得預期結果的策略和能力。真正的幸福來自對勝任與自主的共同追求。(所以勝任應該包含能力與適合的環境)

聯結(歸屬)：激發內在動機的第三個心理需要

“完全投入在做自己的過程中，從而發現自己是完全而真實地融入社會的…”。人們不僅需要勝任和自主，還需要在感受到這種勝任和自主的時候感受到與他人的聯繫。我們稱之為歸屬(relatedness)的需要，即感受到愛與被愛的需要，關心與被關心的需要。

動機；自我決定理論

自我決定論(SDT，Self-determination theory註2.) 假設了所有人都試圖滿足的三種需要：勝任、歸屬(聯結性)和自主性。三個與生俱來的需求，愛德華先生認為；如果能滿足該需求，則將會為個人帶來最佳的發展與進步。如果我們僅僅滿足了其中一種或兩種需要(或是一種也沒有滿足到)，那我們就無法維持心理的健康。更嚴重的是，如果一個人滿足這三種心理需要的努力受阻，那麼這個人就會產生像饑餓的這種生理需要；在沒有滿足時所表現的那樣，可能先是會以更大的決心去滿足它們，而隨後；再遇到阻礙時可能將導致這種努力的下降減少，進而形成心理失調的狀態，而降低個人成長的動機。

在自我決定理論看來，由於外在動機所提供的獎賞會削弱個體的自主感，因此而導致內在動機的降低。這也是我們在管理上不能輕易運用獎賞來激發團隊效能的最大原因。但是；幸好敏捷開發的回饋機制剛好能彌補這個缺憾，一個職級純粹的正向回饋，不但不會削弱自主性，更可以形成能力感而反而加強哦內在動機。這就是愛德華所謂的動機轉化。因此是當的表揚可以保持人的自主性(例如「你是一個優秀的工程師或主管」），但不應讓他感覺受到有條件的控制性的表揚(例如"你是一個優秀的工程師，確實像我們所希望的那樣」)。

歸屬感；自我決定理論主張，滿足一個人的關聯需要也是發展內在動機的一個重要的促進因素，但是，這種需要可能不像自主和勝任能力的那樣的根本(但它對團隊表現出來的戰力，卻有著巨大的影響)。在團隊中體驗到與他人的一種關聯感，這種歸屬感將營造在(彼此)關懷的氛圍中體驗到滿足感，而更能夠增強一個人的內在動機。所以，如果工程師感受到團隊對他的期望的話，他能更自由自在地發展與學習。

自我決定理論詳細闡明的三種需要對成長和發展來說具有很重要的意義。

轉化外在動機成為內在動機

運用外在動機作觸發，再將外在動機轉化為內在動機。按照自我決定理論，假如外在動機能夠內化(internalized)或整合進一個人的自我感知之中的話，那麼，曾經由外在因素所導致的行為就會變成由內在動機所驅動的行為。就像上圖中所描述的動機連續體一樣，內化具有多種不同的水準。最左端是無動機(no motivation)狀態，此時個體要麼不投人活動，要麼僅僅是"過場" 而已（Ryan & Deci，2000，你可能會訝異動機不是只有二種嗎? 但根據卡倫.霍妮(Karen Danielsen Horney )所說的，當我們的能力和自主性的基本需要不能得到滿足時，就會出現第三種動機，稱為無動機狀態。例如，早期的工程師，茫茫然的趕著工作，如果不是明顯的表現出自己的能力有所不足的話，他可能根本就不會去刻意的進行學習。或者，在長官的強迫下，他可能僅僅會表現得"假裝在學習"，而沒能真正的由內心的慾望去驅動進行學習。具體表現出來的是，上個月才開發完的專案，相關的專業知識一下子就給忘光了。

圖中間部分是外在動機，它描述了內化的不同水準。四種外部調節從左向右移動的話，行為就變得越來越內化。感知到的歸因點就從外部向內部轉移。當我們為了獲得或者避免由他人所支配的獎賞或懲罰而做出行為時，就會出現外部調節（external regulation)狀態。所以說，如果查理斯為了獲得金錢或是為了避免懲罰而閱讀的話，那他就是處於外部調節中。內部(注入式)調節(introjected regulation)類似於外部調節，行為仍舊受到獎賞和懲罰的驅動。然而，注入式調節包括由個體經驗所偶然產生出的自主感，稱之為自我捲入(外在動機看似容易引發，但產生的複雜的心理效應卻反而不好管理，宜謹慎使用之)。

在專案的開發過程中，當我們開始出於本身的利益而考慮其價值時，我們就處於所謂的認同調節(identified regulation) 中了，此時的行為仍屬於由外部因素驅動。例如，工程師可能認識到，這是很重要的一項技能，因此樂意花費自己的時間(自主性)，用更多的時間進行學習。即使是這種認知，動機仍舊來自外部，但是，此時的目標與僅僅是一種害怕失敗與獲得獎勵對比，就更加個人化了。

最後一種外在動機是整合調節(integrated regulation)。當個體不僅認為這種學習有用，而且也將其整合於自我的感知中時，就產生了整合調節，一般運行敏捷開發的團隊，藉由團隊所形成的自組織文化的氛圍，團隊大部分的成員大都能夠運行在認同調節與整合調節之間的層次中。(註4. 21世紀的自我決定論，參考自)

活潑的團隊，本身就是一種激勵。

小結

動機是成功人士不可或缺的原動力，自組織則是成就傑出團隊不可或缺的團隊文化。二者之間的關係，一個是個人另一個則是由多人所組成的團隊，個人的成功來自於持續的自我激勵，而團隊的運作則藉由成員之間的相互激勵來達成目標。愛德華先生的自我決定論點出了我們可以致力於激勵個人動機與培養自組織團隊的方法，藉由滿足個人與團隊的自主、勝任與歸屬感(聯結)三個需求來激發內在動機並藉以形成高效的學習。

傳統上；我們總是問孩子們功課作完了沒？而不是問他作完題目後你學到了什麼？前面的問法，隱含著控制與究責的意味，容易讓人產生疏離感，令人聽了心生畏懼毫無激勵的效用可言。而後面的問法，就把主權交還給孩子，讓他有自主的感覺，有機會說說自己的想法或是總結獲得的經驗(當然抱怨一下也可以吐吐怨氣有益健康)，這一點展現了自主效應的重要性。

相同的，我們問工程師程式寫完了沒？做完測試了嗎? 也是錯誤的一種問法，較正確而有意義的問法，應該是; 用這種解題的方式你覺得效能如何？我們應該注意些什麼？

敏捷開發在這裡與自我決定論有著相輔相成的效果，小增量與多迭代能提供開發者落實他的學習效果，而回饋則更能夠提供自我反思的機會，它們對觸發內在動機都有著顯著的助益。也回應了開始時的第一個問題(如何來激發人們的內在動機?)，如果我們在進行開發工作時，能夠落實敏捷開發的小增量、多迭代與尋求回饋的開發方式，自然就能借助SCRUM的框架來形成團隊與個人的內在動機。

而實踐透明、檢核與調適的敏捷四大會議正好能協助轉化團隊的外在動機成為內在動機的一種實踐活動。也回答了第二個問題(如何轉化外在動機成為內在動機?)，對團隊而言能夠落實招開Scrum 的四大會議(請對照到上圖中的轉化過程；計畫會議；讓團隊成員確實認知我們的開發任務及目標。檢核、回顧會議；讓我們取得客戶的回饋，修正我們的開發方向，有機會精進我們的協作方式，並在自組織的團隊文化的規範下，讓團隊成員有機會相互激勵形成學習的熱情與動力)，以培養、觸發開發者動機為優先考量，自然能夠水道渠成順利的將外在動機轉化成內在動機了，這一點看起來好像過於理想化了，但也不禁讓人體會到 Scrum Master的重責大任，與Scrum框架的深層內涵。

常常有人會問沒有Scrum Master 的敏捷團隊損失了甚麼?

我想損失了高效運行敏捷會議所自然而然的形成激發內在動機的機會；是一大損失。反之；DX設計者能夠適時協助團隊做好這些敏捷的會議，也是一大助益。

開發者體驗最適合由資深程式設計人員來擔任，他以過來人的身分扶助開發團隊披棘斬荊的克服開發過程中的種種障礙，協助團隊順暢的完成他們的任務。然而開發的工作是由學習開始，工程師必須要先學會欲開發的領域相關知識後，才能順利開始他們的coding作業。所以我以為開發者體驗設計，應該由激發團隊的動機作出發，因為學習的好壞是開發作業能否順暢的基礎，而內在動機又是學習者進行學習時的最好武器。因此在這裡介紹大家，一種既能夠啟發內在動機又能夠轉化外在動機成為內在動機的自我決策理論(SRT)。DX設計者能透過適時的協助團隊去掌握自主、勝任與歸屬感(聯結)這三個需求，自然能夠順利而高效的完成開發作業。

學習是一種同時兼具外在及內在動機的行為，最容易形成轉化。

成為一個優秀的開發人員

要成為一個好的開發人員所需要的是一種思維方式，一種DX的思維，而不僅僅是擁有好的技能。當他遇到問題時的思考方式，不僅僅是思考如何解題，而是如何進行(做到)更好的協作。

註1. 一些有關DX設計技能的文章

如何引導開發人員高效學習的技巧 – 談如何教導他人的布魯姆提問法。
工程師的自我學習技巧 – 談自我學習工程師的自我學習。
開發者體驗設計 – 開發者體驗即學習 -一招三式
落實學習以獲得真正的知識 – 知識的轉化
開發者體驗介紹 – 開發者體驗DX
開發者體驗即學習與解題 -談為何學習是DX的關鍵開發者體驗即學習與解題
溝通-喬哈里窗 –解釋ORID與GROW為何有效的協助DX設計師的溝通原理

註2. 語出 愛德華 L.德西 著作《內在動機：自主掌控人生的力量》
經由內在動機而非外在動機，才是創造、責任、健康行為以及持久改變的核心所在。外部的各種巧妙激勵或者施加的壓力 (以及內部的壓力) 有時的確能使人順從，但這種順從將帶來各種負面後果，包括滋生反抗的衝動。

如果個體所處的社會背景能夠滿足基本的心理需求（自主性、勝任感和歸屬感），它們就會得到積極、同化和綜合性質的發展格局。另一方面，過度控制，非最佳挑戰和缺乏歸屬會破壞自然賦予的固有的實現和組織傾向，因此這些因素不僅導致主動性和責任感的缺失，還會導致痛苦和精神疾病。

其實；自主、勝任與歸屬感(聯結)這三個需求，也深深的隱含在敏捷開發的運作中。它們與是否能夠形成敏捷自組織團隊有著相輔相成的關係。

註3. 見《內在動機》ch5.

明確行為與期望之間的聯繫能夠激勵需要人們看到他們的行為與期望的結果之間的聯繫，而工具性允許人們看到這些行為與結果的聯繫。（不管工具性的缺乏到底是體系、組織的錯還是處於優勢地位的個人的錯），他們就得不到激勵。

註4. Ryan, R. M., & Deci, E. L. (2000). Self-determination theory and the facilitation of intrinsic motivation, social development, and well-being. American psychologist, 55(1), 68.

布魯姆提問法

2022 年 11 月 29 日2022 年 11 月 29 日 ruddyllee2 則迴響

班杰明·布鲁姆(Benjamin Samuel Bloom)是美國教育心理學家，於1956年在芝加哥大學所提出布魯姆分類學(Bloom’s taxonomy) 的教學目標分類法，是一種以按部就班的漸進教學方式，最終目標是讓學習者能夠在不同範圍裡都能夠聚焦以獲得最佳的學習效果。

Bloom分類法 (Bloom’s taxonomy) 的層次結構是廣泛被接受的一種教學框架，所有教師都應該通過認知學習過程去指導學習者。所謂的按部就班就是指學習能力一層一層的漸進提升，共有六層；如下圖；每一個較簡單的類別(下一層)都是想掌握下一個較複雜的類別(上一層)的先決條件。而提問法就是指按照不同層級提出相對的問題來引導學習者以促進學習效果。下圖；層級中的六個動詞都是掌握和運用新輸入的資訊的思維工具。它用途廣泛，幾乎可以運用於任何場合。不論是在教學上還是在工作中，在你設計自己的計畫以實現個人目標時，這個分類法都可以作為你速記的工具。非常適用於當 mentor 帶新人或 DX設計師設計強化開發者學習過程採用。

講師在下課後問學員有問題嗎?

大部分的時候你都會得到沒有問題的回答。
這時候你會開始懷疑，到底學員們懂了嗎、懂幾分呢? 還是你根本沒講好，
他們或許完全沒有聽懂。
…
還是你根本不該問這個問題。
(請審視你該問哪一個階段的問題，如果你問的問題屬於評估階段的層次，對初學者來說自然是啞口無言了)

講師們；上圖是班杰明·布鲁姆幫你做好的學習分類，請試著由淺而深的問幾個問題，你就知道教學的效果了。

本文的目的是講述DX設計師應該要具有的教學認知，也就是要怎麼樣指導別人學習，我參考的是心理學暢銷叢書作家彼得．霍林斯Peter Hollins(註2.)的一系列作品，至於學員們自我探討如何可以自學得更好的部分，請參考工程師的自我學習。

教學探討

教學本質上是一種對話，在這種對話中，新的資訊被我們傳遞給還沒有掌握它們的學員。至於你採取的教學方法取決於你如何看待學員、訊息以及知識傳遞的規則。而對學習者提出問題，是藉由「提問」的方式，希望能夠直接命中目標，但應該問甚麼樣的問題才會有效呢? 這便是本文想探討的布魯姆提問法。

如何來幫助工程師學習呢?

通過提問的方式(批判性思維問題)，引導學習者開發布魯姆所謂的各個層次的思維，並令學習者能夠更加注意細節，提高他們的理解能力和解決問題的能力。對於開發者體驗設計(DX設計師)；某部分而言就是要運用有經驗的員工在某種程度上同新進員工接觸得更多，讓他們想起當初自己不會操作機器時的感覺(體驗)，自然就更能夠理解新進人員的困境。開發者體驗可以利用這一點，通過自然分享知識的過程來完成對新人的培訓(新人，指的是初次接觸某項專業知識的人員)。

【提問】假設你的團隊成員向你請教一件你很擅長的事，而這件事他從來沒有做過，你會怎麼回答他呢? 怎麼樣的回答才是一個稱職的 mentor 呢?

【解答】

※把自己所掌握的知識教給他人，你可以從他們已經瞭解的知識來入手，然後再一點一點的逐步地幫他們建構新知識。例如，你先講一個基本原理，或者利用他們已知的概念知識來擴展和引入新知識，然後設置一個針對問題的任務，讓他們思考如何進行，進而強化新知識的學習。我的習慣是畫圖，運用圖畫的方式來闡述概念，用盡量簡化細節的方式來引導產生共識，試圖讓聽者有一個初步的概念，然後在慢慢的把細節塞進圖示裡，來做為討論的細目。

建構主義教學法；正是由概念開始先避開細節的教導方式。然後在視該成員對這個知識了解的程度，也就是從更小、更簡單的概念中去構建逐步探討複雜的概念。當成員吸收了這種學習的方式後便可以這種結構化的方式自己繼續去學習。當對象是一群團隊的成員的話，更可以運用不同程度的提問，造成成員們之間進行討論，創造一個合作的環境。你無須一開始就以高度系統化的方式來傳授知識，而是要運用成員們已經知道的知識作為基礎，來傳遞你想教的內容。嘗試運用類比法(參考建立知識的聯結)是一種很有用的方法，可以讓成員在舊概念的基礎上構建對新概念的理解而獲取新的知識。

要成為一名稱職的Mentor，你的角色實際上是為成員設置有用的“障礙”，讓他們在消除障礙或解決問題的過程中學習到新知識，而不是直接告訴他們解答。學生學不精通的原因；往往是因為學生總是希望老師準確地告訴自己如何思考和理解某一概念，而不願意自己去構建對概念的理解。這便是學習的深度所在，也是知識能否長存記憶的基礎。

※如何把這個知識運用在解題上頭?

運用實作的模擬過程讓過程變得生動。這便是及時適當的提問所帶來的好處。我們可以藉由一系列由淺而深的問題，引導學員思考建立他自己的解題步驟。

※由協作中提高成員對知識的吸收力

讓團隊成員分組討論可以促進他們之間的協作能力，也能進而提升學習效果。(教導敏捷觀念時我們經常會分組討論，就是要藉由團隊成員的互動建立團隊共同協作的能力)。團隊中會間接出現成員之間彼此相互教學、相互學習的現象。讓團隊成員一起學習與解題是培養自組織的良方。

範例: 在網路上搜尋到一篇好文章，希望能夠深入閱讀並牢記內容時，運用布魯姆分類法來深化記憶。

小結

當學習自然發生時，它是漸進的，是發生在相互建立的小單元中的。因此，當你希望盡最大能力教學時，就需要找到能反映這種自然學習過程的方法，並在教學中運用它們。所以你需要考慮到學習者的認知負荷 (當你學習新知識時，大腦需要更多的認知能量，這就是認知負荷) 。而提高學習或教學效果的方法就是盡量減少認知負荷，即利用最少的認知能量獲得最多的知識。

試想一下，如果你要把一大堆石頭從這個地方搬到那個地方，而你只有一輛小手推車，那方法很明顯，就是慢慢搬，一次運一小堆。同理，你要對所學的內容進行處理，讓其更容易被大腦吸收。如果你讓學習者把複雜的事情分解成幾部分來做，就是在改變大腦必須處理的內容以減輕認知負荷。而不是一開始就看見整體的複雜結構。

布魯姆分類法指出，想要達到對專業知識的最高層級理解，你必須完成6個連續的層級。實際上，很多人都很難完成分類中的所有層級，只不過他們都意識不到這一點，所以不要讓自己也陷入這個誤區中。接下來，我們看一下該分類法包含的6個由低到高的理解層級，具體如下所示：

(一) 記憶 Remember: 是從長期記憶中提取相關知識。包括: 1.再認知。2.回憶。

(二) 理解 Understand: 從教學訊息中創造意義；建立所學新知識與舊經驗的連結。包括:1.詮釋。2.舉例。3.分類。4.摘要。5.推論。6.比較。7.解釋。

(三) 應用 Apply: 牽涉使用程序(步驟)來執行作業或解決問題，與程序知識緊密結合。包括：1.執行。2.實行。

(四) 分析Analyze: 牽涉分解材料成局部，指出局部之間與對整體結構的關聯。包括：1.辨別。2.組織。3.歸因。

(五) 評估 Evaluate: 根據準則(criteria)和標準(standards)作判斷。包括：1.檢查。2.評論。

(六) 創造 Create: 涉及將各個元素組裝在一起，形成一個完整且具功能的整體。包括：1.設計產生。2.計畫。3.製作。

從第一層開始，“記憶”是對先前學習過的知識材料的回憶，包括具體事實、基本概念、術語等(就是再認知、回憶)。第二層次“理解”指能夠把握知識材料的意義，可以通過三種形式來表明對知識材料的領會：一是轉化，即用自己的話或用與原先不同的方式表達自己的想法(請學員用30秒電梯演講的方式在站立會議時簡述自己學習的心得，然後在會後再給予意見，可以加深理解)；二是解釋，即對一項信息加以說明或概述；三是推斷，即預測發展的趨勢或後果。

第三層次“應用”是以記憶和理解為基礎，把先前學到的知識訊息遷移到新的情境中去解決一些實際問題。

》工程師若是沒有刻意做學習規劃(例如: 填寫學習工單或是進行簡報式的行為)，通常就只會學習到這個階段，它屬於實作階段，能順利產出解題的程式，但缺乏深入的分析、評估與創意。在這一層次；他僅是完成他的工作，而非成為了所謂的專家。

第四層次“分析”則是將學到的知識材料分解，明確各部分之間的相互關係。例如: 做規劃或製作文件報告的行為能提升辨識及組織的能力。也是工程師開始進入轉化學習隱性知識的開始點。(隱性知識指的是當事人的經驗、技能，除非當面問他，其他人都不容易知道的知識)

第五層次“評估”屬於較高層次的目標，要求通過鑑別和審辯，並基於一定的準則和標準對材料或訊息的價值做出判斷。

》工程師往往在專案開始時就被要求對工作進行估算或是評估專案要如何進行，它們依據的是自己過往的經驗，而不是針對這個專案知識訊息的評估，所以初期的估算只能當作參考，它可能隱藏著很大的誤差(請參考: 軟體估算: 黑夾子揭密、估算與風險)。

第六層次“創造”是對知識材料進行深度加工，將各部分要素重新整合後設計、產生出新的模式或結構，這是最高水平的認知學習結果。

》創意總是發生在習以為常的情境下。人生不會有重來的機會(迭代只是更多的機會)，開發專案也是如此，總會有不同的因素參雜進來，即便你已經做過好幾回的工作，它還是可能出現出乎你預料的事情。對於工程人員而言，創意往往就發生在企圖解決不可預期的現象，我們為了克服它而在解題的過程中產出了超過預期的設計(前提是我們已經提升到了這個層次)。

布魯姆以為；一旦你達到了“創造”的水準，就說明你對這個主題有了深刻的理解。然而，如果你做不到上一個層級，你就無法完全掌握下一層級。我們在生活中經常能看到，一個人對一個主題沒有做到充分的理解就試圖對其進行評估和判斷，那是因為他沒有遵循分類法。就好比你在下課後「問學員有問題嗎?」一樣，你可能再要求他們做評估和判斷，然後給你回答。所以結果就是沒問題，但其實背後都是問題，至於他們能夠走到哪裡呢?下圖便是這個問題的回答。

是單純地記憶知識點重要，還是培養思維品質更重要？

知識一旦進入長期記憶，就像肌肉記憶，一旦你學會了如何騎自行車，你就一輩子不會忘記如何騎車。再透過知識轉化就可以讓它再成長，成為更深入的知識，而專家便是這麼來的。而這也是DX設計師希望在專案開發後團隊成員能夠成為這個專案的領域專家，所做的設計努力。

至於學習者現在在哪一層呢? 就用提問的方式來確認。問該層的下一層應該有的認知問題就看出來了?

認知心理學

其實布盧姆分類學是以學習的心理過程為基礎的，這個過程很好概括：在理解一個概念之前，你必須先記住它；要應用一個概念，你必須先理解它；要評價一個過程，你必須先對其進行分析；要得出準確的結論，你必須先對它完成全面的評估。這個方法的挑戰在於反省和瞭解你目前處於這個分類法中的哪一層級，只有這樣，你才能確定接下來你須掌握什麼知識。

最後一個層級是創造又稱之為綜合層。在這一層級，你與資訊的關係非常重要——你要進行創造！寫作、作曲、拍攝電影、編寫劇本、角色扮演、利用已知事物來創造新事物等都是利用已知資訊構建新事物的創造性工作。層級與層級之間是會重疊的，因此，使用布魯姆分類法的重點不是要確定每一層的動詞。相反，這種分類法是一種工具，可以説明你處理的訊息，從不同的角度來審視資訊，就像你戴上不同顏色的眼鏡，在不同的光線下查看相同的資訊一樣。

布魯姆分類法是問問題的依據，他並沒有教你如何問租好問題，有疑問的話請參考: 參考如何問出好問題 -Question thinking.

註 1. 修訂版布魯姆的教育目標分類法先依知識維度和認知歷程維度，形成一個二維矩陣後，再進行教育目標的分析。

布魯姆分類法是由本傑明·布魯姆(Benjamin Bloom)於1956年創建的，並在2001年進行了改進，它是衡量大學生學業成績的一種方法。此後，它一直被學術機構用於製定課程框架，確保孩子能徹底地理解內容。我們在此處介紹它，是因為它可以作為一個逐步遞進的指導方針，說明開發者在學習過程中的6個層級，幫助你加深對內容的理解。

註 2. 彼得．霍林斯 Peter Hollins 心理學暢銷書作家

現居美國華盛頓州西雅圖。著有：《什麼都能教的最高教學法》、《最高自主學習法》、《停止拖延的情緒行為動力學》、《加速式‧子彈學習法則》、《幸運，你可以學會的能力》。

註3. 運用衡量來評估初學的工程師與專家之間的距離，請參考: 開發者體驗即學習 -一招三式。

工程師的簡單觀念

2022 年 11 月 25 日2022 年 12 月 08 日 ruddyllee發表留言

人們感受到的很多壓力並非源自於有太多事要做，而是源自他們做的事已經開了頭，卻沒有完成.

-《Get Thing Done》David Allen

我們都知道程式要寫得盡量的簡潔，完成相同功能的程式碼能越簡單越好；在這裡簡單就是美! 但我們也都知道要尋求簡單，實際上一點也不簡單，而且還有些困難。這裡我們把“簡單"定義成；更具有條理性，能夠按部就班依照清單上的順序，有條不紊地處理你的工作。就是"保持簡約，專注行動"。而不是專注在規劃或系統上。簡約就是要: 我們應該聚焦於簡化，儘量減少要做的事情，這樣你就能集中精力去做真正重要的事，並把它做好。

開發者的簡約；就是把開發設計的工作梳理得簡潔順暢，DX設計師不會幫你做這些事，你必須自己去完成。但其實；你只要養成一個習慣就可以了。這裡提供一個方法讓你做到簡約。他是我自己一直遵循的作法，提供你做參考。就是一次養成一個習慣，不要管書裏頭說的；甚麼五個原則十個習慣的，不要管他有幾個，我們只做一個，只懂一個就夠了，以下是我 追求簡單 的作法。數十年過去了，我依然如此，相信你也能因此有一個好的開始。

簡單總是只在開始時，大自然是複雜的，總會把我們帶到複雜的境界，想要徹頭徹尾的簡潔，還不如把一開始做好。

設計模式 Design pattern
模式可以幫我們應付程式的複雜性，要學會設計模式，只要要養成一個習慣，是的；只要死守一個原則就夠了，至少一個。它就是: 單一職責原則(Single Responsibility Principle)。它是《Clean code》作者 Robert C. Martin 所發明的 SOILD 原則裡的第一個原則，這裡我們只取一個而不是五個都要，那樣就太貪心了，而且你本來就應該一次只做一件事，然後把它做好就對了。

單一職責原則(Single Responsibility Principle)
定義: There should never be more than one reason for a class to change.
.
意思是；一個類別只能有一個改變的原因。
就是一個類別只負責一件事情這樣就不會產生相依性了。
.

做得好，就能減少程式碼的相依性了，這是未雨綢繆的程式設計方式，因為當程式越寫越多時，越來越複雜的程式碼光想就不敢去細看它了，哪敢再去更動呢?這時候你需要的是簡單；也就是做好單一職責原則。

具體上 SRP說: Separate the code that different actors depend on
意思是；分開不同角色所依賴的程式碼。

使用SRP原則的目的是；實現高內聚力，將不相關的程式碼移除，使得整體的程式碼中的每個部分都與自己實作的功能相關，沒有一個服務對多個角色的問題。

它能解決甚麼問題? 就是解相依性，當改變一段底層的程式碼，會影響到其他也相依到這個功能的程式碼時，解法是把他們區分成不同的 class 然後各自擁有自己的 interface 就解開相依性了。(缺點是功能類別被切得太細時，就可能會發生過度設計，而使得類別凌亂而難以歸類，提醒你了!)

Uncle Bob 說單一職責原則是關於函式和類別的，但它又以不同的形式出現在二個層次上，在元件層它成為內聚性規範的CCP原則(註1. the Common Closure Principle共同封閉原則)，在架構層它又負責建立架構邊界的變化軸(將程式碼的依賴關係從資料流裡解耦出來，並耦合到架構的層級上，這裡的層級；指的是策略與輸入及輸出的距離，定義是: 管理輸出與輸入的策略是系統中最低層級的策略)。

範例: 一個具有多種功能組合的產品，若是模組沒有切割好，當出現問題時就無法迅速釐清到底是哪裡出問題了(相依性太高)，必須集合各個功能的專家一同來做診斷。(典型的複雜系統所表現出來的行為模式，讓人聯想到康威定律)

程式碼雖然是可異動的，但還是希望「最少改動，最大收益」。

-DevOps

簡單有用的原則

Code review時的準則: 一個函式應該做一件，而且只做一件事(它不同於SRP原則但都符合簡單的原則)。我們在寫程式時，思慮充沛的程式設計人員，你禁得起這個誘惑嗎? 我們常常會想把解題的功能都放在同一支程式裡(至少把商業邏輯先做對了再來模組化也不遲，但你從來就不會記得要回來修正的)。心裡想的是將 MVC模組混在一起效能最佳，總之先解題在說，思緒也最完整，看程式時能一目了然，沒有隱藏、沒有邊界層的干擾，不用在模組之間切來換去。你可以這麼做，只是損失了可重用性，只是像在吃義大利麵時一樣，怎麼看都十分混亂。失去了一開始時擺盤的優雅又可口的外貌。更別談維護工作了。

每個卡關的人都應該先認真地自問：「我先做了哪一件事之後，其他事就會變得比較容易，或者不必做？」

– Gary Keller

聚焦能帶動後續改變的一件事，許多事會自動消失不用做！

電影《城市鄉巴佬》其中有一幕場景令人印象深刻：堅韌不拔的牛仔領隊老柯與城市鄉巴佬米契一起離開隊伍去尋找走失的牛群。儘管他倆平時衝突不斷，但在這次共同尋找走失牛群的過程中，他們對生命這個話題展開了一段平靜的對話。電影中，老柯勒停下馬兒面向米契。

老柯說:『你知道人生的秘密是什麼嗎？就是這個』 -說著，他伸出一隻手指。

米契不解地問: 『人生的秘密就是手指？』

老柯說: 『人生的秘密就是只做一件事，就一件。只做一件事，其他的事都不值一提。』

米契又問: 『那麼，這件事到底是什麼呢？』

老柯: 『你必須自己找到它。』

老柯告訴我們的人生的秘密，其實也是成功的秘訣。

廁所客觀的反思

這是”單一職責原則”字面上給我的最大聯想，獻給正在卡關的人，卡關；我的習慣是coding 時一直喝可樂(咖啡也行，那為什麼不喝水呢? 因為水的利尿效果太差，當然用蕃茄鐘也行，但不自然，時間到了它會提醒你你已經混戰很久了，該是客觀一下反思你到底在做甚麼的時候了!)，這樣可以造成頻繁的起身去上廁所，這時候我便有機會客觀地自問：「我先做了哪一件事之後，其他事就會變得比較容易，或者不必做了？」。

一直到學了看板方法之後，我才知道這叫限制理論(Theory of Constraints，TOC) ，在你想改善任何流程的時候，你應該先探索哪裡是最大的限制所在，然後先改善它，才不會落入短板理論的陷阱，或是先弄清楚他們的相依性，找到關鍵點，才不會掉入流程相依性的惡夢。

簡單就是一次做一件事，維持全貌清晰可見。

開發者最痛的二件事；一是程式寫不出來，又求助無門。另一個是，突如其來的Bug，完全看不出問題在哪裡，又沒人可以問。(其實；求人不如求己，學好做好設計模式，救人救己)

小結

SRP 有多棒呢! 它可以減少你未來開會的次數，讓你變得無比的簡潔。

程式的相互依賴性，是系統開發效能的一大致命傷，依據康威定律的積極推論結果: 軟體系統的最佳結構深深受到使用它的組織的社會結構所影響，因此，每個軟體模組只有唯一的一個理由需要改變。才能維持良好的系統架構(註2. 參考自《 Clean architecture 》 )。

當系統逐漸變大功能變多的時候，變得複雜的時候，相依性將是它異動效能的最大限制，我們會為了一個小小的修改動作而大動干戈的邀請所有相關部門的人來一起開會，為的就是怕修改會影響到他人，這是最大的浪費。但你可以改變它，就是在一開始就守住單一職責原則。無形中你就已經減少了你未來開會的次數了。

單一原則；一個就好，但不能都沒有。

你要有一套簡單的清單系統、你要有一套搜尋資料的技巧、要有人可以給你回饋、要養成時時反思改善自己已有的習慣 以及 要保持熱情。道理簡單但你必須去做，只有行動才能換來改善，光用想的是沒有用的。

一個例子: 想當年；在軍中輪到假日值班的時候，碰巧是女朋友23歲生日，沒能外出慶祝額外的思念，心中一直想做點甚麼來幫她慶生；讓她高興一下，結果就坐在值班櫃檯前寫了23封信去祝她生日快樂! 換來的是連郵差先生都受不了，要親自祝她生日快樂，這是四十多年前的往事了，現在老婆再想起來，依然回味無窮。這是具體行動的例子。生活或工作中有太多令人覺得不滿意的事了，你可能會有「想做點甚麼」的想法，那就花點心思去做吧! 即時的行動才不會有遺憾。

從這裡開始；為自己設計或找一套既簡單又隨時可用的清單系統，從這裡開始你的簡單之旅吧! 而且不要停下來。

把一件事情徹底搞懂，這是簡單化的第一原則。要先有複雜的理解，才能有簡單化的價值

– Edward de Bono.

( 這是由單一職責原則與簡單的思維所引發的聯想。)

註1. CCP 共同封閉原則 – Common Closure Principle

屬於內聚力原則，將那些會因相同理由、在相同時間發生變化的類別，收集到相同的元件之中，將那些在不同時間、因不同理由發生變化的類別，分割到不同的元件之中。

註2. from 《 Clean architecture 》第19章策略與層級.

工程師的自我學習

2022 年 11 月 22 日2022 年 12 月 12 日 ruddyllee3 則迴響

自學是一場獨角戲，是一場與自我鬥爭的苦戰。沒有外在的驅動力，只能靠內在精神、信念以及目標感來驅動。這份內在驅動是“做到”的真北，它不來自外化的術，而來自內心的道。

-高靜

工程師是在做中學習的知識工作者，
但這不表示靜態的學習對我們就沒有作用，
黃金學習比例是介於 3 : 7 之間。
為了把事情做得更好，要更重視學習。

生活即學習

這是杜威(John Dewey)先生留給世人的名言，意指『教育即生活，生長即成長』，所指的是教育思想，但是用來描述現代程式設計師的工作型態，也十分洽當。工程師一定是先學會開發領域的知識才能開始撰寫程式的。因此開發工作的第一個步驟便成了「自我學習」。而程式寫的好壞也直接的跟學習的好壞有關。本文的目的是提供給大家一種高效的自我學習方法。我參考的是斯科特·揚的「整體性學習」策略，它是一種有助於高效學習的策略，它不只是一種學習的方法而是策略。這是我挑選它來加強自我學習的一大原因。

做了40 幾年的工程師，我早已習慣自學；也有自己學習的方法，但為了DX 設計、為了協助工程師學得更有效率，我努力尋找能讓人提高效率的各種學習方法(這類的圖書還真是多啊! )，最終我放棄了尋找單一的方法而選擇了這個策略，它是由加拿大學霸 (這個時代表示很厲害的人物就稱之為”霸”，代表他很擅長於自我學習，而且能學得很厲害) 斯科特·揚 (Scott Young) 所著的《如何高效學習？》。然後我把自己的理解跟習慣加了進去(作者建議怎麼做的)，

請參考上圖；由左上角的「自我提問」開始，這是我進行自學的習慣，也就是用寄信給自己的方式來以問自己問題做起始(email 給自己)。這樣做的原因很多，其中一項是為了確定學習的方向(註 6. 確認問題)，另外就是記錄學習的過程，把學到的知識靠 email系統盡量地顯現出來，即便於搜尋又能避免遺忘。還有一項是敏捷化的重點；就是做「自我回饋」，這種回饋讓自己隨時隨地便於進行反思，又能加深記憶。這種迭代探索問題的方式，可以強迫自己在收到email 之後再思考一次，我這樣實踐十多年了受益良多，提供你參考(自己問自己問題是人生自我了解的第一步，練習提問更能促進自己與人交談的能力，百利而無害)。

因為它是策略；所以即便我有自己的學習方法，依然能夠透過它的觀點而頗有收穫。本文的目的是為了讓開發者有更好的學習體驗(DX)能夠工作得更為順暢，讓工程師在自我學習的運作上能夠更得心應手。

所謂的整體性學習 (Holistic learning)；就是從多方面多角度來看待知識。是一個能讓你更有效學習的策略，通過搭建自己腦子裡的資訊網路(知識體系)，將新吸收的知識與自己既有的認知進行關聯，那些相互關聯起來的知識能便夠使你真正做到對知識的理解，從而可以對知識達到真正的內化吸收的效果。斯科特·揚認為每個人最適合學習的方式不盡相同，因此才以提供策略的方式來教你學習，至於最適合你高效學習的方法，你可以參考此策略再自己去嘗試發掘它。

這是我最喜歡整體性學習的地方；就是從形成知識的概念談起:

整體性學習基於三種主要觀點：（1）結構（2）模型（3）高速公路

結構；就是一系列緊密聯繫的知識

結構就好像你思想中的一座城市，在城市中有很多建築物，建築物之間有道路相連，有些建築高大而且重要，與城市中的其他建築有上百條路相連，而其他一些無關緊要的建築，則只有少數泥濘的小道與外界相通。

模型；是簡化抽象化的結構

它是結構的快照，更為簡單和更易儲存。模型對於快速學習新概念至關重要。模型就像是結構的種子，是一座建築的地基和框架，是知識最核心的概念，在此基礎上將引伸出全部的知識。

高速公路；是結構與結構之間的聯繫

結構裡有很多路將建築連接在一起，擁有數百條城市內部的公路當然很有用，但是光有內部的路並不足以發揮具有整體性大腦的真實力量。因此，你需要的是城市之間的高速公路，即結構與結構之間的高速聯繫。

【對照到開發者】

》提問: 什麼是有經驗的工程師跟初學者之間最大差異?

結構: 有經驗的工程師能夠看見較完整的全貌；能夠系統化地看待問題。然後建立起予已有的知識與相關知識之間的聯結。

模型: 形成概念；善用更抽象化的描述來描述解題的步驟。也就是核心概念，通過將一些概念聯繫在一起，創建成一個模型。

高速公路: 在最簡潔不添加任何修飾的解題作法下，能夠更快的找到完成任務的最短路徑。使學習更富有彈性，而不是僵硬死板的學習。

斯科特·揚在書中說道；每個人都有最適合他自己的學習方式，而他所提的只是做為參考，讀者應該自己再去發掘，找出適合自己的學習步驟。所以上圖中的五個步驟加上第六個步驟的驗證步驟，這六個步驟也就沒有強制的順序性，僅僅是提供給大家做參考(詳細說明請參考: 開發者體驗一招三式)。

自我學習的技術 -從最弱的地方開始

有效的改善，首先要找出自己的弱項。有人擅長搜尋找資料、有人則心思細膩不易遺漏，為了加強自我學習的能力，你應該像運動選手一樣，先弄清楚自己的缺點在哪裡，是發球穩定性不佳呢? 還是不擅長接邊線球?，然後針對缺點進行改善，這才是最有效的改進方法，如果缺點是不擅長接邊線球，改進方法就很明顯了，你需要移動得更快，問題(目標)便成為如何訓練才能讓腳步更快速的移動。 (註1. 完整的說明請參考. 如何高效學習？第二部分高效學習的技術)這裡；我覺得可以用那六個執行步驟來做反思，問自己在哪裡最得心應手? 哪裡又最傷透腦筋? 寫下來(這是做好輸出output時，不能缺少的動作，你的反思就依據你所寫下的東西做決定。或是運用費曼的學習法(註2.) 快速的檢視一下自己的概念)。抽象化的看待這些技術，它們是比喻、內在化、基於流程的記事 和 畫圖表法。

設法將知識關聯起來，因為知識不是孤立的；所謂的關聯指的就是比喻和类比。也就是運用舉例的方式來建立自己腦子裡的資訊網路(知識體系)。比較有趣且需要注意的是關聯也會有錯誤與正確的區分。舉例來說；事情一開始我們可能一致認為是甲方的錯，但隨著各自發表的證詞，最後發展可能真正是乙方的錯。而我們應該記取的是不應該只聽取片面之詞就輕易地做判斷。聯想到產品的開發上頭；你可能會想到「以終為始」的思考方式，這種思維方式就比較不容易產生對產品認知的偏頗了。

整體性學習將觀點聯繫在一起，應用模型，建立結構以理解不同類型的知識。

–斯科特·揚

圖一的自我學習標題下有一行輸入與輸出的字眼。左側屬於輸入區塊的包含了: 獲取、理解與拓展。右側是: 拓展、修正與應用。其中「拓展」同時出現在二側，明顯的它是整體性學習中最花力氣的地方，這一步將形成模型、高速公路和廣泛的聯繫，從而獲得良好的結構(我一直把它看成是概念)。對於產品開發而言就好像雛形(protype)的製做一般，我們經過理解之後，試著抽象化(製作)忽略細節的雛型設計，因此拓展的步驟才是整體性學習的真正開始。

對自己的知識進行管理 最後，我們來到圖一的下半塊: 知識管理。這是落實自我學習的重要關卡。俗話說: 「學得快，忘得也快」，它是指倘若學習後又沒能夠跟生活經驗進行互動，這樣便很難維持長久的記憶。我們依據知識管理之父野中郁次郎先生的SECI理論(請參考知識的轉化)，也就是知識螺旋轉化模式來看自我學習。

【說明】

結合整體學習法的五個實踐步驟與自我成長的螺旋梯，運用輸出與輸入來區分自我學習的實務。輸入佔三分；透過聽與看的學習，例如: 參加研討會或經由媒體視頻作線上學習。當然也包含傳統的書籍、文件的閱讀。輸出佔七分；著名的費曼學習法(註 2.)正是所謂的教學相長，這也說明了能真正改變學習效果的是輸出(Output)。

輸入3分輸出7分是最高效學習的黃金比例(參考自樺澤紫苑的《最高效學習法》)。樺澤紫苑的自我成長螺旋梯正好與野中郁次郎先生的SECI理論相吻合(知識創造的過程需要經過隱性知識和顯性知識二者之間互相作用)，表明了知識必須在輸出與輸入之間逐步的昇華，知識也才會落實(野中郁次郎先生稱之為知識創造的螺旋)。

開發者體驗即學習，

但學習不僅僅是學習而是開發者實作後的體驗的總和。

結合開發流程與自我學習步驟

工程師當遇到自己不了解的需求時就應該提問，在我們開始提問之前應該要花時間先做一些功課，這時候就可以開立學習工單了，忠實的記錄下你花多少時間進行學習，讓學習的過程再開發流程中也能夠透明化。大抵上輸入(學習:讀、看)與輸出(實作解題: 說、寫)的比例宜為 3:7 (註4.)。過度的進行學習並不會明顯的獲利，反而會耽誤專案開發的時程，而且並不是所有的需求都要求我們從頭開始學起。已經有許多團隊知道要在專案開始時加強學習，這是對的，但大部分的人以為學習就是輸入，因此花了大部分的經費跟力氣做了開發作業的前置訓練。這是嚴重的誤解，因為工程師的學習方式大部分來自職級的開發作業，我們習慣在實作中換取經驗，也就是一邊工作一邊成長，因此我們不該將學習作業完全依賴於輸入上頭，反而應該加強「做中學」效果會更勝於單純的學習。

上圖中；獲取與理解二個步驟是屬於輸入的部分，宜占整個開發流程的三分之一，我們在這裡強調應該視需求的難易程度開立工作單進行透明化的學習(例如: 參加外部研習或實戰工作坊)。拓展步驟則位於輸入與輸出並存的階段，對照到的程式開發步驟，對學習而言是一邊做一邊進行學習最重要的階段，為工程師的可視化的產出。這時候持續驗證可能才是最重要的動作。因為你所學習到的知識不一定都是對的，你需要過濾掉錯誤的資訊(這正是DevOps的三步工作法裡的第三步嘗試錯誤(fail often，fail fast)的真諦，另外一層的意思是；它並非實質的犯錯而是因為吸收到錯誤資訊被誤導後，需要再進行修正的錯誤知識，這是工程師在犯錯時反而可以學到最多的理由，因為它糾正了錯誤的知識)。

接下來是學習的修正階段，程式做修正的時機點，可能是作Code review時的修正動作或是被測出Bug的時候不得不作的修改，這都是一種成本較高的回饋，如果能提前獲知對開發作業都可以提升效能或降低成本。怎麼提前呢? 就是自己先作閱讀檢核時能夠遵循團隊的程式規範與自己先作測試。這二者都依賴於你的自我察覺(awareness)能力，要提升它就是要在平常時就養成好的工作(coding)習慣。最後是應用階段，是把自己的功能服務發佈到團隊共同的程式碼中進行整合，這時候一些無形的需求與限制就可能自動浮現出來了，也是我們學習在團隊中進行共同開發時獲取的經驗所在。

其實是六個步驟

隱藏在五個學習步驟後面的是驗證(verify)，也就是對自己提問:『你怎麼知道你正在吸取的知識是對的呢?』。對學習而言；學得快固然重要，但正確性可能是更重要的一環，與其產生認知錯誤，還不如多花一點點時間來進行檢核。這是敏捷開發將流程設計成迭代方式的基本精神。

工程師自我學習的重要時期

小結

讓我們回到第一張圖，透過「自我提問」來啟動你的學習，我喜歡透過Email問自己一些問題，然後透過整理和過濾這些問題，來釐清哪一個問題才是你真正要面對的，然後排序一下，找錯了就換下一個。雖然還是你自己認為的(自以為是的一種假設，你還是可能會犯錯)。但我很喜歡用這種假設思維的模式來過濾資訊，因為即便錯了也能很快的重新再來(進行開放空間Open space時，就是要用這招，雖然花時間但效果好極了)。不僅如此；因為有了假設，你的搜尋就可以收斂許多，凡是跟假設無關的資訊大可忽略它，這是長期使用 Google 搜尋時所換來的心得(你可以觀察那些能夠很快google到問題的傢伙，他們都是懂得運用假說思維來過濾龐大訊息的人)。

收到自己 Email 的訊息，要回覆嗎?

當然要回，因為這便是「迭代」的精神。當你在不同的空間和時間裡遇到同樣的問題時，是重新進行搜尋分析，還是依據先前的認知進一步的探索，你便有了選項，可以作成假設進行驗證，這便是對知識進行了探索的一種反思方法。

怎麼樣高效的自我學習呢? 這一點只有「驗證」可以給你保證。也就是只有在你自我學習到的東西都是正確的、經過確認的事實時，排除了那些錯誤會誤導你走偏了的訊息後，讓到終點的路徑變短了自然效果就提升了。這一點；解釋了整體性學習為何刻意在學習的每個步驟中都加入驗證的原因。因為即便你能夠學習得比別人還快，但是方向若是錯了，學得再快都沒有用。

千萬別再說沒時間寫測試程式了，就是因為你沒有寫測試程式才會讓自己忙得去處裡各種Bug而失去時間的。

自我學習最怕的是沒有回饋

一個人帶著秘籍深入山林，在完全不受干擾的情境下習得絕世武功，這種矇著頭學東西的方式，在今日處處講求團隊協作的開發模式下早就已經不合實際。團隊圍坐在一起進行程式開發作業(運用網路的即時溝通方式也行)，大家一起學習、一起分享知識成果，其中最大的利益便是能夠獲得彼此回饋的好處。我們可以透過別人的回饋，很快跳脫一切自以為是的假設，釐清心中的疑惑，這也是敏捷的真諦(註 3.)

讓我們回到第一張圖中間的概念部分，斯科特·揚先生運用「結構、模組、高速公路」的比喻，抽象的說明了有經驗的工程師為何比初學者能更快更好的完成任務的原因。這是一種以終為始的觀點，他接著說明了我們可以使用的技術(比喻、內在化、基於流程的記事和畫圖表法)來增進我們的學習效果，這一段正好可以和樺澤紫苑所謂的成長的螺旋梯相結合，透過「輸入vs. 輸出」的思維方式來分析學習的過程，它引出了適合工程師在開發作業時的學習黃金比例: 三分輸入七分輸出。這一點正好修正了大部分人以為學習就是輸入的錯誤觀念。其實輸出才是落實學習的最大因素。

工程師在開發作業的流程中一向是忽略「學習」的項目，默默的吸收或跳過了輸出的部分。沒有透過進一步的可視化學習來彌補不足的開發知識，只是用習慣來預估開發所需要的時程，在沒有概念的清況下進行估算或Breakdown作業實在很不科學的，很可能讓自己一不小心就掉入了開發的煉獄。(至於要學到甚麼地步呢? 那就是要有"概念“，概念是一個良好的認知的開始)

在團隊開發中「學習」是彌足珍貴的一個項目，共同學習可以在各方面加強團隊的共同能力、團隊文化或是自組織的強化。當團隊對同一個物件有著不同的認知時，這才是開發作業上最危險的因素。所以請讓開發者的自我學習透明化，讓團隊有相互協助共同學習一起成長的機會，這才是團隊走向敏捷化的開發方式。最後讓我們來談一下心態至上的道理。

以學習為目標的開發方式 vs. 以完成工作為導向的開發方式

專案一定有開發時間的限制，達成目標的過程就是學習的過程，達成了目標也就達到了學習的效果。為了完成專案，你必須圍繞著目標努力學習，以專案為基礎的學習符合整體性學習的每一個過程。明顯的這是一種高效的學習方式。

若是工程抱持「以完成工作為導向的開發方式」時，學習將侷限於完成工作而已，就好比真的有一張考卷一般，學習者只要學會回答考卷上的題目就過關了，我們並不一定要對問題有著真正的理解，這麼作雖然輕鬆，但換來的是；考試結束後，答案為何很快就會忘得一乾二淨了。因此學習者的心態至為重要，他將決定你的學習深度，反之；當學習深度不足時，即便專案開發得很順利，累積下來的知識你也會很快地就遺忘掉了。

範例: 在網路上搜尋到一篇好文章，希望能夠深入閱讀並牢記內容時，運用布魯姆分類法來深化記憶。

註1.《如何高效學習？》第二部分高效學習的技術

在學習整體性學習概念時，一個很好的方法是把它比喻成下棋，首先你要瞭解下棋的基本規則和基本目標，書裏頭第一部分可以看作介紹了關於整體性學習的一整套規則和目標。一旦理解了下棋的基本規則，你就要開始進一步學習具體的策略和如何贏得比賽了。第二部分就是介紹學習的不同策略，內容都是作者個人使用中覺得非常有用的策略。

第二部分中陳列的技術如下：

A）獲取知識 1）快速閱讀 2）筆記流
B）聯繫觀點 1）比喻 2）內在化 3）圖表法
C）隨意資訊的處理 1）聯想法 2）掛鉤法 3）資訊壓縮技術
D）知識擴展 1）實際應用 2）模型糾錯 3）以項目為基礎的學習

常用的技術 : 比喻、內在化、圖表、流程圖

》比喻

比喻本是一種文學上的工具，用來將某個物體與其他物體聯繫在一起，而實際上二者並沒有實際的聯繫。比如說一名女性有沙漏一樣的身材，並不是說她的身體是玻璃的，黃沙從她曼妙的身體不停地往下流淌，這只是一個比喻，形容她的身材與沙漏的曲線一樣玲瓏。

故事中應用比喻可以把普通人的經驗與不尋常的體驗相聯繫，比如一個故事中的惡人約翰“有一張沙皮狗樣的臉”，讀到這樣的文字，你很容易在腦海中想像出約翰的那張臉。在這裡，比喻法就成功地借助沙皮狗（你曾有的體驗，相信你看過沙皮狗的模樣）告訴你約翰的模樣（你不曾有的體驗）。比喻法在整體性學習中扮演的角色是類似的，比喻就是在不熟悉的知識和熟悉的知識之間架起一座溝通的橋樑。比喻在文學中主要提供視覺上的相似，而在整體性學習中聯繫的是類似的過程：事件或者資訊的順序。

》內在化

你可能聽說過視覺化，就是在腦海中想像圖畫的過程。內在Scoutt創造的名詞，指不僅僅在腦海中出現圖像，而且有聲音、觸覺和情感等。一般說來，一幅圖就足夠了，但是能夠調動更多的感知與知識聯繫在一起，甚至與情感相連，得到的關聯一定比單一的圖像更強 (即所謂強聯繫)。

要內在化一個知識：最好的方法就是先簡單地在腦海中想像一幅圖像，如果知識本身就有圖像時最好，想像一束光進入你的雙眼，通過視網膜上的視杆細胞和視錐細胞，再通過視神經進入大腦的過程肯定比想像所謂的道德哲學要容易得多。

》圖表

圖表是內在化的簡化。創作圖表比想像一幅圖像花費的時間更多，但是操作起來更容易，而且可以用於非常抽象的觀點，抽象的觀點一般難以想像。學習時，圖表技術也可以很容易地和筆記流技術以及積極閱讀相結合。一幅圖表就是一幅將多個資訊壓縮在一起的圖畫，圖表最常見的形式是帶有數位資訊的圖表。散點圖可以將成百上千的資料點壓縮到一張圖中，流程圖技術可以把一系列複雜的內部作用關係和步驟繪製到一幅圖中，讓人容易看明白。

》流程圖

以圖表為基礎的流程圖適用於以下幾方面。·繪製一系列的步驟。·繪製歷史事件，創造分支將事件聯繫在一起，不僅通過事件之間的因果關係，而且根據事件的發生時間來建立聯繫。·繪製一個系統(例如函數在程式中怎樣執行)。流程圖的基礎是從一個簡單的元素開始，然後在這個成分及與之相聯繫的不同知識之間畫出聯繫箭頭，從最原始的觀點出發，逐步畫出其他相關的觀點來。

註2. 費曼學習法

費曼先生說：『如果你不能向其他人簡單地解釋一件事，那麼你就是還沒有真正弄懂它。』

費曼技巧的具體實踐：

第一步：選擇要學習的概念首先選好你打算深入理解的概念，拿一張空白紙，在最上方寫下概念的名稱。
第二步：設想你是老師，正在試圖教會一名新生這個知識點這一步你要假想自己費盡口舌讓一名毫無這方面知識的學生聽懂，並把你的解釋記錄下來。這一步至關重要，因為在自我解釋那些你理解或不理解的知識過程中，你會理解得更好，而原先不明白的地方也得以理清。
第三步：當你感到疑惑時，返回去吧每當你碰到難題感到疑惑時，別急著往下走，學習不是單行道，回過頭來，重新閱讀參考材料、聽講座或找老師解答，直到你覺得搞懂了為止，然後把解釋記到紙上。
第四步：簡單化和比喻；如果你的解釋很囉唆或者艱澀，盡量用簡單直白的語言重新表述它，或者找到一個恰當的比喻以更好地理解它。

費曼技巧對於自我測試、考察對知識點的理解程度，是一個很好的方法。他也解釋了為何有許多講師對獲取新的知識(新版本)都學得特別的快，原因是他們不只要自己懂，還要設法讓學員聽完後也能學會。

這是一個找到自己的認知盲點的好方法: 首先要選擇好一個概念，簡潔的把你的認知寫下來，檢視自己所寫下來的東西，最後試著提出比喻，用其他方式來形容這個概念。這種提出類比的方式可以很快地看到你的盲點，屢試不爽。

註 3. 實行敏捷的團隊經常掛在嘴邊的一句話: 『敏捷少了回饋就不是敏捷了』。

註 4. 3:7 的學習輸入/輸出的黃金比例。參考自樺澤紫苑的暢銷書《OUTPUT最高學以致用法》輸出的基本法則三.(p28)

黃金比例值約 0.618在國外稱為中外比、中末比、黃金比、黃金率、黃金數字，古代中國稱為「弦分割」。(Mario Livio 一書中的黃金比例是大：小約為 1.618)

註 5. 積極閱讀法

積極閱讀不是一種快速的閱讀方法。它強調深入地理解材料，所以自然降低了閱讀速度。積極閱讀不僅僅是簡單地在書上畫各種顏色的記號和在空白處寫一寫心得體會，還是將知識點真正地整合在一起。

開始積極閱讀時，準備好要讀的書和筆記本，在筆記本上寫下每章的標題和亞標題，每讀完一小部分時(指讀法；指頭指向閱讀)，在筆記本上記一些筆記。進行積極閱讀時你需要記下：

（1）這一節中主要觀點是什麼？

（2）我怎樣才能記住主要觀點？

（3）我要怎樣將主要觀點拓展開以及應用它。

第一個問題僅僅促使你完整地獲取資訊；第二個問題迫使你對資訊進行聯繫、視覺化和比喻法；第三個問題要求你將資訊應用在不同的情境中。

這三個問題迫使你將每個知識點都要經過整體性學習裡的理解、拓展和應用三個階段。

註 6. 確認問題，找錯方向就白找了，會浪費掉許多時間，所以先用這個方法確認一下。

將問題寫下來在主詞與述詞下畫線做區分，然後改變主詞、述詞的先後位置，讓問句產生各個方向的意義，把他們 listing 出來之後，再進行排序，挑選最上面的一個作為探討的開始。

API First 的策略與架構

2022 年 11 月 14 日2022 年 12 月 01 日 ruddyllee發表留言

在開發團隊裡聽到有人在討論 API …
在業務部門裡聽到有人在談何時會有 API …
在客服團隊裡聽到有人在跟客戶談如何使用 API …
在捷運上聽到有人在談 API …
在公車上裡聽到有人在談 API …
在大眾媒體上聽到有人在談 API First …
…

那一瞬間，很難描述當下的感覺，開始時；是懷疑他們知道自己在談的東西嗎? 懂得API是怎麼回事嗎?

慢慢的；才意識到他們是在談論如何解決眼前的問題。

API First 是一種策略還是架構呢?

對經營者而言它是一種策略，對開發者而言是一種架構，整體而言它其實是一種變革。這場變革我們應該專注的目標是甚麼? 全員的共識又應該是甚麼呢?

【說明】

左側；將API First視同是一種策略，意圖在最大發揮API的經濟效益，我們姑且稱他為API經濟，一般是公司上層的決策者的issue，目的在解決跨公司、跨領域穿越邊界並即時協作上的問題。

右側；將API First視同是一種架構上的改變，意圖在改善增進開發與維運的效能，一般為架構師與開發部門的issue，目的是解決系統越來越複雜所造成的效能問題。

二者的交集是為何? 將決定著這場改革的成效。數據顯示(註 1. 開發者市場) 開發者體驗將是我們做好 API First 的核心關鍵。

可以解題的就是良方

趨勢就是這樣造成的，老闆們居於策略的考量想運用 API來解決跨邊界協作的問題，因為這個世界到處都要求協作，你已經不能再在封閉的空間裡運作了，無論是 Amazon.com 或 Netflix 等技術先驅，都在運用並提供 API給外部提供新服務並在內部提高效率。就如同 91app 所推行的OMO(Offline Merge Online，註6.)一樣，線上需要線下，線下也需要線上，網路讓門市在實質上跨出空間的限制了。另一方面；架構師則居於架構的考量，想運用 API的模組化性能來解決系統過度複雜的問題。如上圖所示，二方面都有自己的考量，只是不曉得他們的交集是否能夠對應得上? 是否擁有有共同的目標和願景? 這正是本文想要探討的。

什麼是API First？

API First開發是一種開發模型，其中通過組合的API功能，提供內部或外部服務來概念化和建構應用程序。所謂的API First公司則是指那些採用 API First開發模式的組織或企業。

API正快速的增長

在市場上；跨界的API增長反映了一個新的現實：技術用戶需要跨越多個設備的體驗。他們希望他們的數據和服務能夠跨平台、即時可用和共享(尤其是電子支付，更像是多管道、貨幣的多元化)。這意味著每個企業實際上都是軟體企業，無論是服務外部客戶還是內部員工(請參考貝佐斯頒布的那道「API 授權」備忘錄)。而在開發部門裡；微服務、Less code甚至No code，掀起了內部的整合與模組化的要求，模組與模組之間紛紛開始制定API呼叫的風潮。而原本我們所熟悉的API(Application Program Interface) 早已不是程式庫(library)、元件(Component)…這類單純作為程式模組化的實作介面了。幾十年來，它們作為一種讓不同的軟體應用程式之間相互通信的手段。而今天雖然仍然扮演著這個角色，但不僅僅跨越電腦、手機和智能設備相互連接，同時它們在市場上支援著各種服務的相互連接，居於後台負責連線與資料傳輸的重任而無形地工作著。這也意味著開發者將體驗空前的跨界與網路多元化、多目標的連線模式。

在上一個十年裡，UX設計師成功的將原本將會是越來越厚的一疊疊的輔助說明文件變消失了，任何產品在使用設計上都應該讓使用者直覺的就能完成最基本的操作，而不需要再去翻閱輔助說明。口號則是以使用者為導向，任何產品都應該追求讓使用者順利的完成基本任務為設計的目的，而成功的產品一定是擁有最佳使用者體驗的產品。

依據埃文斯資料公司(Evans Data Corporation) 的開發者體驗報告，目前的趨勢將導向為開發者導向的市場(developer Market)趨勢，該公司2019 最新統計的資料顯示2018年全球共有2300萬軟體發展人員，預計到2023年底這個數字將達到2770萬。(註 1.)而這群人將是電子產品或是手機上應用軟體App的最大購買者。所以；未來最具潛力的使用者將是軟體開發者。這也讓開發者體驗(DX, Developer experience)成為實施 API first 的成功基礎。

API first 是企業的核心肌群

API對企業的重要性就好比「核心肌群」對人體運作的重要性一般(註 3. 核心肌群)。核心肌群能有效地藉由動力鏈傳遞力量到四肢，讓人體可以做出更順暢、更有爆發力的動作，如果核心不穩的話，就像站在一個浮板上要你全力丟球，在站不穩的情況下，力量根本使出不來。訓練核心肌群也可以矯正身體多處的疼痛，並且降低運動的傷害，提升訓練的功效！企業推廣API First 也是如此，它能健全組織的各種運作模式，使得企業不論是對內或是對外都有著一致的開發模式，因而健全了組織的運作。

隨著雲端運算的大量使用，加上大數據與機器學習的興起，網路越來越和實體的經濟結合，這些商業模式的變革，加速了API的發展。進而促成了所謂的API經濟的誕生(它是指企業通過API建立合作關係而產生的經濟活動，註4)。

企業不斷的強化自身核心競爭力，希望能夠服務更多的使用者，將所有的服務通過API銜接給合作夥伴、APP開發者、智慧設備生產廠商，實現資料、服務的有限開放，從而服務更多的業務場景，快速形成一個龐大產業鏈。這一點可以使得企業在不改變現有生產模式的情況下滿足使用者碎片化且日益膨脹的需求。這也是造成這股API first 風潮最吸引人的地方。

談產品開發要以使用者為導向；也就是UX至上，談API first 就必須以開發者為導向，也就是開發者體驗( DX) 至上。

甚麼樣的API是好的API

這是設計API時的挑戰，好的API讓開發者能夠迅速地學會如何有效率的使用它所提供的服務，除了傳統對API的要求(範例、注意事項)之外，更大的要求是如何有效率的使用這些服務。

甚麼是好的開發者體驗?

好的產品就是客戶買回去，能夠順利的解決它的問題。而好的開發者體驗就是開發者在呼叫它時能夠得到正確和品質良好的服務，並藉此而能夠順暢的完成組織團對所賦予他的任務。

概念的價值，
就在於它提供了一個可預測事情進行的理解方式，以及當不按計畫進行時，
要如何來排除障礙.

-Design Pattern

共同的藍圖與可視化開發

API First 的變革，不同於敏捷變革，它可以明確地擁有共同的藍圖來顯示改變的方向、願景與時程。有了明確的時程做依規，可視化的建構流程便可以如同敏捷Sprint 開發一般的協助雙方調整各自的腳步來配合整個生態系統。但API First 與傳統開發大不相同，它完全建立在共同開發的跨團隊協作上，因此開發領域要大上許多，它需要擁有像 SCRUM的每日站立會議來協助大家的同步作業並分享心得。它需要以需求來驅動，因此更需要採用像使用者故事地圖(use story mapping)這類需求的藍圖來協助大家同步。而開發者則要由熟悉的自我學習的方式轉變到較頻繁溝通、分享的團隊學習歷程，而這也正是實踐DX所需要肩負的責任。上圖中；以雲端的方式來描繪藍圖，實質上它是API First 規劃策略藍圖時最有趣的地方，也就是你可把企業想要開放的功能服務，都視成是位在雲端上的獨立 Services，當然前提是要將安全做好、做足了。

小結

API經濟帶來了許多新的商業模式，可以輔助企業以低成本快速回應市場需求，建立企業生態，促使跨產業鏈的企業能力整合，產生創新出新的經濟形式。但相對的；由於使用你的API 的對象變得寬廣，使用者數量激增，而不同用戶又有著不同的需求，這會造成我們的API用戶與當初設計者不盡相同，反而會，帶來巨大的開發改變和維護的工作量，這是API 開發上潛在的隱憂。

API技術上的隱憂 -改版的漣漪

API也要做相對應的更新，API是有生命週期的。而我們的使用者都是使用系統或軟體再調用我們的API的間接使用者，API的更新需要使用者跟著做相應的改動，而每一次更新對用戶來說都是一種傷害，我們稱它為改版的漣漪。解決之道；對內部呼叫而言，過去是大喊一聲要大家來開會，在會議中詳細的說明即將異動到的地方，麻煩大家回去再檢查看看是否有影響，有問題的再排schedule 來配合。這是跨部門之間一種極端勞民傷財的協作方式。在實施API First的期間，應該設法將這類的偶發協作改成定期服務的形式(將協作變成服務化，以降低溝通的成本)，成本將會低得多了。對外部呼叫而言，我們需要做好原有的API版本控管(註5. Version control)或相關版本說明(例如 Visual Studio 版本及可配合的 .Net Framework 版本)。類似大型軟的預作宣告(例如: version XX將在2019年停止服務 )，這種現象也將會越來越為普遍。重要協力廠商則需增加異動前期預告的推播通知。

實施 API First 在初期，能夠體驗到效能的相對提升是一件令人欣慰的事，但在相依性越來越高的系統中(生態圈中)，要發佈一個新版本(套件)可能很快就會變為一場惡夢了。如果相依性關係過高，可能面臨版本控制被鎖死的風險(必須對每一個相依套件改版才能完成某次可以成功的升級)。而如果相依性關係過於鬆散，又將無法避免版本的混亂(假設相容於未來的多個版本已超出了合理的數量時)。當你專案的進展因為版本相依性被鎖死或版本混亂變得不夠簡便和可靠時，就意味著你正處於相依性地獄之中，唯有能夠隨時的關注開發者的體驗才能在順暢的開發中順暢的相處著。

API策略上的隱憂

不是每家公司都想成為一家軟體公司的。API 的增長反映了一個新的現實：技術用戶需要跨多個設備的體驗。他們希望他們的數據和服務能夠跨平台而且要即時可用並能夠穩定的共享。這意味著每家企業都必須擁有這些軟體公司才擁有的能耐，才足以存活在這樣的生態圈裡，無論是服務外部客戶還是內部員工。

開發者體驗(developer experience, DX) 是API First 實施成敗的核心，過去身為程式設計人員我們常常會遇到一些API 荒唐的連自己的demo 程式都不會通過(demo 程式不work)，我們總會嗤之以鼻，懷疑該公司到底有沒有在做測試，但在API First 的時代下，我們應該做的是立即反應給該單位，你的 API 出狀況了，要做好回饋並要要求即時的修正，設法讓損失降到最低。因為大家都處於一個共同的生態圈下，損失也是共同的。

即時回饋是做好DX的決條件，不論是內部或是外部的服務，我們需要即時的回饋來使損失減少到最小。這一點；就像工廠裡的自動化生產線一般，我們需要及時監控來保證服務的正常化。避免這種無知的浩劫，需要隨時蒐集數據與進行判斷的IOT(物聯網Internet of Things 是指連接著各種裝置的集體網路和幫助裝置與雲端和裝置之間互相通訊的技術)的觀念都是做好 API First 不可或缺的一環。

讓 Code Review 成為最重要的一環

程式碼審核(Code Review)是既花時間又花人力的工作，但對於 API First 的開發團隊而言它的重要性更是不能取代。傳統的 code review 多以程式的正確性與可讀性為主。但在這裡審核者又多了一個身分，就是扮演使用者的身分，所以簡單好用又順暢成了另一項要求，反之；它可能是讓撰寫程式的開發人員學到最多的地方(提前取得回饋)，因此盡可能維持小更改的開發模式，就變得更為重要(註 8.Google 的 code review)。

註 1. 有關埃文斯資料公司(Evans Data Corporation)，的數據調查結果。

註 2. Postman是一個API平台，供開發人員設計、構建、測試和迭代其API。截至2022年4月，Postman報告擁有超過2000萬註冊用戶和75,000個開放API，據稱這是世界上最大的公共API中心。該公司總部位於舊金山，並在其成立地印度邦加羅爾設有辦事處。

註3. 核心肌群

沒有一個時代像這個時代一樣，年輕人如此的愛好健身，這一點從處處林立的廣告，那些健美的健身教練招呼你趕緊來健身的誘惑，就可以看得出來了。要健身最基礎的鍛鍊便是鍛練核心肌群了，它不是單純只有肚子區間的肌肉，較為正確的定義，凡是能穩定軀幹、負責保護脊椎提供脊椎足夠的支撐力的肌群，都稱之為核心肌群。它的主要功能是能有效地藉由動力鍊傳遞力量到四肢，讓你能做出更順暢、更有爆發力的動作，如果核心不穩的話，就像站在一個浮板上要你全力丟球，在站不穩的情況下，力量根本使出不來。訓練核心肌群也可以矯正身體多處的疼痛，並且降低運動的傷害，提升訓練的功效！相同的觀念隱喻企業組織的支持與動力來源。

註4. API經濟

是指企業通過API建立合作關係而產生的經濟活動。過去這項活動往往需要建立在企業與企業的互信上面，但這已經不再是一個單純的概念了，很多企業已經運用在商業活動之中，通過API呼叫粘合更多合作夥伴，擴充企業服務場景，促進企業的轉型和升級，甚至重構整個行業的商業價值鏈。

註5. 版本格式規範(六碼)：主版號.次版號.修訂號，版號遞增規則如下：

例如: Microsoft Visual Studio Community 2019，版本 16.11.4

主版號：當你做了不相容的 API 修改，即16
次版號：當你做了向下相容的新增功能，即11
修訂號：當你做了向下相容的問題修正。(即4)

先行版號及版本編譯資訊可以加到「主版號.次版號.修訂號」的後面，作為延伸。細節請參考: 語意化版本 2.0.0

註 6. 91App 由 OMO 進階到創造消費虛實融合D2C帶動零售轉型浪潮

註 7. API As A product 將開發API 視同是開發產品一般，旨在描述開發API 不是一勞永逸的。API 是需要維護和改進的關鍵構建模塊。公司應該要正視並意識到這一點並建立團隊來支持並長期的維運它。

註 8. Google 的 code review

參考《Software engineer ar Google》的說明: Write Small Changes 寫出小的更改

要保持程式碼審查過程的靈活性，最重要的做法可能是保持小的更改。理想情況下，程式碼審查應該是容易理解的，並且對審查者和作者來說，都是集中在一個問題上。谷歌的程式碼審查過程不鼓勵由完全成型的專案組成的大規模修改，審查員可以理所當然地拒絕這樣的更改，因為它對於一次審查來說太大。較小的改動也可以防止工程師浪費時間等待對較大變更的審查，減少停滯時間。這些小更改在軟體開發過程中也有好處。如果一個特定的變更足夠小，那麼確定該變更中的錯誤來源就容易得多。

儘管如此，必須承認，依賴於小更改的程式碼審查過程有時很難與主要新特性的引入相協調。一組小的、漸進式的程式碼修改可能更容易單獨消化，但在一個更大的方案中卻更難理解。不可否認，Google的一些工程師並不喜歡小改動。存在管理這種程式碼變化的技術（在整合分支上開發，使用不同於HEAD的diff base管理變化），但這些技術不可避免地涉及更多的開銷。考慮到對小改動的優化只是一個優化，並允許你的過程適應偶爾的大更改。

“小”改動一般應限制在200行左右的程式碼。一個小的更改應該對審查者來說是容易的，而且，幾乎同樣重要的是，不要太麻煩，以至於更多的更改被延遲，以等待廣泛的審查。

開發者體驗即學習

2022 年 11 月 08 日2023 年 01 月 03 日 ruddyllee2 則迴響

當開發者學習得越順暢，開發者體驗就會越順暢。

也就是說；我們應該對開發團隊的學習過程進行設計，讓他們能盡快學會、學好開發的相關技能，讓他們有能力克服難關，進而加快開發效能。

– 開發者體驗即學習

如何提升開發者體驗

前言

2019年底，我在無意間踏入了探索開發者體驗的旅程，找不到書本在談開發者體驗(DX, developer experience)的，只好四處尋找相關的文章、網站資料。這段期間；發現了一個網站就叫 DX Hero (https://www.dxheroes.io/)該公司是一個開發適合開發者平台的產品為主的公司，名符其實是為了developer 著想。還有一家作工具的廠商就叫DX (https://getdx.com/) 它致力於開發使開發者表現出最好一面( Empowering developers to do their best work)的開發工具。這二家公司在網站上也都有提到他們心中對「開發者體驗」 Developer experience 的定義。另外；在學術論文方面，我所找到最早的一篇是來自赫爾辛基大學二位教授的文章，標題是: Developer Experience: Concept and Definition 由Fabian Fagerholm與 Jürgen Münch 共同完成，是一篇會議論文(Conference Paper，註1.)出版日期是June 2012. 文章裡從認知、情感與感知三個面向來探討DX。算是比較學術性的探討。

如何做好開發者體驗

老師:『我想嘗試為團隊進行開發者體驗，要從哪裡開始呢?』這是經過這幾年為了推廣DX所做的許多演講，會後收到最多的提問。我每次的回答事後都帶給自己深刻的反省，因為每回我的回答都不盡相同，連我自己都不滿意了，學員又怎能受惠呢?(註5. 有關DX的演講)不急；下面的一招三式就是持續反省後的成果。

持續思考同一個議題超過數年，對我而言是一件比較少的經驗，因為身為專業的講師，一直有各種演講邀約，必須經常依照主辦單位的宗旨來調整議題，因此一直繞著同一個主題作研究是不太可能的(註5. 還是連著講了好幾年)。但是一直到今天我仍然沉浸在這種狂熱的追尋中，原因是我已經做了一輩子的工程師了，深深知道開發者遇到難題時的痛苦(雖然我的孩子們已經度過這段歲月了，不能再拿他們作藉口了)，但為了未來即將踏入這個領域的工程師，我仍想把自己的一點理念貢獻出來，希望對工程師或是他們的公司能夠有所幫助。

努力了四年；有一天突然被一句話所喚醒，就是『開發者總是自我學習的』，只要知道專案要作些什麼，我們就會想儘各種方法、到處去找資料幫自己惡補，祈禱自己能盡快進入狀況，盡快學會如何開發，盡快開始開發作業，並能如期完成。既然如此，為什麼我們不能刻意的為開發者來設計這段學習的旅程呢，給他們各種協助，讓他們能夠更快更好的度過這段開發的旅程呢。(我的自我學習)

下面是蒐集來的成果，沒有一樣是我獨創的，都是來自古老的議題: “如何做好學習" 的經驗收集。為了便於記憶我把它取名為一招三式，希望未來能夠持續有第二、第三招來獻給大家。

【一招三式】

第一招開發者體驗即學習 : 要求正面去看待學習，工程師不是什麼都會的(老闆總是這麼想，只要會寫程式就行了)，我們也需要學習只是我們背後的學習你看不見罷了。開發者需要時間去學習開發工作的專業知識。要正視它；就是把學習的時間也納入專案開發的流程，希望的是工程師要先有概念以後才去做估算、Break down to task，不是還沒弄清楚就按習慣進行盲目的猜測，因此要先學習。要敏捷化；就是逐步的學習、開發然後驗證。也就是落實敏捷開發所謂的: 小增量、多迭代與尋求回饋。

把開發作業視同學習，我們就能在很多地方借助增強學習的方法來協助開發者，畢竟學習是一個最古老的議題，也擁有最多的方法及資源可供參考。

• 第一式差距彌補法：思考開發者如何由初學者進階到專家的差距彌補方法，它是由 Julie Dirksen 所著的經典教學設計《怎樣有效學習》的六個學習差距裡找到的，開發者需要得到協助，從明確的認識自己的差距開始，到有效的補足這段差距，以便能夠順利進行開發作業(請參考: 開發者體驗即學習與解題 -學習篇)。

• 第二式自學的六個階段 : 基於工程師總是在進行自我學習，但是；誰又知道你是否是順利或是遭遇到空前的困難，我參考了 斯科特.楊 的 「整體性學習裡論」來協助我們進行自我學習時不會誤踩雷區的做法 (註 3. 參考實行整體性學習 Holistic Learning)

• 第三式習慣性拒絕 : 這一式是為了克服由自我學習走到團隊學習的障礙，克服習慣性防衛 (defensive reasoning)，一種自以為是的不良思維所做的提醒，你一定會有這種思維但你一定可以更 open mind 一點，避開這種思維，也就是擁有所謂的「綠燈思維」。(註6. 綠燈思維 )

協助工程師逐步的學習

基於工程師進行開發作業的程序，一定是先學會開發領域的專業知識後，才可能就學到的知識進行程式撰寫的工作。這個過程是逐步深入的，它就像敏捷開發的衝刺(Sprint)週期一般，我們一邊進行學習一邊進行開發作業，逐步的對專案的知識領域有著更深入的了解。因此；學習的成果越好自然就更有機會開發出更好的產品或功能。

讓自我學習變得更有效率

軟體工程師，大部分的技術都是自學的，所謂的學習；從我們聽到專案大概要做甚麼的時候，就開始上網蒐集資訊了，運氣好時；當這個主題很熱門的時候，一下子就可以找到好多可以參考的資料，這對開發任務而言真是大有幫助，也讓人信心大增，可謂為是一個好的開始。當運氣不好的時候；幾乎很難找到任何可以參考的資料，這個時候就慘了，趕緊思考一下如何求救、有誰可以幫得上忙的。老實說；我們很少由書本上去找答案，這樣學東西太慢了，即便每周都要上書店去晃個一、二回，這種閒逛通常是看些有趣的東西罷了，解題；要從書本上開始，太慢了，想想還真的有一點懷念學生時期，那種書中一定有解答的日子。這是工程師解題時，知其然而不知其所以然的原因，我們總認為自己沒有時間去探索書上的基礎原理，等有空時再去參考吧，然後就沒有實際上去深究過，因此學習的深度就不足，而就很難把它放入長期的記憶，因此遺忘的也就特別快了。

工程師學習的越順暢，開發作業上也就會越順暢。因此我把它稱為「開法者體驗即學習」。這一點；與使用者接觸到產品時的第一個動作是相似的，使用者會立即進入學習的模式，當它能越快學好如何使用我們的產品時，它的體驗自然就會越順暢，而這是好的 UX 設計所必須克服的第一要務。再回來看看 DX 的設計也是如此，開發者變成了使用者，這時候開發者所面臨的是各種程式的介面(Lib、Component..、或是 API)，他必須盡快的學會如何呼叫它、使用它，才可能夠繼而來完成他自己的開發工作。

開發者體驗即學習

當開發者學習得越順暢，開發者體驗就會越順暢。開發者必須在專案開始之初，迅速學會與完成任務必要的專業知識，而且只有在他學會了以後才可能做好他的工作。這個過程是自然而然的敏捷的，也就是開發工作是在一邊學習之下一邊完成的，而不是一次完整的學會了才開始開發工作的。這也說明了需求的安排是否能夠由淺而深的經過刻意的設計，會最有利於工程師的學習，這一點與學校裡的老師努力的製作教具與塑造學習環境，道理是相通的。想要協助工程師學習，所以我們要刻意的針對學習的目標，去設計學習的路徑。

功能要開發的好，工程師必須由一位初學者的位置，上升到迅速成為某個領域的專家，然後再把它套用到程式的功能邏輯上頭，並驗證這個功能符合使用者的要求，而這個使用者通常是指的是另一位開發者，就是這個原因讓我們經常把開發者體驗看成是使用 API 時的體驗。但這無疑的是開發者體驗的一種較為狹義的定義，如果我們把整個開發的生命週期都放進來，則廣義的定義應該是泛指開發者在開發的過程中的所有體驗(註 2. 開發者體驗的定義)。

團隊的學習過程

由於近代的開發作業幾乎都是團隊共同協作的成果，很少再有一個人矇著頭進行開發就能完成的工作了。我們經常是承接別人的功能與服務然後在傳遞給他人，扮演著團隊中繼者的角色。因此將團隊協作可視化可能是團隊學習再經典不過了，是團隊開發不能忽略的一環。因此在上圖中我把學習的過程描述成可視化學習，因為工程師面對問題時，你的難題對團隊其他成員而言，可能就不是難題。把解題的過程描述成可視化的思考，讓團隊能夠共同面對問題可視化是必要的第一步。

將開發過程視成為一種旅程，

好處是我們可以幫他們準備在旅程中所需要的各種配備，並教會他們如何正確而有效率的使用它，讓這段旅程變得更為順暢。

我們可以直接詢問開發者他們的困擾在哪裡? 然後設法幫他們解決困擾。這是一個必要的步驟，但就像進行 UX 設計時一樣，使用者並不一定知道他真正要的需求是甚麼? 所以這裡；我透過自我提問的方式來解題。

【問題】

※我們由三個問題做出發，來思考如何讓開發者能夠順暢的完成工作:

如何經由DX的設計，使工程師能夠快速的由初學者提升到專家的水準?
如何能夠讓開發者高效的學習?
如何消除影響學習的障礙?

( 第一式差距彌補法 )

》由初學者到成為專家

為了讓開發者能夠快速學習，我們需要像補習班一樣，透過(教材、教具)良好的設計，來幫學習者適應新的或需要改進的學習體驗，讓學習者可以與實務同步，幫助他們學會只做真正需要做的事情。也就是把學習視同是一段旅程，然後透過設計一條學習的路線，讓學習者從一個新手快速成長為專家，並避開那些無謂的工作。

首先；學習如果視同是一段旅程的話，起點到終點之間的差距就是我們所要規劃的範圍了。而我們要教學習者的就是識別差距並跨越差距了。

這裡參考Julie Dirksen所著的經典教學設計《怎樣有效學習》的六個學習差距作為DX設計分析的主要項目，當然在開發團隊中每個人有著不同的任務要克服，因此就會有著不同的學習路徑需要去克服。除此之外不同的開發者也會隨著個人的工作年資與個性而需要不同的設計。

首先要消除干擾

我們總以為事情沒做好是缺乏專業知識所造成，也就是「表現=能力+知識」。但其實表現的最大障礙不是不知道要做什麼，而是不作我們知道的事。讓我們修正一下上面的公式成為「表現 = 能力 – 干擾」。這裡的干擾指的是包含廣泛的非主要性的工作，就是吃掉開發者正常工時的其他次要工作，這些非主要性的工作佔據工作者大部分的工時，讓開發者反而沒有足夠的工作時間。這一點就如同 DevOps 首部曲《鳳凰項目》書裡頭的布倫特先生一樣，他是項目的主要負責人，但在日常的工作中去不斷的在幫助他人解決問題或接受電話的干擾回答各種問題，這是造成項目進度不佳的主要原因，因為它沒有時間做自己的開發工作。所以我們再進一步了解團隊成員的學習差距之前需要先克服的一點。

你覺得自己一天應該只開幾次會議，才能夠擁有足夠的開發時間?

如何跨越這六個差距

衡量；每個人的學習起點不同，因此面臨的差距也不一樣，有的人缺少的是某方面的知識和信息，有的人則是缺少在工具使用上的操作技能，有的人是會做但缺少動力，有的人是想作而缺乏良好的開發環境，還有的人是不擅於與人協作，也就是溝通能力不足。因此如圖一(評估開發者由初學者到成為專家的差距)

右側的雷達圖所示是透過訪談所得，我們應該先識別每個開發者，他的最大差距是甚麼，才好對症下藥，做法是提出問題；透過提問來判斷開發者要完成任務的雷達屬性圖示。

知識

學習者達到成功前需要什麼樣的信息？(缺少的知識)
學習旅程中學習者需要什麼？(需要什麼樣的支援)
對於學習者何種方式的支持將會是最好的？(需要甚麼樣的知識協助)

技能

什麼將是學習者需要練習以達到熟悉掌握的？(掌握開發流程的技能)
學習者實踐的機會在哪裡？(有足夠的實習經驗)

動機

學習者面對變化的態度是怎麼樣的？
他們是否會對產生變化的知識進行排斥？

習慣

所有非與生俱來的行為都是習慣麼？
有沒有未經學習就已經形成的習慣呢？(他自己知道嗎?)

環境

環境中是什麼阻止學習者達到成功？
需要什麼以支持學習者才足以達到成功？

溝通

目標是否清晰地得到傳達？
學習者與團隊其他成員的溝通是否良好?

你可以與團隊成員溝通詢問他們最大的困擾是甚麼? 然後針對上面初學者到專家之間的六項差距進行雷達圖的評估。然後再決定如何設計這段學習的旅程。

( 第二式自學的六個階段 )

》如何能夠讓開發者高效的學習?

首先我們來思考「為什麼資深工程師總是能把專案做得更好?」我們採用斯科特.楊的整體性學習裡論來分析它的原因: (註 3. 參考實行整體性學習 Holistic Learning)

其一、因為他對專案開發(結構)有著更深的理解(建立了較完整的知識聯繫)。

其二、他知道更多的開發模型，因此對於專案開發比起初學者更有概念。

其三、他能夠判斷出哪一條開發路徑，可以用更快的方式到達目的地

針對自我學習的六個必要的解題階段:

一)、獲取階段 :

工程師喜好運用 Google 或 Stackoverflow 網站進行搜尋，這樣很快就可以找到一堆資料，但是較正確的做法應該是先在公司內部進行搜尋，然後才去參考外部的資料。然後在進行搜尋之前先進行假設思維，或一邊搜尋一邊進行假設，然後對假設進行驗證，這樣做可過濾掉一大半的資料，省去大半的時間。

二)、理解階段 :

無論你找到甚麼想關的資料，一定要徹底的理解它，一知半解為了求快而不求甚解直接採用網路上的解法，是工程師最容易遭遇問題的作法。我們總以為這個問題我一定不是第一個遭遇到的或是唯一一位遇到的人。所以我可以參考別人的解法，當然附有範例程式就更好了，直接拿來改會更快。因此而忽略了，他人解題的情境可能與我們的不同，設備也可能不同。所以務必先徹底理解才能拿來運用。

三)、拓展階段 :

為了要進行整體性學習，在取得理解之後，你需要與既有的專案進行關聯，這個動作可以避免你見樹不見林，用狹窄的視野一廂情願的使用找到的資料。你應該習慣性的將找到的解題資訊與面臨的問題產生關連性的拓展起來(包含橫向與縱向的拓展，請參考 斯科特.楊所著的《如何高效學習》)。

四)、修正錯誤 :

錯誤可以讓我們取得反思，真正的學習不只是深刻的理解而已，而是懂得如何更廣泛的使用它。我們用看與聽來進行比較、參考別人的作法，然後用說與寫的輸出方式來抽象化這些知識(請參考 KOLB的經驗學習環)。所謂發生錯誤的時候讓我們學得更多(這裡是藉由修正別人的錯誤取得知識)。尤其是你在 Stackoverflow 網站上所找到的資訊，它們普遍都存在著相當的錯誤，所以才會陳列出來請求回饋，我們應該以求證的心態來找出它的錯誤之處，然後再進行反思自己如何避開這些錯誤。

五)、應用階段 :

應用是學習的最終目標，能做到學以致用才是真正的學習。學習時的理解只是一種附產品，實踐才是展示真正的學以致用(KOLB經驗學習環的第四階段)。

六)、驗證階段

上面五個階段，每個階段都需要驗證。因為進行程式開發時你應該只相信可以被驗證的訊息，尤其在團隊開發中，讓驗證成為你的可信度背書(可靠)，在團隊開發中因此而換取他人的信任。

這六個階段是特別針對你在網路上找來的訊息資料，並在融入開發作業之前，必要的實作步驟。其中最不能省略的步驟就是驗證(verify)，要確認你真的正確的將它融入你的程式功能中了，而不是另一個有著黑箱效應的網路功能模組。

( 第三式習慣性拒絕 )

》如何消除學習的障礙?

發覺並打破習慣性防衛(Defensive reasoning，註4.)。不會坦然承認自己不懂是工程師在學習上最大的障礙。這是五項修練裡彼得.聖吉先生所謂的學習的誤區。工程師在開會時害怕承認自己對這個問題了解的有限或是聽不懂，經常表現得不懂卻裝懂的樣子。尤其是對一些專有名詞的詮釋，講的人應該主動去仔細描述他想表達的意義及影響，避免他人在不懂之下卻裝懂，自然就無法提供有價值的意見，白白浪費開會時間。這是溝通時的一種障礙，同時也是學習時的障礙。

例如: 進行程式碼審核(code review)時由於專案時程太趕，負責審核的資深工程師很快地放行，沒有花時間來仔細進行審核。

因為時程太趕，這個理由很堅強，每回聽到時程太趕，就會興起立刻跳過一些步驟地想法，工程師因此失去了審視自己寫程式所犯錯誤的機會，因此而一再犯錯沒機會修正的機會，正是如此:

你因為專案時程太趕，所以沒時間寫測試程式，但實際上；就是因為你不寫測試程式，造成錯誤太多，才會忙著修正錯誤而造成你沒有時間的。

小結

請記下這【一招三式】: 第一招是讓開發者體驗即學習(就是協助開發者學習)，三式是 :

第一式差距彌補法 – 設法彌補初學者與專家之間的距離。
第二式自學的六個階段 – 避免濫用網路資訊，建立自己的知識關聯性。
第三式習慣性拒絕 – 克服習慣性拒絕去接受他人不同的意見。

首先；我們要選擇直接面對學習的挑戰，不要讓開發者再單獨一個人進行學習了，我們應該把學習的時間和成本在專案開發之初也估算進去。因為專案開發最終還是團隊共同開發的成果，所以我們不應該讓開發者各自採取(隱性)獨自的去面對問題，應該善用團隊的力量讓問題透明化大家一起來面對，讓工程師的學習也能夠跟上時代的腳步，多樣化而不是一層不變的，這便是開發者體驗設計的真正目標。上圖(多元的學習與設計)顯示在生活與工作中人們真實的學習旅程，在正式與非正式的學習管道下，我們應該選擇何者為佳呢? 答案顯然是視情況而定。

在正式學習的管道上；我們應該讓開發作業(敏捷開發)與學習相結合。視專案的需求，安排正式的學習方式，例如在專案開始時請來專家來進行正式的演講教學，運用這種開放的學習方式，讓團隊在同一個主題下有著共同的認知，避免了認知的差距。相對的非正式方式，則可以成立社團讓社群學習的方式融入開發者的社交生活中，讓開發者也可以透過社群的力量，拓展個人的視野範圍，讓工程師得到幫助順利的完成學習作業，這二種學習方式見仁見智各有他的功效，可以配合主題的困難度與團隊的運作進行操作。

在為開發者設計學習路徑的時候，我們不太可能在一開始就能夠明確的知道何者可行何者應該避免，即便我們在一開始就把訪談的工作做得很紮實，我們依然應該與敏捷開發的回顧會議相結合，針對不同的衝刺(sprint)目標與增量進行調整，目的是讓開發工作與學習成果相結合。其中包含開發者之間透過觀察與協作的隱性學習，也包含開發者將學習到的隱性知識轉化為顯性知識進而成為團隊共同擁有的群體知識(參考知識的轉化)。

當開發者學習得越順暢，開發者體驗就會越順暢。也就是說；我們對開發團隊的學習過程刻意的進行了DX開發者體驗設計，讓他們能盡快學會開發的相關技能，進而加快開發效能。基本作法是一、首先識別差距，運用一對一的DX訪談來衡量讓初學者到成為專家之間的差距，使用的方法是雷達圖示分析法，測量的項目是Julie Dirksen的《怎樣有效學習》的六個學習差距作。二、落實開發；針對開發者習慣的搜尋後開發的方式，進行獲取、理解、拓展、修正、應用、驗證的六階段自學者的落實開發模式。

最後我們為了讓團隊學習能夠順利進行，要先打破個人的習慣性防禦態度，讓團隊成員能夠坦然承認自己所不懂，並願意分享自己所獲得的隱性知識(如果你有專職的Scrum Master，這一點你大可放心的交給她/他去做吧)。在彼此能夠坦然回饋的狀況下進行團隊學習。透過這種傾向正面的開發者體驗將激發團隊的潛能，進而達成高效的開發成果。一定要尋求回饋，把來自他人的回饋當作是珍貴難得的寶藏，當回饋讓你開始反省自己的時候，學習的心態就自然的被啟動了，但重點還是在反省後你做了甚麼樣的改變，這個改變是你落實Kolb經驗學習環的出口，你做了甚麼改變，就是你真正學到了甚麼。

只有能改變你行動與認知的訊息才是知識。

最後補述一段約翰.哈蒂先生對「可視化學習」的定義，它對「工程師必須自我學習又要成為自己學習時的老師」有著異曲同工之處:

The ‘visible’ aspect refers first to making student learning visible to teachers ……, also refers to making teaching visible to the student, such that they learn to become their own teachers.” (John Hattie, 2009)

意思是；一方面要讓學生的學習對老師是可見的，另一方面則是讓學生可以成為他們自己的老師。稱之為；可見的學習者(visible learners)：

一、是讓教師能看見學生的“學習”，能清楚得看到自己所起的作用；
二、是讓學生看見教師的“教學”，促使學生逐漸成爲自己的教師。

註 1. 參考自赫爾辛基大學二位教授的文章，標題是: Developer Experience: Concept and Definition由Fabian Fagerholm與 Jürgen Münch 共同完成，是一篇會議論文(Conference Paper，註1.)出版日是June 2012.

註 2. 開發者體驗的定義

註 3. 實行整體性學習(Holistic Learning 斯科特.楊)

這位是以自我學習聞名的加拿大學霸 斯科特·揚，他從高中開始放學後就幾乎不學習，儘管如此，他還是以全班第2名的成績畢業。讀大學時，他每天學習一般不超過2個小時，但他的平均成績總保持在A以上。從加拿大馬尼托巴大學商科畢業後，他又以超凡的速度學習了麻省理工計算機課程，並登上TEDx的演講台，向全世界宣講自己的學習經驗。

斯科特·揚在家用了12個月，通過網路完成了四年麻省理工大學33門的計算機課程，節省了150萬的大學學費。

整體性學習的三個主要觀點: 結構、模型、高速公路。

結構；就是一系列緊密聯繫的知識。
模型；模型就是簡化之後的結構，對於快速學習概念至唯有用。
高速公路；就是知識之間快速的連結。

這三個觀念十分抽象，但解釋的很好。我另外也參考了他的六個必要的解題階段，用來克服我們從網路上獲取不明資訊時可能的誤導運用。

註4. 習慣性防衛 (defensive reasoning)，源自當代管理大師 克瑞斯.阿基里斯(Chris Argyris)先生所謂的行為科學理論。這是運行"團隊學習"時最大的阻礙因素。

習慣性防衛的根源是懼怕暴露出我們想法背後的思維。防衛性的心理使我們失去檢討自己想法背後的思維是否正確的機會。對多數人而言，暴露自己心中真正的想法是一種威脅，因為我們害怕別人會發現它的錯誤。

要想打破這種習慣性防衛的本性，需要一種開放的思維方式，擁有 open mind才容易去接受別人的意見，稱之為「綠燈思維」。

註5. 這段期間(2020~2022)我的演講總免不了提到”開發者體驗”的字眼。有哪些演講呢? 統計一下也嚇到自己了。其中包括: 開發者體驗DX、敏捷開發與開發者體驗設計、如何提升團隊的開發效能、談假設思維之下的開發者體驗、談敏捷開發下的DX、打開DevOps的后門: 開發者體驗、如何打造优秀的高效能团队、开发者逻辑。真要感謝主辦單位的容忍。有興趣的人應該可以在網路上找到相關的PPT檔，雖然我從來不用 PPT講課，但它已經包含了課程中的大部分資訊。

『我想嘗試為團隊進行開發者體驗，要從哪裡開始呢?』

如果你也問過這個問題；這篇文章就是為你(妳)們寫的。

註6. 綠燈思維

綠燈思維是指當遇到別人提出新的觀點或跟自己不同的意見時，第一反應是：我應該怎麼運用在自己身上？反之；則稱為紅燈思維。