軟體開發見聞錄#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團隊)落實開發紀律的組織及方法。