项目管理沙龙第九次聚会纪要

项目管理沙龙第九次聚会纪要

前不久在腾讯举行了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讲一下他们的敏捷实战经验。