Ruddy Lee 分享空間

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

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 年 05 月 03 日 ruddyllee2 則迴響

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

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

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

「認知負荷」Cognitive load

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

「後設認知」；認為是個人對認知活動的理解、意識與監控的歷程。

開發者體驗DX與認知負荷

軟體的開發是一種學習的過程，對開發目標所必須具備的相關知識，工程師只有在學到了某一個程度之後(適當地學會了，例如: 80分)，才可能做出正確的軟體來，因此每一個專案對工程師而言；因為有期限的壓力，幾乎都是一種開啟快速學習的過程，因此開發者會產生如學生一般的學習壓力，也就是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的教練模式。這二種對話的都可以終生受用。

估算的不確定性錐

2022 年 03 月 18 日2022 年 03 月 24 日 ruddyllee發表留言

{ 歷史緣由 }

不確定錐的最初概念是由美國成本工程師協會(AACE International)的創始人所開發出來的。他們在1958年發表了一個建議的具有不確定性範圍的標準估計類型分類系統，並在當時的文獻中提出了“錐形”插圖。這個概念被Barry Boehm(美國著名的軟體工程師、南加大教授) 所採納。Boehm 稱它為“漏斗曲線”。Boehm 和他在南加州大學的同事後來的工作將它應用來自美國空軍和其他來源的一組軟體開發專案的數據來驗證此模型。後來NASA軟體工程實驗室進一步驗證了這一基本模型，並把它納入文件規範。

用“不確定性錐”這個名稱來描述這個概念是在《Software Project Survival Guide》1997的書，是著名《Code complete》的作者 Steve McConnell (2004) 所採用的，我也是從這裡得知原來估算還可以有憑有據的。敏捷開發因為執行小增量、多迭代而產生了下圖的微不確定性錐(註1)

基本上；估算是一種對未來的猜測，是不可能準確的，但我們要的是參考。 How To Estimate Software Development Time

不確定性錐(The cone of uncertainty)簡介

在專案的早期，要建構東西大都十分模糊，但我們需要對軟體的具體細節、需求的細節、解決方案的細節、專案規劃、人員配備和其他專案變量等都需要去弄清楚。然而對這些因素的任何誤判都有可能會導致專案估算的巨大變化，但有趣的是我們不能沒有規劃，因為資源總要視需求的規模才好進一步決定要投入多少量又或許是放棄。但是實驗證明我們可以邊做邊進一步增進對它的認知(細化)程度，並隨著對這些可變性來源的進一步確定，由於專案中的可變性減少，因此專案估算中的可變性也就會減少。這種現象就被稱為“不確定性錐”，如下圖所示。在專案總日程時間的前20-30%期間(1/5到1/3之間)，錐體有顯著變窄的現象。

橫軸包含專案的各種里程碑，例如初始概念(initial concept)、批准的產品定義(approved product definition)、需求完成等。這裡所謂的“產品定義”僅指向產品在商業上的願景或“概念”，它同樣適用於開發Web服務或內部軟體系統和大多數其他類型的軟體專案。

縱軸包含由熟練的估算人員在專案的各個點創建的估算中發現的誤差程度。估計可能是針對特定功能集的成本以及交付該功能集需要多少工作量，或者是針對特定工作量或計劃可以交付多少功能。 “範圍”；指專案規模的工作量、成本、功能或某種組合。如上圖所示，做完真實結果是1的工作量，有的人評估的是4倍的工作量，而有的人評估的是1/4的工作量，上下就差別高達16倍了。這就是縱軸的刻度由0.25X 到 4X的原因。

縮小不確定性錐體

PO和客戶會問的問題是: “如果我再給你一周的時間來完成你的估計，你能降低不確定性嗎？” 這是一個合理的要求(所有老闆都會這麼想)，但不幸的是，無法按該要求交付。

研究發現，軟體估計的準確性取決於軟體定義的細化程度。(這句話是一個嚴重的陷阱，前提是你要逐步地去確認才成立，而不是花很長的時間去規劃) 定義的越精細，估計就越準確。要逐步估計解決(降低)可變性的原因才是王道，因為減少估算可變性的唯一方法是減少專案本身的可變性，它需要逐步的去完成。

一個重要且困難的概念是，不確定性錐體代表了專案中不同點的軟體估計可能具有的最佳案例準確性。圓錐代表熟練的估計者創建的估計誤差。很容易做得更糟。不可能更準確；只可能更幸運。

錐形表示最佳案例估計的另一種方式是，如果專案沒有得到很好的控制，或者估計人員不是很熟練，估計可能無法像錐形所示那樣改進。下圖顯示了當專案沒有以減少可變性的方式進行時會發生什麼——不確定性不是錐形，而是持續到專案結束的雲。問題不在於估計值不收斂；問題是專案本身沒有收斂，也就是說，它沒有產生足夠的可變性來支持更準確的估計。(註2. 參考自construx)

只有在你做出消除可變性的決策時，錐體才會縮小。如下圖所示，定義產品願景(包括承諾您不會做的事情；確認目標刪除無關工作)也可以減少可變性。再次定義需求，包括你不打算做什麼或怎麼做，可以進一步消除可變性(參考敏捷的迭代作業)。明確的使用者界面也有助於降低因誤解需求而引起的可變性風險。當然，如果產品沒有真正定義，或者產品定義稍後重新定義，那麼錐體會變寬，估計精度會變差。

.

不確定錐與承諾的關係

軟體組織過早地在不確定性錐中做出承諾，無意中破壞了他們自己的專案。如果一個組織在初始概念或產品定義時提交，它的估計會有 2 到 4 倍的誤差。在專案中過早做出承諾會破壞可預測性、增加風險、增加專案效率低下並削弱管理專案以取得成功的能力。

在錐體的早期，廣泛的部分不可能做出有意義的承諾。有效的組織會延遲他們的承諾，直到他們完成了迫使錐體縮小的工作。在專案的早期中期（大約進入專案的 30%）做出有意義的承諾是可能和適當的。

軟體估計的準確性取決於軟體定義逐步的細化程度

【敏捷專家對估算的看法】

策劃過程比計畫書更重要。

估算是漸進準確的。

專案計畫的很多決策都是折中的結果。

需求分析讓我們思考做正確的事，策劃讓我們思考正確的做事。

請注意帕金森定律，任務總是推遲到最後一刻才完成。

讓估算成為陷阱的工作方式；多工作業。實驗證明工程師在手上有二個不同性質的工作在進行時，表現的最有效率。一旦超過了，效能就會急速下降。(參考自mike cohn 的《敏捷估計與規劃》)

.

不確定性和迭代開發的錐體

不確定性錐在迭代專案中的應用比在順序型專案中的應用要複雜一些。但是如果你正在處理的專案在每次迭代時都執行完整的開發週期(即從需求定義到發布)，那麼您將在每次迭代中經歷一個"微型錐體“。在為迭代進行需求工作之前，您將處於錐體的“已批准產品定義”部分，從高到低估計值有4倍的可變性。通過短迭代(1到4周的開發循環)，可以在幾天內從“批准的產品定義” 轉移到 “需求完成”和“使用者界面設計完成”，將可變性從4倍降低到 1.6 倍。如果您的時間表是固定的話，則 1.6 倍的可變性將適用於您可以在可用時間內交付此特定功能，而不是工作量或時間表。

許多開發團隊採取中間的作法，在專案的前端定義了大部分需求，但設計、構建、測試和發布都是在較短的迭代中執行的。換句話說，專案按順序通過使用者界面設計完成里程碑(避開前面大約 30% 的日期時間)，然後從該點開始轉向更具迭代性的方法。這麼做可將錐體產生的可變性降低到大約 ±25%，這種足夠好的思維方式並採用專案控制(透明、檢核與持續調適)來達到目標，會同時享有迭代開發的多種好處。而專案團隊更可以在專案結束時為尚未確定的需求留出一些計劃時間(例如: Scrum 的梳理會議)。這引入了一些與功能集相關的可變性，在這種情況下，這是一種積極的可變性，因為只有當確定要了實現的功能時，你才會去使用它。這種中間立場的做法對成本和進度的長期可預測性以及適度的需求提供了靈活性(這讓軟體開發很像裝潢業的收費方式，可惜客戶不見得會接受)。

工程師的信心點

這是自己長期觀察的經驗。在專案開發時程進行到1/5到1/3工期的時候，工程師經常會對自己的工作及交付時程具有更高的信心。就是更有把握會在什麼時間能夠完成開發任務。我們拿它來與不確定性錐做對照，你會發覺工程師在需求完成 到 使用者介面固定下來之間會激發出自信心。這或許是因為不確定的東西(變量)減少了，自然而然產生的心態，這也是工程師對自己的能力的把握度的表現。這個時候；工程師應該做第二次的估算，重新審視一下整個專案，然後以達成使命的方式去努力地交付它。這就很像實施 OKR 時設定Key results 的激勵方式了，(回想一下將關鍵結果設定成1.0 的結果)讓我們有機會突破自己；並發揮潛能。

軟體估算的主要目的不是預測專案的結果。它是確定一個專案的目標是否足夠現實，以使專案受到控制以滿足它們。

—史蒂夫·麥康奈爾 Steve McConnell

小結

我們生活在一個有著年度預算的世界裡。不幸的是，這在我們的工作場所引發了很多緊張的壓力和戲劇性的變化。在某些方面，年度預算是很自然的(我們以一年的周期生活和日期追踪)，但在其他方面，由於一年在市場上是很長的時間，它存在著各式各樣的衝擊和變化，它們對於計劃來說是一件很糟糕的事。

請記住軟體評估的全部意義只在於確定專案是否可行。

{ 說明資料 }

註1. 微不確定錐

註 2. 參考自 construx 的 the cone of uncertainty

開發者風格 Developer style

2022 年 03 月 15 日2022 年 06 月 22 日 ruddyllee發表留言

我們因穩定的學習風格而形成習慣，而習慣造就了我們的行為風格。

開發者本身所展示出來的風格；包含: 一、專業技能上的表現。二、工程師在團隊互動之下的感受。及三、個人自身的成就感，這三方面的綜合交互作用所形成的一種對外的形象(註1)。本文想藉由強調加強開發者的反脆弱性來塑造有利良好的開發者體驗的風格。

開發者所展現的風格是依據他對軟體開發(策略)的認知而來。

甚麼是軟體開發策略Development Strategy

就是我們在開發過程中的指導原則，就是；當我們面對問題時；決定甚麼該作而甚麼不該做的依據。我一直認為它是一種避險原則，直到遇見了塔雷伯的否定法(註2.)。他說:『實際上人們是通過反向方法尋求成功的，這是一種進化過程的選擇：下棋高手通常通過不輸棋而取勝；人們通過避免破產而致富；宗教大多制定許多禁忌；生活的經驗主要是關於我們應該避開什麼事。由於採取了一小部分措施，你便能夠降低個人發生意外的大部分風險。』這一點十分吻合工程師開發過程中所採用的試錯法(try & error)原則，我們在撰寫程式時會不斷的試錯，直到功能能夠完成。從此自己便改用脆弱性與反脆弱性來擬訂開發的策略。舉例: 敏捷開發聚合了團隊的力量，運用團隊的知識和力量來一起完成任務，讓工程師在面對問題時變得較不畏懼，也就是增加了反脆弱性。

反脆弱公式

不怕波動；上檔利益大於下檔利益；得多於失及產生有利的不對稱性

估算還是不估算

傳統: 沒有估算怎麼作資源規劃呢?

敏捷: 估算是為自己設定一個時間限制。

寫甚麼樣的文件

傳統: 客戶需要文件來做教育訓練

敏捷: 寫自己會喜歡查閱的文件。

主動協助團隊成員

傳統: 打考績可以促發員工更賣力的工作

敏捷: 自由學習是最珍貴的。學校是結構化學習的場所，嚴重傷害了自由學習的力量，讓學習受到了侷限。出社會後，在團隊中協助他人，則是一種最好的自由學習。

小增量的實踐者

傳統: 弄不清楚開發團隊的負荷，是否表現得壓力太大或過得太輕鬆了?

敏捷: 養成頻繁交付，透過展示取得回饋，然後快速調整的習慣。讓團隊在節奏中進行開發，漸漸的發現自己的能力及負荷。

產出模式

傳統: 只要專案能夠準時完成，要怎麼做都可以。

敏捷: 匯聚開發的經驗持續修正模式。站在嘉惠他人的立場，經由產出Pattern 的方式讓經驗可以重復派上用場。

反脆弱的運用

目標；在專案開始前制定如何提升效能的策略。如上圖運用 IPO效能提升法(註3.參考自從此不加班的IPO工作術)。在INPUT端；制定甚麼該做/甚麼不該做的表格，並陳列出自己工作時可能遭受干擾的事項。運用排除法在事前預先設定應對方法(上圖中的二個正三角形，排除那些可能妨礙工作效率的瓶頸)。Process 時必須要能夠保持身心能夠專注工作的狀態，然後在OUTPUT端能夠瞄準工作所要達成的目標努力達成它，並尋求客戶的意見回饋，藉此給客戶它真正需要的東西。事後透過過頭來看燃盡圖(它記錄了我們的開發過程)，藉此評估自己是在哪裡出了甚麼問題，未來又應該如何改善。

可參考的反脆弱思考步驟:

第1步：識別問題領域。針對問題做好開發計畫，盡量按計畫工作，但計劃總是趕不上變化，要可視化問題及可能的干擾，適當進行調整才是王道)

第2步：創造可選擇 (選擇能增加反脆弱性，列出可能的干擾；希望能夠透過事前分析擬定的應對策略，來降低脆弱性)。

第3步：確認槓鈴策略(從系統的角度看待開發作業，多做重點，思考如何防範突發性的事件以降低被干擾的風險)

第4步：試錯，否定錯誤選項(運用否定法，以假設的方式，經常性的作檢核與調適)。讓問題可視化；能看見問題才能針對問題求解或是尋求避開會降低自己效能的干擾。

(參考自註2. 的反脆弱的思考步驟)

小結

開發者體驗設計的目的是要工程師能夠順暢的開發出高品質又有價值的功能。塑造開發者的反脆弱性風格，採用系統思維的理念做為出發點，並以提升開發者本身的適應性，來自適應外界的變化。這是參考自《反脆弱》一書，以增加不怕波動的適應性，增加作業上的可選擇性、讓上檔利益大於下檔損失 及 有利的不對稱性原則等方法來增加開發者的反脆弱性。呼籲一下「簡約至上」的不變法則。

工程師的風格往往來自他的行為習慣，而習慣則成形於他的學習風格，至於為什麼會有這樣子的學習風格，則來自於他的人格特質。

-《天生不同》Isabel Briggs Myers

<< 演講的資料 >>

註1 . 參考2013 芬蘭赫爾辛基大學法比安 · 法格霍爾姆與尤爾根 · 姆·昂奇二位教授的研究報告。

註2. 納西姆·尼可拉斯·塔雷伯的否定法。塔雷伯以《黑天鵝效應》一書聞名於世，”否定法”是陳述在《反脆弱》一書第六冊。塔雷伯主張認識論的核心宗旨如下：我們知道錯誤的事情遠多於知道正確的事情，或者就脆弱 / 強韌的分類來說，負向知識(什麼是錯的，什麼不起作用) 在錯誤面前比正向知識 (什麼是正確的，什麼起作用) 更強韌。鑑於我們今天所知的知識可能被證實是錯誤的，但我們今天認識到錯誤的知識則不可能變成正確，至少不那麼容易，因此，通過減法獲得知識遠遠比通過加法獲得知識多。

註3. 清水久三子所住的暢銷效能提升術《從此不加班的IPO工作術》

註4. 參考每日頭條: 反脆弱思維教會我在不確定性時代，更好管理自己時間和投資