似懂非懂的摸索期,Scrum到底是阻力還是助力?
接下來要說的是我們2016年9~12月的故事。
對於一個傳統產業來說，自己養RD並不是一個會讓老闆買單的事情，我們在2015年底時就定義了Server是我們的核心功能，把Server控制好，就掌握了整個產品，人力上的安排以Server優先，client端的分別以專案外包、駐點人力的方式運作。
 |
| 某一次回顧的小把戲 |
當2016年8月底我們終於把Server換掉之後，所有舊資料成功、無感的轉移，還新增了原本辦不到的功能，但是真正跟使用者最直接相關的，是他們手機上的App、電腦上的PC client，使用者感受不到改變，還覺得越改越差，此時我們才領悟client端也應該屬於核心功能，於是重新檢討人力配置，鞭策老闆找人、加人。
似懂非懂的摸索期
PO按兵不動了幾個月（等我們換Server）之後，終於可以開始開發新需求了，於是要求團隊要寫user story、估點數、拆task等scrum要素，而我當時也只是上過兩天某顧問的敏捷專案管理課程，處於一種大概知道要做什麼，但是沒辦法把別人教會的情況。
面臨的問題：
- 寫user story變成我(client PM)跟server PM最痛苦的事，當時的product backlog超級長（現在還是很長）而且跟sprint backlog混在一起
- 現在回想我們其實花了好多時間在寫一些做不到、沒人要、不重要的user story
- Release plannig點數的估算抓不到要領，每一條user story大家都要想很久，好像是為了估算而估算，不知為何而估
- Bug太多，很多時候都是插件解bug
- 站立會議可以開到一個多小時，然後大家還是各做各的
- Retrospective很乾，沒人要說話，或是都是一兩個人在說
- 團隊不清楚自己要做什麼，變成PM需要assign task
- Sprint review時最煩惱的是我，因為大家都只顧自己做的一小部分，build不出來最後一天才知道
- Kanban/Redmine/Backlog(放在google drive)維護起來好累，不知道要看哪一份
- PO:已經花很多錢請顧問教run Scrum了，所以我們要繼續run下去...
- …(回憶起來好痛苦）
開始移除障礙-沈默的retrospective
我最先開始處理的問題是retrospective，因為一個不說話的團隊很恐怖，不知道大家在想啥，不知道有哪些問題，自然也不知道怎麼去改善問題。我先google到的是如何讓retrospective變得更有趣，然後就一樣畫葫蘆，像Sailboat就被我們改編成海賊王，Team Journey變成愛馬仕小火車，Speed Car是我的最愛。慢慢地願意說話的人多了，也比較能夠知道團隊在意的問題是什麼，然後對症下藥。
 |
| 我們也有歪樓板的海賊王 |
站到天荒地老的Stand up meeting
第二個處理的問題是站立會議太久。一開始是Server+App+QA+PM一起開，然後單位的老闆只要沒有會議就會來參加，最多可以到14人左右，有人一時興起多講幾句就會超過半個小時，我自己也覺得站得很累。第一次改變是把Server跟App分開，然後Server team就一直維持每天早上9:30-9:45am直到現在。App team跟Server分開後變成9:45開，但回顧時還是有人覺得浪費時間、沒必要、沒有用，所以改成每天中午12點前在slack上的特定頻道update自己的status，隔了一陣子又有人覺得這樣不好，所以目前最新的狀態是每週1,3,5下午五點開。
Kanban退休
第三個處理的問題是Kanban，因為David說當電子看板跟實體看板並行時，他會犧牲manager的時間去維護實體看板，所以我就犧牲我的時間去做這件事，但是實在是太花時間了，加上大家也逐漸習慣到redmine記錄跟bug有關的內容，到Backlog記錄新功能有關的內容，不需再要透過Kanban進行任務指派跟管理，所以自然就不需要用Kanban了。
下一篇就要寫上完Daniel的CSM之後，我都做了啥^_^*
