June 21 20:00~22:00
可能是前幾天校對Teddy的「巨作」看得太累了，等到書本送印之後，Teddy整個人好像被榨乾似的，都沒什麼精神。這禮拜接下來的幾天就先以「省電模式」低速運轉一下，下週再重新出發（希望不要本週省電，下週沒電XD）。
有鄉民留言說比較想要知道「Branch/Merge Pattern」，這種需要花腦筋的文章，寫作日期要等Teddy吃了大還丹之後再視情況而定。還有學妹問Teddy：「為什麼學長的粉絲好像都是一些怪怪的人」。沒辦法，物以類聚。Teddy這種怪咖，也只能吸引到一些「怪叔叔」或「楊婆婆」這種天賦異稟的粉絲…XD（請勿對號入座啊XD）。
***
言歸正傳，在這一系列的文章中，Teddy以「Q&A」的形式，來回答鄉民們在執行Scrum時也可能遭遇的問題。先從幾天前在「六月份Scrum軟體開發流程實作班，Day 2」所提出來的10個問題做為開端。
在回答問題之前Teddy想說明一下，很多在導入Scrum時所遭遇的問題都沒有所謂的「正確答案」。Teddy的回答只是依據自己經驗所判斷的回應，不代表在所有的情境下都適用，鄉民們在服用這些「成藥」之前最好還是請教一下「醫生」（鄉民甲：這算是先撇清關係嗎？）。
問題：團隊成員需要花費好幾個小時來準備sprint review，是否需要將準備demo的工作列為task？
回答：Teddy曾經聽過一種說法：「準備sprint demo的時間不要超過30分鐘」。假設鄉民們先勉為其難的接受這種講法，那麼回答這個問題的可能答案應該是反問自己：「為什麼團隊需要花費好幾個小時來準備sprint review？」。在回答「為什麼團隊需要花費好幾個小時來準備sprint review？」這個問題之前，如果貿然把準備sprint review獨立成一個task，那麼有可能會忽略開發流程的潛在問題，也失去了改善的機會。以下是幾個常見需要花費數小時準備sprint review的原因：
- 系統不易佈署：要demo的系統需要花很多時間才裝得起來，所以每次sprint review光是安裝與設定準備demo的系統就花費好幾個小時。造成這個問題的原因最常見的原因就是沒有自動化安裝程式，所以每次都要手動安裝。包含重建資料庫、安裝作業系統、安裝demo系統、設定demo的資料等等。
- 準備review時才發現一堆錯誤：每個Story都「宣稱」已經完成，但是等準備demo前，負責demo的人實際去操作使用之後，才發現一堆問題。
- 製作過多文件：負責demo的人花費過多時間準備demo的文件或精美投影片。這種情況經常發生在被指派到demo某的story的人，不知道要如何正確demo這個story。於是為了保守起見，花了很多時間，準備了很多demo的資料。例如，從該功能的設計文件、演算法、架構圖等慢慢解釋起，最後才demo如何使用該功能。
如果鄉民們的團隊是因為上述原因導致準備demo的時間過久，首先要做的事情不是把demo獨立成一個task，而是要思考如何改善現況。
系統不易佈署
需要花費長時間才可以將系統安裝與設定成功，這可以看成是「持續整合沒有做好」的警訊。如果持續整合作的好，系統應該要很容易可以被自動化安裝，否則就不可能做到「持續整合」（需要長時間才能把系統裝好，這樣的情況是不可能實施「持續整合」的）。所以，團隊首先要做的，應該是要跟Product Owner討論，看看是否可能在後續的sprint中，加入幾個technical story，用來改善團隊實施持續整合的能力。至少在持續整合系統上，每建構一次軟體，都要產生一份安裝程式。團隊成員只要使用這份安裝程式，就可以快速的設定好要demo的系統。
準備review時才發現一堆錯誤
在剛導入Scrum的團隊身上經常可以發現這個問題，同樣地，這也是一個軟體開發流程的警訊，代表團隊的品質不佳。可能是開發人員沒有寫單元測試，或是寫的太少。也有可能是每項工作被移到Done之前，缺少第三者的驗證。團隊可以藉由在DoD中明確定義工作完成的最小要求條件，例如每個method至少要寫三個單元測試，或是在task board中，在Done之前增加一個Review階段，並且規定所有的task在移到Done之前，一定要讓第三者（不是原本認領該工作的人）確認過之後，才可以移到Done。或是團隊也可以藉由實施pair programming來降低產生bug的機率。
製作過多文件
這也是另一個初學Scrum的團隊很容易發現的問題。傳統上，開發人員經常被要求寫所謂詳細（但卻沒人要看）的需求、分析、設計、與使用文件，或是在demo的時後要製作精美的投影片。避免這個問題的方法，可以在sprint review之前，由Scrum Master事先寄出sprint review meeting agenda（請參考「Scrum 是什麼（3）：三種補充文件」），讓準備demo的人員，知道每個demo項目大致有多少demo的時間，以避免準備過多的資料而沒有時間可以demo。
***
看到這邊鄉民們可能會問：「那如果上面三種方法都嘗試了，但是短時間之內團隊還是需要數個小時來準備sprint review那該怎麼辦？」那沒辦法，如果上面幾招都用了，但是都沒有效果，很有可能是團隊在每個sprint中安排太多功能性story（functional requirement），導致沒有時間去關注品質或是流程改善（例如撰寫單元測試與做好持續整合）的議題。在這種情況下，團隊也許該考慮是否每個sprit不要安排那麼多的功能性story，讓團隊有足夠的時間可以逐步提升敏捷實務做法的能力，也許幾個sprint之後團隊的開發流程會變得比較順一點。
最後，如果Teddy所建議的方法都沒用，那鄉民們就放心地增加「準備sprint review」的task到每一個story裡面吧。反正法律也沒規定「準備sprint review」不能變成一個單獨的task…XD。
***
友藏內心獨白：法律沒規定的事可多的哩。
