講師是 Bentham Chang (張濱顯)，人蠻開朗的，上課的過程還蠻歡樂。其實關於 unit testing 的作法等等技術細節網路上資料很多，我比較有興趣的是他分享的在微軟工作的經驗，還有微軟的文化。
從 Developer (Dev) 的角度出發，工作上最直接相關的組織長得像下面這個樣子（接下來會大量使用到 Dev 這個 term）：
雖然我的圈圈畫的很醜，但我想表達的是在 MS 沒有上下階層的關係，三角形好像還是有個頂點:p 當然每種職位一定有 junior/senior 之分，也有各自的 Lead (e.g., Test Lead, Dev Lead)。
基本上從職稱就可以知道大略的工作內容（聽說很多美國公司也是採用類似的架構），PM 就是專案經理，Test(er) 在台灣常常叫 QA，Dev乍看之下好像是PG (Programmer)。
但是在台灣很多公司是 follow IBM Mainframe 時代的 terms，所以會有 PG/PA/SA/SD 等職位（很有 waterfall 的 fu），在上圖中看不出 PA(程式分析)、SA(系統分析)、SD(系統設計) 等職位，但是顯然這絕對不是說在微軟做軟體都不需要經過這些步驟。
我的感覺是 MS 的 PM ＆ Dev 都是一起 co-work 的，只是 PM 面對客戶的時間比較多，主要負責寫 spec（相當於台灣的 PA/SA 的工作），但是過程中要密切跟 Dev (lead) 討論系統設計（SD）的問題，最後由 Dev 負責把程式實作出來（PA 大概算基本能力吧）。
另一個很明顯的重點是 Tester (QA) 是很重要的職位，必須要請人專職負責，而不是把 testing 當做 Dev 的工作中的其中一項。從這裡也可以思考，如果像微軟這樣重視 testing 的公司做出來的產品還是有可能被批的滿頭包，那麼沒有專業請人做 testing 的公司做出來的產品，品質/安全性會是怎麼樣？
扯遠了，Bentham 說，在 MS 內你可以自由選擇要做上述三種工作的哪一種，並且每種職位還可以進一步選擇要做 Indivisual Contributor (IC) 或是 Lead (manager)。
MS 的 Dev 都是很聰明而且非常有自主性的，基本上可以說整間公司都是自我實現的熱血的人（自我實現這個 term 請參考 Maslow’s hierarchy of needs），所以不適合用「公司政策」這種政治性的手段來強迫推行什麼制度（e.x., unit testing），因此 MS 管理 Dev 的原則是先盡可能提供他們一個舒適的工作環境（食物啦、飲料啦），之後要推動政策的時候，只要能夠說出個道理（e.g., unit testing 的好處），就能讓 Dev 自動自發的去執行了。
MS 的 Dev 有什麼需求呢：
- (Free) Food：Google 也是這樣搞的。台灣微軟好像也差不多。MIC 和 MIT 都有很多零食飲料。
- Quite (environment)：就是說喔，不要跟 sales 坐同一間辦公室啦！
- Keyboard：在 199x 年的時候 MS 很多 top Devs 比較習慣 unix-like 的 text editor/command-prompt tool，很不喜歡用滑鼠的
- Cool idea：設法把公司要推動的東西塑造成很酷的，讓 Dev 認為做這些事情是他們自己想要的
- Ship it：「我的程式被幾千萬人使用」是 MS Devs 成就感的來源，所以儘快 ship product 是很重要的
另外一個故事是以前 MS 每週會舉辦一個 tool 比賽，因為 Devs 在平常工作的時候很喜歡自己做一些小 tool 來自動化一些重複、繁瑣的工作，因此為了鼓勵這個風氣，每週舉辦一個 tool 比賽讓大家炫耀一下自己的作品，大家覺得不錯的 tool 就會考慮整合到產品中，據說 VSTS 的 testing framework 就是把這類 tool 整合進產品的結果。
呼，寫到這裡有點像流水帳，不過其中有很多可以好好思考的地方。就讓我用「這跟台灣真是差很多阿！」來草草結尾吧，千言萬語，不知從何說起阿～ :p
沒有留言:
張貼留言