敏捷开发怎么理解_ios开发中如何理解敏捷性开发 - CSDN
  • 如何理解敏捷开发

    2014-08-30 13:39:56
    从知乎摘抄的 敏捷的核心就是短周期迭代交付,可视化,自适应调整,

    从知乎摘抄的

    敏捷 Short Cycles that are test-driven and feedback-driven, yielding constant improvement 的核心就是短周期迭代交付,可视化,自适应调整,开放式及时沟通,所有的敏捷实践基本都围绕这些核心展开,如果要再对敏捷的核心进行抽象就是迭代+自适应。

    首先,敏捷开发是一种过程控制论,通俗地说,就是一种做事情的方法

    1. 它适用于软件,可以改。如果是硬件,改起来就没那么方便了。

    2. 它适用于客户不知道自己要什么的情况,其实这样的客户占大多数。因为客户不知道要什么,所以我们需要不断帮客户弄明白他到底要什么。

    也就是说,需要和客户沟通,合作,倾听,反馈,持续改进等等。

    3. 它适用于竞争激烈的市场,这样的情况下,赶在竞争对手前交付一个不完美但至少能用的产品非常重要。

    4. 它适用于快速变化的市场,你在埋头造一辆汽车的时候,客户已经想开飞机满天飞了,这就需要你能一步步地把汽车改成飞机,还能保证按时交付。

    5. 它适用于在一个地方办公的小团队,一般7到9个人。这样使得敏捷中主要的沟通方式F2F是可行的。


    其次,敏捷开发是一套工具集,里面有形形色色的工具,你可以不搞敏捷,但可以用那么一两个工作来提高效率。

    比如:

    1. stand meeting: 我昨天干了啥, 今天准备干啥,中间碰到什么问题,三个问题,简洁有效的小团队沟通方式。

    2. KANBAN:直观地反映工作进度,反映流程遵守情况,反映流程缺陷。

    3. plan meeting,retrospective meeting:适合小团队的写作和优化反馈方式。

    4. user story: 站在用户的角度讲需求

    5. 持续集成:随时高质量交付的基础,有利于应对剧烈变化的市场。


    再次,敏捷开发是一种企业管理方式

    比如:

    1. 一线员工可以同时是架构师,ScM, 开发工程师,测试工程师。这样可以发挥他的主观能动性,有利于提高效率和创新。

    2. 敏捷不专注于团队中个人的绩效考核,而更多侧重于整个团队的绩效。

    3. 把大项目拆分成小项目去做,每个sprint都是一个迭代,需要输出一个高质量的版本,相当于完成一个小项目。

    bug的生存周期也被控制在一个迭代以内,降低了风险,也减少了后期改bug的工作量。

    4. 把数十人的大team分成几个敏捷团队,这几个敏捷团队的ScM、OPO再组成一个更高一级的敏捷团队,利用stand meeting,retrospective meeting

    Knaban等敏捷元素,可以避免数十份邮件也不能解决一个小问题,互相踢皮球,沟通不畅等大企业病。

    5. 老板可以是最大的opo, 他给下面的高管将idea(user story),定期检查Demo,把控产品的用户体验,负责与外界的沟通和合作。

    展开全文
  • 随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。

    随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。

    背景

    我们公司引入敏捷开发的时间并不长,在实施敏捷的过程还存在一些问题,自己在实施敏捷的过程也存在很多的疑惑(毕竟原来没有学过,和真实的经历,体会),所以最近一直在学习敏捷,看敏捷的视频和阅读相关资料,同时结合自己实施敏捷的经验,通过分享博文进行一下简单的总结,目的有四:
    1. 详细的介绍和学习一下敏捷开发
    2. 和CSDN的大牛们一起分享交流,学习,提高一下
    3. 总结实施敏捷过程中的问题,不断反思,不断提高
    4. 最后,希望对不了敏捷的朋友有一定的帮助

    什么是敏捷开发

    敏捷开发(Agile Development)不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。

    怎么理解呢?

    • 首先,敏捷并不是一门具体的技术,而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。

    • 其次,敏捷开发都具有以下共同的特征:

      1. 迭代式开发
      2. 增量交付
      3. 开发团队和用户反馈推动产品开发
      4. 持续集成
      5. 开发团队自我管理
    • 最后,相比于“传统”的瀑布开发模式,敏捷开发是一种“现代”的开发模式。

    具体方式

    上面说了敏捷是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而具体的开发方式有哪些呢?

    Scrum,极限编程(XP)精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)等等。

    除了Scrum和XP,对于上面的其他开发方式,我也只是简单了解,大家可以多查查相关的资料。

    我们可以简单的对比一下Scrum和XP:
    1. 在开发的过程中,你可以采用Scrum方式也可以采用XP方式;
    2. Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的。

    敏捷开发宣言

    《敏捷宣言》

    我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,我们形成了如下价值观:

    个体与交互 重于 过程和工具
    可用的软件 重于 完备的文档
    客户协作 重于 合同谈判
    响应变化 重于 遵循计划

    在每对比对中,后者并非全无价值,但我们更看重前者

    敏捷宣言是对敏捷的高度总结和升华,即使现在不理解也没有问题,在实践的过程中我们会逐渐对它有一个深刻的认识。

    敏捷开发十二原则

    在敏捷开发中,我们遵循以下准则:

    1. 我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。
    2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
    3. 要不断交付可用的软件,周期从几周到几个月不等,且越短越好
    4. 项目过程中,业务人员与开发人员必须在一起工作。
    5. 要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
    6. 无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
    7. 可用的软件是衡量进度的主要指标。
    8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
    9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
    10. 要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
    11. 最佳的架构、需求和设计出自于自组织的团队。
    12. 团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

    敏捷开发宣言比较抽象,但是敏捷开发十二原则就非常具体了,相信用过敏捷的人都知道,上面的十二原则都是开发过程的经验总结。看到十二条原则,一一的对比我们公司在实施敏捷的过程,还存在一些问题,这些问题直接导致了低效率的,不顺畅的敏捷,例如:最后一条,团队要定期反省,这点做的就不好,造成团队的积极性降低,开发效率下降,而且很难作出调整,甚至我开始也是拒绝的,有了这些原则作为指导,我们可以更加从容的实施敏捷。

    敏捷开发十二原则是我们实践的具体指导方针,它可以指导我们实施更加成功的敏捷。当我看到这些内容时,真有一种如饥似渴的感觉,真想一下子都把他们装进我的脑子里。书到用时,方恨少。及时补充自己永远都不晚。

    总结

    敏捷的思想今天算是深入人心了,后面的具体方法就是教会我们如何实施敏捷。有了这些思想,整个世界都开始美好了。

    下篇博文,进入我们的重点简单介绍Scrum以及Scrum的流程,敬请关注。

    展开全文
  • 我对敏捷开发理解

    2017-04-18 07:10:42
    我对敏捷开发理解就是快速影响客户的真正需求。 以前的开发是重文档的,先做需求调研,整出个需求文档出来,然后根据文档开发。我见过最厉害的需求文档连每个界面包括上面的控件大小、颜色什么的都画出来了。 ...
    我对敏捷开发的理解就是快速影响客户的真正需求。
    以前的开发是重文档的,先做需求调研,整出个需求文档出来,然后根据文档开发。我见过最厉害的需求文档连每个界面包括上面的控件大小、颜色什么的都画出来了。
    生产中人们发现这种工作方式有一些问题。比如周期太长,需求文档是重要资料,修订它一般需要比较麻烦的控制流程。周期长还有一个不足就是不能适应快速变化的世界,一个需求文档搞半年,需求文档出来的时候业务已经发生了重大变化。
    还有一个比较致命的问题就是我们多数人并不能很好的把业务流程抽象成合适的需求文档,由于能力和沟通上的问题,经常会发生我们做出来的东西和客户真正想要的东西差异很大。
    所以敏捷的思路就是减少使用需求文档,改用可以使用的程序原型让客户体验,使用较小的更新让客户可以更多的反馈意见,根据客户的意见进行灵活的调整。
    敏捷可以解决一些问题,当然也带来了一些问题。敏捷是一种思路,并不应该仅仅是一些死板的教条的方法。
    甚至于我们不标榜敏捷开发,然而可以在实践中和客户加强沟通,尽可能让客户通过体验提出想法,提出修改意见,可能对我们的工作都会有一定的帮助。
    展开全文
  • 1. 敏捷是“一个”过程  敏捷不是一个过程,是一类过程的统称,它们有一个共性,就是符合敏捷价值观,遵循敏捷的原则。  敏捷的价值观如下:  个体和交互 胜过 过程和工具  可以工作的...

    1. 敏捷是“一个”过程
    

    敏捷不是一个过程,是一类过程的统称,它们有一个共性,就是符合敏捷价值观,遵循敏捷的原则。
    

    敏捷的价值观如下:
    
    个体和交互 胜过 过程和工具
    
    可以工作的软件 胜过 面面俱到的文档

    客户合作 胜过 合同谈判
    
    响应变化 胜过 遵循计划
    
    由价值观引出的12条敏捷原则:
    
    我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
    
    即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
    
    经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
    
    在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
    
    围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
    
    在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。
    
    工作的软件是首要的进度度量标准。
    
    敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
    
    不断地关注优秀的技能和好的设计会增强敏捷能力。
    
    简单——使未完成的工作最大化的艺术——是根本的。
    
    最好的构架、需求和设计出自于自组织的团队。
    
    每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
    
    建立敏捷联盟的17位大师所创立的敏捷方法包括:极限编程,Scrum,特征驱动开发,动态系统开发方法,自适应软件开发,水晶方法,实用编程方法。这些方法统称为敏捷方法。
    
    其实每个人都可以从敏捷宣言和原则出发,明确问题,找出一些解决方法,形成自己的过程。我觉得国内的软件环境这么复杂,程序员的自主精神又这么强,敏捷方法应该是在中国首先提出才对,只是国人都有唯标准唯规范至上的心理定式,即使找出好办法,也觉得不规范,没有深入形成理论,无法提升高度,始终是跟着鬼子屁股后面走,我想这也是国外软件行业不成熟的表现之一吧。
    
     
    
    2. 敏捷仅仅是一个软件过程
    
    如果仅仅从软件过程的角度去认识敏捷实施敏捷,效果不会太好。敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上,正如敏捷宣言的第一条“个体和交互胜过过程和工具”所说的。
    
    涉及到人的问题,就已经不再是过程所能覆盖的了,就到了企业管理的层面上了,包括企业的价值观和文化。这也是敏捷在国内实施的最大障碍:
    
    把客户当作合作伙伴而不是对手,从客户角度出发去想问题,充分的跟客户沟通,而不是出了问题推诿责任。目标是让软件实现客户的价值,而不是收钱就完事儿。
    
    把人的能动性调动起来,给动力而不是给压力。
    
    要实用而不是要规范。让开发人员理解并实施,体验到敏捷的好处,而不是盲目机械地实施规范。
    
    没有绝对的权威,每个人都有可取之处。
    
     
    
    3. 迭代就是敏捷,UP属于敏捷。
    
    看到这么多人都把UP归入敏捷,我都开始怀疑是不是自己搞错了。但是在我的印象中:
    
    UP 是重型的过程,虽然引入了迭代,但是其原则和价值观与敏捷是不同的。敏捷注重的是反馈,迭代周期尽量的短,重在客户的参与,通过客户的参与,获取持续的反馈,不断调整使整个项目走在正确的方向上。同时也给客户一个感受和思考的机会,因为对于大多数客户而言,目标是明确的(不排除有些客户目标也不明确),但是具体怎么做,开始时是没有想法的,只有看到具体的东西的时候,才知道“噢,原来可以这样,那我想把这里调整一下”。
    
     
    
    4. 敏捷是彻底革命的。
    
    敏捷,特别是XP,让人有耳目一新的感觉,觉得以前的所有软件工程理论,设计方法都可以抛弃掉了,推翻一切,从头再来。抱着这种想法实施敏捷,那就错了,敏捷不是“石头里蹦出个孙大圣”,以前的软件过程中也有敏捷的影子,只是没有像敏捷一样上升到价值观和原则的高度,比如快速原型法。敏捷是在对已有的软件过程方法的改进,抛弃的是传统软件工程低效的外表,以往的软件过程中很多技巧都是很实用的。实施敏捷应该以现有的软件过程为基础,从敏捷宣言和原则出发,利用敏捷的方法来改善过程。
    
     
    
    5. 敏捷是反文档的。
    
    文档只是为了达成目标的一种手段,如果这种手段是低效的,那就换一种手段。可是完全抛弃了文档,怎样解决沟通的问题?难道你想每次沟通都完全用手比划,用嘴说,跟不同的人重复表述同样的想法,那样更是低效的。
    
    应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识,知识具备两种形态,显性的和隐性的,传统的观念是尽量把隐性知识显性化,即文档化,而忽略了这其中的代价(特别是更新同步文档的代价)。
    
    因此,在实施敏捷的时候,需要在团队内明确哪些知识是必须显性的,这些知识可以通过文档交流。哪些知识是可以隐性的,这些知识则完全可以通过口头的方式进行交流,以达到沟通的最佳效率。
    
    文档不是目的,有效沟通才是目的。
    
     
    
    6. 为了敏捷而敏捷
    
    “嗯,敏捷这么好,我们也敏捷吧”,可能很多人会有这种想法。忘了以前是在哪儿看的大师采访录:
    
    Q:“我们现有的过程很好,不知道怎么用敏捷改进?”
    
    A:“既然很好,那就不要用敏捷”。
    
    做什么事情都要有明确目标的,敏捷虽好,得看你需不需要,能不能解决你现在头疼的问题,如果不是,那就不要给自己找麻烦了。
    
     
    
    7. 敏捷是CMM的反义词
    
    在桂林会议的讨论中,很多人把CMM作为敏捷的反义词,我觉得这不是很合适。CMM只是一种衡量软件成熟度的标准,并非过程,和敏捷不是一类概念。如果要给敏捷找一个反义词,我觉得传统的瀑布式开发应该更合适一些。
    
    并且,我认为,如果CMM还能继续流行下去的话,应该会有公司可以用敏捷改善的过程通过CMM认证。
    
     
    
    8. 敏捷是自由的,无约束的。
    
    敏捷强调的是自组织团队,发挥人的能动性,以动力代替压力,让人有绝对自由的错觉。但是应该清楚,凡是都是要讲究一个平衡,人也是两面的,消极的一面和积极的一面同时并存,绝对的自由会放纵人消极的一面。敏捷并非是绝对自由,无约束的。作为管理者,有一个职责,就是引导团队成员用自己积极的一面去压制消极的一面,不能放任团队中出现搭便车的现象,否则将打击整个团队的士气。如果实在无效,那就只能将其排除出团队了,这个惩罚够有约束力吧?
    
     
    
    9. 重做就是重构
    
    重做不等于重构,很多场合这两个概念是混淆的。但是在敏捷中,重构的一个特征是必须可控的。当对系统结构进行大的调整时,如果没有测试驱动辅助的话,那么可控性就会很差,这不能叫做重构。


    来源:http://boboku.tianyablog.com/blogger/post_show.asp?BlogID=9171&PostID=2761785&idWriter=0&Key=0

    展开全文
  • 如何理解敏捷开发

    2019-01-04 16:16:15
    一、什么是敏捷开发敏捷开发,以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 二、敏捷开发的特点 敏捷是以人为中心的软件开发方法,保持简洁的代码,经常性测试以及及时地交付应用的功能...
  • 敏捷开发流程总结

    2010-07-20 15:36:00
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以...
  • 一个是敏捷开发的宣言 另一篇是稍微具体的方法
  • SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践...
  • 敏捷开发初步了解

    2019-09-02 10:34:44
     笔者也只是一个入行没多久的新手,以下只是笔者自己对于敏捷开发的一些理解,并不全面,如有不同理解/或更深刻的理解可以回复进行互相学习。更深入的理解仍需要长时间实践的沉淀 1. 敏捷开发是什么?  敏捷...
  • 敏捷开发的初始理解

    2018-05-24 17:06:49
    一,什么是敏捷开发1,敏捷开发的概念敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用...
  • ios敏捷开发理解

    2019-03-13 14:37:56
    一,根据以下几个问题来谈谈敏捷开发 1.什么是敏捷开发? 2.为什么使用敏捷开发? 3.如实使用敏捷开发? 4.采用敏捷开发的产品效果? 二.什么是敏捷开发敏捷开发是一种价值和原则,指导我们更加高效的...
  • 敏捷开发和迭代开发

    2019-06-27 17:05:44
    敏捷开发与迭代式开发是整体与局部的关系 敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试...
  • 我对敏捷开发的一些理解及其可行性分析。
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 敏捷开发思想

    2019-04-12 22:55:16
    敏捷开发思想SCRUM 是什么?敏捷开发是什么?以人为核心是什么意思?迭代 是什么意思?SCRUM 与 敏捷开发思想有什么关系?敏捷开发的模式分类(摘抄至互联网):SCRUM 的工作流程(摘抄至互联网)流程: SCRUM 是什么? ...
  • 如何理解敏捷开发? 没有参与过敏捷开发项目的人可能觉得敏捷开发抽象难懂。举个例子,敏捷开发像是在冲浪,一直处于动态、不断变化的环境中。在项目研发过程中出现的需求变化和挑战就是你在冲浪时要应对的海浪。...
  • 说一下你对敏捷开发理解,为什么要使用敏捷开发? 》瀑布模型的典型问题就是周期长,发布烦,变更难。 》敏捷开发就是快速迭代,持续集成,拥抱变化。     所谓“敏捷”,顾名思义,可以通俗...
  • 接触“敏捷”这个词有蛮久了,团队近半年也在实行敏捷开发,对于敏捷也有一些感触… ### 啥是“敏捷开发” 对于“敏捷开发”,网上有很多解释,可以查到一大堆相关文章,而且很多文章都有自己的不完全相同...
  • 敏捷开发 vs 传统模式

    2015-05-28 22:41:00
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  • 这是敏捷开发绩效管理的第一篇。(之一,之二,之三,之四,之五,之六,之七)“敏捷开发绩效管理”本身是个伪命题,因为敏捷开发本身不想涉及绩效管理,这就像“C++绩效管理”的搭配差不多。但是人们选择敏捷开发...
1 2 3 4 5 ... 20
收藏数 61,191
精华内容 24,476
关键字:

敏捷开发怎么理解