從scrum到放棄scrum

剛剛去Agile Meetup的活動，第一次參加五分鐘分享的題目。

其實我不是很知道scrum的全貌，只是偶而從朋友或前主管口中聽到，今天這個題目是有點誇張。其實我只是講一下我們team之前跟現在的作法，換過三個主管，很明顯看得出來每個人的差異。



印象最深的某一個主管，因為他不會寫code，是個PM出來的，然後又沒案子讓他管。
技術方面的問題不會問他，只需要管每個人的進度，delay的話會幫我們解決：比如說激發我們的戰鬥力或找其他人來幫忙cover。所以他每天都在想新招式（的樣子），想說怎樣讓我們工作的更有效率、更快樂。

我後來才知道這叫daily scrum

也或許當時年幼無知，對什麼管理方法都沒有什麼排斥，也無從比較。做就對了，過得還蠻快樂的，那個時候雖然常加班，六日工作也是常事，但是大家一起努力把一個之前沒做過的東西拼出來的感覺......實在是超爽的，這應該就是startup裡面創業蜜月期的感覺吧。

後來公司組織更動，整層樓的人原本都是寫code的，換成一半程式另一半是Art + PM，
天天hackthon的生活開始了，跟案子相關的同事都集中在自己的前後左右，以前要溝通需要上下樓或寄email，現在只需要屁股扭一下，椅子划過去就好了，省下很多溝通成本，另一個好處是跟同樣的人合作不需要再講一次工作上的細節，比如說iOS app的切圖有Retina的格式，我只需要對兩三個人教一次，以後再合作就駕輕就熟了，公司有10幾個art，不會同樣的事要教10幾次。第三個好處是因為PM跟Art就在我旁邊，所以我有很多機會可以觀察到他們在處理哪些事情比較需要幫助，可以幫他們量身打造需要上的教育訓練，像之前就上過「mobile app常用的第三方服務：給PM看的版本」，去掉所有程式碼部分，加強重點在那些第三方服務是在幹嘛還有要如何跟工程師溝通！

這樣的方式似乎有一點敏捷式開發的味道，如果可以更深入，我們或許連prototype的建立都可以做出一套流程，可惜沒有daily scrum了。

而且帶出一個缺點，同事之間技術交流的頻率變少了，新feature不會做不能一次問，要一個個問大家有沒有做過。所以有了新的補救辦法：

大量的技術分享會

一個人1～2個月會分享一個題目，可以是新framework介紹、專題分享、或是code review，其實2個月也差不多完成一個案子了，如果一直沒有梗就一直code review也是可以的。每個禮拜都有1～2場的教育訓練，聽了兩個月就超充實的！我想就算未來組織又再度變動，技術分享會還是會存在的。

與其案子來再去找答案，不如平常就先累積能量、每個方向都有一個人特別專精，人人有功練，也蠻不錯的。