免費的講座難道就不能問點簡單的問題嗎（上）

March 11 21:10~22:31

 

昨天（三月十一日）Scrum經驗分享活動結束之後有一位鄉民問了Teddy一個關於分工的問題：

鄉民：我們在開發一個手機app程式，團隊成員分成三組，有UI組，手機app組，以及後端的server組，每組大概都有3個人左右。如果要採用Scrum，當UI組在作介面設計的時候，那app組跟server組會沒事做，要如何解決這個問題。

相信很多人在開發軟體時都會遇到類似的問題（無論是否採用Scrum），這個問題的本質可以描述成：

如何讓不同專長的人一起很順的共同合作開發一個產品或是專案

 

Teddy在演講的時候經常談到在台灣開發軟體一個普遍的現象，那就是分工不合作。Teddy個人認為促成團隊成員分工且合作有可能是很多想嘗試Scrum的團隊會遇到最困難的問題之一，因為這個問題不旦牽扯到人的問題，還跟組織結構有關（李組長眉頭一皺，發覺案情並不單純）。參考下圖，Teddy列出四種執行專案的人員分配方式：

• Tyep A：把專案切割成兩個小專案，分別是前台專案（開發手機app）與後台專案（提供前台手機app所需的服務或是其他後台營運所需的功能）。這種分法把UI部門獨立在開發專案之外，當app開發人員需要UI部門的協助時，需要提出需求，再由UI部門的人安排時間來幫app開發人員設計或是檢視他們所開發程式的可用性或是使用者經驗。會把UI部門獨立於專案的原因，有可能是公司有很多專案需要進行，因此把UI部門當成一個共享的資源來使用（UI resource pool）。所以，UI部門的人雖然可能每天都有做不完的UI設計或是評估工作，但是實際上他們很有可能根本從來沒真正參予過任何一個專案的開發工作，甚至也沒有機會真正使用自己所設計出來的最終產品。
  
• Type B：和Type A很類似，但是把前台和後台的開發人員拉到同一個專案團隊中。Type B比Type A要好一些，因為不管開發團隊如何切割，整個產品最後對使用者而言都是「一個產品」。Type A的切割方式可能導致前台與後台的人互推責任，或是雙方各自認為自己已經把工作做好了，但是沒有人去關注整個產品的整合問題，到最後產品還是不好用或是問題多多。
• Type C：把UI、前台與後台的人通通抓到專案裡面來形成一個「虛擬團隊」。雖然這些不同專長的人都屬於同一個專案，但是專案成員還是依據專長區分成UI小組、App小組、後台小組，實際上分派工作的時候還是各做各的。
• Type D：Scrum建議的團隊組成方式—cross-functional team。翻成白話文就是：爭什麼， 摻在一起做撒尿牛丸啊。「理想上」團隊成員具備多種專長，可以比較有彈性的調度到不同種類的工作上。

看到這邊鄉民們一定會說，那有可能組出Type D的這種 幻想 夢幻團隊啊，你要叫UI的人去寫程式，怎麼可能。同樣的，請後台的人去設計UI，這不是請鬼拿藥單嗎？反正綜觀Scrum或是敏捷方法中，「沒有人性」或是「不合常理」的事情又不是只有這一件，所以請不要過於驚惶。先不要急著否定，換個角度思考，如果你被指派去組成一個Type D的團隊，你會怎麼作？（辭職不算…XD）做到了又可以有那些好處？

下回繼續。

鄉民內心獨白：怎麼有點拖戲的感覺…編劇，你累了嗎…XD。

***

友藏內心獨白：Teddy說過好幾次了，軟體開發活動中，最難的就是讓人動腦啊。