當局者迷

Oct. 04 10:16~11:05

 

還記得Teddy在《Slow-start：導入Scrum首部曲》裡面提到一個故事…

鄉民：我們正在開始團隊的第一個sprint，我要求團隊要做Code Review。可能是因為剛開始做Code Review，所以很常發生Task A有人已經做完，移動到Review上，結果負責Code Review的人在過了一天之後發現不少需要修改的問題，所以把Task A又移動回Checked Out，這樣來來回回N次，花費了很多時間。

Teddy：要讓團隊熟習Scrum框架本身就是一件需要花時間的工作，所以一開始先利用幾個sprint（也許2-4個月）讓團隊成員（PO、SM、Team）慢慢習慣在Scrum框架下的合作模式。例如，剛開始時PO寫出的story可能不夠完整（沒時間寫how to demo），或是團隊在sprint planning meeting時溝通不夠，導致真正施工的時候問題很多。如果在隊成員剛剛開始導入Scrum的磨合期，一次劈哩啪啦的丟出太多東西，Scrum也要學、unite test也要做、還要架持續整合系統、做code review、看測試涵蓋率報表等等。團隊成員保證翻臉，你的Scrum當然也run不下去了。

Teddy：既然一開始跑太快容易發生太多塞車，所以還是採用slow-start策略，等「平台穩固」（團隊慢慢熟悉Scrum）之後，再來決定要導入那些工程實務做法也不遲。

Teddy內心獨白：好棒的建議啊 。

***

昨天下午YA先生好心地介紹Teddy認識一位朋友，這位朋友是在輔導Startup公司的顧問，在此簡稱A先生。在聊天的過程中，Teddy提到一個問題。

Teddy：導入Scrum會衝擊公司的文化，有時候公司主管聽到Scrum要做這麼大的改變，就打消念頭了。

A先生：可否舉個例子？

Teddy：例如，我在幫客戶導入Scrum時，一開始只要求兩件事，「讓團隊成員坐在一起（拆掉團隊成員的辦公室隔間）」以及讓團隊成員可以「每週工作40小時（培養有規律的步調）」，但是光是這兩點就很難做到，尤其是「每週工作40小時（正常情況下儘量不要加班）」這一點很多公司的老闆與主管更是不能接受。

A先生：…思考中。

A先生：這我理解，「不加班」只是手段，目的是希望員工可以有效率的利用上班時間完成手邊的工作，並且讓工作沒有效率的問題可以被暴露出來，以謀求改善之道。也許你可以考慮換一種說法，只要強調導入Scrum之後可以改善效率，讓員工有時間可以做更多「（其他的）事情」。也許等團隊真正熟悉Scrum之後，不須（經常性）加班這件事自然水到渠成，也不用你多說。

A先生：以前我們在幫企業客戶導入新的軟體系統的時候，客戶（真正的使用者）都會擔心新系統會大大改變現有的工作流程，他們需要學習很多新的東西。但是我們都會先用「善意的謊言」安慰他們：「你放心，這新的系統很簡單，不會改變太多你目前的工作流程」。先讓客戶願意嘗試，否則就沒有導入的機會了。

***

人都是有盲點，有時候自己陷在某一個點當中，當下認為很重要的事情，其實以原本想要達成的「最終目的」來看，卻只是一種方法的選擇而已。在聊天的過程中，A先生還提醒Teddy一句話：當顧問的人，只能盡其所能地提供建議給業主，但是「公司是他的」，對方想要採納多少建議，自己不用看的太重，把責任都攬在自己身上。

回想起「敏捷軟體開發宣言」的第一句話：

藉著親自並協助他人進行軟體開發，我們正致力於發掘更優良的軟體開發方法。

最終目標是希望團隊可以了解「更優良的軟體開發方法，以開發出更好的產品」。其他的都只是「工具」，這些工具要不要用、何時用、怎麼用，還要需要因地、因人、因時來判斷。否則大家自己回家看書就好了，還要導入顧問做什麼。

***

友藏內心獨白：無形的東西真的不容易賣啊。