前言
很多公司都使用敏捷開發, "Let's learn as we go. Let's adapt as we go", 這個精神是好的, 但不應該變成沒有計劃, 沒有方向. 很多產品經理變成了專案經理, 他們對產品沒有自己的想法, 只是把所有 backlog 裡的 task 都按 sprint 排進去, 結果一個專案彷彿可以永無止境的做下去, 或是時間到就上線, 不管三七二十一. 我們應該問問自己"最終我們想要完成什麼?", 而不只是關心兩個星期後要完成什麼.這不是說要回到從前的 waterfall 開發模式, Basecamp 的策略長 Ryan Singer 為大家介紹目前Basecamp 採取的開發模式: Shaping, Betting, and Building. 這個開發模式如同 Agile, 有固定的timebox, 在 Basecamp 內 timebox 是六個禮拜. 不同於 Agile 的是, 他們並不是把四個月的產品切成六個禮拜為單位, 逐步完成它, 而是六個禮拜要完成一個可以發布的產品, 所以設定了六個禮拜, 而不是兩個禮拜. 根據他們的團隊大小與產品規模, 六個禮拜的工作量可以完成一些值得發布的功能, 六個禮拜的 timebox 限制會改變他們的設計與實作方法. 六個禮拜後是兩個禮拜的"cool down", 用來解 bug, 同時討論接下來要做什麼.
Shaping
六個禮拜稱為"Cycle", 是讓工程師與設計師好好發揮, 不能被打斷的時間, 為了要讓這時間能夠有效被使用, 會有準備階段, 稱為"Shaping". 提出想法或客戶需求的人需要做功課, 研究實用性, 找一些 RD 討論技術可行性. 當準備妥當後, 就可以把提案帶到"Betting Table", 進入"Betting"階段.Betting
Betting 通常發生在兩個禮拜"cool down"時, 大家討論接下來要做什麼. 在這個階段, 大家可以自由發表提案, 提案內容可能包括:"我看到了這個機會/問題, 我提出某某做法. 我驗證過哪些部份可行, 哪些部份還未知...". 這個階段是在決定未來的六個禮拜要花在哪裡, 賭注就是六個禮拜的時間人力成本. 在賭桌上, 我們都知道, 不能一味的加注, 輸了就下桌. 如果六個禮拜過去, 我們啥都沒有完成, 就宣告這個提案死掉了, 這是風險管理. 在我們搞清楚為什麼交付不出來之前, 不應該再加人加時間. 如果有人覺得想法夠有價值, 他可以再讓它進入"Shaping"階段, 繼續做功課, 打磨它, 有一天可能就回到Betting Table. 當提案被接受後, 就進入"Building"階段.Building
"Building"階段是指派人到提案, 而不是指派工作, 提案要怎麼完成是這些人去思考的. 這個階段的精神與 Agile 很像. 將提案垂直切割, 真正做前後端整合, 盡早向外面的人展示你完成了什麼, 而不是把每個元件都先建出來, 最後才做組裝, 這就是"Getting Real". 垂直切割的提案細項稱為"Scope", 它比 task 要大, 通常是3~4天的工作量, 在 Building 的過程中, Scope 會漸漸長出來, 因為目標是六個禮拜交付, 團隊成員必須來回討論哪些 Scope 是 nice-to-have, 哪些是 must-have, 在過程中強迫對話與給予回饋, 而不是大家各自領回 task, 埋頭苦幹.有時候六個禮拜結束, 你會說"我只需要再多一個禮拜!", 那我們就需要看看剩下的工作是什麼. 工作有分上坡面與下坡面. 上坡面是你看到山, 但你不確定要怎麼走. 例如你手上有些 geodata, 你也知道有 geodata library, 但你沒有使用過這個 library, 還有很多不確定性. 而下坡面是指你已經知道路在哪裡了, 只是需要時間走完它. 舉例來講你要煮晚餐, 如果你已經知道你要煮義大利麵, 而且你手上有食譜, 你需要的只是採買與按食譜做出來, 你有100%的信心可以完成, 那麼就值得延長時間.
沒有留言:
張貼留言