您的位置:首页 > 业界新闻

敏捷开发将死,互联网开发需要探索性研发流程

2012-11-07 17:32 716 查看
在互联网企业中经历过诸多项目自后,所有的项目经理、TL都会发现这样一个现象,即团队已经使用了敏捷开发流程进行开发的项目(比如Scrum),但是项目依然会延期,会失控,而且质量依然会时好时坏,这和在传统软件研发过程中引入敏捷流程后所带来的巨大改进大相近庭。为什么会这样的,笔者根据自己观察到的一些现象试着分析一下,供大家思考、讨论:

互联网项目开发与传统软件项目开发有几个根本性的区别:

传统软件开发的需求一般是确定的,而互联网项目的开发需求有些是不确定的。
互联网项目与传统软件开发相比,项目周期更短,需求变化更快。
商业策略不同,传统软件强调正确充分地理解需求,然后交付、维护;互联网强调运营,需要不断的跟踪用户的需求,并迅速转化为线上功能,并实时从线上得到用户的反馈。

从这些不同中,我们很容易发现,在开发传统软件中,需求确定,开发时间相对较长,交付版本与需求相同即可,而传统瀑布模式的缺点在于开发过程过长,所以使用敏捷开发流程以后,大的工作项被硬性的切分为小的工作项,然后通过不断的迭代去逼近那个确定的需求,所以能够得到比较好的效果。

但是,当使用相同的方法对付互联网项目时,问题就出现了:

互联网项目的需求是不确定的,这也分两种情况,一种情况是你确实没办法知道需求真的是什么,比如:让某个交互界面有更好的用户体验,或者给用户更有相关性的广告,这样的需求的特点就是没办法清楚的描述需求,即使用户本人也描述不出来,但是如果你做了一个功能或者改进,他们能够很快的评价这个功能和改进好还是不好,这就好像去食客通常不会做菜,也没有办法向厨师描述怎么做菜才能取悦自己,但是他们可以对做好的菜给出意见,好或者不好;还有一种就是需求一直在变化,原先需求并非不变,只是没有变得那么快,比如原先是3~5年,而现在是3~6个月。

需求不确定,那么通过拆分工作项保证执行力的做法的效果就不明显了。与此同时,开发过程中的不规范难免以工期紧当做借口,当系统中的问题代码和设计积累到一定程度时,系统的质量开始下降,这样会进一步延缓开发进度,当项目经理不得不因为质量问题而降低研发速度时,互联网项目的商业策略便越来越得不到满足,迭代速度越来越慢。

笔者根据相关互联网企业已经开始的某些尝试,斗胆给出一个解决方案:探索性开发流程。

首先,应该把互联网开发团队一分为二:工程化团队和探索性团队。将所有与需求确定的功能抽象出来,平台化,由工程化团队支持,维护,并持续重构;将所有与用户体验和判断相关、需求又不确定或者变化很快的需求交给探索性团队。探索性团队的主要使用语言是脚本和Java语言,在试验田上工作,主要任务是通过不停的快速开发和迭代,明确什么样的需求是客户需要的,周期建议是1~2周一次发布,代码不进行测试,也不进行单元测试,通过试验田的流量比例(比如:3%)来控制由于质量问题所带来的线上损失。而工程化团队在效果确定后负责将探索性团队的需求整理出来,代码重构,在完全上线。同时,工程化团队需要编写强大的平台以缩短探索性团队快速迭代的时间和人力需求,同时尽量考虑到探索性团队的代码质量较低的问题,进行危险控制和隔离。

工程化团队使用传统软件的开发模式,团队结构为PM/Dev/Tester/PE,进行传统的Scrum;而探索性团队使用完全开放的开发模式,团队结构为PD/Dev。

写得较仓促,希望有人和我讨论,后续会refine。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐