佳麗很快在Pete 協助下的搬到他們刻意經營出來的專案辦公室，Gavin為了促進溝通順暢，也搬出自己的小辦公室，與大家坐在一起，由於人數只有七位，基本上每個人都可以不需要走動就可以與任何一位對話。除了可移動的大白板，上面貼了幾張 Gavin 寫下來的 Sprint Backlog Item 紅黃便利貼外，Cash 與 Fields 還一起製作一個頗有戰鬥指數的招牌 『AI 探索 War Room』垂掛在辦公室正中央。

基本上這樣的環境營造出很輕鬆就可以在白板上看著代辦事項做討論，Daily Scrum 時大家圍著白板附近。同時日常工作上轉個頭就可以開個小會，降低文件溝通的低效率。

在這一天的Daily Scrum，佳麗拋出了困難：”昨日已經約定幾個部門頭頭，排定這幾日做需求討論，今日我計畫與。。。。現在已知在這一個Sprint 裡，DM與ARM兩個老闆都不回公司，尤其 DM 部門頭出差在對岸，預計要一個月後回來。ARM部門頭主要常駐軍方研發中心，約到的時間會在下個 Sprint。以上或讓我無法在此 Sprint 完成預計目標。”

Moore 驚訝：”需求訪談難道不能用諸如 Message, Line, WeChat, WhatsApp 等等帶有視訊會議工具來完成嗎?”

佳麗笑著回答：”也許對別人是可以這樣完成的。但我習慣只用這些工具來約定時間，需求訪談時，我堅持要面對面，因為我需要觀察對方提出來的需求的穩固性，再決定後續要安排多少的活動來逐步開發出需求來。多年的嘗試我已經確認這點：非正式的需求訪談會議，因為對方不太會準備太多，所以效果通常不佳。”

這個 Gavin, Molly 頗有感，越是高層主管要約需求訪談會比較囉唆，畢竟稍微有軟體上線經驗的主管會意識到所提出的需求對應的就是成本，從一開始的開發成本外，過程軟體運作維護成本，還有最頭痛的使用成本。所有軟件最終都是要用戶使用才有效益，這個成本也很恐怖。所以以正式會議舉辦，可以讓需求方有更多的思考與準備素材。

Fields 來自 ARM這個部門，主動要幫忙與之前的同事探聽一下，看是否有捷徑可走。另外Gavin 也意識到有個他主導的待辦事項『框定專案範圍，聚焦AI某些領域』相依於佳麗提到已經無法 100% 完成的事項，所以也能推知這事項無法100%完成。

Molly 主動以 Scrum Master 來解讀這件事，籠統的講這是屬於低估了一個PBI待辦事項的規模，但是幾乎是所有專案都會發生的，在 Sprint Review 會議上，報告完成了哪些事項；同時也把未能完成事項在下一個 Sprint Plan 會議考慮進去即可。通常會隨著專案的推進，大家對此專案的熟悉度提高了，工作拆解能力提高了，會慢慢降低此類無法完成的PBI發生。

Moore 的危機感發作，萬一不幸 Sprint Review 狀況很慘烈，他想要了解這是否要究責哪位成員？

Molly 跟大家解釋：
“Scrum 我個人覺得它神奇的地方就是在不是看個人，是團隊一起承擔責任，雖然我們工作展開每項待辦事項都有一位 Person In Charge，但是某人遭遇困難時，是大家一起想辦法化解，不能只是旁觀，因為萬一專案失敗了，不可能有某位成員還能獨享尊榮。”

“那如果有人擺爛，只想割稻仔尾，坐享其成呢？” Moore 追問。

Molly繼續以慣有微笑回應：“這個我只能講我遇過的情況，團隊中有人因為能力實在無法勝任，每天的 Daily Scrum 沒法多談昨天完成什麼，今天打算做什麼也支支吾吾的，或是更絕的常常躲 Dail Scrum會議，不用兩週，就會開始主動談離開這個專案了。”

“至於能力夠但是擺爛的人，我倒是沒遇到，但是人總是有高高低低的時候，偶而情緒低，身體狀況差等等，工作成效沒達到預期，只要說出遭遇問題，大家會判斷的，不太容易持續裝下去騙下去。我思考過原因可能是每個人多少有榮譽心吧？而 Scrum 目的就是要為精英們創造一個得以取得成就感的團隊氛圍。所以這個機制至今我還蠻相信有用的。”

Gavin：”我理解公司後來把Daily Scrum 納進我們的UP裡，也是認為他有助於小團隊的管理。就我以前接觸過的客戶，在製造業現場很多有所謂的『每日工具箱會議』一開始是要避免工安問題，原先是單向由主管宣導，但是其實很多問題現場工作人員才是第一個發現的，後來也有演化成組員之間互助提高品質與效率的一環。我覺得兩者精神似乎很雷同，都是要建設團隊自主管理積極性。”

備註：

專案的工作執行記錄在【深度學習所需入門知識--一位初學者的認知】