今天的內容源自於一個學長於Facebook上問的問題：『你的軟體即將於這個sprint結束之後就要準備送給測試部門進行測試，但是軟體還有幾十個open issues (bugs)還沒解完，而其中大部份的issues都只有某一位programmer可解。請問假設你是Scrum Master，你將如何處置？』這問題一出，引來許多人的討論，也有人開玩笑地說在解決完issue後要把那一位唯一能解的programmer開除，因為他程式寫得不好，所以別人才看不懂無法解決問題，真的是這樣嗎？有時候程式看不懂，並不是因為程式寫得不好，而是領域差太遠。如果整個專案都在同一個領域中，大家都是該領域的programmer，還出現這樣的情形，或許那位programmer真的要稍微檢討一下，但如果一個跨領域的專案，而且跨得很遠，如果沒有另外一個領域的知識，寫程式都很難寫了，更別說要解bug了。
另外，bugs明明是學長放在括號內的補充說明，大家似乎都把open issues跟bugs畫上等號，但有時候open issues不見得是bugs，例如有一個車牌辨識的模組，由團隊中唯一一個影像處理專才A開發，大多數的情況下都能辨識出車牌號碼，但前一個sprint結束後，QA實測後發現當在黃昏接近晚上時，辨識率就很差，甚至比晚上還差，因此QA列出一個issue希望能夠改善辨識率，這是一個issue但不是bug (目前沒有100%辨識率的影像處理技術)，問題來了，車牌辨識的過程中，有許多參數可以調整，調整了x參數可能可以提高黃昏時的辨識率，但也降低了白天的辨識率，或者是這個演算法本身就是有在白天到夜晚這之間昏暗不明時辨識率下降的問題，但其他時間辨識率很高，要解決這個issue，沒有影像處理相關知識，短時間內要解決基本上不可能，最後還是交給A來處理。
雖然大多數Scrum的書都說，當一個Scrum team要組成時，成員的能力必須涵蓋開發整個專案所需要的各種知識，現實狀況中，如果專案沒有跨很大的領域，這可能容易達成，例如幫銀行開發某個行銷活動的配合系統，那大概就是由具database / network / security能力的programmers，加上有處理過金融系統經驗的programmer，這樣的團隊就組成了。不過話說回來，會用database的programmer好找，懂得最佳化database的programmer就不見得好找；直接用network API寫程式的programmer好找，會設計protocol或實作protocol的programmer難找，當網路出現異常，能排除網路問題的programmer也不好找；會用加解密API寫程式的programmer好找，但對流程是否安全、金鑰是否安全等問題清楚的programmer就不見得好找，於是，在公司經費有限或是徵才不順的情況下，可能出現一個團隊裡都是只會用API的programmer，外加一個經驗老到的天才programmer (同時具備上述三種技能的最高等級)，如此一來，即使不定期的由經驗老到的programmer和其他人pair programming，當發生問題時，可能還是由經驗老到的programmer處理。
有人可能會問：為什麼？都已經用pair programming了，知識應該會慢慢傳播給其他人啊！原因很簡單，有些知識很難透過用pair programming的方式傳遞，這個現象當領域跨得越遠越明顯，上述的network / database / security領域，會用API算是programmer的基礎技能，就算不會用，用Google搜尋都能找到一堆API的範例，至於API背後的原理，不重要也沒人想管，程式會動就好，而pair programming最容易傳遞的知識，我個人認為，正好就是從Google能搜尋到的東西，背後的原理...程式都寫不完了，還有空講長篇大論？其實，pair programming確實很容易培養新人，從不會用API到會用API寫程式，但當程式出現問題時，從pair programming中學習到的『零碎』知識，往往派不上用場。
我還記得之前有入學新生問我：『念資工數學要不要很好啊？』我笑答：『跟那些念數學系的相比，我數學沒有很好耶，但大多數的情況下，確實用不到高深的數學...』，我說的是大多數情況下，但我還是遇到了那些少數案例，慶幸的是當時用的是『偽Scrum of Scrum』，解決跨領域的問題，那是一個將某數位電視協定，從最底層到最上層，含播放器都寫出來的專案，該協定主要有四層，每一層都需要不同的『數學知識』，而我和學弟負責的那一層，數學是最少最簡單的，而我們的上一層，就需要一大堆數學知識在背後，不然資料就解不出來；更上層的網路層，數學可能沒用到很多，但通訊協定要非常熟才行；再更上一層Video/Audio的解碼/同步/錯誤消除都用到相當多數學。說真的，雖然我主導架構設計會議，但跟他們開會，常常是鴨子聽雷，看他們寫程式，每一行都看得懂(都是很簡單的資料搬移、加減乘除)，但就是搞不懂這背後的數學和用途，我頂多幫他們找找看有沒有memory leak (該專案是C/C++/Java混和的Android專案)。
為什麼我會說是『偽Scrum of Scrum』呢？因為領域跨很大，所以由該領域的專家教授帶領的學生組成子Scrum team，然後由總計畫和每個子Scrum master組成Scrum of Scrum，每個子Scrum team實際上都只有1~3不等的組員而已。我是只畫class diagram不寫code的Scrum master，把數位電視協定標準中我們負責的那一層近200頁看完的和寫code的是學弟，其他組如何配置人力我不確定，但大概只有Video/Audio那一組有投入到3人，其他都不足3人，所以呢？整個team其實不過1x個，要視作一個扁平的Scrum也不是不行，因為當某一層出問題時，能解決問題的也只有某一組的某一或二人。話說回來，當初如果不是用Scrum of Scrum的方式組成開發團隊，情況是否會改善呢？我的答案是很難，整個數位電視協定的標準，橫跨1x份文件(我也不清楚為什麼沒有一份完整的文件，而是四散在不同的文件中)，全部加起來有一千頁之多，能把每一層都弄懂個有三或四成都很困難了，只有三四成的知識能解bug嗎？
像這樣跨領域的專案，我還能再舉幾個，例如更早之前我參與的某個號稱下世代無線通訊協定的模擬軟體(emulator)，第一代的標準才2xx多頁，第二代的標準也暴增到上千頁，比起剛剛提到的數位電視標準還複雜，總共有七層，但每層大多只有1~2人負責，總計畫最多投入到4人。又例如網路遊戲，需要network、3D graphics、physics、AI、database等技能，但都是蠻相異的領域，以現在『App團隊』的規模，上述技能都能各有一個programmer就算是很不錯了，如果某領域出現問題，雖然還是得等該領域的programmer負責，但總比由一個人承擔二項或更多項技能好，因為當多個領域都發生問題時，卻還是得通通由那一位『天才』負責。
說了這麼多，但問題已經發生了，身為Scrum Master該怎麼處理？既然是跑Scrum流程，也代表story沒做完並不是不能接受的，因此應先就已發現的open issues跟product owner討論，那些issues的問題可能不大(例如結果是正確的但performance在某些情況下會很糟，但那些情況並不常見)，某些issues可能很重要(很常當掉或是某個UI很不好使用)，討論後列下priority，並由product owner決定是否要延長專案的時程(學長加上這個sprint是release sprint的限制)，或是在不延長專案的情況下，在這個sprint優先處理那些issues，那些issues在release之後以patch的方式發行。
當要處理的issues決定後，召開一個技術會議，由該名能處理的programmer針對每個issue可能的原因進行說明，如果是bug，先從『取得資訊』的動作下手，取得資訊相較於解決問題容易，可以由其他team member處理，方法可能是在程式中加入printf，ㄟ~身為軟體開發與測試實驗室的成員，應該鼓勵大家用寫單元測試的方式，盡可能將可能發生bug的地方隔離出來，這時候該programmer可以處理非bugs的issues，讓issues和bugs同時處理，當issues處理差不多了，這時bugs應該也已經被隔離出來，該programmer可以節省隔離bugs的時間，至於在解issues/bugs時要不要pair programming呢？我持開放態度，因為就我的經驗，解bugs時，通常碰觸的程式碼都是很侷限的，對傳遞知識有多大幫助我沒什麼看法。
我想預防還是勝於治療，我知道會想當programmer的人對程式都蠻好學的，但我也認為真正能夠學貫古今、博學多聞在各個領域都專精的天才並不多。如果遇上跨領域的專案，組成開發團隊時，還是盡量讓每個領域都有二個以上的專才，這樣遇上issues時，才不至於都落到只有一個人能負責的局面，雖然學長曾在一個座談會上說：『pair programming能分享知識，雖然不可能轉移100%的能力，但也可能有個三四成或六七成』，但就像有個軟體工程諺語說：『Debugging is twice as hard as writing the code in the first place』，這時候(處理issues)，半吊子的人真的能派上用場嗎？不把問題愈挖愈大就不錯了。至於知識傳遞，我相信有其他更好的方法，例如每周一次全員都參加的workshop，由該領域的專才，提供有『系統的』知識傳遞，可以是投影片式的教學或是上機實習式的練習，我相信會比pair programming更有效率，前提是，product owner不介意每周有幾個小時整個Scrum team沒在工作XD。
留言列表
