2013年2月25日

系統測試就像健康檢查



很多人都有做健康檢查的經驗,一次健康檢查會包含身高、體重、肝指數、膽固醇、胸部X光等等基本項目,可能有時你還會額外再多檢查腸胃鏡之類的項目。不過不管有多少檢驗項目,都是一次做完的。

之前曾有過project在搶快,不管有些功能還沒做完,就硬要進VT的系統測試,還要求先給一版已經完成的功能先測試,過一陣子等其他功能完成了再給一版測試,如果有功能比較慢可能還會有第三版。老闆只看到project進入測試階段,卻不知道只是表面功夫。開始測試時沒什麼問題,然後等後來版本進測試時才發現原本測試過沒問題的case又有問題了,就這樣來來回回搞得測試時間都跟開發時間差不多了,還是沒辦法有效收斂。

[ PL的Project Management]知道就做得到?

接續上一篇 PL的Project Management]順序很重要,Requirement=>Design=>Implementation
後面的問題,為什麼這麼簡單又直覺的邏輯和做事步驟,真的在project執行時卻很難做到呢?

先來看看幾個對話:
<1>
RD:VT測試發現的這個問題是因為之前interface沒有考慮好相容性的問題,現在要嘛把interface改得更完整,只是接口二邊的模塊也都要動到,schedule一定會受影響,不然就還是用舊的,新的功能就先disable,等以後接口改好了再enable。
PL:這不是給我找難題嗎?怎麼都測試一半了才發現這個問題,設計和實作時怎麼都沒發現功能有問題?而且這個功能是客戶指定要的,怎麼可以disable呢!要改,schedule會delay;不改,又要想辦法說服客戶project沒有這個功能。天啊~~

<2>
PL:這個功能一定要現在project後期加進來嗎?為了這個不重要的功能影響project進度,很不值得。
Sales/Boss:很多客戶都要,不在這次平台版本加進來,就要等下一次,那些客戶都等不及了,很可能會轉單到對手那邊去。
PL:這次版本release的主要目的就是給大客戶的,但是大客戶並不要這個功能,是不是可以先找人開發這個功能,但是等這個版本release後,再把功能整合進來以patch的方式release?這樣既不影響現在project的進行,也可以很快讓其他客戶有這個功能。

2013年2月4日

[ PL的Project Management]順序很重要,Requirement=>Design=>Implementation

SW process的第一個phase並不是implementation phase,而是requirement phase,也就是說如果project一開始就朦著頭就開始實作階段,那是錯的,也是假的,因為連要做什麼都不知道,又怎麼可能開始做呢,先搞清楚requirement是什麼才是最重要且第一個要做的事。

有的PL為了搶快,或是為了讓老闆看得見產出,即使在做什麼都不明確的情況下,project就投入人力開始implement,這是錯的,也是假的。為什麼是錯的?簡單的邏輯-清楚要做什麼(What to do) ==> 才思考應該怎麼做(How to do) ==> 然後才是開始實作(Do it),對應的SW process順序就是Requirement phase ==> Design phase ==> Implementation phase。客戶明明要的是要<重型機車>,結果你自己很高興地做了一個<很重的機車>,然後才發現做錯了,你能要求客戶把需求改成<很重的機車>嗎?所以順序不對,就不合理,就是錯的。那為什麼是假的呢?因為現在實作完成的東西,會因為requirement不對、design不合而需要修改,甚至重來,看起來已經完成100%的工作都可能要再歸零重做,也就是現在完成的工作可能都是白工,所以是假的。

Requirement phase (What to do) ==> Design phase (How to do) ==> Implementation phase (Do it),簡單的邏輯,淺顯易懂,不過<知易行難>,看過很多project直接就要開始進入implementation,忽略requirement、跳過design,妄想要一邊實作一邊釐清需求,一邊實作一邊修改設計,這樣的做法或許對很小很小的task有用(因為重工的代價很小),但對於project來說,那會是讓事變多好幾倍、功減一大半的行為。