能聽聞當時Gavin與佳麗兩位參與者一搭一唱的講述業界軼聞，Molly 多少也回憶了當時第一次接觸Scrum，於專案中接受洗禮，酸甜苦辣感同身受，所以聽的還蠻開心的。考慮到已經接近傍晚，她可不喜歡因為閒話家常而需要加班，趕緊提醒兩位長輩拉回AI專案來：

"由這段歷史來看，Servo說這個AI探索專案要採敏捷方式是否意味著我們只能採 Unified Process? 其實關於 Unified Process 敏捷不敏捷，業界有不同聲音。我前一家公司，在決定採 Scrum 之前也評估過 RUP，最後不採用UP的最大原因聽說是其所必須製作的文件，對創新團隊來講過於沉重。當然還有其他偏好問題的莫名原因。”

Pete 聽此論述似乎找到知音人，補充；”雖然 UP 是個框架，可以因應專案的特性去訂製符合需要的版本，但是因為我們公司是做軟體委外開發的生意，為了保護甲乙兩方，我們後續增訂出來的 T軟公司標準UP， 我們簡稱 TUP, 而且要用台式英語念成 TaPu, top以示優越，必須製作的文件還是相當多。更慘烈的是UP 似乎比較適合軟體開發專案，我們這種叫做AI 探索的專案，有多少成分是軟體開發? 這幾天我也在思考如何因應，坦白講我也想過要建議採用 Scrum"

“關於這個專案所需製作的文件，我建議如公司傳統的檢驗標準，準備給誰看，看了能產生多少影響。如果最終沒有能對公司、客戶、股東產生任何效益，就儘量少做。這可不是 Moore is better.” 聽到Moore又拋出這個老梗來，Gavin 與 Pete 馬上捧場大笑幾聲。

(圖片取材 Peter Dolog 2009 Unified Process)

Fields 只擔心他並不懂軟體工程，敏捷不敏捷無從判斷；"假使要採用 Scrum 能否提供一點訓練? 進公司的新生訓練TUP佔好大部分，後續專案實施時，又有師兄師姐帶。" 他是看著Molly說的。Molly 感應到立即承諾就算沒要採用 Scrum 她也很樂意分享她覺得受益良多的知識。

佳麗點出公司 TUP 的弱項：”因為我們承接到案子時，客戶已經確認案子的商業價值與可行性，我們裁減掉了UP 決定專案成敗的關鍵階段， Inception Phase。這個專案最好納入，尤其 Business Case 可要好好分析一下。”

Cash對這個主題似乎不感興趣，只是提醒大家：”最近如有要買筆記型電腦，又要帶獨立顯示卡的，務必挑選 Nvidia 的，顯示卡記憶體最低要 4GB，這樣要做機器學習的相關練習會比較有幫助一點，打怪也會比較有效率”。這個話題又引發一番舌戰，略過不表。

這個會議Gavin原先召開是要腦力激盪看如何採用 Agile 方式進行 AI探索，在與佳麗兩人一搭一唱聊公司 UP 歷史時，他擔心讓成員覺得這是沒效率，閒扯淡的團隊，卻引出大家共同話題，隱約可看出一些共識。也許這個團隊已經快要成形了。

他請 Molly 稍微準備一下資料，跟大家介紹一下 Scrum。Molly 希望不是上課式的講Scrum，因為現代人 Google 一下有一堆資料可讀，儘量式互動式的討論。大家都相當讚許這樣的方式。