Scrum團隊如何落實自動化測試與持續整合？

Feb. 13 15:25~16:26

問題

朋友的Scrum團隊跑了半年，每個sprint結束所產生的可執行軟體離「潛在可釋出」還有一大段距離（品質不是很好）。團隊開始思考要如何提升品質，讓每個sprint可以交付「潛在可釋出的產品增量」。

團隊從QA部門借調一位測試人員—QA甲，希望借助他的力量提升軟體品質。但是QA甲以往都是用人工手動測試來驗證功能的正確性，並不會撰寫自動化測試案例。因此，QA甲需要等待團隊成員完成user story之後才可以開始測試。但通常user story完成後也接近sprint尾聲，沒剩多少時間讓QA甲去手動測試。

有團隊成員建議，請QA甲在下個sprint測試上個sprint的功能，但是這又引發出其他的問題，例如：

• 程式碼凍結：QA甲要測試上個sprint的功能，就必須要求開發團隊不要修改上個sprint所完成的功能。實務上並不可行，因為下個sprint很有可能就是要基於上個sprint所完成的功能繼續開發，要求程式碼凍結會讓開發流程過於僵硬。
• Done Done：因為上個sprint完成的功能留到下個sprint才驗收，那到底上個sprint做完的功能真的有做完嗎？換句花說，上個sprint的Done不是真的Done，還要經過下個sprint的驗證後才知道是不適真的Done。那如果下個sprint找出上個sprint的bug，又該在何時處理？如此一來，沒完沒了，整個開發時程也不容易掌握。

***

理想狀況

自動化測試與持續整合是軟體開發（不管是否採用敏捷）不可分割的一部分，團隊一開始在撰寫功能之前，就要先把持續整合環境架設好，讓自己的空專案可以在持續整合系統上建構，之後才逐一開發新功能。而每一個新功能，都要有足夠的自動化單元測試、整合測試與驗收測試。

為了達到測試自動化的目的，在Scrum團隊中的QA人員（Scrum團隊成員通稱為開發人員）需要具備撰寫自動化測試案例的能力。如果負責測試的開發人員沒有撰寫自動化測試案例的能力，就要考慮：

• 是否願意學習新技能，並且與開發人員一起緊密合作
• 考慮離開Scrum團隊

Teddy的意思並不是說所有的測試案例都必須要自動化，有些測試案例，例如UX方面的測試，或是自動化成本太高的UAT，或是探索式測試，還是可以用人工的方式來做。但大原則是絕大部分的測試必須要自動化，而身處Scrum團隊的測試人員也必須具備撰寫自動化測試案例的能力。

***

非理想狀況怎麼辦

如果團隊已經跑Scrum一陣子，一開始沒有落實自動化單元測試與持續整合，要怎麼「半路出家」？

假設團隊中沒有任何一個人具備自動化測試與持續整合個觀念，最快的方式就是請人教，或是去上課，把基本的知識在短時間先補齊。

接下來可以在DoD（Definition of Done）中訂定自動化驗收測試的標準，讓往後所開發的功能都有基本的自動化驗收測試。至於之前所開發的功能，可以採用以下兩種方式來補寫自動化測試：

• Bug-driven：當發生bug的時候，先寫一個自動化測試案例來反映這個bug。此時這個測試案例一地會失敗，然後去修改程式碼，直到測試案例通過就知道bug改好了。
• 預算制度：每個sprint投資固定時間去補寫之前的自動化測試案例。

***

測試先行或測試後行？

有些技術能力比較好的團隊，會採用測試先行（test first），也就是測試驅動開發（test-driven development）、行為驅動開發（behavior-driven development）、實例化規格（specification by example）的方式，讓撰寫測試案例成為開發流程中的上游，test code先於production code，以避免測試後行（test last）的缺點—先寫production code，永遠沒有時間寫test code。

Teddy覺得測試先行或是後行都可以，但重點是「測試一定要行」。只要有紀律，養成測試是開發不可分割的一部分，測試先行或測試後行可以依據團隊的能力與專案特性自行調整。

***

友藏內心獨白：自動化才能提高QA的價值。

繞過去，好嗎？

Jan. 31 23:07~23:58

▲逢山開路，遇水搭橋

問題

從去年開始Teddy和指導教授一起帶幾個實驗室學生做研究，目前遵循clean architecture的方法正在開發看板軟體。一個多禮拜前學生問Teddy關於Repository的介面設計，經過討論後Teddy請他們做點研究，下次開會再談。

今天回學校和學生開sprint review會議，順便請學生說明他們研究Repository的結果。學生告訴Teddy他們發現有兩種Repository的設計方法，第一種是接受由外部給定的specification當作查詢條件，可以比較有彈性的支援多種查詢條件。第二種是在Repository介面上設計常見的方法，例如findAll、findById、findChildrenById等。

學生採用第二種設計方法，聽了請他們選擇的理由後，Teddy還是覺得不滿意（forces沒有被平衡XD）。於是請學生把domain model叫出來，一起讀過一次，發現他們所採用的Repository介面設計無法支援domain model的所有物件。

***

程式可以動啊

學生寫的程式可以動，這個sprint所完成的user story還算做得不錯。但是，如果細看軟體設計，其實還有不少可精進之處。

Teddy告訴他們：

Repository的問題還沒徹底解決，雖然程式可以動，但是如果不管這個設計問題，繞過去，以後你們還是有很大的機會會再遇到它。你們是研究生，專案中遇到問題應該利用機會把問題搞懂，徹底解決。日後遇到同樣的問題，既使context不同，別人花三天，你們只要花一小時就可以解決。層次與專業就是這樣累積出來的。

這個問題，最好的解決方式就是你們搞懂後做出設計的決定，然後說服我（教我）。次一等的解決方式，就是我弄懂後教你們。最糟的方式就是不管它，反正程式可以動就好。

***

Repository Pattern

因為Google太方便，所以學生遇到問題尋找資料，大多下個查詢條件，然後看最前面的幾個連結之後就做出結論，草草結束。Teddy在〈增進學習力的三個練習〉提到，首先要知道名詞的定義。學生只知道可以套用Repository pattern，但很可能對於該pattern的定義只是一知半解。

在《Patterns of Enterprise Application Architecture》的第322頁就介紹Repository pattern。在《Domain-Driven Design: Tacking Complexity in the Heart of Software》以及《Implementing Domain-Driven Design》也都有提到，後者並且包含範例程式碼與實作細節。

***

龜毛

大家都說日本人做事很龜毛。同樣的商品，例如Toyota汽車，MIT和MIJ，相信大部分的人還是比較喜歡日本原裝進口。為什麼？因為組裝的人不一樣啊…Orz

軟體開發是一種專業，就好像醫生也是一種專業。你總不希望醫生開刀的時候遇到問題「繞過去」吧？！反正 程式可以動 人還有呼吸就好XD。 

***

友藏內心獨白：書還是要讀，不能只看網路文章。

只聘請願意寫單元測試的軟體工程師

Jan. 30 17:48~19:00

▲古早味的VB程式

一個測試，各自表述

一位從事測試工作的朋友告訴Teddy，他在應徵工作時主管告訴他，公司的工程師都有做單元測試。到職之後，有一天朋友去找工程師…

朋友：我可以看一下你寫的單元測試程式嗎？

工程師：什麼程式？

朋友：單元測試程式，主管說你們都有做單元測試。

工程師：喔，單元測試喔。有啊，不過我們都是手動測試，自己手動測自己寫的function。

朋友：（黑人問號？？？）

***

自動化

單元測試是指對程式可執行的最小單位（單元）進行測試，可能是function或是object。一般而言單元測試如果沒有特別強調，預設狀況下應該會認為是自動化單元測試，也就是透過單元測試程式碼（unit testing code）去測試生產程式碼（production code）。

Teddy剛開始寫第一個自動化單元測試是N年前還在用VB 6.0開發Windows軟體的時候。寫過VB（非現在的VB.NET）程式的鄉民都知道，VB的程式邏輯很容易和UI元件產生緊密耦合，必須透過使用者介面來測試系統功能。Teddy從台北工專電子科畢業，然後當兵，到退伍，寫了好幾年的VB程式，獨自開發7~8個不同的系統。

一開始也都是自己手動測試系統功能，但是時間久了之後覺得好累，因為手動的「廻歸測試」簡直不是人幹的工作，太花時間、累人又無聊。但是如果不手動「廻歸測試」，什麼時候修改功能造成bug又不知道。等到客戶踩到雷回報錯誤，又有漫長的除錯工作和加不完的班，也是很討厭。

後來JUnit被發明且流行之後，Teddy才知道原來有自動化單元測試這種東西。可惜當時沒有免費的VB Unit工具，從網路上花了幾十塊美元買了一個VB Unit工具，正要興高采烈的寫單元測試時，才發現寸步難行。因為VB程式的邏輯很容易全部都寫在使用者介面中，根本無法單獨測試邏輯。

***

相依性分離

後來才知道原來VB可以寫OCX與DLL元件，沒有使用者介面的程式邏輯可以寫在Class裡面包成DLL（VB 6也有Class，支援介面繼承但不支援實作繼承）。把程式邏輯從UI元件抽離，改放到DLL之後，便可以對DLL寫自動化單元測試。

有了這次經驗，開始愛上單元測試。雖然自動化單元測試不能完全取代透過使用者介面執行的驗收測試，但可以大幅減少手動測試的數量，而且當單元測試案例執行失敗時，也可以減少除錯的時間。

另外還有一個好處，就是為了提高自動化測試的程度，程式的模組化也提升。以前Teddy很瞧不起VB 6，認為它不是一個「完整的物件導向語言」（因為不支援實作繼承）。但後來又讀了〈Design Patters〉，才知道原來應該多用物件聚合少用實作繼承。VB 6也可以寫出很棒的物件導向程式以及套用設計模式。

***

今天暫時停止

近20年後的今天，在台灣會寫單元測試的工程師已經很多了……才怪。和20年前相比的確是變多了，但是以全體程式開發人員當分母來看，工作上把「撰寫單元測試當作軟體開發不可分割的一部分」的工程師還是少數。這種狀況不知道是要歸咎於台灣的資訊教育有待加強，還是職場的大環境不支持。

一個沒有自動化單元測試的團隊，手邊的軟體不是「軟體」，而是「硬體」，硬梆梆的沒人想改也不敢改。這種情況還學人家談什麼敏捷開發、擁抱改變，早點洗洗睡吧。

***

軟體工程師要提升自己的價值，除了學好物件導向技術以外，最立竿見影的方法，就是開始寫自動化單元測試。

***

友藏內心獨白：一試成主顧。

流程權威

Jan. 29 21:28~22:31

▲起床了

問題

上周末在泰迪軟體上【Scrum敏捷方法實作班】，休息時間有一位學員問Teddy…

學員：《Essential Scrum》書中提到Scrum Master的責任，其中有一點是「流程權威（Process Authority）」。請問我要怎麼讓自己變成流程權威？

***

狹義來說

Scrum Master協助團隊、Product Owner、與公司獲得Scrum的好處（請參考〈Scrum Master 的存在〉） 。因此Scrum Master對於Scrum框架與價值、原則、實務做法等，都必須要非常熟悉。

換句話說，Scrum Master必須是敏捷專家。這一點聽起來好像很簡單，但Teddy遇過很多Scrum Master，即使已經上過CSM、CSPO的課程，但對於基本的敏捷精神與Scrum框架還是一知半解。

舉幾個例子：

• 只有Product Owner能撰寫user story。
• 只有在review meeting時可以review做完的user story。
• Sprint長度越短越敏捷，所以團隊不管怎樣就是要採用一周一個sprint。
• 在Review meeting討論流程改善，在retrospective meeting討論需求。
• 把cross-functional與multi-skills搞混。
• 把actively doing nothing搞成passively doing nothing。
• 這個sprint兩個禮拜功能做不完，所以動態調整把sprint改成三周。
• Sprint review只管完成user story的個數，忽略交付給使用者的價值。

***

廣義來說

Teddy認為敏捷開發的各個派別，XP、Scrum也好，精實開發、看板方法也罷，只是不同人對於追求 「The timeless way of software development（軟體開發的永恆之道）」所提出來的見解。

「能量不滅」，傳統軟體工程所探討的問題，敏捷開發幾乎都會碰到，只是敏捷開發採取的應對策略可能有所不同，但要解決的共同大問題就是那一個。所以要成為流程權威，就必須知道軟體工程所探討的問題，然後回頭對應敏捷方法如何處理這些問題。

最好有自己參與過軟體開發的經驗，包含專案與產品開發，與不同程度與背景的人合作，越多樣性越好。親身體驗軟體開發的各種forces（作用力、限制條件），越能夠感受軟體開發的Quality Without A Name（無名的特質）。

***

誰適合當Scrum Master

經常有朋友問Teddy：「哪種人適合當Scrum Master？」依據《Essential Scrum》的看法，Scrum Master必須是：

• Coach
• Servant leader
• Process authoring
• Interference shield
• Impediment Remover
• Change Agent

以上任何一點只要做到極致，就已經是該領域的專家了。而Scrum Master居然要同時精通「武當六絕」，這根本需要百年難得一見的練武奇才方能達成使命。難怪有一位HR曾經跟Teddy開玩笑說：「找Scrum Master好像在找聖人一樣」。

誰適合當Scrum Master？不同背景的人，只要具備上述能力其一，就有機會擔任Scrum Master。Scrum Master也是人，也需要持續學習。如果是coach背景的人當任Scrum Master，也許對於軟體開發流程不熟，就需要補足這方面的能力。如果是老闆的兒子或女兒當任Scrum Master，應該在阻礙排除、干擾屏蔽與變革代理有很大的貢獻，但其他責任可能就需要補強。

總之，將相本無種，人類當自強。

***

友藏內心獨白：把自已當成一座橋梁，理論與實務的橋樑。

Product Owner的怨念

Jan. 29 10:22~11:48

▲排除阻礙可以改善開發進度

價值驅動

在Scrum框架中，Product Owner的主要責任是負責產品的投資報酬率（ROI），換句話說要釐清對使用者有價值並且能為公司帶來收入的需求，並依據需求的價值安排施工順序。

但是，「使用者價值」是很抽象的概念。幸運的話，等產品上市之後，從銷售量與使用者回饋得以驗證。不幸的話，產品釋出乏人問津，怎麼死的都不知道。

***

PO心中的痛

既然價值不好控制也不易評估，許多Product Owner便將眼光放在「進度控管」上面，畢竟產品的釋出進度也是Product Owner需要負責的部分。Teddy認識的Product Owner，10個裡面有11個或多或少都覺得開發團隊進度太慢。Product Owner經常公開或私下抱怨：

為什麼這個sprint只拿那麼少量的user story？

每個sprint承諾的user story為什麼總是做不完？

承諾的user story做不完為什麼沒有「自願加班」把它做完？

***

為什麼快不了？

「預估進度與實際進度不符」是軟體開發經常面對的問題。根據字面上的意思，「預估」原本就包含「猜測」與「誤差」的涵義，而「實際進度」總是要等做出來之後才曉得。所以「預估進度與實際進度不符」實屬正常現象，請安心服用。

但是，身為Product Owner還是要為產品的整體進度跟老闆或客戶交代，因此無法容忍實際進度跟「Product Owner腦袋中的進度」相差太大。如同Teddy常說的，Scrum只是一面照妖鏡。Scrum跑的好，可以反映出個人、團隊與組織的現況。如果Product Owner覺得團隊進度太慢，應該與團隊一起探討關於進度認知落差的原因，例如：

不熟悉Scrum：剛開始接觸Scrum的團隊，前半年可能都還在熟悉Scrum與敏捷開發的思維與團隊合作模式，因此開發進度會比較慢。

團隊的真實進度就是如此：以前隱瞞現實狀況才讓進度看起來符合預期，例如：犧牲品質、功能沒有做完但卻宣稱已完成，反正有問題等QA測試再來除錯就好了。現在跑Scrum，透明性增加，只是反應出團隊的真實狀況而已。

需求的不確定性高：需求的不確定性高，或是Product Owner與開發團隊缺少問題領域的專業知識，導致邊開發邊釐清需求，以及增加重工（rework）的時間。

技術的不確定性高：開發過程採用太多新技術，因此團隊成員需要花很多時間去學習與熟悉這些技術。加上新技術通常不太穩定，學習資源也比較少，因此增加團隊的學習曲線。例如，採用新的JavaScript框架、新的程式語言、新的軟體架構、新開發環境或建構工具。

多工與中斷太多：除了開發工作，團隊經常被中斷處理其他產品或專案的維護或救火工作。這可能代表以前開發的品質太差，現在回過頭來「討債」。或是每個人負責的工作太多，多工切換導致浪費，雖然每個人看起來很忙，但真正花在工作上的時間反而很有限。

外部相依性高：開發的產品有很多外部相依性，例如需要與協力廠商配合，或是開發軟體相依於公司其他部門的韌體與硬體。無法有效管理外部相依性，因而影響到產品開發的進度。

開發環境與設備太爛：有些公司業務團隊就在開發團隊的隔壁，業務與客戶講話自然音量比較大，干擾了開發團隊的思緒。另外，開發設備太爛也會嚴重影響開發進度，例如開發電腦太慢、記憶體太小、沒有雙螢幕、鍵盤太難打、持續整合伺服器跑太慢、測試設備不足等，都會影響開發進度。

開發人員不適任：進度太慢當然也可能是開發人員本身的問題，可能能力不符合團隊的期望，而且一直無法有效提升自己的能力。或是有些團隊成員立志當米蟲，能撈就撈、能混就混。也有些人比較適合傳統瀑布式專案，一個口令一個動作，不習慣Scrum團隊的自組織模式，因此表現不佳。遇到這種情況，就不需要客氣，該換人時就需要換人。

***

對症下藥

沒有Product Owner會嫌自己團隊開發太快，只會覺得可以再快一點嗎。但Scrum的目的原本就不是快，而是讓公司可以在快速變動的環境之下保持成功。Scrum跑的好，首先可以反應出團隊現況的生產力。不管有多慢，很抱歉你的團隊就是這樣，除非你有能力可以換一個你覺得更棒的團隊，否則請先接受這個事實。

接下來才能夠靜下心思考，如何讓你手邊這個由派大星、海綿寶寶、天線寶寶與珊迪所組成的團隊，可以在兼顧需求交付的前提下，透過迭代與增量的方式，逐次提升團隊所能交付的價值。

這並不一定代表團隊馬上就具備越開發越快的能力，也有可能是Product Owner更能判斷客戶所需要的價值，因此開發越少的功能就能夠具備足夠的產品競爭力。也有可能是改善價值鏈的瓶頸，使得工作流動更順暢，減少交期（lead time）。當然團隊成員的投入程度、溝通與解決問題能力的提升，也是提升交付速度與價值的重要因素。

***

友藏內心獨白：敏捷就是最大化未完成工作的藝術。

台北101蘋果直營店送修MBP

Jan. 28 17:06~18:15

電池膨脹

▼Teddy有一台2016年購買的MBP 15”，平常當作桌機使用，附加功能就是Eiffel與Ada的熱墊。

去年12月初，無意中發現MBP的螢幕無法蓋起來，仔細一看才發現應該是電池膨脹。聯絡Apple 線上客服，把照片傳給客服人員，對方也覺得是電池膨脹，請我不要再使用電腦，趕快送修。

研究了一下網路上的資料，打算預約台北101蘋果直營店送修，但刷了好久的網頁全部時段都是預約額滿，根本無法松修。退而求其次找台北車站的Studio A，也是預約額滿。後來12月中出國，就拖到今年才處理。

***

僥倖預約成功

回國後又忙了一陣子，眼看MBP「大肚便便」，深怕有一天電池爆漿，要是把整台筆電都弄壞就慘了。最後放棄送修台北101蘋果直營店的想法，預約了德宜台大店，雖然網路上似乎風評不佳，但只有這間離Teddy家還算近的蘋果授權維修店還有預約的名額。

但是，有一天晚上失眠，1點多左右突然看到台北101蘋果直營店有一個送修時段。預約成功的當下，感動到快哭出來，比中了200元發票還高興XD。

***

送修

1月24下午提早一個小時出門，沒想到塞車加上找停車位，最後趕在3:11分才到達蘋果門市。現場狀況就跟網路上描述的一樣，人很多，標示不清。更精確地講，沒有任何標示。據鄉民表示送修要在一根大柱子旁排隊，走到大柱子旁抓了一位穿黑色外套紅色T恤的店員，確認這裡是送修的排隊隊伍。之後就等待蘋果的維修人員有空時會來找你確認資料。

等了不到10分鐘，就輪到Teddy。確認預約資料後，被帶到大桌上等待維修人員。

▼2~3分鐘後維修人員來，Teddy告知MBP疑似電池膨脹。維修人員看了一眼馬上就確認，真的是膨脹XD。二話不說開了維修單，做了基本的硬體檢查之後，告知Teddy換電池連同鍵盤與觸控板會一起換掉。因為Teddy有購買蘋果的延長維修服務，MBP用了兩年還在保固期內，所以不需付費。

送修過程還算順利，下午3:30我就離開蘋果門市，整個過程約20分鐘。

以下是維修費用，如果沒有保固要自負15,514元（未稅）。當初購賣AppleCare花了11,334元（未稅），算是有賺回來XD。

***

維修完成

Teddy要維修的零件有庫存，預計3~5天可完成。1月24下午送修之後，隔天1/25晚上7點就收到維修完成的通知。但26、27日Teddy剛好要上課，等到今天才去取件。

取件的過程一樣不知道要去哪裡排隊，問了店員，原來就在送修隊伍的右手邊走道。核對證件之後，很快拿到筆電。確認可以開機，看起來沒什麼問題就走人了。

***

後記

蘋果直營店的店員很客氣，但不知道為什麼，透著一種刻意想要營造某種氛圍的感覺，不知道用什麼言語形容（Quality Without A Name…XD）。

可能是電池膨脹的問題比較沒爭議，所以送修過程很順利。但前提是，你必須能夠預約到蘋果直營店…Orz。

***

友藏內心獨白：新的iMac什麼時候才要上市啊（敲碗）。

Product Owner 的存在

Jan. 15 12:48~14:33

▲擁有就要負責，不要製造流浪產品。

作為解決方案

Product Owner（產品擁有者、產品負責人）這個角色接近傳統專案的產品經理或專案經理，雖然傳統專案沒有這個角色，但Product Owner目的與責任並不難理解。畢竟不管瀑布式專案或敏捷專案，總是要有人來管理需求與規劃產品藍圖，

依據中文版Scrum Guide對於Product Owner的說明：

由此可看出Product Owner藉由管理Product Backlog將產品價值最大化，其他文字敘述則是進一步解釋Product Owner這個角色如何達到此目的常見做法，也就是對Product Owner這個解決方案的詳細說明。

***

解決什麼問題

如果Product Owner是一種解決方案（Solution），請問他要解決的問題是什麼？

從Scrum Guide的敘述，Product Owner要解決的問題有三種可能的表達方式：

Problem 1：如何最大化產品價值？

Problem 2：如何管理Product Backlog？

Problem 3：如何管理Product Backlog以最大化產品價值？

Solution：指派一位Product Owner來負責。

***

Product Owner Pattern對於Product Owner的描敘則是：

One person needs to be responsible for the Product Backlog. This person needs deep domain knowledge, business insight, understanding of product technology, technical dependencies, and the authority to force rank the backlog to maximize business value.

（一個人需要負責產品Backlog。 此人需要深入的領域知識、商業洞察力、對產品技術的理解、技術相依性，以及排序代辦事項以最大化商業價值的權限。）

依據Product Owner Pattern的描述，可以將Product Owner要解決的問題寫成：

Problem：如何管理Product Backlog？

Solution：指派一位Product Owner來負責。

***

Product Owner的難題

指派一個人當任Product Owner，透過排序product backlog item （產品待辦事項）來最大化產品的商業價值，即時且持續的交付高價值的產品給客戶，聽起來是多麼理想與合理的一件事。但實務上，好的Product Owner也是很難找。

Product Owner經常遇到以下難題：

• 未被授權：既然Product Owner「擁有產品」，就應該被公司充分授權，才能夠對產品的成敗負責。但實務上，Teddy遇到不少「有名無實」的Product Owner，只是老闆的代理人，大部分團隊提出的問題都無法當場回覆而必須回頭問老闆。遺憾的是，老闆又很忙，無法及時與Product Owner討論，導致整個團隊溝通非常不順，也很容易造成大量的重工（等產品做好之後老闆看到才說這不是他要的）。
• 沒有主見，不願承擔：也有不少Product Owner雖然獲得公司充分授權，但他卻不敢也不想承擔「做決策」的風險。這種Product Owner的口頭禪就是：「由團隊決定、都可以、這個需要再研究。」甚至把做決定的工作「外包」給其他單位，以便到時候萬一產品失敗，可以有人一起承擔「歷史共業」。

　沒有主見或不願承擔，也有可能代表Product Owner　對於產品領域知識不足，也缺乏產品的熱忱。

• 進度壓力無處發洩：依據Scrum框架，Product Owner決定What（做什麼），開發團隊決定How（怎麼做、做多久）。換句話說，完成每一個功能所需的時間是由開發團隊所決定，Product Owner必須尊重。

在傳統的專案開發中，如果產品經理或主管對於開發團隊的進度不滿意，大體脫不了痛罵一頓與祭出激勵手段（棍子與胡蘿蔔策略），最後再要求員工 強迫 自願加班。但採行Scrum之後，Product Owner突然失去「自願加班」這個萬用工具，當他覺得進度落後時，自然會產生焦慮感，然後將此種壓力用明示或暗示的方法轉嫁到開發團隊身上。久而久之Product Owner與開發團隊彼此看不順眼，互相抱怨。

***

熱情與看法

Teddy始終相信，如果你對於產品沒有熱情，就不要擔任該產品的Product Owner。就好像如果你不喜歡貓，就不要貿然的學人家養貓。你可以養狗、養鳥、養烏龜、養兔子、養小孩，甚至什麼都不養。

有熱情，才會想方設法把產品做好。熱情可能來自先天對於產品的喜愛，例如有些人天生就熱愛玩Game。熱情也可能來自後天的訓練，例如你原本不喜歡玩Game，但為了生活從事遊戲開發若干年後，慢慢地愛上玩Game。

對事情有熱情，就會慢慢培養出「職業達人」的堅持。自己對於產品有看法，才不會人云亦云，做出有特色的產品。

***

友藏內心獨白：不要製造流浪產品。