敏捷开发-快速迭代

今天跟大家分享的是“敏捷开发、快速迭代”。我们大都采用的是“瀑布开发模式”,有了问题,就得返工,虽然最终的产品会比较齐全完善,但是开发周期太长,开发人员会产生排斥,甚至厌恶的心理。经过YH系统的开发,也且生体会到了这一弊端。

有问题就要去解决它!于是我想到了“敏捷开发”。借鉴敏捷开发模式,来改善软件开发过程,提高项目的开发效率。

要想借鉴,首先得弄懂以下3个问题。

1. 什么是敏捷开发

百度百科中是这样解释的:敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

我们可以这样认为,敏捷开发是一种面临迅速变化的需求快速开发的能力。要明确几点:

敏捷不仅仅是一个项目快速完成、而是对整个产品领域需求的高效管理;

敏捷不仅仅是简单的快,而是短周期的不断改进、提高和调整;

敏捷不仅仅是一个版本只做几个功能,而是突出重点、果断放弃当前的非重点;

敏捷不仅仅是随时增加需求,而是每个迭代周期对需求的重新审核和排序。

2.如何进行敏捷开发?

敏捷开发的体系建设主要有如下六个方面:

1、组织建设

      也就是团队建设,建立以产品经理为主导,包含产品、设计、前后台开发和测试的team,快速进行产品迭代开发;扁平化的团队管理,大家都有共同目标,更有成就感;

2、敏捷制度

      要找准适合自身的敏捷开发方式,主要是制定一个完善的效率高的设计、开发、测试、上线流程,制定固定的迭代周期,让用户更有期待;

3、需求收集

      这个任何方式下都需要有,需求一定要有交互稿,评审通过后,一定要确定功能需求列表、责任人、工作量、责任人等;

4、工具建设

      是指能够快速完成某项事情的辅助工具,比如开发环境的一键安装,各种底层的日志、监控等平台,发布、打包工具等;

5、系统架构

      略为超前架构设计:支持良好的扩容性和可维护性;组件化基础功能模块:代码耦合度低,模块间的依赖性小;插件化业务模块:降低营销活动与业务耦合度,自升级、自维护;客户端预埋逻辑;技术预研等等;

6、数据运营与灰度发布

      点击率分析、用户路径分析、渠道选择、渠道升级控制等等。

有幸拾得某位牛人的敏捷开发经验,再结合自己的理解,一起拿出来与大家分享一下:

1 、 重点明确,及时调整。

      通过分析需求的紧急性和重要性,做出优先级的判定,优先级从1排到10,没有重复;

      迭代中严格按照优先级顺序开发,即使最后时间不够,也能保证最需要的功能开发完成;

      每次迭代前重新调整需求的重要性,及时加入重要的业务需求和用户需求,将重要性不高的需求往后调整。

2、倾听用户的声音、相信用户的直觉。

      在迭代中充分关注线上版本用户的反馈,并且主动联系用户了解困扰,在当个迭代或下个迭代快速优化;通过对用户反馈的及时响应获得用户的认可和口碑。

      这里就提到一个名叫“AB test”的开发模式,一个问题有A、B两种解决方案,不知道哪个更符合用户的需求,那么就让用户去选择,根据用户的反馈去迅速调整。

      有兴趣的话,可以看看这个视频,是我在找资料时看到的,里面讲到了这个问题,即小米MIUI产品经理许斐演讲的“快速迭代的互联网开发模式 ”。

3、勇于创新、小步快跑。

      在迭代中勇于创新,快速实现创新想法,并在后续的迭代中不断优化。

      一直远离媒体视线的腾讯CEO马化腾,在“合作伙伴大会一周年”的活动上,也给合作伙伴和同行们“小步快跑,快速迭代”的建议,被赋予“一直在模仿,从未被超越”称号的腾讯开发团队,其实创新也是国内最多的。

4、持续不断地发现问题,解决问题。

      通过每天的版本发布来检验团队在每日立会上做出的承诺;

      测试和验证功能的开发程度;

      对于功能的实现第一时间给出反馈,并能快速调整,而不会像瀑布式等到开发末期才发现实现上的问题。

5、持续提升整个团队的产品能力。

      专门的团队面向一个产品领域;

      持续优化用户体验和产品流程;

      通过产品迭代的心跳保持产品团队的用户和市场敏感度;

      提升产品经理的产品感觉、提高技术团队的产品意识;

      团队伴随业务而成长,获得更高的成就感。

更多具体的实施和经验分享,可以参考“项目管理专栏”。

说了这么多,归结起来就是,产品通过不断的获取用户新需求,不断的更新迭代而愈加成熟。而快速迭代,则能提升团队的市场竞争力,从而快速占领市场。

看过一幅图片:快速迭代,越变越美。那么如何快速迭代呢?

3.如何快速迭代

其实这个问题已经在第二个问题中回答过了,这里再单拿出来说,是为了强调一下。

现在是互联网的时代,互联网产品的更新速度可谓是日新月异。互联网的开发模式也是主要围绕“快速迭代”的主题来开发产品的 在飞速发展的互联网行业里,产品是以用户为导向在随时演进的。因此,在推出一个产品之后要迅速收集用户需求进行产品的迭代——在演进的过程中注入用户需求的基因,完成快速的升级换代,裂变成长,才能让你的用户体验保持在最高水平。不要闭门造车以图一步到位,否则你的研发速度永远也赶不上需求的变化。

可能我们做的不是互联网的项目,但是如果是大项目,依旧推荐使用敏捷开发。分级需求,快速迭代产品。让用户能在短时间内用户用上你的产品,短时间内使用到新功能。

采用“短周期迭代法”,可以压缩项目开发实施周期,减少项目风险,简化管理,提高各个环节达成率,有效推进项目建设。

快速迭代,版本更新快,所以要考虑降低项目风险,确保正确的方向。

敏捷开发能够缩短项目的反馈周期,因其将项目分成了若干个迭代周期,每个迭代周期结束都能立即反馈。且通过不断的沟通,还能减少理解上的偏差,配合反馈,减少误解,从而降低修正错误的代价。且每个迭代周期的结束都能接受验证,从而能快速的适应变化,及时的适应新的需求,保证产品的正确性。

那么迭代周期设定为多少合适呢,“小步快跑、快速迭代”,当然系统大小也会影响到迭代周期,所以把迭代周期一般设置为1-6周为佳。

曾经跟QQ安全管家的一个开发人员聊过天,得知QQ安全管家是一星期一个beta版本,一月一个正式版。小米的MIUI更新周期,每天都有更新给荣誉开发组,每周都更新ROM包,提供给用户下载。百度每天都会有上百次更新升级上线,网页搜索的结果页每一天都有几十个等待测试上线的升级项目。可见快速迭代是多么许多公司都推荐的一种开发模式。

还有一点要注意,快速迭代,不是说一定要做好了,才能上线,半成品也能上线。

在没有上线之前,你怎么知道哪好那不好。所以半成品也是可以出门的,一定不要吝惜在家,丑媳妇才需要尽早见公婆。尽早的让用户去评判你的想法,你的设计是否可以赢得用户的喜爱。快速发出,紧盯用户反馈。百度完成了第一版的搜索引擎,也是让用户去做的选择。用百度CEO李彦宏(Robin)的话来说“你怎么知道如何把这个产品设计成最好的呢?只有让用户尽快去用它。既然大家对这版产品有信心,在基本的产品功能上我们有竞争优势,就应该抓住时机尽快将产品推向市场,真正完善它的人将是用户。他们会告诉你喜欢哪里不喜欢哪里,知道了他们的想法,我们就迅速改,改了一百次之后,肯定就是一个非常好的产品了。”

简单地分享了一下对敏捷开发,快速迭代的理解。这里再给大家一个连接,51CTO的《专题:初探敏捷开发》,供大家参阅。

时间: 2024-10-24 02:04:25

敏捷开发-快速迭代的相关文章

解析敏捷开发的特点

近期公司在着重推进项目的敏捷开发,虽然以前也接触过,但还是去参加了下敏捷开发的培训,对于产品经理来说,如果推行了敏捷开发,则产品经理的协调沟通作用会更加的凸显出来,毕竟前期没有文档,只有演示稿甚或是图纸的情况下,沟通是非常重要的,特别是确认所有的需求功能点,并给需求功能点的优先级排序,确定敏捷开发的迭代周期,这些都需要沟通去解决,例行的会议也会比较多,产品经理肯定都要参与其中.对互联网行业来说,敏捷开发能更快速的响应不断变化的需求,对产品经理来说,如果同时参与的项目多一点的话,那就更加的杯具,你

分享实施敏捷开发的技术方面的先决条件

本文根据作者黄文海的实际敏捷开发与项目管理经验分享了实施敏捷开发的技术方面的先决条件,希望为准备引入敏捷开发的团队提供方向上的指引. 迭代开发是所有敏捷开发方法的共同特征.迭代开发中的两个迭代之间往往涉及对同一个功能的变更.这种情况下,当前迭代测试时不仅要执行针对这一功能变更的修改和新增测试用例,还要执行那些不需要改动的用例,以保证两个版本间的兼容性.随着时间的推移,迭代过程中需要运行的兼容性测试用例会越来越多.此时,如果没有自动化测试工具支持,要在一个迭代内运行之前所有迭代的兼容性测试用例往往

Google+话题探讨分享:应用快速迭代(敏捷模式)和用户不升级

文章描述:当移动应用"敏捷迭代"遇到"用户不升级". 某个深夜在Google+参与一个话题的讨论,事后觉得这个话题有价值,就继续做思考整理.顺便把stream里的内容转贴在文末留以备份,方便沉淀,也可以让大家继续参与交流讨论. APP升级习惯调查 是这个话题讨论的源头,这篇日志是从移动应用快速迭代升级与用户忽视或者不升级应用之间带来的冲突,引发的一连串的思考和分析. 根据这个话题,我也做了一些延伸的思考. 在移动应用的研发中,应用快速迭代(敏捷模式)和用户不升级应用

敏捷开发学习分享

程序员都很懒,你懂的! 敏捷不是快,而是拥抱变化(不断反馈的一个过程).                                                        简单的说,敏捷开发是一种以人为核心.迭代.循序渐进的开发方法.在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征.换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态. 敏捷原则:主张简单,拥抱变化,可持续性,

利用Rational Team Concert在敏捷开发中进行持续集成

本文将介绍如何利用 Rational Team Concert(RTC)在敏捷开发过程中进行持续集成.详细说明了如 何在 RTC 中通过采取一系列的步骤和脚本开发,来保证持续集成过程的连续性和提高整个项目的效率. 同时还阐述了每一步可以利用的工具和最佳实践,从而使开发过程更加规范化,高效化. 概述 Rational Team Concert(RTC)是 Jazz 产品中最重要的一个,是一个可以任务分解集成,源代码版 本控制,进行自动构建和报告的工具.Jazz 做为 IBM 下一代的软件交付平台,

使用.NET进行高效率互联网敏捷开发的思考和探索

不知从什么时候开始,创业变得很廉价,谈什么都是互联网,动辄融资千万.这阵风好像也刮向了程序员中,有那么一大批开发者,数据结构不好好学习.数据库原理不扎实掌握,在github上发布几个项目,用nodejs创建一些服务,再用H5写出APP,就自以为迈入了高级程序员的队伍,能够运筹帷幄互联网项目,难道学习新技术.新理念就是快速成长吗,显然不完全是,在这浮躁的氛围中,各种粗制滥造的互联网网站.APP接踵而至,很多看似漂亮的APP,连简单的http接口安全都没有措施应对,很多美丽的响应式网站,目录结构随意

敏捷开发的几点建议

同步发表在:http://snowdream.github.io/blog/2016/04/07/agile-development-advices/ 移动互联网行业由于节奏快,产品迭代周期短,因此多采用敏捷开发进行快速迭代.下面我从Android客户端研发的角度,说说敏捷开发中的几点建议: 模块化 当项目开始变得很大时,需要按照主要功能进行模块化.同时对人员进行分组,每组负责一个主要模块.由于迭代周期短,任务重,可能在开发过程中,某个模块无法按照要求,在既定的时间内完成开发任务.这时,应该由产

快速迭代的开发方式中的QA实践方法

背景 尽管"小步快跑"的快速迭代开发方式早已成为互联网软件开发的主流指导思想,但大量开发团队在落地这一开发方式时最常遇到的问题就是"如何QA",因为,传统软件行业的QA方式(手动测试,回归测试等)无法适应每天多次上线的迭代节奏.这时,开发团队往往会面临这两种窘境: 要么是为了速度不顾质量,导致线上故障频发:要么是为了质量而固定发布窗口,导致业务不够敏捷. 那么,在快速迭代的开发方式下,究竟应该采用怎样的QA实践才既能控制住风险又能跟上节奏? 本文对小博无线技术团队在

敏捷开发时代:软件安全测试需更灵活

我们生活在一个软件定义的世界中.软件几乎接触到方方面面.任何努力保持竞争优势或市场先机的企业,都必须在某种程度上重新整合其软件.这会导致快速的开发方法,如敏捷开发和开发运维,促进持续的产品改进.但是,这些新的开发方法能够使测试最小化,反过来又可能破坏性能和安全性. 为保持竞争优势,企业必须提供高质量的应用体验.此外,安全是必须的而不是"有安全性也不错".因而,持续的测试方法已经日益重要,其动态性就像新的开发过程一样.幸运的是,企业越来越明白这种不断增长的需要,并且重新思考整个过程. 推