方格精選
軟體開發見聞錄#9：談「開發紀律」／葉光釗
閱讀時間約 4 分鐘
隨著軟體開發方法、工具、以及成品應用方式的變化，軟體開發已經不能只靠單一證照、程序、手段來完成；雖然如此，為了專案的進度與品質控管，仍然有一些共通的道理是必須遵守的。本文就來談談這些同樣也適用於其他專案管理的基本原則。
在微軟歷鍊這麼多年，有件事蠻汗顏的，就是從來沒有拿到過任何證照，連微軟自己的都沒有；還好公司、同事和客戶都很寬大，所以對工作並沒有什麼影響。
倒是很多人問我這個問題：微軟對軟體開發的方法，有沒有像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會過關，還是下個階段再提吧。
原則如此，還是要有適當的組織結構才能落實。下一次就來聊一下微軟（尤其是Office團隊）落實開發紀律的組織及方法。
- 「軟體開發見聞錄」系列文章
為什麼會看到廣告
留言0
查看全部
你可能也想看
Google News 追蹤
我們可能會有一種迷思，不管開發什麼系統，開發團隊都袛會有一種方式來工作。反正不管怎麼樣，系統最終也一定是能開發出來的。那麼選擇開發生命週期又跟我何干？本篇將會介紹專案經理應該如何為不同特性的專案選擇最合適的管理策略，即生命週期。
在這篇文章中，我們將介紹工作與以前念書時期在開發流程上的差異，並深入瞭解CI/CD、Travis CI以及加解密的應用。 CI/CD是自動化的軟體開發實踐，而加解密則是保護機密資料安全的重要技術。
在數位時代，Scrum已成為專案管理的利器。本文介紹Scrum的核心角色、工件和事件，並結合我開發CDP的實際經驗，分享如何通過產品待辦清單管理、Sprint計劃與執行、每日站會和Sprint回顧來提升專案靈活性與效率。希望能啟發更多專案經理運用Scrum，優化專案流程。
專案失敗以往被定義為超期、超預算或無法結案，但現今專案管理思維重新把失敗定義為未能產生預期價值。文章從產品經理、軟體設計和管理流程三方面提出對失敗專案的見解和解決方法。
軟體開發專案管理的失敗原因複雜多樣，但管理不善是其中一大原因。學習為軟體開發專案而設的管理方法是有效管理的第一步，需對軟體開發專案的特徵進行評估，選擇合適的軟體開發生命週期和專案管理方法。
相較於接案公司，說到自有軟體產品的企業，普遍大家會自動套上粉紅濾鏡，覺得產品公司就是比較好，不像接案毛利低、又常常有時程壓力。
在網路上也可以找到各式各樣的文章告訴你接案公司的各種地獄故事，覺得如果有選擇的話，可以做產品就不要接案，就連以前的我也都有一顆產品夢。
但事實真的是這樣嗎？
確保沒有遺漏或錯誤
程式的完整資訊資料對於程式設計至關重要。這是因為只有透過完整的資訊，我們才能確保在程式設計中沒有任何遺漏或錯誤。最終，後台管理扮演著管理系統中所有動作和行為是否符合特定標準的重要角色。
採取不符合預期的行動
這種符合性的重要性在於，當我們設計程式時，希望使用者按照預期的方式
資料的統合
在程式設計中，其他人通常關心是否注意到執行的細節。作為程式設計師，主要應該關心的是程式的表現，但往往忽略了很多細節，這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合，也就是資料是否被正規化。
不同類型的資料在系統中呈現一致
正規化可能對一些人來說聽起來很抽象，有些人
不論企業使用的伺服器和客戶端是使用何種作業系統，定期更新補丁是必不可少的。
這道理仿如真理，因為世界上還沒有一個作業系統是完全沒有漏洞的，只要有漏洞被發現，就要推出補丁，作為使用者的角色就得決定是否安裝。
筆者曾經和一些決策層交談，他們未必是IT業者，但也懂得補丁要越快更新越好。但其實這觀點並不
MPL授權是目前與法律有最完整對應的授權條款。然而MPL授權對於原始碼仍保持copyleft特性，對商業開發而言或許仍有疑慮。
因此若有商業團體共同開發時，採用Apache 授權較佳；如果不在乎他人如何利用、優化原始碼，或希望原始碼盡可能地廣為散播，幾乎沒有任何限制的MIT或BSD授權是較好的選擇。
我們可能會有一種迷思，不管開發什麼系統，開發團隊都袛會有一種方式來工作。反正不管怎麼樣，系統最終也一定是能開發出來的。那麼選擇開發生命週期又跟我何干？本篇將會介紹專案經理應該如何為不同特性的專案選擇最合適的管理策略，即生命週期。
在這篇文章中，我們將介紹工作與以前念書時期在開發流程上的差異，並深入瞭解CI/CD、Travis CI以及加解密的應用。 CI/CD是自動化的軟體開發實踐，而加解密則是保護機密資料安全的重要技術。
在數位時代，Scrum已成為專案管理的利器。本文介紹Scrum的核心角色、工件和事件，並結合我開發CDP的實際經驗，分享如何通過產品待辦清單管理、Sprint計劃與執行、每日站會和Sprint回顧來提升專案靈活性與效率。希望能啟發更多專案經理運用Scrum，優化專案流程。
專案失敗以往被定義為超期、超預算或無法結案，但現今專案管理思維重新把失敗定義為未能產生預期價值。文章從產品經理、軟體設計和管理流程三方面提出對失敗專案的見解和解決方法。
軟體開發專案管理的失敗原因複雜多樣，但管理不善是其中一大原因。學習為軟體開發專案而設的管理方法是有效管理的第一步，需對軟體開發專案的特徵進行評估，選擇合適的軟體開發生命週期和專案管理方法。
相較於接案公司，說到自有軟體產品的企業，普遍大家會自動套上粉紅濾鏡，覺得產品公司就是比較好，不像接案毛利低、又常常有時程壓力。
在網路上也可以找到各式各樣的文章告訴你接案公司的各種地獄故事，覺得如果有選擇的話，可以做產品就不要接案，就連以前的我也都有一顆產品夢。
但事實真的是這樣嗎？
確保沒有遺漏或錯誤
程式的完整資訊資料對於程式設計至關重要。這是因為只有透過完整的資訊，我們才能確保在程式設計中沒有任何遺漏或錯誤。最終，後台管理扮演著管理系統中所有動作和行為是否符合特定標準的重要角色。
採取不符合預期的行動
這種符合性的重要性在於，當我們設計程式時，希望使用者按照預期的方式
資料的統合
在程式設計中，其他人通常關心是否注意到執行的細節。作為程式設計師，主要應該關心的是程式的表現，但往往忽略了很多細節，這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合，也就是資料是否被正規化。
不同類型的資料在系統中呈現一致
正規化可能對一些人來說聽起來很抽象，有些人
不論企業使用的伺服器和客戶端是使用何種作業系統，定期更新補丁是必不可少的。
這道理仿如真理，因為世界上還沒有一個作業系統是完全沒有漏洞的，只要有漏洞被發現，就要推出補丁，作為使用者的角色就得決定是否安裝。
筆者曾經和一些決策層交談，他們未必是IT業者，但也懂得補丁要越快更新越好。但其實這觀點並不
MPL授權是目前與法律有最完整對應的授權條款。然而MPL授權對於原始碼仍保持copyleft特性，對商業開發而言或許仍有疑慮。
因此若有商業團體共同開發時，採用Apache 授權較佳；如果不在乎他人如何利用、優化原始碼，或希望原始碼盡可能地廣為散播，幾乎沒有任何限制的MIT或BSD授權是較好的選擇。