互联网敏捷开发之路

互联网行业是一个快鱼吃慢鱼的行业，也是在所有行业中竞争最激烈，变化最快的行业。据统计，2007年的web2.0热潮当中，中国互联网站总数超过130万。如何在这样的行业中脱颖而出，敏捷开发理念让互联网公司看到了新的曙光，同时也在互联网产品研发方面掀起了一场革命…

互联网产品研发特点互联网行业除了竞争激烈之外，其产品服务模式也具有鲜明的特色。互联网的产品往往是面向海量用户的服务，它非常关注用户的行为和反馈，一切以用户价值为核心是互联网产品最核心的特点。这一特点也决定了互联网产品研发具有如下4个关键特性：

1、产品的高度不确定性。 互联网产品面向的用户非常多，这些用户分布在广泛的区域，存在着不同阶层的用户群体，用户的行为和习惯也大多不同，因此作为一家提供海量用户服务的互联网公司，用户需求的获取充满不确定性。如果没有科学的用户研究方法和体系，没有关注用户行为的量化分析工具和理念，是很难给出产品的清晰定位，因此也无法提供真正满足用户需要的产品服务。

2、产品需要快速响应用户的变化。 因为产品的高度不确定性，大部分的互联网产品服务在整个用户研究，需求分析、产品研发及交付服务的过程中，都采用探索式、适应性的研发理念进行产品的研发。通常，他们会把整个产品研发周期划分为若干个迭代，采用迭代式的演进过程，不断的去交付新的产品特性，并通过观察用户的反馈和行为，进而随时调整产品的思路和方向。在这样的情况下，时间是一个很好的促进因素。迭代式开发方法让互联网公司可以更好的缩短产品上线的时间，并完成产品方向的检验和服务的提供，保证在激烈竞争中立于不败之地。现在大部分互联网公司都有自己的实验室，如Google Labs，在该网站上可以看到Google正在试验中的新产品，用户可以去体验并给这些产品提交反馈，Google的开发团队会根据这些反馈来及时调整产品的方向，以提供更好的服务，这样就形成了一个良好的用户端到开发团队之间的互动，也很好的解决了这些产品本身所存在的高度不确定性的问题。

3、团队具备高度创新能力。 根据Business Week做的Most Innovative Company研究，前50位最具创新性的公司从1995年到现在的年平均股票回报率为14.3%，远远高出S&P的行业标准。在互联网行业也是一样，Google之所以能取得如此巨大的成就，通过对它的研究，我们发现，创新是Google成功的秘宝。Google的创新法则包含精英的团队、创造性的氛围、自由提出想法的渠道和20%自由工作时间的机制。由精英组成的敏捷产品开发小团队作战模式是Google创新得于支撑的最关键因素。而在国内，大部分的互联网公司都还是采用“抄、糙、超“这样的一种产品服务跨越式发展思路，但是实际上，在激烈的竞争环境当中，大部分的互联网公司交付的产品都一直停留在“抄”的阶段，而“抄”也更多是形似而神不似。2007和2008年在web2.0的大潮当中，有多少模仿Facebook的SNS社区在不断涌起和不断消茫，其本质还是在于缺乏创新，缺乏对用户需求的最本质的把握和差异化服务的提供。可见，创新对于互联网产品是多么的重要。

4 、产品的Small Release发布模式 。只有创新和更快的开发还是不够的。互联网公司必须更快的交付、交付出质量更好的，更符合用户需要的，并且交付成本更低的产品给用户，这样的公司才能具备更好的竞争优势。传统的软件公司在产品交付过程中需要耗费大量的人力和财力才能解决产品交付的问题，如微软这样的公司，他们在交付类似office这样的软件时，需要先批量刻录，通过渠道发行，开产品发布会等等措施才能把产品交付到终端用户的手中，而交付后还存在巨大的风险，比如用户在安装的过程中出错了，产品在使用过程中有很多Bug等等，所有这些都让传统的软件开发商需要投入巨大的代价来完成产品的交付。而对于互联网产品来说，产品的交付有天然的优势，通过互联网这个巨大的平台，产品的交付可以以很低成本的交付到用户面前。但是由于有海量的用户在使用这些产品，如何保证交付的质量，如何保证更好的满足用户的需求呢？我们把互联网产品的交付方法定义为Small release。它有两个特点，其一是发布过程是逐步对用户放量的过程，其二是尽量早发布，常发布，注重用户的反馈。通过Small release，我们不仅仅做到了更好控制发布过程中产品不完善所带来的大范围影响的风险，同时也进一步提升了产品的质量，并以最快的速度获取到用户的反馈，以帮助产品的改善。

高度不确定性和团队具备高度创新能力要求互联网产品研发要更关注“用户“和”体验“；快速响应变化和Small Release则说明了互联网产品研发的“适应变化”能力。 《敏捷软件开发宣言》所提到的4个核心价值观，它们的要点刚好与互联网产品研发特色想吻合，因此，敏捷开发的理念正不断给互联网公司研发部门所接受，腾讯、Yahoo！、阿里巴巴、校内网等互联网公司都纷纷引入了敏捷开发，并逐步形成各自的最佳实践框架。

敏捷开发实践之路 世上没有轻而易举得来的敏捷，敏捷也不是银弹，你不能指望用简单的3-5步就能实现它。那么，对于互联网产品研发，如何开始敏捷开发的实践之路呢？接下来，我将结合我长时间的实践和思考，通过以下5大步骤来进一步论述。

1：兴奋参与，平等沟通。

人是软件开发中是最为重要的因素，通过观察大量成功项目，我们发现，一个成功的团队总是能做出满足用户需要的产品，它与使用什么技术，采用什么过程没有必然的联系。对于采用敏捷开发的团队而言，要让敏捷开发能在项目中更好的得于应用，成员的兴奋度是非常重要的基础。我们提到的兴奋度包括成员对产品的Ownership、成员在工作中的快乐感和自豪感、成员在工作中的学习能力和可塑性等。我们通过在具体的团队中推动敏捷开发实践的过程中，发现以下的一些点是可以帮助到团队去提升兴奋度的。

1 、团队核心人员的示范作用。产品经理是互联网产品研发的最重要角色。作为团队的核心人员，他的示范作用非常明显。产品经理首先要非常喜欢自己的产品，他需要有把产品当作自己Baby的心态，对产品要体现出热心、爱心、细心和信心，并在团队中进行传播和感染。

2 、从用户和市场中寻找积极正面的反馈。人都有工作自豪感（成就感动机）的追求，因此，产品的不断成功，可以给团队带来极大的兴奋感和成就感。因此，通过定期的用户数据和收入数据的分析，比如产品的同时在线用户数不断攀高、产品本季度盈利再上一个新台阶等等，这些都是很定量的提升团队成就感的方式。

3 、不怕犯错误，培养尝试的勇气。人都可能犯错误，最优秀的团队不是完全不犯错误的团队，而是善于在错误中总结经验和通过学习不断超越自我的团队。互联网产品研发团队尤其如此，互联网产品的高度不确定性，经常会让我们不断的要犯一些“方向性”的错误，我们不能因为犯了错误就去责怪团队，评判团队，而应该拥抱变化、及时发现问题，并进行适应性的改进和学习。

4 、 消除沟通障碍和顾虑，保持广泛、平等的沟通 。软件开发活动是一项团队活动，要使这个群体有效运作，成员之间的沟通和交流非常重要。但是我们也发现，很多团队不具备这样的基础，他们在实际的沟通过程中存在很多障碍，比如开发人员的内向型心理、沟通方式存在问题等等。因此我们要打破这些障碍，在我的实践中，通过IM工具可以有效的解决沟通心理障碍的问题，我们会给团队建立一个QQ群，很多想法和讨论都会通过该群来进行，我们发现，在QQ群里面，每个成员都会很放松，很自由，思维也非常活跃，它有效的帮助我改善了团队的沟通氛围。

5 、保持模糊的工作边界，培养产品的归属感。传统的项目管理方式强调人员的分工，职责清晰化。但是实际上，对于互联网产品的研发，保持一定的模糊工作边界，可以更好提升每个成员的产品归属感。以产品特性的发展过程来说，产品的特性不仅仅来自产品经理的规划，用户的反馈，同样也来源于团队内部。我们看到很多互联网公司都有自己的产品博客，在上面，团队成员可以分享自己对产品发展的看法，提出自己的创意和想法，这些都是去提升产品归属感的好方法。如果团队中人人都有机会充当产品经理，有这个产品就是我自己产品的感觉，我们可以想象，产品一定可以获得更良好的发展。

6 、积极寻找公司领导和全员的关注和支持。不断寻找公司领导的关注，可以保证团队时刻收到激励。特别是当邀请到公司的老板来参与你的项目的时候，这种快乐感和自豪感会极大的刺激团队，它能极大提升团队的热情，即使是加班加点也会毫无怨言。在我的实践过程中，我们常常会通过给项目设定阶段里程碑，当里程碑达到的时候，我们会给团队举行一个Party，并寻找老板的奖励，老板会在Party上给团队直接的激励，当然更重要的是，他会给我们的Party买单。

此外，我们经常提到敏捷团队Monkey的角色，意思是一个团队中常常有一个人会充当搞笑Monkey的角色，他每天都会通过在团队中传递快乐的信息来增强团队的兴奋度，比如每天下午找个时间给团队发一些笑话，让大家在开发过程中也能充满笑声。提升团队兴奋度是解决团队的沟通问题的很好办法，它作为敏捷开发实践的起步，也许不如敏捷开发所提到的具体实践那么具备可操作性，但是它确实相当重要。它是成功的项目团队所具备的共同特质，它甚至可以极大激发团队的创新能力。

2：增强团队内透明度。

认为软件开发是交流的协作游戏的观点指出，项目进展的速度与信息从一个人的头脑传递到另一个人的头脑所需的时间相关。Alistair Cockburn提出了“信息对流”的词汇，他用热气流动来比拟信息在人们之间的流动，并提出了“渗透交流”的概念，他认为，在一个物理的办公环境，每个人在专注于自己工作的同时，会不由自主的听到一些声音，如别人正在讨论某个问题，并能从中不自觉的提炼出一些感兴趣的信息，这可以使发现信息和传递信息的成本降低，因此他觉得物理环境的布局，比如结对编程的座位设置对于信息传递都是非常重要的，同时他提到了在办公局域放置“信息辐射器”的重要性，而信息辐射器所起到的作用就是增强团队之间的透明度。常见的增强透明度的方式有：

1 、故事墙

故事墙展现项目迭代中的User Story的实现情况，用来透明化项目的实时进展情况。它的目的是使任何人只要进入团队的工作区域，就可以立刻了解项目的进度，每个人现在的任务，一些团队需要改进的地方等。

2 、 进度报表。

上图是典型项目进展BurnDown chart 的展示图，透明的展现了项目的进展情况。

3 、回顾总结（Well Less Well）

回顾总结是发生在迭代结束的时候，团队成员针对本次迭代所做的总结方式。它可以透明化的让团队成员都了解到本次迭代做的好的地方以及需要改进的地方。

3：频繁心跳，张弛有度，保持稳定的迭代节奏

Martin Fowler 提到敏捷过程是基于适应而非预测的过程。他认为，敏捷软件开发是一种自适应的跟踪过程，通过快速、短迭代式的开发，不断产出和演化可运做的软件，根据用户的反馈信息做适应性调整，然后进入下一轮快速短迭代式开发是敏捷开发最核心的理念之一。

图：Peter Wegner用数学方法给出了严格的证明

在进行实践敏捷迭代式开发方法的时候，有2个要点是需要注意的。

1 、稳定的迭代节奏是保证团队可持续交付可工作产品的基础。

一个成熟的团队，总会有约定俗成的团队协作的默契。对于敏捷开发的团队而言，稳定的迭代节奏可以让产品保持更稳定的交付。我们有一个产品制定了固定的发布周期，比如每周五固定会发布一些产品的特性，这个时候，总会有一群忠实用户来体验新的特性，长此以往，慢慢的就培养了用户的习惯，并且也保持了用户对产品的期待。Scurm方法也非常强调稳定的迭代节奏，它把每个Sprint都固定为30天，并以此来保持可控的，稳定的节奏，它假设，30天是人们做回顾总结最好的一个时间段，小于或大于30天都会降低这样的效果。

2 、自适应计划的建立。敏捷不是不做计划，而是从Plan到Planning！

常常有人刚接触敏捷开发的时候，都会产生一个误区：“敏捷是不需要计划的”。说这话的人忘记了一个很明显的现象，敏捷开发小组经常会每个一周两周就会花大概半天的时间来进行IPM会议，并列出任务列表。开发小组会把计划的活动扩展到项目的整个过程，而不是在项目一开始就先期完成所有的计划，但是这样的结果常常被认为，敏捷是无计划的。

其实，敏捷开发不是不做计划，而是从Plan到Planning，下图就展示了敏捷开发的Planning的过程。

我们在Planning的过程中也有3点要注意的：

1 、我们仅仅对下一个迭代做详细的计划，长期规划以粗颗粒形式来描述。

2 、整个Planning过程会设定明确的Milestone，Milestone本身也可能发生变化。

3 、到达Milestone的路径是灵活、适应性的。

4：坚持Small Release法则

前面提到，互联网的产品发布模式是Small Release模式。Small Release使产品的交付一直处在半透明的状态，产品上线发布不要一下子就面向用户全体，而是有策略有节奏地逐批放量。它是一种典型的敏捷化发布方式（集市型），采用Small Release以后，通过逐步放大用户群，一方面让用户参与了产品的“测试”，有利于降低缺陷影响的范围和风险，另外一方面也降低了对产品测试资源的投入，没有必要对每一次非正式版的发布进行全面回归测试。另外通过Small Release也实现敏捷原则之一“现场客户”，它建立了一种快捷的用户反馈搜集渠道，通过与用户的快速交互和收集反馈，可以更好的确定下一次Small Release的目标。业界很多互联网公司都采取这样的一种产品发布模式。下面是一些例子：

1. 在eBay上，Gmail测试帐号曾拍出了200美元，《魔兽世界》的内测帐号更拍到了500美元
   Napster 推出其音乐下载服务的2W个beta测试帐户,引来300W的用户注册
   Kazaa 文件交换服务，在数天之内瓜分完20W个测试帐号
   

Small Release 除了是一种尽早发布的理念外，同时也是一门技术活。实施Small Release 对产品架构有一定的要求。大致包括4个方面的要求：

1 、系统切割的组件化；

2 、用户规则的可配置化；

3 、系统服务的版本化；

4 、系统升级的平衡化；

同时，在运营环境上，常常需要部署版本服务器，负责对产品不同版本Release的版本控制工作。

5：加强用户参与，尽快收集用户反馈

微软研究院的Bill Buxton在 MIX09 中做了演讲，他指出尽管当前经济不景气，但是对于与用户体验相关的职业，却可能有非常好的机会。他指出在上一次经济大萧条期间，“工业设计”这个职业脱颖而出，而现在则将会是用户体验，他称之为“回归用户体验”。对于互联网产品来说，用户体验的重要性勿需再讲，更重要的是，如何让用户参与？前面提到的Small Release 目的之一就是让用户能尽早的参与到产品的体验当中去。此外，我们还有以下的方法来让用户更好的参与：

1 、直接观察法 。 直接观察法就是要走到用户实际的环境中去，走入用户的世界，可以采用结构式或非结构式的访谈，时间和方式都可以灵活，但是有个原则：第一就是要仔细的观察，看看用户真正的工作环境，方式，条件。第二就是要多问为什么。

2 、案例研究法。案例研究法主要是找特定的用户群体或典型的用户，这种方式不适合普遍的用户目的调查，但是可以作为对边界用户目的，极端用户场景的分析。这种方法比较合适应用在对现有产品的改造过程。

3 、 调查问卷法 。 最常见的方法，通过设置系列的问题来完成对用户的研究。

4 、人物角色法。人物角色法其实是一种数据建模的方法，通过对特定用户数据的建模，为每个主要的用户群体都创建一个虚构的人物角色，然后去扑捉该群体的最重要的方面，比如他们试图完成那些任务，他们的最终目标是什么？

5 、焦点小组（Focus group）。焦点小组依据群体动力学原理请大约6~9个参试（Participant）对某一主题或观念进行深入讨论。焦点小组实施之前，通常需要列出一张清单，包括要讨论的问题及各类数据收集目标。在实施过程中需要一名专业的主持人，主持人要在不限制用户自由发表观点和评论的前提下，保持谈论的内容不偏离主题。同时主持人还要让每个参与者都能积极地参与，避免部分用户主导讨论，部分消极用户较少的参与讨论。焦点小组具有群体动力（Group dynamics）、自由开放（Open discussion）、定性数据（Qualitative data）和适合探索目的（exploratory purposes）等特点

用户参与已经成为互联网产品敏捷研发最关键的一环，它有效的弥补了互联网产品由于空间所带来的“非客户现场“感，通过这些科学的方法，开发小组跟”客户“又可以保持顺畅的沟通，保证产品是建立在满足用户真实的需求之上的。

一切刚刚开始 现如今敏捷开发已经到了炙手可热的程度，很多公司都已经跟风似的在引入敏捷开发。但敏捷开发真的是银弹吗？是放之四海皆准的真理吗？其实不然，在我们长期的实践过程中，我们发现很多开发组在应用敏捷开发的时候存在很多误区和形式主义。他们常常以为，每天早上坚持开晨会，产品规划按迭代来计划，定期回顾一下这样就是在敏捷开发了，然而他们却忽略了敏捷最核心一点就是“交付可工作的产品成果“，虽然他们在项目过程中划分了若干个迭代，但是每个迭代完成后并没有输出可工作的产品，也没有交付给用户使用并收集反馈，所以在形式上采用了迭代的方式，但实质上他们跟传统的瀑布模型并无差异，因此我们都称之为“伪敏捷“，同样还有很多这样的例子。此外，敏捷开发在不同的团队的应用也不尽相同，业界也有多种的方法体系。但是我们透过这些方法发现，敏捷开发只是一种理念，它传递着以人为本的管理理念，强调团队的自我管理和驱动，并持续改进个人和组织的思想；敏捷开发也提出了一些做事原则，如小步快跑、简单设计，拥抱变化，持续集成等等，这些理念和原则跟互联网产品研发特色异常吻合。

在接下来系列文章中，我将继续分享在互联网企业中，独具特色的敏捷开发实践历程，我会着重提到互联网产品特性驱动的需求管理方法、打造兴奋，平等，参与型团队的项目管理经验、运营形产品的敏捷实践方法等等。我相信，敏捷开发在互联网行业的应用也是刚刚开始，希望通过系列的分享交流，能得到更多朋友的反馈和建议，让敏捷开发能做得更好！

原文出处： http://hi.baidu.com/chenwei6111/blog/item/b3bacf38c7e86fccd462253f.html