這些問題都不在Scrum
內容大概是這樣的，PM問我有沒有什麼好的方法來管理Bug? 沒頭沒尾，我當然反問他：『Visual Studio Online不夠好嗎?』他只說：『覺得太浪費時間了?』我只好問：『怎麼說呢?』
大概的狀況如下:
Tester測試後把bug列上了TFS，變成work item，接著就擱在那裏了。首先，這個bug沒有owner，這問題好解，如果很嚴重只需要在team room或是日常溝通或deily scrum時，讓PM/PO/SM把bug指派給特定developer即可，如果不急，最遲最遲Planning Meeting或retrospective meeting做都行。這沒問題，接著，變成developer解完bug後，這個bug就擱在那裏了，tester不會(也不想)去再次驗證，或是tester常常覺得developer改的不是他說的bug，不然就是developer不理解tester所謂的bug是什麼意思???
劇情到這裡就很玄了，我開始有點聽不懂。
我只好問：『developer和tester都是自己人吧? 在同一間辦公室嗎? 』
PM回答：『他們坐在附近。』
我問：『那，他們都不溝通的嗎?』
PM說：『溝通太浪費時間了!』
我追問：『那它們怎麼確認bug的細節呢?』
PM：『就是寫在TFS上啊』
我：『寫bug description? 包含重現的步驟? 包含測試時採用的帳號? 還有操作的順序? 還有... 』
PM：『沒有，就寫一行，幾個字這樣...』
我：『...』
我只能說，這是素養的問題，這跟Scrum無關。
首先，並不代表你run了Scrum，原本專案中的問題就會消失，頂多大家職責開始變得清楚了，是誰的責任，會比以前更清晰。再說，Scrum讓團隊變得敏捷，但團隊成員中，程度好、程度差並不會因為這樣就有所改變。你還是得去面對以前碰到的問題。包含管理問題。
前面提到的狀況，是軟體開發中很典型的常見狀況。developer和tester之間的溝通障礙，本來，scrum就不鼓勵用文件來溝通，文件頂多是用來記錄，而溝通這種事情，最好是面對面進行的。而PM/PO卻覺得面對面溝通沒有效率，所以希望用文件來取代面對面溝通。(這是真的，因為很多developer溝通起來像鬼打牆，繞來繞去兩小時後還在討論一樣的問題)
但其實，用文件溝通是『經過研究指出最無效的溝通方式之一』，我始終不相信透過文件溝通會比面對面溝通來的有效且明確。
文字，其實是一種抽象的表達，有時候用錄影的影片，效果都比文字來的好上一大截。
我強烈的不建議團隊用文件來取代溝通，特別是描述性質的文件，描述功能、描述bug、描述規格...等。我希望PM/PO打從心裡質疑文件，而把文件當作一種紀錄工具而非溝通工具。
我常常讓PM/PO跟客戶談規格的時候，一邊打開VS Online的backlog/features，並且同時當著客戶的面把功能敲入系統，但請注意，這不是拿來跟客戶或developer『溝通』用的文件，而只是一種備忘，避免漏掉了某一個客戶提到的需求。
有各種技巧和方法來描述user story，你在坊間可以看到各種優雅或是前衛的方式，甚至搭配影音或是ppt slide，有太多太多方式聲稱可以清晰地描述規格，但我建議你，不要太過於全盤相信。只透過文件的溝通，永遠不能取代面對面的交談。
我衷心地建議PM和開發人員：我們可以竭盡所能地要求文件清晰，但不要以為文件就是溝通的工具。溝通，除了理解對方想表達的內容，還包含接收對方的感受。
有些Developer會說，我之所以選擇寫code，就是不希望碰到用戶，難道不能只看規格書來寫程式嗎? 我只能說，Developer，請多加訓練自己溝通的技巧，面對客戶、面對用戶，去了解對方真正的需求，去感受到對方的情緒，少說話，多聽，複述對方的需求，直到對方認為你了解他心裡所想的，那才是溝通。
截至目前為止，我從未讀過可以讓我"感受到用戶情緒"的文件，文件是死的，但人是活的。所以，千萬不要只看文件去理解規格，不管是features/bugs都是。
請不要誤會我覺得文件不重要，文件是重要的，但文件不是拿來溝通的。人，才具有溝通的能力，隔了一層文件，只能有最基礎的認知和理解，而不容易掌握到全局。developer千萬別放棄自己溝通的能力...傳統認為SA/PM才需要具備溝通技巧的時代慢慢要過去了...
如果有機會，我們改天再來談談溝通的問題。
留言