美國軟體工作: 一個會議，三個環境，九個成員

雖然學理上認為 Scrum 會議最好控制在九個成員之內，但是實際上這個數字在很多公司只是參考用而已。成員越多當然越不好， 因為 Scrum Master 會很難控制會議進度。有很多時候在 Scrum 中，不少人會對一些專案流程充滿疑問，問東問西。這時候 Scrum Master 就會說一句話: Take it offline 。因為他也知道再討論下去只會浪費時間。

這個會議主要是每個人報告進度用的，不是討論專案細節部分，更不是批鬥大會。會議中讓大家掌握我們現在的專案究竟處於何種處境 ? 所以你會常聽到 Scrum Master 最常說的一句英語口語: We need to know where we are at.

軟體的環境分為三種: Test (測試)環境，Stage (待命) 環境，Production (正式) 環境。Developer (程式設計師)有自己的Test 及Stage環境。QA (測試人員) 也有自己的 Test 及 Stage 環境。Stage 是模仿 Production 內所有的環境。QA 必須在 Test 環境中認可後(sign-off)才能再將環境推往Stage 及 Production 中。這時就產生了1個很好的面試實務問題如下:

QA 在他們的環境中發現了Developer 的程式有問題，因此寫一個Bug 請 Developer 改程式，但是Developer 卻在他們的環境中測不出來， 請問你是 Developer，你可以將 Bug 變成 No Repro，退回給 QA 嗎? 若是 Developer 真的將Bug 變成 No Repro，退回給QA。請問你是QA， 你應如何處理?

如果你是 Developer 或 QA， 曾待過的公司有上述 Test 及 Stage環境，這一個問題你應該會很容易回答。這個題目出自美國微軟面試題。

一般台灣的軟體公司只有 Test 及 Production。有些台灣及美國的華人公司為了讓系統趕緊上線， 就只有 Production，連 Test 也沒有，真是誇張。

美國的軟體上市公司因為受到SAS 70或Cobit 法案，非常嚴謹。一般人是不能隨便碰Stage及Production內的資料庫。若是被審查(audit)， 罰款是最輕的處罰。若要確認 Stage 或 Production的資料無誤，請提出申請，讓 DBA 幫你尋找。所有申請需符合SAS 70法案。

若專案已迫在眉睫， 但是 Developer 程式卻還沒修改完成，就意味著 QA 不能進行測試。QA 就會寫一個 Priority 0 的 Bug 說明自己已完全不能做事(Blocking) 。這也意味專案一定會被拖延。這時候 Scrum Master就會趕快決定接下來該如何做?

你這時就會發現同一天不同時段可能會出現上述我提的這三個環境。不同的環境會有不同的Build， 供大家使用。若 Test 及Stage 環境都已通過QA 的認可，但是到了 Production 時卻發生了問題，此時Production一定要回到(Roll Back)前面的版本才行，並再退回 Stage， 重新再找出問題。問題解決後，再推向 Production，於是再得到一個新的Build。這時也產生了另一個美國微軟面試題如下:

如果昨天的Build 很好，但是今天的Build 卻不好，這是為何? 當初我被問到這一題時，我很驚訝，因為這一題是送分題。老闆根本就是在考我有無實務經驗。

經由一個會議，三個環境，九個成員互相合作，你會發覺整個團隊全部動了起來， 真是朝氣蓬勃。專案中如何亂中有序其實是考驗著整個團隊的全體成員。這也是軟體專案成功的地方。

如果你在美國從事軟體業，對上述我說的一個會議，三個環境，九個成員應該會有很深的體會吧。

延伸閱讀:
喜愛美國工作的會議-Scrum
美國工作難找嗎? 問當地獵人頭公司最準