敏捷开发将死,互联网开发需要探索性研发流程
2012-11-07 17:32
716 查看
在互联网企业中经历过诸多项目自后,所有的项目经理、TL都会发现这样一个现象,即团队已经使用了敏捷开发流程进行开发的项目(比如Scrum),但是项目依然会延期,会失控,而且质量依然会时好时坏,这和在传统软件研发过程中引入敏捷流程后所带来的巨大改进大相近庭。为什么会这样的,笔者根据自己观察到的一些现象试着分析一下,供大家思考、讨论:
互联网项目开发与传统软件项目开发有几个根本性的区别:
传统软件开发的需求一般是确定的,而互联网项目的开发需求有些是不确定的。
互联网项目与传统软件开发相比,项目周期更短,需求变化更快。
商业策略不同,传统软件强调正确充分地理解需求,然后交付、维护;互联网强调运营,需要不断的跟踪用户的需求,并迅速转化为线上功能,并实时从线上得到用户的反馈。
从这些不同中,我们很容易发现,在开发传统软件中,需求确定,开发时间相对较长,交付版本与需求相同即可,而传统瀑布模式的缺点在于开发过程过长,所以使用敏捷开发流程以后,大的工作项被硬性的切分为小的工作项,然后通过不断的迭代去逼近那个确定的需求,所以能够得到比较好的效果。
但是,当使用相同的方法对付互联网项目时,问题就出现了:
互联网项目的需求是不确定的,这也分两种情况,一种情况是你确实没办法知道需求真的是什么,比如:让某个交互界面有更好的用户体验,或者给用户更有相关性的广告,这样的需求的特点就是没办法清楚的描述需求,即使用户本人也描述不出来,但是如果你做了一个功能或者改进,他们能够很快的评价这个功能和改进好还是不好,这就好像去食客通常不会做菜,也没有办法向厨师描述怎么做菜才能取悦自己,但是他们可以对做好的菜给出意见,好或者不好;还有一种就是需求一直在变化,原先需求并非不变,只是没有变得那么快,比如原先是3~5年,而现在是3~6个月。
需求不确定,那么通过拆分工作项保证执行力的做法的效果就不明显了。与此同时,开发过程中的不规范难免以工期紧当做借口,当系统中的问题代码和设计积累到一定程度时,系统的质量开始下降,这样会进一步延缓开发进度,当项目经理不得不因为质量问题而降低研发速度时,互联网项目的商业策略便越来越得不到满足,迭代速度越来越慢。
笔者根据相关互联网企业已经开始的某些尝试,斗胆给出一个解决方案:探索性开发流程。
首先,应该把互联网开发团队一分为二:工程化团队和探索性团队。将所有与需求确定的功能抽象出来,平台化,由工程化团队支持,维护,并持续重构;将所有与用户体验和判断相关、需求又不确定或者变化很快的需求交给探索性团队。探索性团队的主要使用语言是脚本和Java语言,在试验田上工作,主要任务是通过不停的快速开发和迭代,明确什么样的需求是客户需要的,周期建议是1~2周一次发布,代码不进行测试,也不进行单元测试,通过试验田的流量比例(比如:3%)来控制由于质量问题所带来的线上损失。而工程化团队在效果确定后负责将探索性团队的需求整理出来,代码重构,在完全上线。同时,工程化团队需要编写强大的平台以缩短探索性团队快速迭代的时间和人力需求,同时尽量考虑到探索性团队的代码质量较低的问题,进行危险控制和隔离。
工程化团队使用传统软件的开发模式,团队结构为PM/Dev/Tester/PE,进行传统的Scrum;而探索性团队使用完全开放的开发模式,团队结构为PD/Dev。
写得较仓促,希望有人和我讨论,后续会refine。
互联网项目开发与传统软件项目开发有几个根本性的区别:
传统软件开发的需求一般是确定的,而互联网项目的开发需求有些是不确定的。
互联网项目与传统软件开发相比,项目周期更短,需求变化更快。
商业策略不同,传统软件强调正确充分地理解需求,然后交付、维护;互联网强调运营,需要不断的跟踪用户的需求,并迅速转化为线上功能,并实时从线上得到用户的反馈。
从这些不同中,我们很容易发现,在开发传统软件中,需求确定,开发时间相对较长,交付版本与需求相同即可,而传统瀑布模式的缺点在于开发过程过长,所以使用敏捷开发流程以后,大的工作项被硬性的切分为小的工作项,然后通过不断的迭代去逼近那个确定的需求,所以能够得到比较好的效果。
但是,当使用相同的方法对付互联网项目时,问题就出现了:
互联网项目的需求是不确定的,这也分两种情况,一种情况是你确实没办法知道需求真的是什么,比如:让某个交互界面有更好的用户体验,或者给用户更有相关性的广告,这样的需求的特点就是没办法清楚的描述需求,即使用户本人也描述不出来,但是如果你做了一个功能或者改进,他们能够很快的评价这个功能和改进好还是不好,这就好像去食客通常不会做菜,也没有办法向厨师描述怎么做菜才能取悦自己,但是他们可以对做好的菜给出意见,好或者不好;还有一种就是需求一直在变化,原先需求并非不变,只是没有变得那么快,比如原先是3~5年,而现在是3~6个月。
需求不确定,那么通过拆分工作项保证执行力的做法的效果就不明显了。与此同时,开发过程中的不规范难免以工期紧当做借口,当系统中的问题代码和设计积累到一定程度时,系统的质量开始下降,这样会进一步延缓开发进度,当项目经理不得不因为质量问题而降低研发速度时,互联网项目的商业策略便越来越得不到满足,迭代速度越来越慢。
笔者根据相关互联网企业已经开始的某些尝试,斗胆给出一个解决方案:探索性开发流程。
首先,应该把互联网开发团队一分为二:工程化团队和探索性团队。将所有与需求确定的功能抽象出来,平台化,由工程化团队支持,维护,并持续重构;将所有与用户体验和判断相关、需求又不确定或者变化很快的需求交给探索性团队。探索性团队的主要使用语言是脚本和Java语言,在试验田上工作,主要任务是通过不停的快速开发和迭代,明确什么样的需求是客户需要的,周期建议是1~2周一次发布,代码不进行测试,也不进行单元测试,通过试验田的流量比例(比如:3%)来控制由于质量问题所带来的线上损失。而工程化团队在效果确定后负责将探索性团队的需求整理出来,代码重构,在完全上线。同时,工程化团队需要编写强大的平台以缩短探索性团队快速迭代的时间和人力需求,同时尽量考虑到探索性团队的代码质量较低的问题,进行危险控制和隔离。
工程化团队使用传统软件的开发模式,团队结构为PM/Dev/Tester/PE,进行传统的Scrum;而探索性团队使用完全开放的开发模式,团队结构为PD/Dev。
写得较仓促,希望有人和我讨论,后续会refine。
相关文章推荐
- IT研发核心课程系列——移动互联网产品团队的敏捷开发之路 每月一期
- 移动互联网敏捷开发流程
- IT研发核心课程系列——移动互联网产品团队的敏捷开发之路
- 参考敏捷之偏互联网项目开发流程----最近在忙的事儿
- 混合敏捷研发(二) 敏捷开发中,Product Backlog 是否足以实现需求管理?
- 敏捷开发智慧敏捷系列之五:定不定流程和模板?
- 《现实世界的敏捷开发-大型敏捷研发团队》培训课程扩展阅读
- 敏捷开发产品管理系列之四:新产品研发
- 敏捷开发“松结对编程”实践之二:计划与设计篇(大型研发团队,学习型团队,139团队,师徒制度,设计评审,预想陈述,共同估算,扑克牌估算)
- Scrum敏捷开发从零开始(3):开发流程
- 敏捷开发“松结对编程”实践之三:共同估算篇(大型研发团队,学习型团队,139团队,师徒制度,敏捷设计,估算扑克,扑克牌估算)
- 敏捷开发的简单流程
- 微软软件研发策略转变之路 从瀑布式走向敏捷开发
- 我的敏捷开发实践—— 拥抱变化的产品开发流程
- 腾讯研发项目总监:互联网产品开发中的“快”字诀
- 应用开发构想:手机条码购物软件(For当当网)--无线互联网需要创新
- 如何打造139团队(不同层次人员的选择与培养,大型研发团队,大型敏捷开发团队)
- 敏捷开发“松结对编程”实践之一:人员结构篇(大型研发团队,学习型团队,139团队,师徒制度)
- 敏捷开发“松结对编程”实践之三:共同估算篇(大型研发团队,学习型团队,139团队,师徒制度,敏捷设计,估算扑克,扑克牌估算) .
- iOS“.NET研究”平台应用开发的敏捷设计流程