大型网站的功能上线控制流程篇 1

ahhuang

相对于项目软件和产品软件的开发（主要是C/S构架），面向大众的网站开发（例如商务网站，门户网站等）有着一个显著的特点：迅猛地推出新特性，改善和淘汰旧特性。只有这样才能够在这个竞争对手多如牛毛，新的想法和创意层出不穷的时代中，为客户带来更多的使用价值以及更好的用户体验，进而能够吸引并黏着更多的，更有价值用户流量。
   
    文章之所以强调“大型”，是因为当网站规模和访问量还比较小的时候，要做到这一点并不难，主要是船小好调头。但是若网站已经发展到一个较大规模时候，我们必将面临诸多的功能分拆，团队的分布式，多线程并行开发的问题。在这样一种环境条件下，我们如何能做到有条不紊的完成这一“快”字诀呢。
   
    在论述这个问题之前，我们先将我们日常的开发内容简单地分为以下几类
  1.新feature（包括旧feature的改进）的上线
  2.过时feature的下线
  3.线上Bug的修复
    -- 严重问题的即时修复
    -- 日常性一般问题的修复
    当然还有诸如网站促销活动，以及与第三方联合开发互动功能等，这些我们在这里就不特别讨论了。
   
    首先我们将上线周期设定为两周，也即每两周都会有一组features可以与用户见面（第一周将代码deploy到产品线上，第二周是稳定期），这样全年就有26（365/14）个可用的功能上线点。该年度计划中所有的feature，在保证其开发先后依赖关系不被破坏的情况下，大致的均分到这26个时间槽上。
   
    接下来对于feature的切分和统筹安排。
    一般来说，各功能在提出阶段，本身通常都是独立且完备的，但很多时候，我们会有相当一部分的功能，由于其粒度太大，或者构思及完成步骤太复杂（例如：整套商业方案的推出，或是技术构架升级），我们必须将其劈成几组相对独立的feature来逐步上线。为的就是能够降低开发失控风险，以及需求设计风险（用户不待见）。
    这样我们就有了两类feature，一类是完全独立的feature，一类是有着前后依赖关系的feature。对于后者，在其分配其时间槽上线的时候要稍微复杂些（一旦某阶段feature的延迟，会冲击到一系列下游feature的开发上线时间），包括设置适当的缓冲间隔，必要时甚至需要剔除掉（推迟）原本计划安排在同一时间槽的其他次重要，但可能有影响的feature
  
    最后各个feature的开发流程都是比较固定的，由于每个feature的粒度都被控制在一个适中的范围内，在确定该feature的伊始，我们就可以给出一个大致的开发预估时间值，并初始定下其在哪个开发槽上线。然后再经由各具体开发团队实际估算，确定具体的开发量，微调之后，进行开发，测试，回归测试，上线。

[ 本帖最后由 ahhuang 于 2009-7-12 12:52 编辑 ]