• 什么时候算时机成熟呢?...网易有道笔记负责人谈敏捷开发的实战经验:什么时候适合使用“敏捷开发”呢?我们的经验是需要两点:一、团队有三名或以上的研发工程师;二、团队内有一名合适的Scrum Master。

    什么时候算时机成熟呢?我们的经验是需要两点:一、团队有三名或以上的研发工程师;二、团队内有一名合适的Scrum Master。

    AD:WOT2015 互联网运维与开发者大会 热销抢票

    网易有道笔记负责人谈敏捷开发的实战经验:什么时候适合使用“敏捷开发”呢?我们的经验是需要两点:一、团队有三名或以上的研发工程师;二、团队内有一名合适的Scrum Master。
    网易有道笔记负责人谈敏捷开发的实战经验:什么时候适合使用“敏捷开发”呢?我们的经验是需要两点:一、团队有三名或以上的研发工程师;二、团队内有一名合适的Scrum Master。

    作者:蒋炜航,网易有道笔记负责人

    注:名词详细解释见文末

    有道云笔记团队成立于从2010年,从成立伊始我们就一直积极地在实践中尝试Scrum(敏捷开发的一种项目管理方法)的做法。到2012年底,3.0发布时,我们在5个主要平台(PC、iPhone、Android、iPad、Web)上总共发布了46个版本,累计了近千万激活用户。在这个过程中,我们逐渐摸索出一套适合以产品和技术创新为核心的中等规模(数十人)研发团队的Scrum实践经验。

    1、Scrum不是万能药,要在时机成熟时推行。

    什么时候算时机成熟呢?我们的经验是需要两点:一、团队有三名或以上的研发工程师;二、团队内有一名合适的Scrum Master。

    刚开始的时候,一个开发团队可能只有一名或者两名研发工程师。这时候并没有全面推行Scrum的必要,而可以借鉴Scrum中的一些做法。比如有道云笔记的Web团队最初就是这个情况。当Web团队只有一名研发工程师时,我们就尽可能地尊重他的工作方式。同时为了保证项目进度可控,我们引入了 Scrum的sprint机制——以sprint为开发周期,每个sprint进行一次Web产品演示。这不但能够让工程师有一个以sprint为期限的压力,还能够让其他同事即时地了解项目的进展,以便做出相应调整。当Web团队扩充为两名工程师时,我们又引入了结对编程、持续集成、相互代码审核等做法。直到Web团队的规模进一步扩张时,我们才开始考虑全面启用Scrum。

    当团队内无法找到合适的Scrum Master时,不要轻易推行敏捷。如果你的团队是由新人组成,或者即使有资深员工但是他并不了解或认同敏捷开发的话,那么你需要等待合适的Scrum Master出现。

    合适的Scrum Master需要具备几个特质:首先,他要认可敏捷开发这种方式;其次,他要熟悉业务,起到教练的作用,能带领团队走正确的流程;并且,当团队遇到问题时,他要有能力和担当引导团队做出决定,在团队成员遇到困难时,他要协助成员解决;最后,他要能识别重要和紧急的事情,而并不是事无巨细的反馈到产品负责人那里。

    敏捷开发虽然希望团队自我管理,但是这需要一个过程,开始的时候,一个合适的Scrum Master至关重要。有道云笔记的Web团队在成立一年多以后才开始推行Scrum,很大的一个原因是在培养合适的Scrum Master。依据我们的经验,最胜任Scrum Master的人选是技术主管。我们也曾尝试过让产品经理担任Scrum Master,但是由于产品经理本身往往担当产品负责人,兼任Scrum Master会影响他在产品机会和产品体验等方面的投入。

    2、限制Scrum团队的规模,建立Scrum团队之间的协作机制。

    随着业务的发展,团队会变大。这个时候不拆分团队的话,效率会变低。

    有道云笔记移动端团队就经历过这样一个过程。很长一段时间Android和iOS的研发工程师组成一个Scrum团队,有共同的产品负责人和 Scrum Master。但是随着移动端团队人数的增长,Scrum会议的效率却降低了。虽然Scrum会议只有不到半小时,但是当说一个平台的事情的时候,另一个平台的工程师会觉得无所事事。发现了这个情况后,我们把移动端团队按照平台拆分成了两个Scrum团队,以确保Scrum会议上说的是每一名参与者都关心的事情。总的来说,参加Scrum会议的所有人,包括产品、开发和测试,不应该超过9个人。

    按照平台拆分团队,限制了Scrum团队的规模,提高了Scrum的效率。与此同时,多个Scrum团队之间必须进行有效的协作。

    在初期,我们鼓励研发工程师通过面对面地商量,快速推进来处理平台之间协作的需求。但是随着业务的发展,这样的协作越来越多,也越来越复杂,这样面对面的讨论往往会疏忽细节需求。比如说,有道云笔记3.0版本中的待办事项功能,就需要PC、Web、Android、iPhone以及Server 等多个Scrum团队一起,对这个功能进行产品定义和确定技术方案。这样复杂的协同需求需要额外的机制来保证。这个机制就是Scrum Master的定期会议。在这个会议上,我们会讨论各个Scrum团队相互依赖的项目,安排好各Scrum团队的开发顺序。对某一件具体的事情,其中的一位Scrum Master会被指定为具体负责人来驱动跨Scrum团队的协作。同样,只有当Scrum团队间的协作任务比较复杂的时候才需要引入这个机制。

    3、产品经理和研发工程师要拥抱Scrum带来的变化。

    在引入Scrum之前,一般的项目管理方式是版本式(瀑布式)的,产品经理决定下一个版本做什么,预期发布的时间,然后由产品负责人或者技术负责人来兼做项目经理。这个时候遇到的问题是项目往往会延期,但是产品经理会有一种对项目把控的感觉。

    引入敏捷开发之后,这个事情变了,发布是跟着sprint走的。基于持续交付的原则,一次发布包含一个或者多个sprint的内容,而这些内容是由团队整体决定的,而不是产品经理个人决定。产品经理只是定义了功能需求的优先级,这些功能需求与代码重构、开发工具、以及市场运营等的推广支持等需求一起排期,最后由整个团队决定一个sprint做哪些东西。

    从表面上看起来,产品经理对产品的把控小了,为此,团队一位资深产品经理有过质疑。最后,我们还是说服了他接受敏捷。事实上,接受Scrum并不困难。这样,产品经理可以把重心放在对产品需求的把握上,而不必整天问这个咋样了那个咋样了。而且,团队的开发效率,功能点完成的速度并没有因此而降低。

    研发工程师同样要拥抱Scrum,调整自己的工作方式。Scrum不鼓励过度设计,而采用涌现式设计。这意味着开始往往不会把技术架构做得大而全,而是鼓励快速出成果。当然这并不是说程序架构能够设计得很糟糕,而是说不要花太多的精力在未知的事情上,小步快跑。为此,代码重构是必须的(编者注:在不改变软件现有功能的基础上,通过调整程序代码改善软件)。我们并不建议整个sprint都去做重构,更建议持续重构,把代码调整也分解成任务,每个sprint做一些。在一些大版本发布之后,重构任务的比例可以适当高一些。

    4、量化衡量团队的执行力的指标:完成度、评估准确度、计划合理度。

    当Scrum团队不大的时候,可以依靠主观感觉来评估执行力。有道云笔记团队在初创的一年内,对sprint的完成情况是没有量化的评估的。

    Scrum教材对执行力的量化评估用的是故事点和速率。由于团队成员实际上都是有道云笔记的用户,能够直观理解产品经理提出的需求。因此我们省去了用户故事,由产品经理提产品需求,而团队把需求分解成任务。经过一段时间的探索,我们定义了几个量化指标,其中最重要的是完成度,我们用这个指标来衡量团队的执行力:

    完成度=1-计划内未完成任务的剩余时间/计划内任务评估时间

    (完成度的数值在80~90%之间比较好。过高的完成度说明sprint计划过于保守。)

    有些管理者会怀疑完成度的准确性:第一是,团队是否会把计划内任务的评估时间评估得过长,使得完成度看起来高?事实上根据我们的经验,团队对计划内任务的评估往往是偏乐观的;第二是,计划内未完成任务的剩余时间是如何出来的?这个是由团队在sprint末尾评估出来的,因为这时技术设计多已完成,这个时间是比较准确的。我们也曾尝试过燃尽图,发现并不如完成度来得直观。

    另外,我们还定义了两个指标来作为辅助参考。一个是评估准确度(计划内任务评估时间/实际使用时间),一个是计划合理度(计划内任务使用时间/计划外任务使用时间)。这两个指标的历史数值可以让我们更加了解团队执行的情况。

    当Scrum团队不大的时候,可以依靠主观感觉来评估执行力。团队扩大后,详细的数值评估必不可少。

    当Scrum团队不大的时候,可以依靠主观感觉来评估执行力。团队扩大后,详细的数值评估必不可少。

    5、高效的sprint计划会的要素:预先梳理需求、合适的任务粒度、随机认领任务、运营调研任务、任务评估。

    Scrum开发中,最重要的会议是sprint计划会。但是在这之前,产品经理和研发工程师可以预先梳理一下需求,以保证sprint计划会可以更加高效和准确。我们尝试过多种方式来预先梳理需求:发邮件、产品与研发面对面沟通、开需求梳理会。哪种方式更好,目前还没有定论。

    Sprint计划会主要讨论几件事情:将需求分解成任务、评估每个任务的工作量、分配任务。每件事情都有各自的技巧。

    首先,任务分解的粒度应该如何?Scrum开发一般认为任务分解得越细越好,但是在实际操作中我们发现如果分得太细的话是有问题的。比如说,认领任务、记录每个任务的工时和完成情况,都会带来时间消耗。我们经过较长时间的实践,发现0.5至3天一个任务是一个合适的粒度范围。

    如何评估工作量和分配任务这两个事情是关联的,不同的人做同一个任务,往往时间会相差很大。所以这时候有一个艰难的选择,是让大家做自己熟悉擅长的事情,还是随机认领任务以达到团队人员对所有模块都很熟悉的状态。一个短期见效,另一个长期可发展。

    有道云笔记PC平台的Scrum团队经历了一个从前者转向后者的过程。在开始很长一段时期里,Scrum团队把自己PC客户端按模块进行拆分,每个模块由一位研发工程师负责,工作量的评估也以这个人判断为准。这个办法帮助团队快速开发了PC的第一个版本和后续几个小版本。但是慢慢的,这种做法的瓶颈就出现了。之前的模块划分随着项目发展变得有些过时,有的模块出现了瓶颈。在最近的几个sprint里,PC平台的Scrum团队已经开始随机认领任务的方式。

    此外,在实际研发工程中,往往会有一些由于团队没有相关的经验而比较不确定的事情。对于这样的事情,我们会先安排一个调研任务,并且将这个任务尽量安排在sprint的早期,并且凭借经验会在计划会上留出后续实际开发的时间。如果调研任务确定这个事情的复杂度可控,我们会在后续的sprint会议上根据调研成果分解出详细的任务,另一方面,如果这个事情的复杂度太大,那么我们会把完不成的内容放到下个sprint。

    任务评估的办法,或者用纸笔写下后同时公布或者用估算扑克,两者本质上没有区别。当有较大分歧时经过讨论后再次评估,次数不宜过多,一般1-2 次就好,不超过3次。如果讨论不清楚,Scrum Master不妨先定一个时间,让会议进行下去。后面实际开发过程中会越来越清楚。敏捷开发本来就是渐进的过程。

    6、流水化安排开发环节与测试环节。

    如何安排测试与开发,是从项目一开始我们就反复思考和尝试的问题。经过一段时间的实践,我们目前采用流水化的方式来安排开发环节与测试环节。具体来说,就是在开发sprint结束后再开始测试这个sprint的产出版本;而在开发的sprint内,开发团队解决上一个sprint的产出版本测试出的bug。虽然这意味着开发团队要在测试环节还未开始之时(Sprint计划会上),就要估计并预留出上个sprint产出版本的bug修改时间,但在实际操作中,开发团队能够通过历史数据做出比较准确的估计。因此这种方式的效果是良好的。

    7、版本发布基本按照sprint周期。

    我们通常在一个或者多个sprint之后(在测试环节之后)发布版本。具体选取几个sprint往往会参考一些市场情况的考虑,比如说将一个做了较多重构的sprint与一个做了较多新功能开发的sprint打包作为一个新版本发布出来。我们基本上不会为某个大版本打乱我们的sprint周期。

    8、Scrum需要配备合适的工程实践,例如单元测试、代码审核、持续集成、项目管理工具。

    我们要求研发工程师必须要写单元测试和相互审核代码。测试驱动开发和结对编程目前还有许多争议,我们也不建议贸然尝试。在实践中,我们采用了简化版本,对可以写单元测试的模块都要求测试覆盖,并且通过测试覆盖率来量化单元测试的力度。此外我们将研发工程师两两结对,相互检查对方的代码,只有经过检查的代码才能最终提交。

    此外,我们对代码进行了持续集成。每天凌晨持续集成系统会自动下载前一天的代码,进行编译和部署。Web端会直接部署到Web测试服务器,而客户端(PC、iPhone、iPad、Android)会自动拷贝到一个内部服务器上。测试人员或者感兴趣的人每一天一上班就可以用到最新的版本。

    关于Scrum的任务管理,我们采用过不同的项目管理工具,包括白板、开源软件等等。总的来说,工具只是简化了一些统计,Scrum最重要的还是敏捷开发本身的思想。

    编者注:名词详细解释(感谢李玮对本文编辑的贡献)

    敏捷开发:相对于传统的版本式(瀑布式)开发模式。以往的开发模式中,一次会做一个大版本,在这个版本的开发过程中定义需要开发哪些功能,需要多少资源,需要多长周期,最终一次性交付这样一个版本。敏捷开发则是将一个很大的版本尽量细分为小的功能、模块或阶段,每次做其中一部分,做完以后立即发布一个小版本给用户。

    Scrum:敏捷开发的一种项目管理方法,通常表示敏捷开发所承担的一个阶段性任务,做完这个任务就可以发布小版本。在做这个任务的过程中团队称作Scrum团队,负责人是Scrum Master。这种Scrum团队和以往的团队相比,要求每一个团队成员掌握更全面的知识,而不是以往软件开发不懂测试,软件测试不懂开发。每个人都需要有独立解决问题的能力。对Scrum Master来说,需要了解整个Scrum的全貌,并具备整个过程中各个领域的知识,因此通常是技术牛人,而不是项目管理者去做Scrum Master。

    Sprint:表示Scrum中的一个阶段,是对Scrum继续的细分。比如分给某个人开发50行代码的一个任务,他的第一个sprint可以是阅读需求文档,第二个是写代码,第三个是debug。好的敏捷开发中每个Sprint的任务量需要有较好的定义,不能太少,也不能让人做不完,因为每个Sprint的时间是固定的。

    原文链接:http://tech.sina.com.cn/i/csj/2013-01-22/18528003613.shtml

    参考:http://developer.51cto.com/art/201301/378700.html

    展开全文
  • 传统的开发模式和敏捷开发模式的对比? 敏捷开发scrum的实施。 什么是敏捷开发 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 在敏捷开发中,软件项目在构建初期被...

    简介

    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢?

    目录

    1. 什么是敏捷开发?
    2. 传统的开发模式和敏捷开发模式的对比?
    3. 敏捷开发scrum的实施。

    什么是敏捷开发

    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

    在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

    传统的开发模式和敏捷开发模式的对比

    瀑布模型:
    这里写图片描述
    优点:
    1. 为项目提供了按阶段划分的检查点。
    2. 当前一阶段完成后,您只需要去关注后续阶段.
    3. 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

    缺点:
    1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
    2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
    3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
    4. 瀑布模型的突出缺点是不适应用户需求的变化。

    敏捷模型:
    这里写图片描述
    优点:

    1. 敏捷开发的高适应性,以人为本的特性。
    2. 更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。

    缺点:

    1. 由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难。

    敏捷开发scrum的实施

    Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,相当于大家像打橄榄球一样迅速、富有战斗激情。而Scrum就是这样的一个开发流程。

    Scrum开发流程中的三大角色
    – 产品负责人(Product Owner)

    主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

    – 流程管理员(Scrum Master)

    主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

    –开发团队(Scrum Team)

    主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

    scrum开发流程图

    这里写图片描述

    1、我们首先需要确定一个Product Backlog(产品需求列表),这个是由PO负责的(如图(一));

    2、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

    3、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

    4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)(如图(二)和如图(三));

    5、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本。

    6、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品。

    7、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

    如图(一):
    这里写图片描述

    如图(二):
    这里写图片描述

    如图(三):
    这里写图片描述

    如图(四):
    这里写图片描述

    敏捷开发管理工具:teambition
    teambition

    参考

    敏捷开发之Scrum扫盲篇
    百度百科
    敏捷开发 模型讲解

    展开全文
  • 敏捷开发 vs 传统模式

    2015-05-28 22:41:00
    这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 大家都知道,创业公司刚开始需要研发出...

    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。

    大家都知道,创业公司刚开始需要研发出一款产品并且能够使公司赚钱的产品,不过大部分创业公司没有那么容易一下就能做出来,很多公司还没有成功的产品资金链就断掉了,公司也死掉了。我们公司是这样一个状况,有一条产品线可以维持公司开支并仅仅刚够盈余,要扩大高速发展还不够,一直维持就没有创业的意义。另一条线是做技术创新为未来能够开发一款人气爆棚的产品摸索着,但是又不能饿着肚子去开发。我们是如何结合自身的特点实施敏捷开发的呢?一个难题,很大的难题!

    我们技术团队人员是这样的配置:1名技术总监、2名资深开发工程师、1名高级开发工程师、2名潜力开发工程师、1名前端开发、1名测试。技术总监需要处理很多团队管理、客户管理的工作,能够参与项目的时间最多每天二分之一。2名资深开发需要负责给其他工程师做导师,参与新项目开发时间大概有80%。高级工程师要预留项目学习时间,参与项目的时间大概有90%。潜力开发工程师需要有一些时间学习技术和项目,但是基本可以做到70%的时间投入项目。前端开发和测试哪里有需要就在哪里革命,属于机动部队。

    现在总共有六个老项目在维护,两个新项目需要开发。六个项目的维护总共需要每周4人天时间(人天指需要花1个人4天的时间完成一个事情)。其中一个新项目“项目1”大概估计120人天的开发时间,需要1个月之内开发完成。“项目2”大概估计要40人天的开发时间,需要2周开发完成。而现在的人力按照能够投入的时间算一下,总共资源为 (1 * 1/2 + 2 * 8/10+1 * 9/10+2 * 7/10) 30天 = 132 人天,6个老项目每周需要4人天,一个月4周,需要 4 * 4 = 16人天。项目能够投入的资源有 132 – 16 = 116人天,而总共需要120 + 40 = 160天,足足少了44人天,这看起来是一个不可完成的任务。

    不过到最后,我们还是使用敏捷开发完成了这两个项目,也没有影响老项目的维护。我们是怎么操作的?最开始我们两个开发,这个时候只要两个人就能够很好的合作把产品开发出来,不需要什么模式。随着人员的扩充,团队间如何协作按时按质按量完成任务就需要好好思考下了。

    尝试一,传统软件开发模式。整个过程为 需求分析、系统设计、任务分解计划安排、开发设计、编码、测试、交付、验收、维护。这个模式也是大家最常使用的模式,不过套用在我们公司时我们是这么操作的。

    传统开发过程
    传统开发过程

    由于公司创业,老板有一个想法,但并不能很好的描述需求,所以需求分析的任务落在技术总监身上。系统设计和任务分解刚开始是技术总监完成,后面资深开发工程师可以承担一部分。开发设计可以让各个开发工程师完成,资深工程师进行把关,再到测试人员测试,最后再交付用户验收、技术维护。看起来很好的模式,开发了几个产品最终有的延时有的产品离用户的期望差距甚远,参与项目团队的人信心受挫。

    为什么会失败呢?后来思考了这些问题:

    1、技术总监不是产品经理,不能够承担产品设计的责任。老板是信任技术总监能做好产品,就交给他做。但这里搞混了一个概念,产品经理和项目经理,技术总监应该起到项目经理和架构师的作用。项目经理管控项目进度和计划、架构师把握整体技术问题。而技术总监接到这个任务又不能不做好,责任所在。说到底,就是机制没有把产品设计和项目经理区分开,不等于技术实现者就是产品设计者。更多的应该让老板或者其他业务人员承担产品设计的工作。

    2、需求不稳定,变化后改动代价大。由于创业,需求为了适应市场会经常调整,但是一但调整,很多开发计划就会受到相应的调整。如果部分功能已经正在开发,调整需求后很多工作要重新开始,严重影响了技术同事积极性。业务不调整需求是不可能的,他们是为了满足用户的要求,用户满意了才能给企业带来价值。不过如果调整,代价太大,很多代码要重写,大家就会责怪技术总监或者项目负责人没有把握好需求。

    3、团队经常加班,但战斗力不强。 核心团队疲于应对需求、技术开发、老系统维护,没时间指导新同事技术学习,而新同事技能暂时还没有发挥出来干活效率低,任务经常延期,没有成就感。核心团队事情很多,没有时间整理项目文档,新员工没有文档上手慢。大家每天很多事情,需要加班才能完成,比较疲惫。每个人除了工作还有很多事情需要做,比如回家看看电视、陪陪家人、看看书学习一下等。如果让一个员工一天二十四小时都是工作,他能同意,他家人也不一定同意。让大家愉悦的开发,比疲惫的上班效率要高很多。

    4、交付软件质量差,离用户期望差距大。创业时大家的想法都是好的,大干一番,做一个所有人都爱使用的产品。现实是残酷的,大家辛辛苦苦做出来的东西,老板不满意、用户不埋单,付出的努力没有人认可。交付的软件没时间自测试,或者自测试不充分,交给测试又是一大堆问题。有些公司还没有测试,直接出去给用户,相当危险。这样交出去的公司不仅仅影响了用户的使用,还影响了整个公司的口碑。

    不是说传统软件开发模式不好,只是不太适合我们这种创业公司。开始尝试其他模式,如果没有一个很好的体制就不能把大家的最大生产力发挥出来。

    尝试二,敏捷开发模式。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法强调以人为本,专注于交付对客户有价值的软件。在高度协作的开环境中,使用迭代式的方式进行增量开发,经常使用反馈进行思考、反省和总结,不停的进行自我调整和完善。

    敏捷开发的主旨

    一:个体及交互比流程与工具更具价值

    二:可用的软件比冗长的文档更有价值

    三:与客户的协作比合同谈判更有价值

    四:对变化的响应比遵循计划更有价值

    而我们之前的问题,交付软件客户不满意、延期、需求更改代价大貌似都可以解决。这么好的模式赶紧要试试,先看一张敏捷开发的流程图。

    创业公司敏捷开发敏捷流程化
    创业公司敏捷开发敏捷流程化

    敏捷开发简单流程

    1、产品负责人将整个产品设计成产品backlog。产品backlog就是一个个需求列表。(backlog可以理解为需求或者要做的事情)
    2、召开产品backlog计划会议,预估每个backlog的时间,确定哪些backlog是需要在第一个sprint中完成的,即sprint的backlog。(sprint可以理解为一个团队一起开发的一个任务集合)
    3、把sprint的backlog写在纸条上贴在任务墙,让大家认领分配。(任务墙就是把 未完成、正在做、已完成 的工作状态贴到一个墙上,这样大家都可以看得到任务的状态 )
    4、举行每日站立会议,让大家在每日会议上总结昨天做的事情、遇到什么困难,今天开展什么任务。(每日站立会议,是在每天早上定时和大家在任务墙前站立讨论,时间控制在15分钟内)
    5、绘制燃尽图,保证任务的概况能够清晰看到。(燃尽图把当前的任务总数和日期一起绘制,每天记录一下,可以看到每天还剩多少个任务,直到任务数为0 ,这个sprint就完成了)
    6、sprint评审会议是在sprint完成时举行,要向客户演示自己完成的软件产品 。
    7、最后是sprint总结会议,以轮流发言方式进行,每个人都要发言,总结上一次sprint中遇到的问题、改进和大家分享讨论。

    我们怎么结合敏捷开发解决现有项目的问题,要记得任何措施都是为了保证按时按质按量把软件交付给用户,不要为了敏捷而教条实施敏捷,公司不能产生商业价值,任何先进的理念或者技术都是无意义的。我们做了这些措施:

    1、推广敏捷开发理念。不管是大公司还是小公司强制推行一项制度效果一般都不怎么好。要能推行下去的任何东西一定要大家接受的,才能被认可。

    • 首先培养测试小妹学习敏捷开发,后续让她承担部分产品责任人和敏捷指导者的角色,原因有:
      a、测试要验收功能,必须理解业务需求。
      b、测试也是QA质量体系的一块,学习好了对于软件质量有个更深的认识。
      c、团队大部分是男生,女生推广更有亲和力一些。
    • 召集所有技术团队开会准备推广。开始和测试小妹好好讨论下,怎么给大家说更有效,更容易接受。她要讲解一定要自己非常清楚敏捷开发,并且准备充分知识点。开会时先指出我们现在问题,让大家看看有什么想法解决问题吗?现在我们做的产品,客户不认可、老板不满意、自己很累没有成就感,有什么办法解决。在大家讨论后,抛出敏捷开发的优势,一般情况下大家都会认可的。大家可能会问到如何执行、落地,可以尝试找一个项目试点,如果实施成功就可以让大家全面推广,不成功也只影响了部分项目。

    2、搭建敏捷开发环境。大家要实施敏捷开发,需要比较好的基础条件保证敏捷开发顺利进行。主要几个关键的软件:nexus 搭建仓库依赖中心、maven 管理工程的依赖、jenkins 持续集成和自动编译发布、svn 集中代码管理、jira 记录需求和状态。具体参考《敏捷开发环境搭建》

    3、敏捷项目实施。整个公司建立以业务目标为导向的氛围。就以“项目1”来说,目的是完成这个项目,需要进行这几步:

    • 先根据各自的能力和意向聚集一批完成这个目标的勇士,不管技术和非技术。如果聚集的人不够,技术总监可以根据总体项目的投入机动调整资源以支持,不过条件允许的话还是根据大家意愿来聚集。最终“项目1”召集了一个技术总监、一个资深开发、两个潜力开发、一个前端、一个测试,除去大家做其他事情的时间,总共可以算作4个人。
    • 充分调动客户(老板和业务同事)参与进项目,他们的参与直接决定了项目成功与否。结合之前的经验,如果他们参与不够,最终做出来的东西就不是他们要的,或者离他们要的差距很大。他们刚开始加入的时候,很迷茫有时会表现的比较抗拒,这个时候一定要耐心坚持让大家把第一个sprint开发成功,使大家尝到甜头。让他们全程参与项目也是表示了我们拥抱变化,如果有需求变化,就添加任务到任务墙,大家可以对所有任务的时间有个全面了解,如果超过sprint结束时间就需要业务决策哪些功能不在这个sprint周期加入。
    • 技术总监安排和客户沟通,客户这里指老板和业务。测试小妹负责和客户沟通记录,技术总监辅助。多次沟通后,尝试让测试把需求原型用最简单的工具绘制出来,技术总监审核通过后和客户沟通确认,反复迭代,直到整个需求大家没有异议。很多公司这种需求是有一个专门产品负责人来执行,但按照我们目前的人力是没办法做到的。这里没有让技术总监做主要是为了避免之前出现的问题,过度技术设计产品。
    • 产品设计出来后,召集项目成员分解任务,确定每个任务的时间,可以使用敏捷扑克牌来估计。任务分解尽量控制在 1-2天的粒度,这样大家1-2天就可以做出一个能测试的原型,尽早可以集成测试发现问题。一个sprint的任务集合尽量控制在1-2周,不能太长,也不能太短。太长会出现疲劳,太短的sprint会让大家觉得工作太多,做完一个又一个。“项目1”估算结果为120人天,总共投入4个人,需要30天4周时间,我们切成了4个sprint,差不多1个月时间完成,满足业务的时间要求。
    • 分阶段实施sprint,绘制任务墙,划分未开始、已计划、进行中、完成、燃尽图。把要做的sprint任务上墙,贴到未开始的地方。

    创业公司敏捷开发任务墙
    创业公司敏捷开发任务墙

    • 每日站立会议大家认领任务。包括业务任务、开发设计、开发编码、前端设计开发、测试等都是一个个任务,统一管理起来。强调的是一个团体,如果有同事请假,其他同事可以顶上完成任务。站立会议总结昨天的任务是否有问题,对于当前的任务有什么建议,尽量控制在15分钟内,有效会议。这里不会像以前业务或者项目经理追着大家屁股要结果,而是团队驱动,每天大家做的事情都反映在墙上,谁出现了什么状况,大家都会帮他想办法,保证整个项目能够成功。每一个任务完成,由项目执行者把任务从进行中贴到完成区域。再从未分配区域认领新任务贴到进行中的区域。
    • 软件开发过程。认领任务后,怎么保证大家开发有质量的代码?团队有资深点的工程师,不需要太多指导,直接可以参与项目的开发。而学习型工程师,需要指导帮助才能一步步做用例、系统分析。技术总监不建议认领太多开发任务,他负责开发团队的概要设计审核,没有审核通过的设计不能开发,并指导大家分析和设计系统。大家都知道,系统思路有了,剩下就是技术实现的过程,只要技能掌握熟练实现基本难度不大。大家可能会问,敏捷开发不是强调软件开发的产品是软件,而不是文档吗?我们这里也不是像传统开发软件一样为了文档而文档,只是让大家把自己的设计思路写下来,只有经过自己仔细设计后才能把思路清晰的写下来。大家写的时候也不需要长篇大论,这样的文档是不欢迎的,受欢迎的文档只需写出用例分析,表设计,复杂的逻辑需要画出流程序列图。
    • 结对编程。之前这个编程模式被无数人调侃过,其实也不可能让每一个项目全程都是两个人结对编程。这个不现实也浪费资源。我们的结对是在大家开发一个难点模块时,会给结对的人增加一项任务去配合其他开发一起完成这个任务。其实我们在开发时,很多时候都会结对,比如指导新同事、讨论设计模块,而之前这些都没有算在我们的开发工作量里。

    创业公司敏捷开发结对编程
    创业公司敏捷开发结对编程

    • 项目演示和总结会议。在项目结束后,让所有参与项目的成员都参加,一起演示给客户展示,并解答客户的问题,充分让大家感受到收获的果实。总结会议主要对于这个sprint中大家遇到的问题和经验分享,并为下一个sprint做准备。

    经过敏捷实施后,我们的生产力提高了很多,员工的积极性提高了,业务的参与使整体需求把控也很好,大家沟通多了,30天的任务提前了5天完成。我们多出来的时间,让大家每周有一天或者半天研究自己感兴趣的领域,但是这些研究最终必须体现出成果。比如后台开发想研究一个新技术,最后做完需要写个ppt 给大家分享下。既能让大家做自己想做的事情,也给大家创造了一个互相学习的氛围。

    ps:所有的模式都不应该是教条的模式,先进的模式并不是好的模式,适合自己的才是最好的。套用一句俗话:不管黑猫白猫抓得住耗子的才是好猫。

    另曝光一下项目1参与成员:

    项目1敏捷团队 
    项目1敏捷团队
    展开全文
  • 敏捷开发实战经验

    2018-05-30 18:22:35
    以下分享产品项目里的九个敏捷开发实战经验。 敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。 在《Scrum:兼顾计划与灵活的敏捷开发...
         敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的,此外还需要各个业务部门对敏捷的理解和支持,形成合力。以下分享产品项目里的九个敏捷开发实战经验。
      敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。
      在《Scrum:兼顾计划与灵活的敏捷开发》一文中,作者最后也提到过,借鉴一种新的模式的时候,最好能够批判性的吸收其精华的部分,不能全部照搬,照搬了反而会出问题。
      其实敏捷对产品经理的要求是很高的,需要安排至少两个迭代的任务,两个迭代的规划。
      对程序员的要求也很高,当所有的任务都拆散了之后,最终做出来的东西要形成一个产品,技术人员的整体意识要比较强,且一开始就得熟知产品的整个规划,否则到最后就会出现所有任务都已完结,合并出来的最终产物却是什么都不是。
      并且敏捷开发不仅仅是IT部门的事情,还需要各个业务部门对敏捷的理解和支持,形成合力,从而提升开发效率和业务满意度。
      运行一段时间的敏捷之后,发现最容易接受敏捷这种方式的是开发团队,不管是瀑布式还是敏捷,只是做工作的形式不一样了,进度更容易把握了,更能适应需求的变化了,实质其实并没有变化。
      对测试团队来讲,测试资源调配会更加的紧张,敏捷要求做完一条侧一条,与原先的整体项目排期完全不一样;对产品经理来说,敏捷能让自身更好的掌握整个产品的进度。
      但需求分析与产品设计阶段的敏捷拆分还是较为头疼的,究竟要不要写文档了,是不是有什么做什么,还是说要规划完整体设计之后才进行拆分?疑问很多,搜集了部分资料,结合敏捷实践的经验,分享如下:
      一、敏捷开发最少需要维护哪些文档?
      软件或者系统产品终归是人来维护的,业务知识和技能的传递就成为产品可持续发展的一个重要因素,这就需要有知识性的沉淀,需要有文档的产出。
      实际情况是大多数人都不喜欢编写文档、也不太喜欢研读文档,因此太多的文档只会消耗团队有限的时间,并不能带来多大的好处;敏捷开发照样重视文档的作用,也重视文档的维护。
      但文档宜少且精炼,一般情况下建议维护三份文档:
      《产品需求规格说明书》
      也即PRD:定义产品应该具有的功能、边界描述等,它作为产品团队之间共同的讨论基础,并在设计和开发过程中不断的更新维护,并记录所有的需求变更;
      《系统设计说明书》
      开发人员编写的技术设计,包含数据库E-R图,架构设计等:说明产品如何实现,内部之间是什么关系;
      《测试用例和测试报告》
      由测试人员编写:记录所有功能点的测试计划、过程和测试结果;
      二、敏捷开发是否需要系统设计?
      前面也提到过,敏捷开发对开发人员来讲实质差异不大,只是以小周期代替大周期。
      小周期包括:需求、设计、开发、测试、发布,这个过程中的设计环节是指要做产品设计和系统设计;由于做完整的设计需要有相对完整的资料和比较长的时间,与小周期是相对立的。
      因此敏捷开发不主张高度细化和完整的设计,提倡做出一个大粒度的框架性设计,一般指架构设计或者系统设计,避免在以后的重构中发生架构级别的变化,然后在逐步实现的过程中逐渐深入展开、细化。
      传统的一些设计方法比如结构化设计、快速原型法都是可以融入敏捷开发过程中加以使用的。
      三、敏捷开发是否需要项目计划?
      敏捷开发只是把整体拆分成许多个体,产品的开发实现过程对产品的功能完整性、稳定性、即时性等都有较高的要求。
      它是一种有组织有目标的行为,往往我们都将其作为一个项目来管理,这就是讨论为什么有产品经理的同时还要有项目经理,为什么要求产品经理要有项目管理的能力,因此它需要项目计划。
      但这个计划是一个短程计划,根据未实现的功能情况、前一个版本的反馈和组织目标制定开发计划;唯有这样才能不断的融入新的需求变更;
      四、敏捷开发的迭代周期大概多长?
      敏捷开发的迭代周期没有硬性的规定,结合项目里程碑、目标、功能实现情况、产品稳定性综合决定,如果产品用户活跃、功能实现难度小、维护复杂度低,建议以周为周期。
    产品项目里的九个敏捷开发实战经验
      对于规模比较大、维护复杂度高的产品,考虑以2周-6周为周期发布较为合适;频繁的发布会降低用户的期望并提高用户成本,给用户心理上带来额外的负担:他会认为产品质量低,质量控制不严谨等;
      五、敏捷开发为何提倡小版本?小版本有哪些优势?
      小版本的目的就是分解复杂度、降低风险,改善团队士气等;小版本有众多优势:
      1、总体风险比较少:小版本变化小,总是在上一个版本基础上局部调整和增加,技术复杂度低;由于规划的功能较少,工作量也易于估算,所以其总体风险比较少,常常能如期发布;
      2、需求的接纳能力强:由于小版本快速实现并发布测试,然后就进入下一个版本的规划实现周期,这样新需求一旦提出就能快速进入开发视野,就能尽快实现;
      3、测试和开发高效协作:开发和测试可以并行工作,当开发实现第一个版本时,测试设计测试方案和用例;发布第一个版本后,开发就进入下一个版本轮次,测试就应用测试方案测试刚才发布的版本,提交Bug;开发在下一个版本结束时修正所有上一轮发现的Bug,然后发布新版本,如此循环往复,开发和测试实现高效协作;
      六、敏捷开发与重构的关系如何?
      敏捷开发以重构为基础,时时刻刻处于重构过程中;
      七、敏捷开发为何强调团队人员的参与、用户的参与?
      敏捷强调团队成员的高度参与就是要统一认识,把团队的目标变成每个人的工作目标,使之为每个团队成员的认同,形成高度的凝聚力,以达到群策群力、高效协作的效果。
      由于没有高度细化的文档,成员之间交换信息的唯一渠道就是面对面沟通,良好的团队氛围和协作关系促进这种沟通,并使消息有效传达。
    产品项目里的九个敏捷开发实战经验
      用户由于缺乏专业训练,无法清晰、准确的表达其意图,导致需求的歧义和模糊;用户的参与使模糊、边界不确定的需求在互动的过程中得到确认和完善;在用户参与过程中,我们常常可以听到这样的话:
      “是的,就是这样的”
      “这正是我想要的……”
      “这里需要修改一下……”
      “我的想法是这样的……”
      这个过程中,用户承担了一部分测试人员的角色。我们努力做的事情就是实现用户需要的东西,并最终让用户喜欢它,唯有用户喜欢它才能用好它,那么我们怎能不认真听取用户的意见呢?一句话总结就是:用户参与帮助我们做正确的事情!
      八、怎么才能评估团队是否已经敏捷了?
      由于敏捷开发没有标准的可供参考的实践过程,所以很难通过某个过程而断定其开发过程敏捷了,那么如何来评估团队是敏捷的呢?一般采用的办法是根据团队呈现出来的氛围、项目运作状态、团队成员的感性认识等方面来评估团队和其开发过程是否敏捷,常见评估项目团队是否已经敏捷的方法如下:
      • 团队有共同的愿景,并且对这个愿景充满信心;
      • 团队有明确的阶段目标并且为每个成员所知晓;
      • 团队知晓当前计划:做什么、何时完成、预期效果等;
      • 团队任务是低耦合的,并且紧密协作;
      发布过程是轻松愉快的,构建版本并不断测试是常态行为之一。
      九、敏捷开发能缩短项目时间并提高质量吗?
      从我的实践经验来看是可以的,但目前无法提供量化的数据做参考,只能从几个方面评估和推断:
      • 用户的参与帮助团队把功能一次性完成并做正确,缩减了返工的时间;
      • 不断的重构和测试发布能把问题发现在早期,整体质量显著提高;
      • 过程目标导向,使团队高度集中于项目目标,提高了生产力;
      • 不断的发布对团队是种正向激励,荣誉感和成功欲使团队保持持续的激情;
      以上是一些敏捷开发过程当中的疑问,其实还有很多,目前我这边还只是主推让开发和测试团队敏捷,PD团队还在摸索当中。下次我会分享一下如何在需求这个层面用敏捷的方式来设计,去产出PRD文档。敏捷设计、敏捷开发、敏捷测试连在一起,这样才能最大限度的发挥敏捷的效用
    展开全文
  • 敏捷开发模式,实质是一种以人为本的开发理念,重视团队沟通,重视客户反馈,重视产品迭代。 根据Agile的思想,我们主要有Scrum和XP两种开发实践,XP中又以TDD较为流行。 Scrum 项目经理从客户(产品经理)获取...

    “你有了解哪些开发模式?” “你了解的这几种模式有哪些不同” “测试方法与目的是什么?”
    带着这些问题,我们来看看Agile 中的Scrum 与 TDD

    Agile
    敏捷开发模式,实质是一种以人为本的开发理念,重视团队沟通,重视客户反馈,重视产品迭代。
    根据Agile的思想,我们主要有Scrum和XP两种开发实践,XP中又以TDD较为流行。

    Scrum

    项目经理从客户(产品经理)获取初步的需求,建立需求列表;
    项目经理(可以分为PO与ScrumMaster)定一个sprint的周期(4周例如),按需求列表分配优先级,以此为前提,与开发小组讨论工作量backlog;
    技术总监按backlog分配任务;开发小组集中速度开发。
    项目经理每个sprint向客户递交可视化产品,评审并讨论迭代需求。
    循环迭代,直至递交完整需求的产品。

    优点:有效提升用户满意度,产品成功率;量化,透明的开发任务,增加效率;不同开发岗位之间的互动,培养了团队凝聚力,减少技术代沟产生的摩擦。

    缺点:项目经理要求极高,对外部客户的需求更变所带来的backlog,经费以及质量控制要有明确的量化能力。对产品迭代需求的优先级划分要合理。对内部开发人员/QA的信息互换要即时。
    对开发人员有更高的要求,没有完善的设计文档(UI/原型)约束,容易产生理解误差,不能解决反复修改需求带来的工作量积压问题,即递交产品前的开发工程量不变甚至更多。

    Scrum小结“敏捷”实质上是对产品需求完善的速率,不是加快工程速度,而是产品后续打入市场的速度!
    正如微信等产品,通过用户反馈后迭代部分业务功能并及时更新即是agile的思想。

    由上可知,Scrum对开发人员个人也提出了更高的要求,尤其是对需求的认识。

    此时我们需要引入TDD的开发模式了,即先写测试后写业务代码。

    T实际上能映射现实业务的需求,在“莽”代码前,开发人员先分析需求,完善测试,再按照测试要求完成代码书写。这样的功能模块跑起来才是有效的,这样的集成系统跑起来才是有质量,少返工,真前进的工程。

    经过一些网络资源的阅读与大佬经验谈,TDD给我的第一印象是前期引入较为困难,测试例的推导不全,后期补测试例的情况较多。如若在Scrum中引入TDD,开发人员Sprint工作量积聚上升,抱怨与抵触声随着backlog增加而来。

    可以推断,TDD对技术总监的要求更高,需要对开发成员进行思想的指导与实践的论证,团队熟练掌握后,后期对于产品的质量的确会有进一步的保证。

    总结:Scrum与TDD近几年的普及与实践都顺应了互联网瞬息万变的节奏,这两种开发模式都对开发人员个人,提出了更高的要求。

    OK~屁文写完,继续补技术知识去了。

    展开全文
  • 瀑布开发模式: 瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了...
  •  敏捷开发模式的三个特点:依赖客户的参与、测试驱动以及紧凑的迭代开发周期。  2. 敏捷测试是协同测试的一种形式,它要求每一个人都参与到测试计划的设计、实现和执行中去。客户通过定义用例以及程序属性参与到...
  • 很显然传统的瀑布开发模式已经不能满足需要了,于是,敏捷开发这种模式就出现了。  接触过敏捷开发的朋友可能会知道,敏捷开发有如下的价值观:  个体与互动 胜于 过程与工具,可工作软件 胜于 复杂文档...
  • 敏捷开发模式

    2018-07-01 01:34:06
    1、敏捷开发的概念从1990年代开始逐渐引起广泛关注,是一种以人为核心、迭代、循序渐进的开发方法。强调以人为本,专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。2、敏捷开发的流程(图为禅道...
  • 敏捷开发模式下需求分析岗 BA 传统的瀑布开发模式下需求分析岗是必不可少的。那么敏捷项目没有需求分析吗?在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的勾当。不写文档,不作需求分析,...
  • 传统的软件开发模式需要经历问题评估、计划解决方案、设计系统架构、开发代码、测试、部署和使用系统、维护解决方案等过程,如下图↓ 采用传统软件开发模式的最大问题是开发周期过长,迭代速度慢。移动互联网行业...
  • 什么是敏捷开发

    2019-05-31 10:49:56
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 敏捷开发模式,往往传统以功能测试为主的测试难以适应新的角色,而敏捷团队也面临着产品质量和快速市场的压力,需要通过快速的迭代抢占市场,但另外一方面质量的问题,又可能导致市场丢弃,这时,测试应尝试调整...
  • 敏捷开发初步了解

    2019-09-02 10:34:44
     敏捷开发,现在大多数团队都在推崇敏捷开发模式  笔者最开始理解的时候,也在疑惑到底什么是敏捷开发,带来的好处又是什么?  笔者也只是一个入行没多久的新手,以下只是笔者自己对于敏捷开发的一些理解,并不...
  • CMMI与敏捷开发模式比较 四月 9, 2012 07:07 by FlySky 我曾经参与了一个新产品项目两个版本的开发,分别采用了CMMI与项目级敏捷方式,总结一下两种模式。 CMMI采用的是传统的瀑布模式开发,开发流程是...
  • 常用的敏捷开发模式

    2015-09-15 15:05:28
    速度是企业竞争致胜的关键因素,软体专案... 这正是Agile Process (敏捷的软体开发流程)于近年来兴起的主要原因,本文将介绍数种广为接受的软体开发流程,及其在运用上的建议。 1 Agile Process -敏捷开发流程  几
  • ios敏捷开发的理解

    2019-03-13 14:37:56
    一,根据以下几个问题来谈谈敏捷开发 1.什么是敏捷开发? 2.为什么使用敏捷开发? 3.如实使用敏捷开发? 4.采用敏捷开发的产品效果? 二.什么是敏捷开发敏捷开发是一种价值和原则,指导我们更加高效的...
  • [摘要] ...以下分享产品项目里的九个敏捷开发实战经验。  敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。  在《Scrum:兼顾计
  • 摘要:敏捷开发和CMMI的过程管理开发是当前关注最多的两种开发模式,其中体现的指导思想和组成内容具有很大的不同,为了更好的再实践中用好两种开发管理模式,促使国内软件企业的开发管理水平的提升,本文通过对两者...
1 2 3 4 5 ... 20
收藏数 66,808
精华内容 26,723