Story由一個人獨力完成，好嗎？

May 012 00:00~00:45

一箱不容二貓 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。至於對方願不願意接受，或是接受的程度有多少，就只能看緣分了。

***

友藏內心獨白：結論還是很宿命論啊。