2014年12月8日 星期一

這些問題都不在Scrum

前幾天,China RD Team有一個PM說,想找我問個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才需要具備溝通技巧的時代慢慢要過去了...

如果有機會,我們改天再來談談溝通的問題

沒有留言: