第八梯次Scrum敏捷方法實作班之Q&A（上）

Jan. 28 09:31~22:28

 

今天是大年初一，祝福鄉民們馬年找到伯樂。

今年1月11~12日舉辦的「第八梯次Scrum敏捷方法實作班」，學員問了非常多的問題，有些問題還蠻有趣的，利用新年時間來分享一下這些問題。

學員：Taskboard可否用電子系統取代？

Teddy：可以使用電子系統與實體看板並行，但不建議用電子系統取代實體看板。雖然說「老佛爺是要放在心裡面尊重的」，但是三不五時不把「老佛爺」的名號亮出來，誰有知道你真的有把「老佛爺」放在心上。實體看板的好處是可以讓資訊一目了然，電子看板雖然感覺起來比較「高科技」，可以「保存資料」、「分享給不同位置的人觀看」，但這應該算是「次要目的」，而非「看板」的「主要目的」。除非你的團隊是完全分散式的團隊，所有的人都不在同一個地點工作，否則不應該完全捨棄實體看板。

科學人雜誌有一篇文章〈大腦偏愛紙本書〉，裡面提到：「人們閱讀紙本書時，可能會在腦中建立如地形般的心智地圖，比起使用螢幕閱讀，更容易記住內容、提升理解力。」看板和書的首要重點，都是「讓人容易理解某項資訊」，如果只是為了「容易攜帶」、「容易分享」、「容易保存」而犧牲了原本「容易理解」的目的，這樣的決定是否值得就需要團隊自行判斷。

***

學員：案子做到後面工作量變少，可以改變sprint長度嗎？

Teddy：這個問題有點奇怪，如果工作量變少，應該是「提早將產品釋出」，為什麼要改變sprint長度？如果是一個新的Scrum團隊，還不了解自己適合怎樣的sprint長度，此時可以在2~4周內嘗試不同的sprint長度。但是一旦找到合適的步調，Teddy不建議變動sprint長度。

***

學員：Story和task定好之後（sprint planning meeting之後），遇到外部急需的功能，要馬上插入，該怎麼辦？

Teddy：沒怎麼辦，就讓它「插入」啊。按照Scrum的說法，sprint進行中不應該調整sprint backlog，但是實務上如果真的有非常、非常緊急的事情，還是應該要優先處理。重點在於，把這種突發事件當成「例外」，偶一為之還可接受。但是，如果「例外」變成「常態」，那就要檢討為什麼會有這樣的現象，是哪個環節出了問題。例如，如果是因為bug太多，導致「救火」的工作比「種田」的工作還要多，從「碼農」變成了「消防隊員」，那就要擬定改善品質計畫。

***

友藏內心獨白：Scrum只是一種做事的方法。