愛上Mob Programming（下）

愛上Mob Programming（下）

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裡面的任何會議，但卻比以往任何時間更了解產品開發的進度與品質。

開發軟體，應該和打籃球、打橄欖球一樣，整個團隊同一時間一起在同一個球場打球。現在想一想，這不是再自然也不過的事嘛！

友藏內心獨白：用過就知道，說破嘴也沒用。