l

2011年7月14日 星期四

Scrum 三年兩個月

July 14 21:07~22:15

算一算從開始帶第一個 Scrum team 到現在也已經過了三年兩個月了,在那之前,Teddy 雖然讀了一堆 agile methods 的書和 papers,對裡面的作法也十分認同,但是並沒有機會真正帶領一個 agile team。經過這三年兩個月,Teddy 有幾點感想。

首先,這幾年 Scrum 在台灣算是有一點小流行,而且由於 Scrum 框架本身很簡單,因此採用的門檻不算高。但是,如果光是學到 Scrum 的皮,而忽略 agile methods 的精神,那麼對於團隊而言可以獲益的地方就相對的比較有限。Teddy 聽某個採用 Scrum 的朋友說起他們實施 Scrum 的方式,一個 sprint 長達 6 周,而團隊實做 story 的方式,基本上還是由所謂的『架構師』設計系統架構,『分析師』負責系統分析,最後再把分析好的設計文件交給 該死的 programmers 去實做。不難想像,以這樣的分工方式,sprint 的長度顯然不可能太短。如果是一個剛開始採用 Scrum 的團隊先採用這種『過渡時期』的作法,倒也無可厚非。但是如果要儘量遵循 agile 的精神的話,日後還是要想辦法打破這種『你是架構師』,『他是分析師』,『我是 倒楣的 工程師』的這種分工方法才好。應該全部的人都是 倒楣的 工程師,要死大家一起死,這樣才有 投名狀 團隊精神啊...XD。

其次,請屏除什麼『打好 agile 專案地基』的這種想法。Agile methods 就是要『embrace change』,就是要 evolutionary design。『捧油』,誤人子弟所賺來的錢,花起來會心安嗎?敏捷開發,絕對,絕對不需要用 UML 或是其他類似的 formal notations 來上手。想學 Scrum 的鄉民們,Teddy 在這邊拜託各位,千萬不要去畫什麼 use case diagrams, 把寶貴的生命(時間)省下來。要看的話,還不如去看 Scrum and XP from the Trenches 就夠了。

再其次,做軟體,用的就是『人腦』。不管用什麼阿貓,阿狗的方法,團隊成員的素質還是最重要的。千萬不要想說,用便宜的價錢多找幾個人來開發軟體,反正人多好辦事啊。錯,應該是人多易誤事,三個和尚沒水喝才是。根據某本書的說法,好的 programmers 跟不好的 programmers,其生產力可以差 10 倍。Scrum 與 agile practices 不是萬靈藥,也不是什麼神秘的武功秘笈。想要知道關於軟體開發的知識,書上幾乎都有寫了。問題出在於『做事的人』有沒有辦法去落實這些招數。這一點 Teddy 多年來有很深刻的感受,為了讓自己晚上可以睡得安穩一點,還是要多花點時間和銀子,找到合適而且可以合作的人。

最後,對於台灣很多中小型軟體開發團隊而言,也許人力不夠,因此導致『一個人打全場』的窘境:Product Owner 要兼任 Scrum Master 甚至還要當 developer,做三份工卻只領一份薪水。亦或是團隊中沒有專屬的 testers / QA Team 一起配合。也有可能對於眾多的 agile practices (例如 unit test,continuous integration,refactoring,pair programming,shared code,等等等等等等...)不熟,或是一時無法落實。此時,請想起 Teddy 所說的『Scrum 之逆練九陰真經 』,但是也要切記不可搞成『同誰,九陰真經不是這樣子練滴 』。

***

這個 sprint 即將結束,明天就是 sprint demo 與 retrospective meeting 的日子,Teddy 在昨天就先把下個 sprint 所要做的 stories 先準備好。今天下午五點左右,同事要 Teddy 幫忙測試(驗收)某個功能。假設這個功能有 10 個可能的路徑,在 Teddy 測試之後發現同事只做了其中的 5 個路徑。和同事討論之後發現,原來另外 5 個路徑需要參考某個資料才可以『有效率』的完成(缺少該資料程式還是寫得出來,但是會效率不彰) 。了解這個狀況之後,Teddy 重新評估一下,認為提供這個資料的重要性提高了,因此就把提供該資料的 story 排入到下個 sprint 中,降低了另外一個 story 的重要性。

Teddy 可以買書,你可以買書,他可以買書,每個人都可以買書。有沒有『傻的願意相信』的精神,那就不一定了。

***

友藏內心獨白:救人啊,地基到底還要打幾集才會結束啊。

13 則留言:

  1. 我覺得還是看案子的特性決定用什麼工具(UML or 其他),以及使用工具的目的。

    像這兩年DVB-H的案子,雖然說是跑Scrum of scrum,每個scrum team負責一個模組,總計畫卻連一個能demo的story都寫不出來,或是反過來說,能demo的story都很大,切割後卻不知道怎麼demo,最後總計畫寫出來的story都很怪(我有點好奇當一個Layer架構的通訊協定,總計畫的story該怎麼寫?)。

    更別說如果從沒討論過怎麼整合?最後整個東西根本就不會動,所以初期的sprint雖然沒用use case diagram,但還是有用sequence diagram討論該怎麼整合,事實上那個sequence diagram只在白板上討論,只能算是一種討論和設計確認的工具(目的是討論)。

    至於當初討論sequence diagram時我擔任的角色算是架構師?還是分析師?我覺得似乎沒那麼重要了,因為我根本就不是總計畫的人卻被X老師凹去做事情。

    第二年只有少數的子計畫有大幅度的改變(我們是其中之一),整體的整合跟框架倒是沒甚麼變,不過慶幸的是之前的設計確實幫了大忙,所以...我們很優閒地把東西做完了,等其他子計畫。

    回覆刪除
  2. To Sprint:

    Teddy 的意思是不說開發軟體完全都不需要化任何的 UML diagrams,只是反對用畫 UML diagrams 的方式來教鄉民們學 Scrum 而已。有機會遇到你再告訴你其中的秘辛。

    回覆刪除
  3. 我完全認同『反對用畫UML Diagram的方式教學Scrum (恕我把X民字眼拿掉)』,因為Scrum本來就沒有規範任何設計方式或設計工具。

    回覆刪除
  4. 那種錢賺起來會睡不著的話哪還有那麼多人在幹IT顧問或是想改行當IT顧問,每家資訊公司都想接一大堆顧問的案子,出張嘴就能收錢,專案做不出來你家的事,我還是照收錢

    回覆刪除
  5. To 匿名:

    所以說 Teddy 還是『涉世未深』,才會有如此天真的想法。錢先騙倒比較實在,反正其他人的『生命』,自然會找到『出路』的啦。

    回覆刪除
  6. 版大, 如果遇到 很強的 Programmer 試圖左右 很弱的 Product owner; 那麼很弱的 Product owner 除了送奶雞以外 要怎麼存活呢?

    回覆刪除
  7. To 樓上:

    (1)如果一個專案有一位『很弱的 product owner』,Teddy 看這個專案也不用搞了,成功機率渺茫,直接解散比較省事。
    (2)存活之道也很簡單,就是趕快讓自己變強啊,不然就是準備開啟 1x4 上面的履歷。對了,還有一個辦法,就是把 所有的 team members 都搞得像 product owner 一樣弱。

    回覆刪除
  8. > 如果一個專案有一位『很弱的 product owner』,Teddy 看這個專案也不用搞了,成功機率渺茫,直接解散比較省事。

    台灣人最會的就是ㄠ,再怎麼低機率的事都想ㄠㄠ看,所以才會搞出一大堆莫名其妙的東西,但事實上,決定不做什麼事跟要做什麼事是同等重要

    回覆刪除
  9. To 樓上:

    台灣人本來就是賭性堅強的一個民族,什麼都要拼拼看...這是一定要的啦。

    回覆刪除
  10. 您好:

    可以請教個關於scrum的實務問題嗎?
    因為其進行方式是由列出story
    然後就按照重要性
    分解出task進行開發
    且成員的安排也強調無分析師、架構師

    那麼是否就完全不需要全面性的系統分析、系統設計的階段?
    關於物件或Table都是有人需要就新增?

    如此在分工進行下
    不會造成相同或相近的東西重複出現嗎?

    雖然知道觀念上有持續整合與重構
    但還是好奇每個人在開發一個功能時
    怎麼能知道是否要共用、修改現有的物件或table
    還是另外增加一個?

    因為是嘗試敏捷式開發的新手
    觀念上若有誤,還請提供一點思考方向

    謝謝

    回覆刪除
  11. To 匿名:

    你這個問題問的很好,相信很多鄉民也會有同樣的疑問,請容Teddy找時間另外寫一篇文章來回答。

    回覆刪除
  12. 感謝Teddy的熱心
    希望能早日拜讀此文

    謝謝

    回覆刪除
  13. To 匿名:

    我前幾天已經寫好了喔,在這裡:
    http://teddy-chen-tw.blogspot.com/2012/02/scrum-14.html

    回覆刪除