軟體開發見聞錄#9：談「開發紀律」／葉光釗

隨著軟體開發方法、工具、以及成品應用方式的變化，軟體開發已經不能只靠單一證照、程序、手段來完成；雖然如此，為了專案的進度與品質控管，仍然有一些共通的道理是必須遵守的。本文就來談談這些同樣也適用於其他專案管理的基本原則。

在 #微軟 歷鍊這麼多年，有件事蠻汗顏的，就是從來沒有拿到過任何證照，連微軟自己的都沒有；還好公司、同事和客戶都很寬大，所以對工作並沒有什麼影響。

倒是很多人問我這個問題：微軟對軟體開發的方法，有沒有像ISO或CMMI之類的標準化認證？經理人需不需要考這方面的證照？

答案很簡單：沒有。

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

當然，沒有標準化，並不表示沒有方法；實際上，微軟對於開發的紀律是非常重視的，因為過去發生過太多的慘案。

另一個特別的地方，就是每個主要開發團隊的自主性都非常高，所以個別團隊所訂出來的方法都不太一樣；更絕的是，以Office團隊為例，每個版本所用的工程追蹤控管指標都不一樣。

為什麼會有這種現象？我的解讀是兩個因素：

1. 功能策略不同

工程手法與每個版本的「功能策略」有很密切的關係；很多團隊還保有「A/B release」、也就是「時程一長一短」的習慣，而不同節奏的專案，KPI就不會一樣。

長時程專案多半因為要做架構的程式碼重構（refactoring）、或是檔案格式的改變 (例如有名的「doc」轉換為「docx」格式），所以控管方式比較接近傳統法則，相對比較謹慎。

而短時程專案則用來釋出新功能，所以手法比較像現在流行的 #敏捷開發 ，不過就是「微軟化」之後的版本。

2. 工程方法不同

隨著技術的快速演進，工程方法也必須跟著配合。尤其現今開發的主軸是以雲端服務為主，它的品質與效能指標與早期的用戶端程式碼（client code）或伺服器端程式碼（server code）也完全不同（例如服務相關程式碼完全不需要測「啟動時間」之類的效能）。

此外，加上開發工具也在變化；解譯程式碼（scripting language）與編譯程式碼（compiling language）的程式碼審查（code review）方式有很大的差別。這樣要固定住工法，幾乎是不可能的。

方法不同，原則相通

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

• 臭蟲追蹤（Bug tracking）資料庫的公開透明

微軟很早就定下bug tracking工具（早期叫做「RAID」，現在稱為「Product Studio」）資料庫內容只能增加、不允許修改或刪除的規矩；所有的痕跡都必須留下，沒有人能夠掩蓋問題或「吃案」。

而且只要是微軟員工，都有權利檢視特定產品的臭蟲內容（當然，看不看得懂是另外一件事）。因為，公開透明是保持品質水準的基礎。

• 工作完成時間的回報

這一點則是花了好久才建立起來的習慣。因為開發者通常不習慣被要求，甚至早期還有許多亂填資料的情況；但是對於較長的工期預測來說，這是不得不做的事。

如果沒有持續的資料累積，工期永遠只能由資深開發者來估計、或者根本亂猜；對於這一點，我們還給了一個專有名詞「SWAG」（Stupid wild-a** guess，總之就是「笨蛋亂猜」）。

微軟的產品經理，對於開發者所提的SWAG是不能質疑的，所以我們振振有詞地要求他們有回報的義務。

• 超級謹慎的DCR（design change request，設計變更請求）審查

微軟的工程管理有一句名言「You always have the next release」，意思就是除非你有天塌下來的理由，別想DCR會過關，還是下個階段再提吧。

當然有些時候還是不得已要改設計，此時很多團隊就會設下限額；每個重大里程碑或衝刺項目（ #sprint ）只能有一或兩個DCR，而且每次審查都會問到祖宗八代，盡量要你知難而退。

原則如此，還是要有適當的組織結構才能落實。下一次就來聊一下微軟（尤其是Office團隊）落實開發紀律的組織及方法。

• 「軟體開發見聞錄」系列文章