敏捷开发 精益开发_精益开发 敏捷开发 - CSDN
  • [b]聊聊软件开发[/b] 软件开发是一种非零和博弈,意思是某一方的获得不是建立在另一方的损失之上(赌 博就是一种零和博弈,获得和失去的总和等于零),所以软件开发必须实现双赢,[color=red]帮助客户成功的同时...
    [b]聊聊软件开发[/b]
    软件开发是一种非零和博弈,意思是某一方的获得不是建立在另一方的损失之上(赌 博就是一种零和博弈,获得和失去的总和等于零),所以软件开发必须实现双赢,[color=red]帮助客户成功的同时帮助自己成功[/color]。如:通过软件帮助客户把手上的5块钱变成50块钱,然后从客户那里拿5块钱。通过软件帮助客户节约50块钱,然后从客户那里拿5块钱。

    [b]从精益说起[/b]
    敏捷开发和丰田的精益思想颇有相似之处。传统的汽车制造是以计划驱动,如根据往年的经验判断今年应该生产多少汽车,但是这样带来的问题是有可能等汽车生产出来,市场已经不需要了,而这就是一种极大的浪费。精益思想是以价值为驱动的方法论,[color=red]精益思想的核心是消除浪费[/color],它认为不为客户创造价值的活动和尽管是创造价值的活动,但是所消耗的资源超多了“绝对最小”(投入产出比低)都视为浪费。浪费有七种:过量生产(生产多于所需),库存(不直接产生价值,并增加管理成本),搬运,返工,过程不当(对最终产品不能增加价值的活动),多余动作(任何不增加价值的设备和人员的动作),等待(两个关联的要素间,未能同步)。

    [b]再谈敏捷开发[/b]
    敏捷开发的核心就是消除浪费。那么在软件开发当中应该如何消除浪费呢?
    [list]
    [*][u]过量生产[/u]:在我们开发的产品当中,如果需求(用户故事)不是把握的很好,那么就会造成很大一部分功能用户从来都不会使用,这就是生产多于所需。所以我们需要用户和业务分析师(BA)或者需求分析师一起来规避过量生产。
    [*][u]库存[/u]:在我们的软件开发过程中,如果一直处于开发中,那么产品未给客户带来直接的价值,这就是一种库存。所以我们可以通过迭代开发和快速交付来减少库存。
    [*][u]返工[/u]:这个在软件开发当作比较常见,可能是对需求理解不透彻,开发出来的功能,不是客户所想的,导致返工。也有可能是当初的设计不合理,不能满足客户的新需求,导致返工。也有可能是开发人员不注意编码质量,导致代码的坏味道越来越重,最终导致代码无法修改,导致返工,我曾经遇到一个核心类有几千行,无人敢动。所以我们需要BA来规避需求风险,需要架构师来规避设计风险,需要好的基础和习惯来提高软件质量。
    [*][u]过程不当[/u]:我觉得这个主要体现在沟通方面。比如我和某同学讲述一个需求,如果别人不用心听,那么信息就不会有效的传递给他,或者是我表达的是A,而他听到的是B。所以在沟通的过程中一定要[color=red]通过消除沟通壁垒来消除浪费[/color],在表述者和聆听着之间存在两道沟通壁垒,减少第一个壁垒,表述者应该尽量站在聆听者的知识背景上去清楚的表达内容。减少第二个壁垒,聆听者应该怀着一个开放的心态,去用心的接收表述者传达的信息,不要在没完全听明白表述者传达的信息之前,就用惯性思维去抵触信息的传递。另外一点,我提倡[color=red]定期沟通,而不是时时沟通[/color],定期沟通是消除信息传递不畅导致的浪费,不提倡时时沟通,是为了减少开发人员的任务切换,从而提高效率。
    [*][u]等待[/u]:这个可能是不同模块之间的依赖和接口的联调需要等待,所以这个可以通过合理的计划来减少等待。也有可能是测试和研发的资源和计划不对称,导致开发的时候,测试闲置,开发完之后,测试资源不足。这个可以通过迭代开发持续交付的方式,来提高测试资源的利用。
    [*][u]多余动作[/u],我觉得主要体现在重复开发。比如每个模块可能都会开发上传组件,分页组件和验证组件,可能都会调界面样式,可能花时间解决一个重复的问题。所以要减少多余动作造成的浪费,我觉得应该加强团队沟通,有专门的人负责公共组件的开发和复杂问题的解决。
    [/list]
    [img]http://dl.iteye.com/upload/attachment/355627/bbdf7eac-891b-3218-85ff-94b4a07a2185.jpg[/img]我很喜欢这幅图片,我把它称为“举重若轻”,对于软件开发而言,它是一项非常复杂非常重的活动,那么如何能够举重若轻呢?我觉得应该采取敏捷的方式,将软件开发活动细化为一个一个非常轻的活动(迭代),那么我们就能做到举重若轻了。

    [b]SCRUM[/b]
    [color=red]SCRUM是一套敏捷开发的框架[/color],说的是在进行一次敏捷开发的过程中,所需要参与的角色,进行的活动和输出的产物。
    角色有三个:
    [list]
    [*][u]团队负责人[/u]:作为客户代表,确定产品的方向和愿景,定义产品发布的内容、优先级及交付时间,为产品ROI负责。没有BA的情况下,可以充当BA的角色,来规避因需求问题导致过量生产和返工所产生的浪费。
    [*][u]SCRUM MASTER[/u]:主要负责消除团队障碍。我觉得他可以负责开发公共组件,解决复杂问题来规避多余动作。通过制定沟通机制,开发流程规避过程不当造成的浪费。通过协调开发计划,来规避等待所造成的浪费。
    [*][u]团队[/u]:一个完成的软件开发团队应该包括销售,售前,用户,研发,测试,售后等所有相关人员,因为任何几个角色都有可能导致软件开发的失败。对于团队而言最重要的是加强沟通,使信息能够准确的传递给团队的每一个人。
    [/list]
    其他的不一一细说了,我认为SCRUM的核心是通过敏捷回顾来持续改进,从而消除浪费。因为在软件开发中遇到的小问题非常多,从而造成大量的浪费,所以必须通过敏捷回顾,不断的总结团队做得好的习惯和遇到的问题,在下一个迭代的开发中的解决这些问题。

    [b]XP[/b]
    [color=red]XP是实现敏捷开发的一些非常好的实践[/color]。
    [list]
    [*][u]用户故事[/u]:是站在用户的角度和应用场景下来描述业务需求。格式为作为..我能..以便于..如作为网络管理员,我能查实时的查看每个设备的CPU利用率,以便于我能即时发现有问题的设备。
    [*][u]TDD[/u]:狭义的测试驱动开发,是通过先写测试代码再写程序代码的方式,来理清编码思路和写有效的代码,之所以说有效的代码,是因为有时候写的方法,你会发现从来没有任何其他的方法会调用它,如多余的修改器(setter)和访问器(getter)。我强烈建议业务服务层代码使用TDD进行开发。进行TDD时很重要的一点是你要会使用IDE的部分快捷键,让代码自动生成。
    [*][u]持续集成[/u]:通过自动化构建工具(cc),持续集成版本,从而可以快速的反馈集成问题。
    [*][u]结对编程[/u]:两个程序员用一个电脑进行编程,一个人负责编码,另一个人负责思考,在编写之前需要和结对的同学表述自己的编程思路,从而将每一个程序员的优秀习惯传播给整个团队,但是遗憾的是结对编程对程序员的要求比较高,最好是两个程序员有一定的能力,并且能力差不多,如果一个能力很高的程序员和一个能力低的程序员结对可能效率很低。
    [/list]

    [b]最后推荐书籍:[/b]
    [list]
    [*]《丰田汽车案例-精益制造的14项管理原则》
    [*]《硝烟中的Scrum和XP》
    [/list]

    [b]推荐博客:[/b]
    [list]
    [*]http://yizhituzei.blogbus.com 一只土贼的博客博客波波客
    [/list]
    展开全文
  • 在 DevOps 的世界里,所犯下的最大的错误是:整天只知讲些文化、协作, 却完全将最重要、最关键,存储在 SVN, Git⋯内的开发人员的 “行为数据” 视而不见。在 DevOps 的世界里犯下这样的错误,将使得团队白白的耗费...

    假如,团队整体的分工模式是错误的,那 DevOps 还是没办法消除团队内不同角色间的甩锅与填坑的;能为团队设计出正确的分工模式,是团队能开始协作的关键的第一步。

    在 DevOps 的世界里,所犯下的最大的错误是:整天只知讲些文化、协作, 却完全将最重要、最关键,存储在 SVN, Git⋯内的开发人员的 “行为数据” 视而不见。在 DevOps 的世界里犯下这样的错误,将使得团队白白的耗费大量的人力、时间,只是照着 “ DevOps 的课本” 在演出一场 “DevOps 的行动剧”罢了;团队对于如何的持续改善团队成员的开发效率、产品的质量,还是茫然无知的。

    不论团队是要导入 DevOps 、Scrum、SAFe、LeSS、Kanban, 都应该要从 “团队的现况” 与 “开发人员的行为数据” 开始。

    所以,身为 DevOps, SAFe, Scrum, LeSS, Kanban 的教练、顾问, 都不应该背离了 “编程”,更不该对 “人类的行为模式” 是茫然无知的。

    我们总是听到,DevOps 能提升效率、质量。

    我们总是听到,不做 DevOps 就会面临被淘汰的命运。

    但是,为何当我们每个人都认为 DevOps 是必要的同时,却很少有人会去怀疑,团队在 DevOps 的 Value Stream 中的集成测试,其实是不可信的?

    就宛如我们总是听到,因为健康检查,而有多少人能及早发现、治疗了癌症;我们每个人也都认为每年的健康健查是必要的。

    但,却很少有人会去关注,有多少比例的癌症病人当中,其实,是每年都有在做健康检查的?!

    我们往往都太急于想在急速变化的IT 产业当中,去抓住一块 “浮木” 来获得安全感、专业感;其实,这块浮木,往往是连我们自己都感到茫然、感到陌生的。

    为何在 Google, Amazon, Netflix 的内部永远都只专注在:人、架构、代码、自动化工具,而没跟风的去搞所谓的 DevOps, SAFe, Scrum, Kanban⋯却仍然能使得产品拥有质量、价值与竞争力?!

    我并不是说 DevOps, SAFe, Scrum, Kanban⋯是没有用的。

    我只是想建议,我们应该要 “颠倒” 下我们理解的思路;不要急着将在 DevOps, SAFe, Scrum, Kanban 中所学到的 “答案”,就直接的套在我们日常的软件开发当中。

    相反的,应该是从我们日常的软件开发当中,去引导、去设计出我们所真正需要的 DevOps, SAFe, Scrum, Kanban⋯

    展开全文
  • Lean UX(精益用户体验)和Agile UX(敏捷用户体验)这两种方法对于设计师来说并不陌生,但对于设计新人来说,想准确地对二者进行区分是件不容易的事。如果你在谷歌中搜索“Lean UX 和 Agile UX 的区别”, 然后一篇...

    Lean UX(精益用户体验)和Agile UX(敏捷用户体验)这两种方法对于设计师来说并不陌生,但对于设计新人来说,想准确地对二者进行区分是件不容易的事。如果你在谷歌中搜索“Lean UX 和 Agile UX 的区别”, 然后一篇篇地阅读相关的文章,你会发现很多观点和立场是互相矛盾的,最终还是一脸茫然。实际上,我们在讨论任何概念时,只要以其在实际中的应用为导向,就不会过分纠结。对于精益用户体验和敏捷用户体验,我们只需知道它们的渊源,核心原则,优缺点,再根据这些来判断其在产品开发中的适用性,就已经足够了。有一点可以肯定:在实际的产品设计与开发流程中,二者大多数时候是相辅相成,混合使用的。




    一、渊源与定义


    精益用户体验(Lean UX)和敏捷用户体验(Agile UX)这两个概念实际上是在精益软件开发(Lean Software Development)和敏捷软件开发(Agile Software Development)的基础上提出的。我们先来看看后两者的定义:


    敏捷软件开发:又称敏捷开发,是一种从90年代开始逐渐引起关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(被认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发过程中人的作用。


    精益软件开发:源于Mary Poppendieck和Tom Poppendieck的同名书籍。这本书将传统的精益原则重新阐释,提供了22种开发实践“工具”,并与敏捷开发的实践做了比较。 通过Poppendieck夫妇在敏捷软件开发社区中的努力,包括在敏捷开发会议上的几次演讲,精益软件开发已经被敏捷开发社区广泛接受。


    同理可得,Agile UX 和Lean UX即两种软件开发方法在设计领域的应用。敏捷用户体验注重产品设计中人员交流,软件交付及开发的高效,而精益用户体验则以人为核心,注重产品与市场的匹配度。两种方法各有优缺点,但同样重要。


    二、核心原则




    三、优缺点,重要性


    在敏捷用户体验设计中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。该方法能提高设计效率和产品的响应能力。


    然而,想要设计出一个好的产品,最终还是与“人”有关,人是既麻烦又非二进制的动物,人的需求只有被整体地结合起来考虑时才能提供最好的用户体验,这是精益设计最显著的优点。由于这一方法一定程度上拉长了产品设计与开发的时间,对于大多数以结果为导向的设计师而言,敏捷设计可能是更好的选择。


    有一点需要注意的是:敏捷不等于低质量,精益不等于低效率。


    四、产品原型在两种设计方法中的作用


    原型作为产品设计初期的雏形,被用于测试产品的可用性,数据表明,原型可以减少产品发布后约25%的bug。因此无论是在敏捷用户体验设计(Agile UX)还是精益用户体验设计(Lean UX)中,产品原型对于设计师都是一个很好的刺激。正是因为有了原型设计,设计师才得以从舒适的房间和办公室里走出去,带着他们的“想法”到客户那里,与他们进行交流,深入地了解用户需求,从而使得两种设计方法中以“人”为核心,以“用户体验”为导向的原则得以被贯彻。


    以下推荐一些优秀的原型设计工具:


    Mockplus – 做原型,更快更简单。支持团队协作和在线审阅。


    Axure – 原型及图表一体工具。


    Justinmind – 网页及移动应用原型工具。

    展开全文
  • 在几年前,我就对软件的敏捷开发有着很高的兴趣的。一直觉得,程序员应该是最自由,最轻松的一种职业!而且我也一直在向这个方向努力!我们应该如何做呢?一说到程序员,大家就公认的是脑力民工!为什么?在程序员...

    在几年前,我就对软件的敏捷开发有着很高的兴趣的。一直觉得,程序员应该是最自由,最轻松的一种职业!而且我也一直在向这个方向努力!
    我们应该如何做呢?一说到程序员,大家就公认的是脑力民工!为什么?在程序员自己报怨开发环境不好,工作量大,任务重,压力大的同时,有没有想过,有些问题其实是程序员自己的原因造成的呢?

    我们来看一个流程的例子:
    从一个问题单开始,你要解决这个问题,首先得申请问题单的查看权限,花5分钟填写一个权限申请电子流,然后等1到2个小时生效。当然,如果你一次申请一个长久有的效的权限,第二次在解决问题单时就不须要了。
    然后阅读问题单,重现问题,如果有不清楚的,可能还会咨询测试人员。假设你在1个小时以内了解清楚了问题。
    然后准备修改问题,得先申请代码权限。填写电子流也就几分钟,然后等待审批,可能得1到2上小时。如果幸运的话,是这样的。
    然后是代码的Checkin与Checkout,以及修改!
    然后是编译,验证。最后出版本!

    OK,这是一个比较简单的流程,我们看看,其实有很多因素可能导致我们的开发流程是效率很低的。例如,在权限申请的等待过程!问题确认过程!电脑文件打开等待过程!网络打开等待过程!等,一些不产生value的过程,都是精益开发中应该减少的。
    我们并不能指望效率会有多高(丰田的效率也只有40%左右,效率就是把一个流程中,产生value的时间除以整个流程的总时间),但在精益开发中,就是要在各个环节中找到影响效率的点,然后尽力的去减少它!
    例如,上面的例子中,当开发人员要确认问题时,应该直接找到测试人员,面对面的把问题搞清楚。而不是在邮件,或者电话中询问题!再如,给开发人员配置更快的电脑,以减少打开文件的等待时间。当然,开发人员也应该自己优化自己的开发电脑。公司优化网络等。
    当然,在整个流程中,要分清楚哪些工作是有效的,哪些是没有效的,并不是件容易的事!一些非常明显的事,如前面提到的等待,就不用说了。
    对于以下一些事件,哪些是有效的,哪些是无效的呢?
    需求分析
    需求设计
    编写设计文档
    测试设计
    编写测试文档
    编码
    测试
    修改BUG
    技能提升
    呵呵,感觉全部是有效的工作!其实不是!
    从用户角度来看,只有编码一修改Bug是有效的,其它的一律无效!
    当然,这是从用户角度来看。从我们开发人员来看,上面的也并不是全部有效的!
    例如:设计文档,测试
    而技能提升是有效的。
    这里不去细致的讨论哪些有效哪些无效,只要记住精益的思想:
    尽量发现开发流程中的无效工作,并尽量减少它!
    当然,精益开发也给我们提供了一些简单的方法来判定有效工作与无效工作!
    这就是精益开发的第一条原则!而后面的所有原则就都是由它产生的!

    另一个就是敏捷开发!敏捷的第一条原则就是满足客户需求!
    第二原则就是适应变化!
    第一原则我觉得不用讲,没客户你就无法生存!
    而第二原则,则相比之下会更重要!为什么,因为只有适应变化,才能不断满足客户需求!而且变化是非常快的,如果软件开发不能适应变化,客户的满意度也会下降。因此,我觉得,软件开发能适应变化,快速反应用户需求与变更,是敏捷开发的核心!
    如何做到这些呢!
    首先就是敏捷开发流程!它使用是迭代开发!
    有人不明白,为什么要用迭代开发。如果在已知用户需求不会发生变化的时候,我们还要用迭代吗,为什么不一次就把事情做好,交附给用户!
    说到这一点,不得不提到精益开发里的一条:一个软件真正有用的特性往往不足50%,而且经常使用的也只有20%左右。如果你觉得用户的需求不会变化,然后一次给用户把所有特性全部完成的话,你就会陷入到这个2-8理论中!
    敏捷的思想是怎样的呢?我们喜欢变化,我们要适应变化,还要引导用户变化!
    例如:在你收到用户的10个特性时,经过分析,可能会发现有4个特性可以不要,或者可以用前面的特性取代!但这是用户的特性,用户就是上帝,你又不好直接回复用户,说这个特性可以不要,只要用前面的特性1,稍微改一下用法就可以实现!
    用户可不吃你这一套!但如果我们先把一些基础特性在前面的迭代中先完成,然后以体验版的形式给用户。一方面验证一些特性,另一方面,也可以引导客户,对后面的特性进行变化!
    这时,用户很有可能对前面的一些特性有新的看法,会要求修改已经实现了的特性。然后对还没有实现的特性可能会不太关心,或者,用户在自己使用的时候,就已经意识到,后面的特性可以不要了!
    这样,一方面我们要增加已经完成的特性,而另一方面就要删除原来的特性需求,或者更改需求!这是好事还是不好呢?就不说了吧!
    如果我们在一开始就想着是这样的发展过程的话,那是太好不过了!当然,如果你觉得用户善变,那我也就无语了!那就还是走2-8理论吧!
    敏捷的核心,就是变化,适应变化!而在软件的开发中,对代码的变化是非常讲究的,也有很多方法和工具。敏捷的迭代是从流程上来管理的,还有其它很多就不多说了。
    今天也就是从培训中学习和了解一点,然后结合自己的想法写了一点!

    转载于:https://www.cnblogs.com/WuCountry/archive/2009/02/08/1386172.html

    展开全文
  • 精益敏捷开发

    2014-11-16 20:26:56
    这是
  • 精益开发 我先把精益开发的概念和七条基本原则列一下,然后再逐条原则表述一下我的理解。 概述 精益(Lean)管理的思想起源于丰田公司,旨在创造价值的目标下,通过改良流程不断地消除浪费。这种方法现已被广泛用于...
  •  精益敏捷开发以轻量级的文档与团队协作, 提高开发的效率◦ 另一方面, 许多人对于精益敏捷开发在轻量级的文档下, 如何保证开发的质量存在著许多的质疑与困惑◦  本文将从 “度量” 的角度, 运用一轻量级度量的...
  • 2012年12月的某日,@scmroad配置管理之路 发出了条微博 “求教,agile 和 lean, 请问这两个词在敏捷中都是是啥含义?有什么特殊的意思”, 后面@张克强-敏捷307,...也有观点认为,精益软件开发敏捷软件开发是并列的
  • 广义而言,精益敏捷是两组具有高度兼容性的价值观和原则,都阐述了如何成功地进行产品开发。Scrum、XP和看板则是将这些原则运用到实践中的三种具体方法。换句话说,它们是精益敏捷软件开发里轻度重叠的三种不同...
  • 引自 blog.sina.com.cn/s/blog_493a84550100ax35.html最近看了InfoQ上关于精益看板在软件开发上的一些实践和应用的文章,敏捷软件开发借鉴了很多TPS精益生产的思想,虽然没有完全提到看板的概念,但是看板在敏捷软件...
  • 敏捷方法 - 精益思想

    2019-08-11 18:22:56
    精益(Lean)思想来自制造业,21 世纪初由Tom 和Mary Poppendieck 引入软件开发领域,精益的很多思想也被认为是对软件行业有参考价值。...当把精益制造的一些思想应用到软件开发中时,我们从敏捷开发的其他...
  •  本文主要探讨在产品外包的模式下, 精益敏捷开发如何能迅速, 有效的提升外包人员的能力◦   本文:  许多的产品当采用外包的开发模式时, 所面临的最大的挑战便是: 外包人员的能力, 素质参差不齐◦  精益敏捷...
  • 现在有许多提高软件开发的方法,敏捷精益是其中盛行的两个。管理者必须决定在其组织机构中运用哪种方法,也可以依据需要解决的问题,来考虑结合运用多种方法。\u0026#xD;\n在题为敏捷地构建,精益地学习的演讲中,...
  • 但是,大多数情况下在软件开发过程中需求会不断变化,而瀑布式开发很难适应这种变化。针对瀑布模型的这一不足,随后涌现了许多开发模式,比如螺旋模型和统一过程开发(RUP)模型。尽管与瀑布模型相比,这两种模型有...
  • 敏捷开发 知行合一

    2018-01-15 14:58:15
    周末阅读了丛斌老师的《知行合一 实现价值驱动的敏捷和精益开发》一书,对敏捷开发有了更直观了认识,总结如下: 关于《敏捷开发宣言》 我们一直在实践中探寻更好的软件开发方法, 身体力行的...
  • 敏捷软件开发工具——精益开发方法》 基本信息 作者: Mary Poppendieck Tom Poppendieck 译者: 朱崇高 出版社:清华大学出版社 ISBN:9787302078678 上架时间:2013-7-5 出版日期:2013 年7月 开本:16...
  • 读书笔记--精益敏捷开发大型项目应用指南>   【摘要】 3月份的时候,根据教练和其他多为项目经理的推荐,开始阅读这本书;本书共三大部分、12个章节,第一部分:思考工具,第二部分:组织工具;第三部分...
  • 敏捷精益和Scrum - 他們的意思是一樣的嗎?雖然有些人可能認為這三個概念是同義詞,但實際上,它們看起來非常相似,但仍有一些顯著差異。 在本文中,我們將仔細研究這些概念並解釋它們之間的區別。 起源 Agile ...
1 2 3 4 5 ... 20
收藏数 7,668
精华内容 3,067
关键字:

敏捷开发 精益开发