在 Scrum gathering Shanghai 2014 中, 一位社群的朋友: 李忠利, 他目前在百度擔任資深架構師, 負責百度知道這個系統的研發工作. 我想大家都知道, 百度在大陸是一家很大的公司, 但是還不算是很頂尖的公司, 老闆在最近幾年, 要求他們要有狼性, 要積極改進系統開發的能力, 因為百度也是一家大公司, 相對其它互聯網公司來說, 他們已經有點老態了. (哈, 這些話好像在台灣也很常見)

原先百度知道的工作模式, 是傳統的瀑布式開發方式, 每個角色分工很明確, 他們並沒有明確的項目經理, PM team, Dev team 和 QA team 各自會把工作做好, 可是這樣合作起來, 效率上是沒有太好. 因此他便開始著手流程改造.

 

zhidao  

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

我覺得他們真的很落實持續改進, 這是我們要好好警惕的, 不要老是數十年都是同一招在做事情, 否則差距就會越來越大....

    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()