開發紀律

在 M 社歷鍊這麼多年，有件事蠻汗顏的，就是從來沒有拿到過任何證照，連 M 社自己的都沒有。還好公司、同事和客戶都很寬大，所以對工作並沒有什麼影響：倒是很多人問我這個問題：M 社對軟體開發的方法有沒有像 ISO 或 CMMI 的標準化認證，經理人需不需要考這方面的證照？

答案很簡單：沒有。就我記憶所及，甚至連需不需要這樣的標準化，都沒有討論過。接下來的問題就很明顯：為什麼沒有？

當然，沒有標準化並不表示不使用方法，實際上 M 社對於開發的紀律是非常重視的，因為過去發生過太多的慘案。另一個特別的地方，就是每個主要開發團隊的自主性非常高，所以個別團隊所定出來的都不太一樣。更絕的是，以 Office team 為例，每個版本所用的工程追蹤控管指標都不一樣。

為什麼會有這種現象？我的解讀是兩個因素：第一、工程手法與每個版本的功能策略有很密切的關係：很多團隊還保有 A B release 的習慣 (就是時程一長一短)，不同節奏的專案 KPI 都不會一樣 - 長時程多半因為要做架構的 refactoring 或是 file format 的改變 (有名的 doc -> docx)，控管的方式比較接近傳統法則，相對比較謹慎。而短時程專案則用來釋出新功能，所以手法比較像現在流行的 agile development (其實也是 MS 化的版本)。

第二，技術快速的演進，工程方法必須跟著做配合。尤其現今開發的主軸是以雲端服務為主，它的品質與效能指標是早期的 client code 或是 server code 完全不同 (例如 service 是完全不需要測 boot time 之類的效能)，加上開發工具也在變化，scripting language 與 compiling language 的 code review 方式有很大的差別。這樣要固定住工法，幾乎是不可能的。

話說回來，開發工程究竟不像流行音樂，可以說改就改。其中還是有幾件重要的原則會恆定持續，而且即是每個團隊都有自主權，還是會不約而同遵守這些些原則。

• Bug tracking 資料庫的公開透明 - M 社很早就定下 bug tracking (早期叫做 RAID，現在稱為 Product Studio)，只能增加，不予許修改或刪除：所有的痕跡都必須留下，沒有人能夠掩蓋問題或是「吃案」。而且，只要是微軟員工，都有權利檢視特定產品的 bug 內容 (當然看不看得懂是另外一件事）。公開透明是保持品質水準的基礎。

• Task 完成時間的回報 - 這一點則是花了好久才建立起來的習慣，因為 dev 通常不習慣被要求，早期還有許多資料被亂填的情況。但是長期對工期預測來說，這是不得不做的事，沒有持續資料的累積，工期永遠只由資深 dev 來估計，或者根本亂猜 (我們還給了一個專有名詞 SWAG, Stupid wild-a** guess)。M 社的 PM 是不能對 Dev 所提的 SWAG 有質疑，所以我們振振有詞地要求他們有回報的義務 :-)

• 超級謹慎的 DCR (design change request) review - M 社的工程管理有一句名言 “You always have the next release"，意思就是除非你有天塌下來的理由，別想 DCR 會過關，還是下個階段再提吧。當然有些時候還是不得已要改 design，很多團隊就會設下 quota ，每個 milestone 或 sprint 只能有一個或是兩個 DCR，而且每次 review 都是問到祖宗八代，盡量要你知難而退。

原則如此，還是要有適當的組織結構才能落實。下一篇，就來聊一下 M 社 (尤其是 Office team) 落實開發紀律的組織及方法。