C.C. Agile Sprint 36實況報導：Scrum路上的血與淚

August 09 22:06~23:16

 

8月6日是C.C. Agile第36次聚會，由陳超分享「My Agile Tour : From Developer to ScrumMaster」。講者在分享過程中講了很多獨立的小故事，很真實的告訴聽眾他們在實踐敏捷開發的過程中，所遭遇到的各種問題，以及如何對這些問題做出反應。

▼2014 年初，講者從新加坡來到台灣，參與他的第一個Scrum專案，擔任開發人員角色。講者提到一個小故事，團隊剛成立時，建了一個Skype帳號作為與協力廠商與其他部門的溝通窗口。當時大家討論要用何種方法來運用這個Skype帳號，包含指定某人、排值日生等，但團隊成員都沒什麼反應。原本他以為大家都很消極，但沒想到帳號建好之後，第一次有人透過這個帳號發問，幾乎同時間好多位團隊成員都有回應，讓他見識到團隊其實是很有向心力的（Teddy內心獨白：這是台灣工程師外冷內熱的一個案例嗎 XD）。

 

▼為了讓sprint review順利進行，團隊曾經在sprint結束前一天規定不能再修改程式，以便測試story。後來發現這種做法其實是一種mini-waterfall，經過討論之後改成每一個story完成之後，找另一個沒有參與開發的人來測試，通過之後就立即找product owner來看，不必等到sprint review。如此一來，如果Product Owner對於story有意見，也還有時間可以修改。

 

▼團隊每個sprint結束之後的story會佈署到staging環境。雖然團隊成員希望可以直接佈署到production環境，但因為Product Owner的「心臟還不夠大」，不敢直接讓團隊把story佈署到production環境。這一點也是團隊目前還在努力的地方。

 

***

▼後來講者調到台中分公司，參加新的Scrum團隊。此時講者的角色變成ScrumMaster。

 

▼因為sprint長度為一周，團隊覺得在這種情況下畫burndown chart幫助不大，經過討論之後決定不畫了。

 

▼修bug要不要請Product Owner開一個story？Refactoring要不要請Product Owner開一個story？團隊有一陣子曾經糾結於這個問題，後來決定讓團隊自行決定，不用請Product Owner開story才做這些提升品質或是消除技術債的活動。

 

▼團隊以往都在禮拜三開product backlog refinement workshop，但是有時候會議中討論的story因為某些因素並沒有排入下個sprint開發，Product Owner好像也沒有因為review的結果而去重新調整product backlog item的優先順序。因此團隊做了兩件事：（1）告知Product Owner這個現象請他留意，（2）將product backlog refinement workshop移到禮拜一，sprint planning meeting之前才開（基本上就是把product backlog refinement workshop和sprint planning meeting part 1合併）。

***

因為時間的關係，還有一些有趣的故事來不及分享。講者下一階段要擔任Product Owner，等明年有機會再請他來分享。

整場聽完之後，Teddy想起前幾天在Facebook上看到朋友分享〈光有熱情不夠！世界名廚江振誠：「我的廚房裡，現在沒有台灣人。」〉這篇文章裡面的一句話：

首先，我不要我跟你說一個東西，你就照著作。我要你的反應、我要你有想法。

講者的公司在新加坡和台灣都有聘請Scrum顧問，Teddy覺得很棒的一點是，他們會想，會有反應、有想法，甚至是「反對的看法」，而不是講一動、做一動。這一點很重要，因為敏捷開發是一個持續改善的過程，不動腦，只是照做，也許可以解決眼下的問題，但很可能也僅止於此。日後環境改變了，卻還死守著不合時宜的做法，這樣就失去了敏捷開發的意義。

***

友藏內心獨白：也許有一天你會懂。