此流程非彼流程

Oct. 24 22:14~23:07

▲工作中的阻礙

幾年前有一次機會參加一個行政團隊的sprint review與retrospective會議。這個團隊剛開始接觸Scrum，他們對於Scrum的理解是由公司內上過Scrum課程的同仁所傳授。在review會議中，同仁甲展示他的工作成果—召募新人流程。他將這個流程視覺化，並比較舊有招募流程與新流程的差異。

Product Owner對於這個展示沒說什麼，倒是Scrum Master問了很多問題。Scrum Master以前是行政部門主管，跑Scrum之後轉為Scrum Master。

***

Review結束之後，在retrospective會議Scrum Master請團隊成員各說出三個好的與三個有待改善的項目。

同仁甲：我覺得Scrum Master要求我們將自己工作流程視覺化這一點很好，讓我比較容易看出現有流程有問題的地方。有待改善的地方就是關於校園招募這部分，我覺得吸引學生來填寫資料的誘因還不夠，這部分的流程以後還可以加強。

就在每位同仁都發表意見之後，Scrum Master請Teddy提供一些建議。

Teddy：我想請問你們知道retrospective會議的目的是什麼嗎？

Scrum Master：知道啊，就是流程改善啊，讓我們可以越做越好。

Teddy：你說的沒錯。請問各位同仁，你們剛剛所提出Good與Improvement的項目，是屬於需求面的改善，還是流程面的改善？

此時安靜了幾秒，大家你看我，我看你，對於Teddy所提出的疑問，大家一臉黑人問號的感覺。

Scrum Master：我不懂你的問題，我們剛剛提出來的的確是流程的改善。像是同仁甲就很明確提出他在校園招募流程方面的改善建議。

Teddy：同仁甲，請問您的主要工作是什麼？

同仁甲：我負責招募與其他人事方面的工作。

Teddy：所以新人招募是你提供的服務，對嗎？

同仁甲：這是我的工作，要說是我提供的服務也可以。

Teddy：你們是行政團隊，不像開發團隊需要寫程式，做出可動的軟體。你們所提供的「服務」就是你們的user story。

Scrum Master：所以你是說，我們剛剛都在討論「需求的改善」？

Teddy：沒錯。

同仁甲：可是我們討論的明明是「流程改善」啊，以我來說，我談的是招募流程改善。

Scrum Master：啊，我知道了。我們實作的「需求」，是對公司提供某種服務。我們討論的都是這些服務的流程，就好像軟體功能怎麼被使用的流程一樣，這是屬於需求的範疇。

Teddy：沒錯。

Scrum Master：我還是有一點不明白，retrospective所謂的流程改善，是什麼流程？

Teddy：是團隊合作的流程，有什麼阻礙存在，讓團隊無法更快、更好的交付價值給客戶。

Scrum Master：可以舉個例子嗎？

Teddy：例如，我觀察到你們每個人所負責的工作彼此獨立，無法互相幫忙。這對你們來說會是一個問題嗎？如果有同仁請長假，他所負責的工作會不會無法進行？你們在提供服務的時候有沒有遇到什麼阻礙？是否很清楚用人單位的需求？會不會經常發生找到人被RD打搶等等問題。

Scrum Master：如果撇開Scrum不談，難道我們不能找時間討論我們提供服務的流程嗎？為什麼要侷限在retrospective所規範的活動範圍？

Teddy：團隊當然需要時間來討論供服務的流程，也就是你們團隊的需求。在Scrum框架中，你們可以在product backlog refinement workshop討論，也可以在sprint planning討論，但不適合在retrospective討論。

Scrum Master：可是我就是不想被框架限制住啊。

Teddy：你會在告別式的時候包紅包嗎？

Scrum Master：啊？當然不會啊，我沒那麼白目。

Teddy：那你為什麼要在retrospective討論需求改善呢？如果你在這個活動討論需求，請問你要在什麼活動討論「工作流程改善」？Sprint planning嗎？不會吧。

Scrum Master：是不會啦…

***

友藏內心獨白：先學會走再看看要怎麼飛。

Scrum Master的兩個魔咒

Oct. 22 13:21~14:20

▲兩個搗蛋鬼

Scrum「大濕」

對於Scrum而言，Scrum Master是一個很神奇的存在。正所謂「好的Scrum Master讓你上天堂，不好的Scrum Master讓你住套房」。這個角色似乎成為Scrum成敗的關鍵因素，理論上你的Product Owner和開發團隊甚至整個公司一開始很爛都沒關係，在Scrum Master的輔助之下，透過持續改善的過程，Product Owner和開發團隊的不足之處都可以慢慢地變好。

理論上…

***

自組織魔咒

Scrum的開發團隊是自組織團隊（請參考〈自組織〉），因此有些Scrum Master會採取所謂的「主動不做任何事」的模式，從旁觀察團隊。當團隊遭遇問題時讓團隊成員自行解決，既使解決的過程產生各種大大小小的失敗也視為學習所需付出的必要成本，Scrum Master儘量不要跳出來幫團隊解決問題。

這一招對於已經具備「自我餵食」能力的團隊成員可能會很有效，但如果團隊成員尚未具備「自我覓食」能力之前就貿然將其放生，最後結果可能不是放生而是放死。從生物的角度來難，當個體還屬於幼年時期，需要的是更多父母親的照顧，然後在個體成長的過程中慢慢培養自組織的能力。

曾經有朋友告訴Teddy，他離開Scrum團隊的原因居然是因為看不慣Scrum Master主動不做任何事的行事風格。團隊也想要自組織、靠自己的力量排除阻礙，但問題是團隊目前就是無能（尚未具備此能力），都跟你發出求救訊號你還置之不理，身為Scrum Master總不能只靠主動不做任何事這一招打通關吧？！

***

寶媽魔咒

為了讓團隊運作順暢，impediment removal（阻礙排除）佔了Scrum Master最多時間，這種情況在初導入Scrum的團隊中特別明顯。

▲節錄自《Essential Scrum》，

雖說Scrum Master需要幫助排除阻礙，但幫助不等於自己動手做，而是讓團隊具備自己排除阻礙的能力。有些過於積極與熱心的Scrum Master可能會認為處在「幼年期」的團隊尚未具備「自我覓食」的能力，如果放任他們自生自滅，將會落入自組織魔咒而無法自拔。因此Scrum Master開始扮演一位認真的新手媽媽，對孩子照顧的無微不至。

在不知不覺中，團隊只要遇到無法解決的問題全部丟給Scrum Master幫忙處理，久而久之Scrum Master變成寶媽，而團隊成員則變成了媽寶。

Teddy認識一位技術很強的Scrum Master，在團隊剛導入Scrum時扮演寶媽的角色，自己動手幫助團隊解決幾個關鍵的技術問題，讓團隊在導入Scrum初期，在兵荒馬亂的過程中增加關鍵穩定軍心的助力。而在團隊熟悉敏捷開發精神與Scrum框架之後，慢慢淡出舞台，切換到主動不做任何事的模式。

***

沒有一定的形狀

好的Scrum Master，沒有一定的樣子。不要看到別人主動不做任何事，以為回家後照做就會成功。別人的Context與你的Context不一樣，無腦照抄解決方案，到時候失敗再來哭哭討拍，抱怨Scrum不適合台灣人乃至整個亞洲人的特殊體質。

套句PPT上鄉民常說的一句話：「正妹不是不給約，而是不給你約」。反思一下，這是正妹（方法）的問題呢，還是自己（團隊）的問題。

***

友藏內心獨白：要先確定是不是正妹。

增進學習力的三個練習

Oct. 17 22:13~22:47

Teddy在北科上課時經常指定學生回家閱讀教科書或技術文章當作家庭作業，隔週上課再討論閱讀內容。大部分的學生並不擅長抓住內容的重點，閱讀經常只停留在字面上的涵義。

Teddy不是什麼閱讀專家，但多年來發覺把握以下三個重點，可以幫助自己在閱讀技術文章時看到不同層次的問題，也可以提升自己的「教學力」。

• 1. 定義：對於重要的名詞或概念，能否用簡潔的字句說出它的定義？例如，試著說出以下名詞的定義：多型（polymorphism）、迭代與增量（IID）、敏捷、Scrum、軟體架構、設計模式。
• 2. 比喻：能否用一般人聽得懂的方式說明重要的名詞或概念？例如，用下圖的磨豆漿來解釋迭代與增量就比較容易讓鄉民們理解。

▲圖片節錄自 https://goo.gl/YgiMyr

• 3. 找問題：名詞或概念通常代表某種產品或解決方案，也就是建築師Alexander所說的Form。學了一堆名詞與解決方案，如果不知道它們用來解決什麼問題，很容易發生吃錯藥的情況。就好像學了一堆design patterns但卻不知道每一個pattern要解決什麼問題，所以就很容易誤用pattern。

有一個很簡單的自問自答練習，可以幫助自己發覺名詞與解決方案背後所要解決的問題是什麼。只要問自己：

If X is the solution, what is the problem?

例如：

• If polymorphism is the solution, what is the problem?
• If IID is the solution, what is the problem?
• If Agile is the solution, what is the problem?
• If Scrum is the solution, what is the problem?
• If software architecture is the solution, what is the problem?
• If the design pattern is the solution, what is the problem?

***

只要把握住這三個簡單的重點，相信可以把技術文章看得比別人更透徹。

***

友藏內心獨白：桌子要解決什麼問題？

擁抱改變，遠離Hard Code

September 19 08:37~09:12

▲圖片來源在此

寫死（Hard Code）

幾天前一位朋友在Facebook上發問：「如何對非資訊人員解釋寫死（hard code）？」

維基百科對於寫死的解釋如下：

寫死（英語：Hard Code或Hard Coding）是指在軟體實作上，將輸出或輸入的相關參數（例如：路徑、輸出的形式或格式）直接以常數的方式撰寫在原始碼中，而非在執行期間由外界指定的設定、資源、資料或格式做出適當回應。一般被認定是種反模式或不完美的實作，因為軟體受到輸入資料或輸出格式的改變就必須修改原始碼，對客戶而言，改變原始碼之外的小設定也許還比較容易。

***

以上解釋，清楚明白，資訊人員一定看得懂，但對非資訊人員可就不好說。昨天Teddy在讀《溫伯格的軟體管理學：第一級評量》看到一個例子：

一間荷蘭公司買了六台Apple Lisa電腦，想試看看能否推廣到整個實驗室使用。誰知Lisa的列印功能被寫死只支援美國標準規格的信紙，不支援歐洲標準規格的信紙，而且使用者也無法自行設定信紙大小（因為信紙大小寫死在程式中）。最後六台電腦全被退貨。

***

適合（Fitness）

在Lisa的故事中溫伯格提到：「一個系統換到新的環境，品質也會改變。……在某些美國人眼中Lisa是一種高品質的電腦。很少有歐洲人這麼認為。」。

以上這個觀念可以用建築師Alexander的pattern框架來解釋，如下圖所示：

▲同樣的Form（Lisa電腦），移到不同的Context（美國或歐洲），原本的好品質／好設計，就可能變成爛品質／爛設計。所以Alexander說：「好設計是Form與Context的適合關係。」

***

結論

寫死的程式碼降低軟體系統（Form）適應不同Context的能力，只要使用的情境改變，原本可以動的程式或功能可能就無法使用。

在大部分的情況下，開發人員請記住以下格言：

擁抱改變，遠離Hard Code。

***

友藏內心獨白：什麼是Lisa電腦？

報恩

September 18 08:58~10:39

▲窗外的浪浪吃飽就睡，何時會上演「貓的報恩」XD

故事一

好幾年前參與第一個Scrum團隊的產品開發，該軟體產品必須支援很多軟體與硬體平台，牽涉到韌體與驅動程式，還要與一些特殊的嵌入式系統溝通。這些軟、硬體平台數量眾多，不但經常改版，並且附贈不少bug。

當時Teddy遇到一個很頭痛的問題：「怎麼設計軟體架構？」因為跑Scrum，不能用傳統瀑布式開發那一套，先花個幾個月收集需求，再花個幾個月設計架構。當時關於在敏捷開發中如何設計軟體架構的資料非常少，能找到的資料也只是提個大方向：「敏捷開發中軟體架構是隨著每個迭代週期長出來的」。

在無計可施之下，Teddy想起念書時在物件導向分析與設計（OOAD）課程學到的RUP（Rational Unified Process；統一軟體開發流程）。RUP的三大支柱：Use Case Driven、Architecture Centric、Iterative and Incremental Development（IID），是不是能在Scrum中使用？

***

敏捷開發方法原本就是迭代與增量，把use case driven換成user story driven，如此一來套用architecture centric的作法似乎也是非常自然的一件事。

RUP把軟體開發分成四個phase：Inception、Elaboration、Construction、Transition。在elaboration結束時大約完成最重要的百分之二十use case，此時軟體架構雛形也大致成形。聽起來很簡單，實際上要在Scrum中套用此原則也不難，唯一需要注意的一點是：「你怎麼知道這最重要的百分之二十use case（user story）是什麼？」。

跑Scrum當然你會有Product Backlog，但這是一個內容隨時間異動的產品功能代辦清單。如果Product Backlog裡面只有接下來1~2個sprint所需要的詳細user story內容，有可能「看得不夠遠」，導致於軟體架構在每個迭代中不斷地（大幅度）修正。所以必須依據專案的特性，包含專案大小、上市時間、複雜度、不確定性等因素，自行判斷需針對這最重要的百分之二十的user story（百分之二十只是一個概念，不一定就是百分之二十，在敏捷開發中這個數字也許越低越好），需要做多少事前設計（up-front design），才能讓團隊的軟體架構成形。

***

故事二

N年前台灣政府砸錢推廣CMMI，當時Teddy還在念書，因故到校外上了介紹CMMI的課程。在學校也修了個人軟體流程（Personal Software Process），體驗了一學期「沒人性」的度量與改善之軟體開發方法XD。

Teddy所認識接觸過CMMI的台灣軟體工程師，幾乎每一個人對它的評價都是「罵聲連連」。CMMI本意良善，可惜在台灣的落實方式變成一種快速拿牌的「文件化流程」。為了長官的績效，為了亮點，原本的精神所剩無幾，徒留形式。

這一陣子Teddy花了一些時間閱讀溫柏格的《溫柏格的軟體管理學》這一套四本「老書」。溫柏格在書中提出「軟體工程文化模式」，包含以下幾個等級：

• 模式0：渾然不知型的文化（Oblivious）
• 模式1：變化無常型的文化（Variable）
• 模式2：照章行事型的文化（Routine）
• 模式3：把穩方向型的文化（Steering）
• 模式4：防範未然型的文化（Anticipating）
• 模式5：全面關照型的文化（Congruent）

模式1~模式5基本上就對應到CMMI Level 1~CMMI Level 5。針對處於不同軟體工程文化模式的公司或團隊，遇到問題時有不同的反應方式。溫柏格這四本書利用幾個簡單的模型（model）來介紹他的軟體管理學，包含：系統性思考、軟體工程文化模式、控制模型、薩提爾的人際溝通模式。

這四本書（中文版）加起來約2200頁，但因為以前 被迫 學過一點CMMI的皮毛，沒想到N年後居然出來報恩，讓Teddy比較讀得懂這一套書。

***

結論

有些人覺得從事軟體開發工作不須要念研究所，大學畢業就很足夠了。因為台灣的研究所教的內容與社會脫節，還不如早早出社會從實戰中學習。也有些人盲目念研究所，只因為鄉民都念了我沒念好像怪怪怪。

不論哪一種情況，大學或研究所教育，雖然求學的當下看起來很多都跟「社會脫節」，但世事難料，就看每個人對於所謂的「社會」的時空定義是什麼。

很多時候，基本功夫做好，才是伴隨自己一生的最佳夥伴。

***

友藏內心獨白：溫故知新。

我沒有被盜帳號之Scrum新詩

August 24 18:09~18:41

好詩、好詩

前幾天在搞笑談軟工Facebook社團貼了一首詩：

我的目標

我想要愛你，而不控制你；
欣賞你，而非評斷你；
與你一起，而不侵犯你；
邀請你，而非強求你；
離開你，無須多言歉疚；
批評你，而非責備你；
並且，幫助你，但不看輕你。
如果，我也能從你那裡得到相同的，
那麼，我們的相會就是真誠的，
並且，會豐盈彼此。

朋友看到嚇了一跳，以為Teddy被盜帳號。這首詩的作者是已故家庭治療大師Virginia Satir（維琴尼亞 薩提爾），出版於《Making Contact》。上面的翻譯是取自於簡中版《與人聯結》，以下為繁中版的翻譯，與簡中版稍微有點差異：

我的目標

我想要愛你，而不抓住你
感激你，而不評斷；
參與你，而不侵犯
邀請你，而不要求；
離開你，而不歉疚
批評你，而不責備；
並且，幫助你，而不是侮辱。
如果我也能從你那裡得到相同的
那麼，我們就會真誠地相會
而且，豐潤了我們彼此。

***

與人接觸

讀到這首詩的第一個反應：「耶，這不是理想ScrumMaster的內心獨白！應該列為ScrumMaster必背新詩。」但後來想一想，不只是ScrumMaster，每個人都可以把薩提爾的「我的目標」當成自己的目標。

如同《薩提爾的家族治療模式》中所提到：生存的姿態，不需要討好、指責、超理智和打岔；只需要一致。

提高自己的價值感，保持一致性，你也可以達到薩提爾的目標。

***

友藏內心獨白：所有的問題都是人的問題XD。

好的理論就是最好的實踐

August 23 23:28~24:00；August 24 00:~00:28

▲貼上封印的實務做法將使電腦無法洩露資料… （黑人問號？？？）

施展不開的苦惱

Teddy有一個很認真學習的朋友，有機會就到外面上課進修。最近這位朋友告訴Teddy他在學習上的一個困擾…

朋友：我上了很多課程，尤其是實戰班，我都有好好的練習。只要我回公司之後，在工作上遇到的問題跟上課時所教的問題一樣，我就能夠處理。但是，只要稍微有點不同，我就不知道要怎麼處理。

聽完朋友的敘述，Teddy的第一個反應就是—「你只是照著人家教你的特定招式練習，你根本沒有真的學會啊。」這種學習模式，只要情境稍微改變，原本罐頭式的解決方案很可能就派不上用場了，而你又不知該如何調整原本的罐頭，讓它在新的情境中派上用場。

***

理論和實務

理論和實務，經常被視為學習天平上的兩端。理論給人的感覺就是抽象、嘴砲、和社會脫節、無法實戰等。實務給人的感覺就是具體、立即可上手，就好像武俠小說中吃了天山雪蓮一樣，立刻增加一甲子的功力。

實務就好像例子（example or instance），非常具體、容易理解且容易照做。如果實務所描敘的情境（context），與問題（problem）和你工作上所遭遇的相同，便可立即套用。但通常越具體、越實戰的實務，其適用的情境也越特定（越窄）。所以，同一種「類型」的問題，可能衍生出數種甚至數十、數百種例子。如果沒有理論基礎的支援，沒有建立分析問題的框架或模型，需要靠自己慢慢地累積各種實戰經驗，然後再抽象化成為自己腦中的解題模型。這是一個冗長的過程，很多人還沒走完這個過程就放棄了，永遠都在「學例子」，而沒有學到例子背後的共通理論基礎。

***

建立收納知識框架

這幾天在某本書（這幾天看的書比較多，忘了哪一本。應該是溫柏格的某本書中引用另外一個人的話，要再找一下）讀到一句類似的話：

好的理論就是最好的實踐，因為它放諸四海皆準。

真是太有道理了。如果你的學習過程，發現自己都在忙碌的收集流行術語，以及參加各種經驗分享，搞到最後自己越學愈心慌。此時就應該停下來思考一下，你有看到人家背後的理論基礎、框架或模型嗎？

舉個Teddy自身的例子，Teddy博士論文的題目是「Java例外處理設計與重構」。一開始Teddy並不是研究這個題目，而是先研究pattern language，幾年後改研究design by contract裡面的contract specification。design by contract其實包含了contract specification與exception handling，但當時Teddy覺得exception handling太難，雖然有很多程式範例與所謂的best practices，但就是缺少一個理論框架，所以這一大堆例子與best practices在實際應用的時候經常互相衝突或不足夠完整解決問題。柿子挑軟的吃，所以Teddy一開始只研究contract specification。

後來陰錯陽差，花了許多時間研究exception handling，也建立了一個理論框架（很簡單的理論XD）來解釋例外處理設計的問題。有了這個框架，分析與設計應用系統的例外處理就變得很有系統化。

***

要怎麼從別人的教學中建立知識框架？最重要，也是最簡單的一點，就試看看教學者有沒有給你源頭參考資料。有些人強調自己的內容就是「原創」，但事實上這個世界真的「原創」的知識非常少，絕大部分都是建立在前人的知識體系上增加價值。好的實例，應該要建立在某些理論基礎之上。上課時可以不談這些理論基礎，但必須要提供參考資料，讓學習者課後有機會可以藉由進一步學習理論基礎來建立收納知識的框架以及培養自我解決問題的能力。

小心「斷水流式」的第二手 （第或N手）知識傳遞，無法追源溯流的知識只能在非常特定的情況下使用，跟「呼名大法」（請參考〈自我感覺良好神功（１）：呼名大法〉）相去不遠矣。

***

友藏內心獨白：巨人知道你站在他的肩膀上嗎？