Wednesday, September 24, 2008

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

雖然學理上認為 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
美國工作難找嗎? 問當地獵人頭公司最準

4 comments:

Kenny Hsu said...

看了你的文章之後才知道為什麼client這邊對於production的任何修改都是非常的謹慎,非得要填表單、、一堆人簽名認可之後才能執行,即使是一個小小的、無關痛癢的update。
至於你說的QA發現Bug,Developer卻無法重現的情況我也遇過很多次,有時候是言語表達不清、有時候是認知的問題、有時候是規格書沒開好導致模擬兩可的情況...等等。
最後的送分題我很好奇你是如何回答的?

Ray said...

Kenny,
This is a very important concept in PROD.

If QAs find bugs, they need to list the repro steps and assign to them. Developers can follow those steps to trace the problem. Without those steps, developers can't find the issues.

About the final question, it is easy. When some developers modify the source codes and check in, their source codes might affect other developers' source codes and features, which causes the build break. It happens all the time.

We always say: This is not a good build. Please have another build ASAP. :)

No Chinese keyboard on my work laptop.

Kenny Hsu said...

呵呵,這又讓我想起以前發生的笑話。QA回報一個bug,我們怎麼都沒有辦法repro,後來直接用電話溝通(QA是off-shore,在印度),才知道原來他們把回傳的Guid數值以為是亂碼回報錯誤,但是Guid本來就是亂碼(應該說亂數比較好一點)...
這是情發生在距離遠很難溝通的offshore QA team很多次了,所以我才會說有時候是認知or溝通的問題。

Ray said...

Kenny,
This QA should write the bug repro in detail.The developer can write something in that bug and assign to QA for more information.

Locations of visitors to this page
自訂搜尋