l

2015年5月12日 星期二

Story由一個人獨力完成,好嗎?

May 012 00:00~00:45

螢幕截圖 2015-05-12 00.40.29

一箱不容二貓 XD。

 

有一個曾經在知名外商X公司工作的朋友和Teddy分享他們執行Scrum的方法…

朋友:我們的story是由開發人員直接認領,比較資深的人會認領較多的story,資淺的人就拿少一點

Teddy:這樣你們的團隊成員不就都沒有合作一起完成story,而是各做各的?

朋友:也不能這樣講啊,我們常常發生資深人員的story都做完了,可是資淺人員的story還沒完成。這時候資深人員就會去幫忙資淺人員。

Teddy:嗯, 這也算是一種形式的合作啦,可是和我理想中的Scrum有點不太一樣。

***

Teddy不只一次聽過這種講法,外商、強國商、台商都有。Story是由個別開發人員去認領,而不是好幾個開發人員一起合作完成。人家案子也是做得好好的啊,也覺得這種形式的Scrum沒什麼不好,而且責任分明,出問題要找誰非常清楚。有需要改嗎?改了之後會不會打壞原本的步調,讓開發變得更亂呢?

由於這些經驗大多是道聽塗說而來,Teddy自己並不在「犯罪現場」,很難具體評斷些什麼。只是直覺上認為,這種合作模式比較像是把story當成ticket(切票、派票)來用,只是一種分派工作的工具,因此很自然只達到分工而不合作(或是好一點,分工少合作)。而且這種工作模式,似乎不容易達到XP所倡導的collective ownership(程式碼共有)。

最後Teddy只能告訴朋友:「我不能說你之前的做法就是錯的,但如果是我,我不會建議團隊用這種方式來完成story。」

***

敏捷開發做久了,慢慢覺得很多事情其實很難說是有絕對的「對」或「錯」,因為今天的「錯」,有時候是為了明天的「對」而必經的一種過程。在持續改善的道路上,必然永遠都有可以變得更好的地方。就像Linda Rising說的:「人都是work in progress」,每一個人都是在製品(半成品),在閉上眼睛之前都有可改善的機會。

這樣不是在和稀泥嗎?好像什麼事這樣也可以,那樣也可以?也不能這樣說,因為Teddy心中對於軟體開發應該要怎麼做比較好,還是有自己的標準。當別人的做法與自己的方法不同,可以用正面表列的方式,將心中的想法(以Alexander模式的術語來說,就是把Teddy認為理想軟體開發的context、form和force)分析給對方聽。或是用負面表列的方式,指出對方做法中可能存在哪些bad smell或是anti-pattern。至於對方願不願意接受,或是接受的程度有多少,就只能看緣分了。

***

友藏內心獨白:結論還是很宿命論啊挑眉質疑

沒有留言:

張貼留言