在 Scrum gathering Shanghai 2014 中, 一位社群的朋友: 李忠利, 他目前在百度擔任資深架構師, 負責百度知道這個系統的研發工作. 我想大家都知道, 百度在大陸是一家很大的公司, 但是還不算是很頂尖的公司, 老闆在最近幾年, 要求他們要有狼性, 要積極改進系統開發的能力, 因為百度也是一家大公司, 相對其它互聯網公司來說, 他們已經有點老態了. (哈, 這些話好像在台灣也很常見)
原先百度知道的工作模式, 是傳統的瀑布式開發方式, 每個角色分工很明確, 他們並沒有明確的項目經理, PM team, Dev team 和 QA team 各自會把工作做好, 可是這樣合作起來, 效率上是沒有太好. 因此他便開始著手流程改造.
1. 第一跳 20 天 -> 11 天
其實這一跳很單純, 純碎只是老闆下令要用 iteration 的方式來開發, 叫大家把時間砍一半, 沒有太大的學問, 在這種 command and control 的體制下, 這是一定可以達到的. 他們的方式還是 waterfall, 可是因為 iteration 的關係, 讓問題很快被曝露出來, 不同角色之間運作不順暢, 並且品質也不好.
2. 第二跳 11 天 -> 6 天
因此他們就開始使用 agile 的開發方法. 並且在以下四個地方加強管控
(1) 檢查需求抵達方式
我們很少能控制需求抵達的時間和數量, 因此speaker採取以下方式,
- 先將所有問題放到序列中, 讓大家知道我們有這麼多事情要處理.
- 請相關 stakeholder 某些特定時間提出和討論需求, 而非隨時隨地, 避免被開發團隊被打擾太多.
- 接著在排定 case 的要處理的優先順序, 讓大家知道我們在處理什麼, 哪些先處理? 或者太多事情了, 需要再加人來處理
(2) 檢查需求處理方式
這裡最主要有兩招
- 以 sprint 方式來進行: 讓需求持續被處理, 持續被交付出來. 並且每個 sprint 開始時可以重新再排順序, 或者是加入新功能.
- 將 story 拆解: 唯有把功能拆解出小的功能, 我們才能分辨出哪些是重要的, 哪些是還好. 也因為切小, 所以比較容易理解, 比較容易交付.
(3) 改變研發交付習慣
開發人員的開發習慣要調整如下
- 根據 story 來交付, 而非 component
- 根據優先順序來開發 story
- 落實 done 的定義
- 要有人統合各個元件, 讓大家彼此知道如何互動, 如何整合
- 修復 bug 比處理手頭上的待做事項重要.
(4) 轉變測試職責
以前測試比較像是後保險桿, 避免被候車撞的很慘. 也就是避免被使用者抓到太多問題, 被罵的很慘. 可是現在要改成車頭燈的角色, 幫專案照亮前面的危險. 所以要能及時提供品質訊息, 專案經理便可以知道, 是否待調整速度, 或是品質的沒有落實等等.
3. 第三跳 6 天 -> 3 天
忠利發現到, 即使發團隊做得再快再好, 可是如果方向不正確, 這個東西不是客戶要的, 也只是事半功倍. 因此接下來應該是要改進業務那邊的能力, 要能及早確認這個功能或體驗, 是否可行, 是否對客戶是有價值. 所以他便採取 Lean 的做法定義出他要做的 MVP, 並且定義出他要衡量的指標是什麼, 再沒有寫任何程式下, 先實驗看看他們想的解法是否可行.
他們用的方法, 和我之前介紹 pretotype 很相似, 有興趣知道詳情的人, 可以自行參考 qCon 北京 2014 的演講, 或是我之前 pretotype 的介紹, 在此我並不想花時間介紹細節 XDD
我覺得他們真的很落實持續改進, 這是我們要好好警惕的, 不要老是數十年都是同一招在做事情, 否則差距就會越來越大....
留言列表
