Molly 與佳麗，Gavin討論了一下，Retrospective 會議還是繼續邀請早上有參與的全部參加，正常這個會議不用太多人參加，因為其目的主要是Scrum Master 協助開發團隊回顧（自我檢討）一下這個Sprint 的運作流程，找出改善點來，所以太多人團隊以外的人參加，就沒辦法暢所欲言。但盤算到Servo, RJ 等人，他們都關心 Scrum 運作，也有考慮變成公司的流程資產，邀請他們應可加速後續的溝通。

請注意：如果按照標準 Scrum Retrospective 會議，應該是 Scrum Master 與開發團隊參與就夠了，其他人必須被邀請才能參加。不要被這裡講的情境誤導了。

雖然 Molly 先前講解時，有提到 Sprint Burndown 圖表來協助追蹤工作消化速率的變化，但在這個 Sprint 這圖無法發揮作用，待下個 Sprint 再考慮製作。

為了這個會議，Gavin 簡易做了一個專案費用與預期計價表，前面他把硬體與專案人事費用（財務部例行報表）滾算出來，蠻容易的；後者，如何計價？按收益，不就是0。按成本似乎有點便宜形式，畢竟他們處在利潤中心的一個專案。幾經思量，再與佳麗討論看看，佳麗覺得還沒顯著貢獻，能否移到幾個 Sprint後再談計價，Gavin考慮到這是大老闆Servo對這個專案提出來的小挑戰，還是依照協定每個Sprint去跑，形成慣例。這次如果刻意忽略避開了，後續只會更難處理。妥協下，因為這段時間大家過程中，都在平均以上的付出，最後還是以成本做定價依據。

會議由 Scrum Master Molly 主導，Molly 準備了一些素材：

建議持續下去的優勢：

1. 堅持Time-Box ，大家的上班時間趨向一致，因而效率提高。
2. 團隊成員能以各自專長互相協助合作完成待辦事項。
3. 團隊因應變化的彈性
4. 共同維護Scrum各角色立場，讓 Product Owner 與 Scrum Master 發揮預期功能。
5. 與傳統Scrum最大差異，每個 Sprint 考慮進成本與效益的平衡。

待加強事項：

1. 待驗證Sprint 期長兩週與專案性質是否合宜？
2. 待辦事項的工作拆解與對應的工作量預估。
3. 延續上述兩點，上班時間已 Time-Box，但工作仍被帶回家加班趕工

關於第 1. 項優勢，佳麗趁機感謝 Cash 為專案改變作息。Servo 與 RJ 也表達現在採不打卡的彈性上班政策，偶而有同仁表達這會影響採敏捷方式專案的工作效率，但是否要改政策讓大家的上班時間趨向一致，還是由專案團隊自訂，他們暫時沒有想法。

ARM 頭 Colin 分享他們團隊派駐均軍方研發園區，每天朝八晚五的，加上客戶對計畫時程安排較鬆，員工每天就九小時在客戶那邊專心在工作上即可，幾乎沒有加班，與他之前做傳統製造業的專案常熬夜趕工相比，每個UP Iteration 完成的Use Case Point 並沒有顯著差異。最大的收穫，他們算過：兩者專案在上線後還需要緊急修復 critical bug的密度差異很大。事緩則圓吧，Colin的解讀。

而對於『因應變化的彈性』RJ 也分享十多年來推動 UP 以及他看到一些掉入誤區的案例：例如過去有專案組堅持文件製作要以UML形式，客戶所提的需求規格書是該客戶 CMMI的歷史遺物，抗拒撰寫。也聽過友商曾在某客戶採Scrum敏捷，堅持軟體程式裡已包含使用說明，也與客戶請求製作軟體SOP產生對立。光是文件製作的爭議類似的個案還有。。。，最後他總結：”開發團隊對客戶要求必須彈性，改變過去的作法。卻堅持自己的一些敏捷教條。這樣的不對等，容易傷害彼此原本就脆弱的合作氛圍。”

對於需要加強的前兩項，李博士認為可以總結成：
“專案如果還在概念發想，只要這領域的精英一兩個投入，因為較難系統化的工作拆解與分派工作，不應該過早成立專案，其他人插不上手。團隊成立後以UP流程來看，Inception Phase 理論上不會太長。 這個可用 Phase Review 來檢視。 Scrum 沒這個機制，所以必須以其他方法來節制，我覺得Gavin的預期收費表，是不錯的方法。因為利益關係人看到花費的成本，多少會降低需求的發散機會。”

Servo 很滿意的點頭，他與 RJ 一直要塑造每個專案成員都是小老闆文化，看來發揮了積極作用。他也談到『工作被帶回家加班趕工』的文化，以他是公司負責人來講，他並不覺得這是光彩的，也想改變，但對大家抱歉的是，至今與RJ 反覆討論，還沒有對策，他期待這個專案看能否協助探索出方法來。

Molly 觀察到這個會議變成管理層的座談會，有點後悔邀請他們。但是也只好咬著牙繼續，她先請佳麗任意發言，佳麗表達該講的簡報都有談到，唯一想表達的是，大家讓她回味做專案的酸甜甘苦。Cash 馬上接口：”也謝謝佳麗姐許多的包容，學到許多技術以外的處理事情的方法。”，他一講完，緊接著Pete, Gavin要搶著感謝，突然間變成感謝大會。

Gavin 除了以Product Owner 表達感謝，以開發團隊成員提出建議，把這個專案區隔成兩部份，其一是探索，探索Scrum與 AI 的目標策略這種比較不容易定義驗收標準，這須彈性因應利益關係人的；另外是工程，針對某種技術或是框架的開發，這就必須作到與 UP 方式可比的效率。李博士理解這議題是要對專案抽絲剝繭：可以工程管理的就採工程量估算執行評估；剩下的就隨機應變了。於是馬上附議。

Fields 除了感謝大家合作精神，更感激Colin同意他加入此專案。最後他以開發人員表達他的需求：儘快有實際的需求目標可聚焦，目標太發散，對技術人員頗有殺傷力。這個議題，李博士與 Colin 都很贊同，他們其實有一些需求是可以嘗試的…但是 Servo 期望多一兩個 Sprint 做 Inception Phase，因為對他來講投資七位人員如能幫忙理順公司運作的流程，得到的價值是無窮的。這個有分歧的議題又被要求加入 PBI產品待辦事項了。

Molly 觀察後續應無『回顧專案』的事項，雖然離預定兩個小時還有十多分鐘，決定提早結束此會議。

Servo 在會議結束後，請大家留下來幾分鐘，他有幾項事交待：

1. 請 Molly 深入了解 CMMI PPQA，在後續跟大家探討在 Scrum , UP 如何對應。
2. 請 RJ 與 Gavin 與對岸某市科技創新委員會的窗口交涉，他前天剛從博鰲會議回來，SM大佬期待T軟協助先與該市的科技創新委員會一起釐清未來事業規劃的方向，後續再與SM談合作適宜，一起規劃工業4.0的投資案。
3. 請Colin與李博士整理現在軍方已經有機器學習的需求中，合適應用在工業界尤其是半導體製造方面的，看能否藉此聚焦這個專案 AI範圍。

備註：

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