只有一個開發人員可以採用Scrum嗎？

Oct. 15 10:14~11:17

 

一般建議Scrum團隊大小在7加減2（也就是約在5-9）人之間，但是Teddy還是經常會被問到一個問題：「我們團隊只有3個人，可以採用Scrum嗎？」當然「法律」沒有規定少於5個人就不能組織Scrum團隊，但是實際實行起來可能會有一些限制。但這些限制不必然一定會造成鄉民們在人少的情況下就不能採用Scrum，端看鄉民們想要從Scrum中獲得哪些東西。

今天來分享一個只有一個開發人員的Scrum團隊的故事。某公司有一位「設計師X」，專門在處裡不同團隊的使用者介面設計需求。大老闆一直覺得這位設計師「效率」不太好，很多工作都沒有做完，但是又無法很具體地說出來到底哪些工作沒有做好。後來，老闆就指派程式設計出身的鄉民甲去「關照」這位設計師X，看看能否提升他的效率。但是，鄉民甲根本不懂「介面設計」，要如何來檢驗設計師X的工作效率呢？

結果鄉民甲採用了一個很簡單策略，就是幫設計師X導入Scrum。嚴格講起來也不能算是真正導入Scrum，鄉民甲主要採用了Scrum裡面的這三點：

• Product backlog：鄉民甲幫助設計師X把他手邊的所有工作，整理到product backlog裡面，然後排定每一件工作的優先順序。
• Sprint backlog：鄉民甲協助設計師X挑出每一個sprint準備完成的工作。由於整個開發團隊只有設計師X一個人，所以每項工作所需的施工時間就由設計師X直接填寫。
• Taskboard：接著，鄉民甲幫忙設計師X建立工作看板，用視覺化的方式追蹤每項工作的進度。

***

過了三個sprint之後，鄉民甲發現，設計師X已經把所有product backlog的工作全部都做完了，而且實際上根據鄉民甲的觀察，設計師X的「工作效率」其實比他大老闆內心所想的還要好很多。那問題到底是出在哪裡？根據鄉民甲的觀察，主要的問題是：

• 最終驗收的人太忙：由於設計師X的工作除了介面設計之外，還包含許多使用者經驗設計。公司大老闆對於使用者介面非常重視，因此所有的介面設計結果，都需要大老闆看過才可以定案。公司之前的情況是，設計師X可能早早就把東西做好，但是大老闆沒有時間看。等大老闆有時間，看了之後又不滿意，要求修改甚至重作。因此從大老闆的角度來看，一件工作的完成，經歷那麼長的時間（大老闆把其他人等待他來驗收的時間也算到設計師X的工作時間上），所以大老闆會覺得設計師X的效率不好。
• 需求修改沒有被外顯化：由於大老闆自己對於介面與使用者經驗設計也有一定的看法，因此設計師X所做出來的東西經常會被大老闆要求要修改。而這些修改的要求，通常都是大老闆「口頭上」直接告知。同樣地，大老闆把修改（有時候甚至是整個重作）的時間看成是原本同樣一件工作的時間，所以大老闆會覺得設計師X的效率不好。
  

***

視覺化管理

套句Teddy經常說的一句話「Scrum不會幫你解決問題，但是可以把問題暴露出來」。鄉民甲將需求與工作流程用視覺化的方式表達出來之後（建立product backlog與taskboard），發現大老闆其實是整個工作流程上的「瓶頸」，因為大老闆實在是日理萬機，太忙了，因此設計師X經常需要等待大老闆有時間的時候，才可以確認他手邊的工作到底是否算是「做完」。有了這樣的資訊之後，鄉民甲就可以跟大老闆溝通三件事：

1. 大老闆那麼忙，是否要授權其他們來驗收設計師X的工作？
2. 是否有可能請大老闆花時間幫設計師X的工作定義一下DoD（Definition of Done）？
3. 幫設計師X釐清一下，他的工作效率其實已經很好了。

至於最後大老闆最後做出什麼裁決，這就不是鄉民甲可以干預的，至少進到「幕僚」的責任，儘量提供老闆決策的參考資料。

***

友藏內心獨白：有實體看板真的差很多。