終局管理

最近 "End Game" 這個詞紅透半邊天 (可惜跟軟體工程沒有關係)，用中文大白話就是 "收尾"。可別小看這個詞，不管是產品還是專案，能不能安全落地，End Game 絕對是關鍵的階段。

記得聽過這樣的說法，飛安事故有七成以上是在於起飛和降落的階段發生的。軟體開發專案有非常相近的情形，雖然沒有統計數字，不過基於經驗，失敗很容易發生在事前的規劃，或是接近結束的階段，甚少例外。也就是如此，M 社對於 "收尾"階段的工作，永遠會佈下重兵，嚴陣以待。

既然是 "終局"，就會有一個 "終點"，而一切的規劃都會是以這裡為基準。在早期軟體多數以 "可安裝" (instabllable) 形式存在的時期，我們設定的是一個 RTM (Release to Manufacturing) 的日期，就是送出去壓光碟啦。而現在多數以雲端服務形式為主，這個日期被稱為 GA (Global Availability) 。無論哪一種，都是表示做出來的軟體達到某個程度，已經告一個段落。

至於 end game 的其間往前推多少，就見仁見智了。在 RTM/GA 之前，會有一個 RC (Release Candidates) 的里程碑，比較多人會把這個日期當作是 end game 的開始。 RC 是一個特殊的觀念: 不像一般人的想像，軟體完工並不是 bug 全解光然後結束，那是不可能發生的，尤其是像 M 社 Office 整合與複雜度都超高的專案。這些絕頂聰明的工程師所能做的，是盡力將 bug 的數目以及嚴重程度限縮在一個範疇裡面。要知道，在這個階段，很多問題都是連動的；修掉一個問題，很有可能引發別的問題。一個滑稽的比喻，這個情況就跟打地鼠一樣，打中了一個，可能別的地方會有好幾個冒出來。

RC 這個里程碑的意義，就是自此之後，每一個 bug fixing 都要仔細研究，不能隨便 check-in。以 Office 為例，這個時候會成立跨產品團隊的審查小組，定期進行每個 bug 的優先處理分類 (triaging)。Traige 是個法文，這個觀念是跟醫療流程中學來的，意思就是針對每個 bug 的修正方法、影響範圍、潛在的問題等等做全面的討論，這樣才能完全掌握修正之後軟體的總品質是真的往前進，並沒有副作用。而每個品組對準備送 triage 的 bug 則要做充分的準備和說明，不然是不准 check-in 進去的 (所以才會有 postponed, won't fix 的 resolutions)。更重要的是，接受 bug fix check-in 的要求會隨直時間接近 RTM/GA 而越來越高，到了前幾周，幾乎只有"召回層級" (recall class) 的 bug 才准修。RC 到 RTM/GA 這段期間的品質穩定度是很高的。

也有人說，廣義的 end game，其實從 code complete 就開始了。CC 指的是所規劃的功能都做完了，但是可能還有很多的臭蟲與整合的問題，所以開始做整合測試與除錯。產品組的目標，就是要從這裡開始降低問題的數目，一路穩定的走向 RTM/GA。很多產品內部自己的控管機制，這個時候就要啟動，例如 team 自己內部的 triage 會議以及 bug review 等等。

End game 真正的重點是將大部分的資源用來穩定品質，而不是最佳化體驗；因為這兩者很多情況下是互斥的。所以還有很多跟穩定有關的事項，例如 DCR 還有很多大客戶的臨時差單要求，不是不能做，而是都要做嚴謹的評估。甚至有些極端的情況，是必須拒絕某些超級客戶的要求，只能敦請公司的 VP 出面與客戶溝通和道歉。

即使到現在形式已經轉成雲端服務，注重開發的速度和流暢度，我想很多的基本觀念應該還是一樣的。