搞笑談軟工: Scrum框架下的跨界開發(2)

2012年7月11日星期三

Scrum框架下的跨界開發(2)

July 10 21:58~22:50

沒想到這一個主題還會有第二集，而且搞不好會變成「連續劇」。今天下午「Apps跨界交流協會」的Ryan帶了一位來自「台創」的「+0」小姐來跟ezScrum團隊繼續討論「跨界開發」的議題。Ryan邀請台創與ezScrum團隊還有Teddy，想要辦一個「跨界開發」的課程。在討論的過程中，「雙方人馬」為了課程要如何進行一度有點小卡住，這也算是遇到跨界溝通的問題。

討論到一半，Teddy突然想到，不只UI/UX designer與software developer（以下簡稱developer）存在著所謂的跨界開發或跨界溝通的問題，單單是developer本身就存在著相同的問題。

看到這邊鄉民們可能會想，奇怪了，developer不是都是「同一國」的人嗎，怎麼會有跨界開發與溝通的問題（迷之音：糧草大營被襲，必有內奸XD）。當然會有啊，想一下，一般的Web系統開發，developer可能包含以下幾種人才：

做網頁與寫Javascript的網頁工程師
用Java寫企業邏輯的程式設計師
資料庫很熟的程式設計師，可能需要撰寫很複雜的stored procedure

以上三類人才，姑且都稱之為developer。這三類的開發活動，其實都需要具備不同的技能。先不要討論把UI/UX designer放到團隊中要如何互動，光是把這三種不同類型的developer放在一起開sprint planning meeting，就有夠好玩的了。請問：

估算網頁工作的時數，要怎麼估？
估算Java企業邏輯的時數，要怎麼估？
估算database schema設計與撰寫stored procedure，要怎麼估？

有些鄉民們可能會說：「這些工作雖然類型都不一樣，但是基本上都還是屬於coding的工作啊，所以大家稍微溝通一下還是可以估算的」。沒錯，重點就是在於溝通這兩個字。在傳統的開發模式之下，專案的schedule是由別人所訂定的，而不是developer。因此，developer基本上不需要溝通每個task需要做多久，反正就是一直被凹，直到做出來就對了。因此，案子從頭做到尾，以上三派人馬可能還是老死不相往來，也不需要去知道其他人到底是怎麼樣去完成他自己的工作。改用Scrum之後，工作的施工時間需要由每一位developer去估算，因此強迫大家去了解其他的在做些什麼、怎麼做。這就是溝通，而且把溝通變成工作流程的一部分，自然而然的發生。久了之後溝通就跟呼吸、吃飯一樣的自然，不同專長之間的界線逐漸就被打破了。

***

但是，UI/UX 設計和軟體開發差距那麼大，有可能搞在一起溝通嗎？Teddy認為這是有可能的。也許期待UI/UX designer會寫程式，或是developer會畫出漂亮的圖、設計出美美的介面或是超級好用的工作流程，在目前來講或許是不可能的任務。但是如同Teddy在「0 與 1 的距離」所提到的：

改善的過程並不是0或1的問題（要嘛什麼都不做，要做就一步到位），而是0慢慢地，慢慢地往1靠攏的過程。0與1之間，還是有很廣大發揮的空間。

只要願意溝通，總是會從0往1這邊慢慢地靠近，至於能靠多近，就要看各個團隊的努力與造化了。

還記得好幾年前Teddy有一段時間對於HCI領域很有興趣，也買了好幾本書來看。但是，靠自己學真的是有點辛苦，但是多多少少還是從0慢慢地往1移動，現在大概移到了0.N左右（鄉民甲：重點是，N等於多少啊？！）。後來Teddy發現，對做軟體的人而言，如果能夠多看看HCI領域的pattern，也不失為一種快速往1方向划動的方法。