2016吉隆坡、馬六甲、新加坡考察之旅Day6-B雞粒飯午餐 & 很多博物館

June 16 18:11~18:40

▼離開三寶廟之後往回走，打算到雞場街吃午餐。經過一條兩旁都是中文招牌的道路，雖然不在雞場街範圍之內不過也很有南洋的味道。

▼沒多久就來到雞場街對面荷蘭紅屋區。

▼中午再吃一次馬六甲有名的雞粒飯。

***

▼吃完午餐後去逛荷蘭村旁的博物館和鄭和紀念館，館內展示了很多馬六甲的歷史文物，還有華人、馬來人的文化，以及介紹歐洲人、日本人占領此地的歷史。

▼鄭和紀念館，小小一間看完之後Kay和Teddy還以為還沒找到它，後來才驚覺這就是鄭和紀念館…Orz。

▼荷蘭教堂，就在博物館旁邊。

***

友藏內心獨白：看得夠徹底了。

敏捷開發的價值

June 13 22:16~23:13

▲Eiffel內心獨白：幹嘛我做什麼你也跟著我做什麼！

問題

敏捷開發被稱為是一種「價值驅動」的開發方法，不知道鄉民們有沒有想過，敏捷開發所談的「價值」來自於何處？

***

顯而易見的價值

價值驅動最常顯現在兩個觀點上面：

• 優先開發對使用者最有價值的功能：從使用者的角度來思考，哪些功能是他們最迫切需要的？迫切需要可能是可以幫助使用者賺更多錢、省更多成本或時間、提高服務品質、去除痛點等。
• 減少上市時間：這也是許多人（特別是老闆）對於敏捷開發的第一印象：「敏捷就是快」。「快速上市」對於企業和客戶都是一種很高的價值，可以提早推出產品，就可以吸引喜歡嘗鮮的客戶，也可以因此獲得使用者的回饋進而修正下一代或下一版產品的開發方向。

以上兩點經常是彼此互相幫助的力量。因為「不知道（更常見的情況是沒有能力預知）」使用者真正想要的是什麼，所以只好透過「小步快跑」（縮短上市時間）的方式期望藉由不斷地迭代來改善產品，以便做出對使用者有價值的功能。

到此為止都很完美，為了做出對使用者最有價值的功能，所以採取小步快跑的模式。但是，鄉民們有沒有覺得哪裡怪怪的？

***

價值背後的價值

真的只要透過不斷地「小步快跑」就可以做出對使用的有價值的產品嗎？

是什麼機制讓團隊可以「持續」小步快跑下去，而不會變成「小步慢跑」、「小步亂跑」或是「腳麻了不能跑」？

要回答這兩個問題，企業需要注重以下價值：

• 增加產品品質：品質的不好的產品，就算使用者因為新鮮感或獨特性而暫時忍受，日後等競爭產品出現很可能立刻投入敵人的懷抱。
• 增加產品的彈性：敏捷開發強調「回應改變（responding to change）」甚至是「擁抱改變（Embrace Change）」，如果你的軟體已經變成硬體（請參考〈讓軟體變軟的兩個原則〉），要如何回應改變？無法回應改變，也就阻止團隊及時推出產品的能力（無法做到減少上市時間）。
• 降低成本：在相似功能、相似品質、相似開發時間的條件下，開發成本越低的團隊或產品自然比較有競爭力。對企業或客戶來說降低成本也是一種重要的價值。
• 增加產品的生命週期：簡單說就是比較耐用。花同樣的錢，有的產品過了保固期隔天馬上壞掉，有的產品過保固期之後還可以用好幾年，當然可以用越久的產品對客戶越有價值。

***

結論

產品價值來自於做對（do the right thing）、做好（do the thing right）、做得更快（do it faster），在Scrum框架下，同時具備這三者，需要Product Owner、開發團隊、Scrum Master一起合作，才可以達到價值驅動的目的。

***

友藏內心獨白：做對、做好，但做得比別人慢也是白搭。

當Pattern遇到Scrum（4）：Sprint

June 09 17:30~18:30; 20:55~21:34；22:27~22:56

▲圖片節錄自Google搜尋「衝刺」結果

Sprint Pattern

今天談Sprint，該模式的原文在此，有興趣想詳讀的鄉民可以參考。今天看Context、Problem、Force、Solution這四個元素。

Context：你有一個價值流與產品代辦清單（Product Backlog）定義暫定交付項目與交付順序。遵循敏捷精神，你正努力儘早交付並抓到可定期產品增量的節奏，同時管理生產成本。

Problem：如何組織開發流程？

Forces：

• 人類最基本的流程建基於節奏，節奏實現了儀式和文化上的其他可見事件。隨著文化成熟，新人可以藉由學習這些節奏來融入這個文化。
• 你要管理風險：長期複雜的專案太常交付錯的功能，或無法在時程內交付原先計畫的功能。
• 產品開發應符合企業期待，定期且準時的交付令人滿意的內容和價值。
• 理想上團隊可以依據需要及時生產任何東西，但如果沒有保持某種節奏，長期來看團隊很難持續且穩定的交付產品。
• 敏捷團隊需要隨時探索（inspect）與適應（adapt），而團隊成員的工作表現通常基於他們所完成的工作與改善成效。在探索與適應的過程中，團隊成員需要知道他們朝向正確的業務目標前進。

Solution：採用稱為Sprint的重複、頻繁且固定長度的時間間隔來組織開發流程。Scrum團隊的Sprint周期通常介於2~4週，在此期間團隊致力於完成交付任務。Sprint的短回饋週期特性並可有效降低重工的比例與成本。

***

討論

針對Sprint模式今天專注在Forces上面。Teddy有一位朋友原本團隊採用Scrum，前一陣子他迷上看板（Kanban），覺得看板沒有Sprint（iteration）的限制，採用流（flow）的方式管理工作，這樣子好有彈性啊。看板也不要求像Scrum一樣組織跨職能團隊，現有的角色繼續維持，採用漸進式方法引入變革，真的是好棒棒啊。

於是他心一橫，將團隊由Scrum轉型為看板。原本一個sprint開一次review會議取消了，retrospective會議也改成「有需要才招開」，美其名為JIT retrospective（Just-In-Time retrospective，即時自省會議）。反正看板只要測量lead time然後管理工作流就可以了，這樣子容易很多啊。

沒過多久，朋友的老闆受不了了。以前跑Scrum每個sprint至少都還看得到團隊有「生出一點東西出來」，改用看板之後，這種「節奏」不見了，所以老闆很擔心，然後變得不開心，最後直接插手要求改回Scrum。

其實看板雖然拿掉了Sprint，但看板也講究「節奏」。Teddy的朋友沒有注意到Sprint原本要處理的Forces，其實改成看板之後這些Forces並沒有消失，依然存在。朋友改了Form（形式），也就是把Scrum改成看板，Sprint變成Flow，卻沒有注意原本的Forces在新的看板方法中有沒有被平衡、如何被平衡。在原本的Forces沒有被平衡的情況下，最後的結果（Resulting Context）不被老闆接受，只好打回原形，乖乖繼續跑Scrum。

出一個題目給鄉民們當作練習：

• 請問Sprint模式所提到的這些Forces，在看板方法中是否依然存在？
• 如果存在，看板方法如何回應這些Forces？
• 如果不存在，針對「如何組織開發流程？」這個問題，看板方法所處的Context是什麼？所遭遇的Forces又有哪些？

***

友藏內心獨白：期末考會考嗎？

當Pattern遇到Scrum（3）：Product Owner

June 05 23:01~23:49

▲沒有破壞，就沒有建設。

Product Owner Pattern

今天談一個比較容易理解的角色：Product Owner。該模式的原文在此，有興趣想詳讀的鄉民可以參考，今天來看Context、Problem、Force、Solution這四個元素。

Context：Scrum團隊成員需要一個單一、組織良好且循序的產品清單項目（Product Backlog Item）列表讓他們可以專注於交付價值。缺少這個列表團隊成員可能做出客戶從不或很少使用的功能、在錯誤的時間點交付功能或根本沒有交付任何功能。

Problem：誰該對Product Backlog負責？

Forces：

• 由一群人負責規劃產品需求可以獲得各種不同的看法，特別是當這群人來自不同部門與不同背景。
• 一群負責規劃產品需求的人如果只是抱持著「被諮詢」的態度，沒有一個人被授權對各種意見做出最後決定並扛下責任，則整個產品需求決策過程會拖很久而拉長產品上市的時間。
• 如果好幾個負責規劃產品需求的人都是「老闆」，有權做出最後的決定，則很有可能這些人彼此的意見都喬不攏，最後導致冗長的討論與政治角力。
• 雇用專職的專案經理來管理專案開發活動與進度是很普遍的做法，但這種作法並不能解決問題。因為團隊開發的是「產品」並不是開發專案，而專案經理並不負責開發產品所需關注的投資報酬率（ROI）。

Solution：讓一位Product Owner（產品負責人）來排序Product Backlog項目、負責產品願景以及交付願景過程中所產生的價值（也就是投資報酬率）。

***

討論

看完上述內容，鄉民們可以試著思考下列三個問題：

1. 除了上面這四個forces以外， 關於「誰該對Product Backlog負責」這個問題，在你的專案中是否還存在其他不同的forces？
2. 你的Product Owner是否平衡了這些forces？
3. 套用Product Owner這個模式可能產生那些結果（Resulting Context）？

***

友藏內心獨白：沒人負責就做不出好產品。

當Pattern遇到Scrum（2）：Scrum Master

June 02 16:36~17:23

▲畫面節錄自電影《達摩祖師傳》

Scrum Master Pattern

今天繼續從pattern（模式）的角度探討Scrum Master這個經常聽到卻不容易做到的角色。Scrum Master模式的原文在此，有興趣想詳讀的鄉民可以參考，在此Teddy想專注在Problem、Force、Solution這三個元素上面。

Problem：如何協助自組織團隊持續改善？

Forces：

• 團隊需要有人監看領導、鼓勵、指出有紀律的工作方式，並且讓團隊溝通保持透明與誠實。
• 團隊有時需要一個對外溝通的官方代表但又找不出合適的團隊成員。
• 在一個極度平等主義的自組織團隊中，沒有人願意主動承擔上述活動的責任。
• 在傳統專案中，透過專案經理的角色來解決上述問題，以便讓事情順利進行。 然而，這種做法使團隊成員把團隊的問題視為「別人（專案經理）的問題」，不會主動以最令人滿意的方式解決問題。

Solution：選擇一位ScrumMaster，用來協助團隊有效率的執行Scrum並且做到持續改善。Scrum Master藉由採取客觀的角度來觀察團隊以完成他的任務。Scrum Master負責協助團隊持續變得更有效率。

***

討論

由ScrumMaster模式的描述，可以看到：

• Scrum Master模式主要在談ScrumMaster對於開發團隊的責任，當然Scrum Master對於Product Owner也有輔助的責任，不過這一點在Scrum Master模式中只有在Resulting Context的地方談了一點點，這也反映出在一般的Scrum專案中的狀況，也就是Scrum Master比較多的時間都在和開發團隊「搞再一起」。
• Scrum Master模式所要解決的問題Teddy整理成「如何協助自組織團隊持續改善」，狹義來的來自組織團隊就是開發團隊，廣義來看包含開發團隊與Product Owner。
• 既然Scrum Master的主要責任是協助持續改善的發生，那麼所有可以用來協助團隊愈來越好的方法都可以收錄到Scrum Master的工具箱中。例如，Servant Leader、Coach、Process Authority、Interference Shield、Impediment Remover、Change Agent、Facilitator。以上技能，任何一項各別來看都是一種獨立的專業。要同時在一個人（角色）身上找得具備以上所有能力，是很不容易甚至可以說是「不可能的任務」。這也是為什麼好的ScrumMaster在市場上一直缺貨的原因。
• 但是，好的Scrum Master是可以協助團隊持續成長、持續改善的人，並不是技能收集越多越好的人。如果把每一種專長看成一種 Force ，想要成為怎樣的Scrum Master，端看自身對於這些Forces的回應。最合適的Scrum Master不一定是平衡全部Forces的人，因為還有Context（公司文化、團隊組成）這個因素要考慮。而且整個Context處在動態改變的狀況，有時候可能Impediment Remover作用力大一些，有時候Coach責任重一點，有時候又要發揮Servant Leader的魅力，帶領團隊無怨無悔地朝向敏捷持續改善。

結論就是：不要期待依靠一位十項全能的Scrum Master幫你的團隊解決全部問題，但你的確需要一位具備「改善魂」的Scrum Master。不只團隊需要持續改善，Scrum Master自己也要有能力持續成長。

***

友藏內心獨白：沒有最好，只有更好。