l

2010年3月19日 星期五

萬事起頭難:如何開始第一個 Sprint?

03/19 22:48~23:58

幾個月前有人問 Teddy,要如何開始第一個 sprint?按照 Scrum 的講法,只要有 product backlog(就是說已經有可以開工的需求)就可以開始第一個 sprint。問題是,實際執行起來好像沒那麼簡單。想像一下,假設你的團隊要開發一個新的『網路性向測驗系統』,很幸運的,你的 Product Owner 已經把需求大致列出,因此你有了一個可以開始施工的 product backlog。但是這個系統還希望能作到下列幾項『非功能需求』:

  • 跨平台
  • 支援多種不同的資料庫,例如 MySQL,PostgresSQL,Oracle,MS SQL 等等。
  • UI 容易使用且必須支援目前主流的瀏覽器
  • 要具備擴充性(這一點很抽象,但是似乎每個軟體系統都想要有擴充性)
你的團隊之前都在用微軟 .NET 技術開發,由於『跨平台』的需求,你正考慮是否改用 Java(PS:你知道 .NET 也有 Linux 版的 Mono 可以用... 但是怕相容性的問題所以暫時不考慮)。問題來了,你的團隊對於 Java 技術不熟,之前也沒有同時支援多種不同資料庫的經驗。對於 Web UI 要使用哪種方式 AJAX 元件也不了解。更慘的是,要如何設計一個具備『擴充性』的軟體架構實在是需要時間來規劃設計。

那麼,就算基本的需求已經有了,技術上很多方向都不確定,如何直接開始第一個 sprint 呢?如果依照 Scrum 的說法,假設第一個 sprint 先挑三個 stories 來做,這三個 stories 會橫跨系統的每個 layers (end-to-end stories)。所以,系統的架構與所要使用的技術就會這樣慢慢地,慢慢地『長出來』。講是這樣講沒錯,可是,團隊成員根本連要使用哪種 Java 技術架構來開發都不知道,真不知道要如何一下子就立刻實做功能。也許就是為了解決專案起頭的難題,所以最早 Scrum 的流程其實是長這樣子滴:


注意到了嗎? Sprints 開始之前有一個 Planning & System Architecture 階段。可是後來 Scrum 的流程圖卻都演變成下面這個樣子:


Planning & System Architecture 階段到底被誰吃掉了,難道真的有那麼順利可以直接就進入第一個 Sprint?

************

這個疑問應該是很多想執行 Scrum 的鄉民們都會遇到的問題。以下 Teddy 列出幾種可能性給鄉民們『僅供參考』一下:


  1. 根本不會有這個問題:你很好狗運,新的案子使用的技術你的團隊已經很熟悉了。所以,沒問題,只要有了 product backlog 就可以開工大吉了。
  2. 帶著鋼盔向前衝:就給它完全相信 Scrum 的精神,直接從完成 stories 的過程中逐步地來釐清所要選用的技術與軟體架構。可能遇到的風險是,在開發的過程中,所選用的技術或是軟體架構改了好幾次。
  3. 先做 technical stories:在 Scrum 中將技術性的問題(例如,架設 continuous integration system)列成 technical stories 是常見的一種作法。所以,第一個 sprint 所選擇 stories 可能都是所謂的 technical stories,包括訂定軟體架構雛型,決定 UI 技術,決定連接資料庫技術等 。不過,這麼做好像跟第一張圖裡面的 Planning & System Architecture 階段所要做的事好像喔。
  4. 規劃一個 sprint 0:這個作法在 Becoming Agile: in an imperfect world 這本書裡面有提到,在書中稱為『iteration 0』(不過這本書被 Bas 罵到臭頭...請看 Amazon 上面 Bas 對於這本書的評論)。這個 sprint 0 要做的事說穿了就是原本的 Planning & System Architecture 階段,只是名稱不一樣而已。
『正港 Scrum』可能不會建議鄉民們採用 4 甚至是 3,因為這樣看起來就有點像是 big up-front design 的嫌疑,然後一不小心就退化成傳統 waterfall 流程了。但是,如果你的團隊就是需要一個小小的『sprint 0』來作為開端,說真的 Teddy 是覺的這樣一點點的事前準備應該是 OK 的啦。畢竟 agile 並不是反對 up-front design,而是反對 big up-front design。但是要記得,sprint 0 之後就要開始 sprint 1 真正開發功能了,不能變成 sprint 0.0 -->sprint 0.1--> sprint 0.2-->sprint 0.3--> sprint 0.x 這樣就陷入了 big up-front design 了。

友藏內心獨白:叔叔有練過,小朋友如果要學的話要小心,逆練『九陰真經』如果走火入魔後果請自行負責。

4 則留言:

  1. 寫得太好了!

    我也提供一些建議給需要說服team裡有設計魔人的小鄉民

    up front design到什麼樣的程度可以試著回答一個問題

    在設計上所投入的資源會不會大於逐步改善的成本?

    如果答案很明顯是肯定的, 那所做的design就是浪費.

    通常專案超過半年以上的開發很難有一步到位的設計, 除非是請先知在做設計啦

    至於逐步改善的成本則可以透過一些軟工的實踐(如XP)來降低

    回覆刪除
  2. 不過如果會考慮到成本問題,那還能叫設計魔人嗎 XD
    有些人就是不管怎樣都要來個大改革,完全不管別人死活

    回覆刪除
  3. 的確,設計魔人通常是不會考慮成本問題,隨時隨地都想把系統來個『徹底大翻修』。如果設計魔人只是 team member 之一,那還勉強可以呼弄他一下(不過每次開會都會搞得很累,光是討論要如何做所花得時間可能都可以把功能做好了)。如果設計魔人是 team leader,就更麻煩了。

    話說回來,設計魔人應該是不吃 agile 這一套的。送他幾本 agile 書看一下,看看能不能去掉他的『魔性』。阿彌彌陀佛...

    回覆刪除
  4. 這問題很難說,我常常當救火隊...感想是不論用什麼開發方法,如果團隊沒有維護逐步改善的想法,讓軟體時時保持一個合理的良好狀態,久了程式也修不動了,最後維護的成本會變得異常之高。

    回覆刪除