老翅寒暑

項目管理沙龍第九次聚會紀要

前不久在騰訊舉行了2011敏捷大會，但是因為加班或者報名的原因，沙龍里只有一個人參加了敏捷大會，所以本次聚會由夏勇分享參加大會的心得。

對大家印象比較深刻的首先是雅各布森給出的一系列敏捷卡片，我們拿到的這一系列卡片有四組，基本覆蓋了敏捷過程的方方面面，對于敏捷過程的指導作用還是比較強的。所以我們決定接下來將這個卡片電子化一下，讓每個人都可以看到。

QZone的產品經理的演講還是挺讓人感興趣的，他號稱是QZone每周五天可做到約二十次發布。在這種情況下，如何保證項目成果的質量穩定，是需要一定的水平的。QZone前臺使用php，后臺使用C++，所有模塊集中發布。他們有一個專門的發布系統，可以做到“一鍵式發布”。他們在發布之前做的測試，只測試一些關鍵邏輯，小的地方就不測試了。QZone自己把這種發布形式叫做“灰度發布”。結合從會議上聽到的消息，我們分析他的測試方法大致有如下幾個：產品關鍵部分要做專門的測試；修改所牽涉的部分做簡單的測試；使用招募的內測用戶對系統進行在線測試；將用戶群拆分，比如把某個二線城市的用戶都切換到新版去用，跟蹤他們的使用狀態等。有人舉了一個淘寶為世紀光棍節做系統壓力測試的例子，因為要產生一個訪問的峰值，所以淘寶發了一個優惠券讓大家去搶，結果峰值自然就出來了。不過像QZone這樣的測試，最小測試顆粒度都應該是User Story級別的，再小可能就太細太多了。

QZone在劃分Backlog的時候，先定2～3個月的目標，顆粒比較粗，然后定每個sprint的目標。我認為這種形式比較適合于那些開始時候需求不明確，需要在過程中不斷挖掘需求的項目。在制定Backlog的時候，采用顏色將Backlog分類，比如數據界面的Backlog標為綠色，屬于Bug的標志為紅色等。這個辦法值得學習。

敏捷會議上的另外有人提出了“輕敏捷”的概念，和與之相對應的“傳統敏捷”相比，他拋棄了過程數據的收集，只看結果。其他經驗的包括流程可視化，流程梳理，以及交流一定要面對面。

雅各布森講了“如何做有效的Backlog”。大致就是說從項目干系人、藍圖、用戶的變更申請等處得到Idea，然后把Idea整理成Use Case。Use Case要包含范圍、場景描述等。再基于Use Case整理出可以Telling的Story。最后把Story拆分成一個個可以交付的Backlog。經過優先級排序、價值評估、風險評估之后，就可以將這些Backlog納入到Sprint中去。

一個Backlog可以分成許多個Task，一個Task分配到一個人。在狀態處理上，Task可以被Block，Backlog可以被歸為impediment。Task的顆粒度要細分到保證能夠在一天內完成。一個Backlog的所有的Task完成之后，稱為Backlog的Complete，但是Backlog要從Complete到Done，還需要經過測試和驗證才行。所以要注意所有Task完成之后，到Backlog的Done還是需要有時間的。另外，上一次Sprint沒有完成的Task，要作為下一個Sprint中最高優先級的工作來做。

下一次聚會，我們請AOM講一下他們的敏捷實戰經驗。