從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場的教育訓練,聽了兩個月就超充實的!我想就算未來組織又再度變動,技術分享會還是會存在的。

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







張貼留言