Jan. 21 18:22~19:50
▲喵星人也要一起mobbing
前言
乍看之下,mobbing是一種浪費,整個團隊一起開發卻只用一台電腦寫程式,感覺是把原本可以平行同時工作變成只能循序工作。今天Teddy從敏捷與精實開發的角度來看,為什麼值得做mobbing。
首先,所有的開發工作,不管是多少人一起開發,大致可以分成兩種工作模式:
- Component Development:開發人員專注於開發軟體系統的某個元件,例如,寫後端領域邏輯、設計資料庫schema與下SQL、寫前端JavaScript、寫CSS。這種模式底下開發人員所完成的工作並不能直接使用,需要經過另一個人整合之後,例如串起前後端,才會變成一個完整的功能。傳統的瀑布式開發,大多採用這種專業分工的模式。
- End-to-End Development:又稱為feature development,開發人員需要負責整個功能,也就是所謂的全端開發。全端開發工作並不限定一個人的全端,也可以是交由一個團隊來完成。例如Scrum團隊就是一個可以交付功能的跨職能團隊(全端團隊)。
***
單人開發
單人開發是一般人最熟悉的開發模式,又稱為Solo Programming。如果是採用component development的單人開發,所完成的工作並不能直接交付給使用者,也就是無法直接產生價值,還需要靠整合流程將所有的元件合併成可使用的功能。
從精實開發的角度來看,這種模式所完成的工作都是半成品(work in process/progress;WIP),做得越多,只是累積更多庫存,徒增浪費。
如果是feature development的單人開發,這個人就是所謂一條龍全端工程師,可以獨立產生價值。好的全端工程師非常難得,可以做到一個人的end-to-end。但人的能力總有侷限,有些全端工程師是屬於比較偏後端的全端工程師,有些則是前端比較強的全端工程師,也有那種前後端都不熟的全端工程師XD。
在這種情況下,全端工程師的產出,就受限於他自己最弱的一環。假設Teddy的後端能力有100分,前端能力只有20分,Teddy的總產能,不是 (100 + 20) / 2 = 60分,而是只有20分。這就是瓶頸,流程中生產力最弱的那個環節將會決定整個系統的輸出。
此外,單人開發還會造成維護的問題。如果這個人離職了,他所負責的程式通常連他自己都看不太懂了,更何況要找一個人來交接工作,難上加難,錯誤百出。
***
雙人編程
為了解決單人開發的問題,eXtreme Programming(XP)很早就鼓吹雙人編程或稱為結隊編程的pair programming。兩個人一起開發,一位扮演司機,另一位扮演領航員,兩人彼此互補,兩顆腦袋一起使用,可以減緩單人開發所遭遇到瓶頸的問題。假設採用feature development:
- 小明:後端能力90分,前端20分,系統產出20分。
- 小英:後端能力40分,前端60分,系統產出40分。
兩個人一起合作,整個系統的產出是60分。看到這邊你可能會覺得Teddy在莊孝維。小明、小英個別開發,20 + 40 也是 60分啊,而且搞不好個別開發速度更快。
但實際上,個別開發的速度,除了受限於每個人自身的能力,還受到很多因素影響。例如,專注力、解決bug的能力、當下看出設計問題的能力等等。一個人開發經常會陷入自己的盲點,導致被一些很簡單的「低級bug」給困住跑不出來,徒增很多試錯的時間。
雙人編程可以減少上述問題的發生,又可以自然產生一種良好的「備胎效益」—所有的程式碼至少有兩個人以上都有能力開發與維護,萬一人員異動也不至於整個停擺。
但雙人編程也會造成其他問題,例如如何搭配成員。把兩個菜鳥搭配在一起顯然無法減少瓶頸所造成的限制生產力問題,把兩個高手高高手安排在一起,可能大部分的時間都在吵架「華山論劍」,樂於忙著練功卻忘了實際的開發進度。
***
團隊編程
在mob programming的情況下,團隊成員每個人同時間都貢獻他自己最強的能力在同一件事情上面。例如團隊有五個人:
- 小明:UI/UX擔當。
- 小華:JavaScript高手。
- 小英:後端專家。
- 小龍:新人。
- 小陳:Product Owner(PO)。
在mobbing的情況下,這五個人一起開發。假設現在要開發ezKanban的使用者註冊功能,如下圖。
▲ezKanban使用者註冊流程
如果是跑Scrum,PO需要先寫好user story,然後在sprint planning meeting帶過來跟團隊解釋。此時團隊可能選擇估算每一個user story的大小,接著再將user story切成tasks。
Spring planning結束後,產出spring backlog並將其布置成task board。然後每天Daily Scrum的時候團隊在task board前面報告三件事並認領新的工作。Sprint結束後還有review與retrospective活動,
如果改用mobbing,因為整個團隊一起開發,所以也就不需要另外再開會。要開發註冊功能,就直接從event storming的圖中選出Register User這個使用案例,如果開發人員對需求有問題,例如:
- 要如何註冊?在ezScrum保存一份使用者註冊資料,還是結合Facebook、Google、Line的帳號即可?
- 要不要整合LDAP做到企業內部單一登入?
- 註冊畫面需要填寫那些資料?密碼的長度有限制嗎?
以往這些問題可能會在spring planning討論,如果沒有討論到,例如要不要支援LDAP,等到實作的時候,開發團隊就必須要再去詢問PO。但PO不一定可以立即被找到,因此就產生所謂等待浪費。也有可能開發人員自作主張,覺得應該要做到很有彈性,所以在沒有詢問PO的情況下自己加入支援LDAP的功能,導致過度設計,等review的時候才發現這個問題。過度設計,或過度生產,也是一種浪費。
在mobbing的情況下,有任何需求面的問題,當下就可以和PO討論,減少大量部必要的浪費。
在開發整個註冊功能的end-to-end過程中,有時候處理UI/UX、有時候處理後端、有時候處理前端、有時候釐清需求,團隊中每一個對該領域最擅長的人都可以貢獻自己全部的力量。當遇到自己不熟的領域,也可以從別人身上學習,逐步加強自己的能力。
至於新人,加入團隊當下就可以有貢獻。因為mobbing的時候大家輪流當司機(拿鍵盤與滑鼠的那個仁),就算自己不知道怎麼寫,導航員也會告訴你怎麼做。這種在工作中學習的模式,可以達到最快上手的目的。
***
單件流
Mobbing可以做到精實開發提到理想工廠單件流的效果,在生產線上,每個節拍時間就有一個工作在每個工作站中流動。不需要庫存,也沒有浪費(假設沒有缺陷XD)。Mobbing與生產線單件流的差別在於,mobbing是整個團隊跟著工作跑,當工作處於開發後端階段,整個團隊就開發後端;處於開發前端階段,就一起開發前端,只有一件工作在每個工作站流動。
Teddy以一個會寫程式的PO的角色,和ezKanban團隊mobbing近七個月,這段時間沒開過以往Scrum裡面的任何會議,但卻比以往任何時間更了解產品開發的進度與品質。
開發軟體,應該和打籃球、打橄欖球一樣,整個團隊同一時間一起在同一個球場打球。現在想一想,這不是再自然也不過的事嘛!
***
友藏內心獨白:用過就知道,說破嘴也沒用。