l

2012年7月11日 星期三

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

July 10 21:58~22:50

image

 

沒想到這一個主題還會有第二集,而且搞不好會變成「連續劇」。今天下午「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方向划動的方法。

***

結論就是,雙方人馬最後同意先嘗試在Scrum框架下,號召UI/UX designer與developer,混和編組,組成Scrum團隊。然後看看在Scrum框架下能否擦出什麼火花出來。

***

友藏內心獨白:擦出火花是OK的,千萬不要搞出人命啊XD。

沒有留言:

張貼留言