敏捷开发是什么意思 精益_精益开发 敏捷开发 - CSDN
  • 精益开发 我先把精益开发的概念和七条基本原则列一下,然后再逐条原则表述一下我的理解。 概述 精益(Lean)管理的思想起源于丰田公司,旨在创造价值的目标下,通过改良流程不断地消除浪费。这种方法现已被广泛用于...

    精益开发

    我先把精益开发的概念和七条基本原则列一下,然后再逐条原则表述一下我的理解。

    概述

    精益(Lean)管理的思想起源于丰田公司,旨在创造价值的目标下,通过改良流程不断地消除浪费。这种方法现已被广泛用于生产制造管理,对于IT系统建设,精益开发的常用工具模型是价值流模型。

    精益开发的基本原则

    • 杜绝浪费:将所有的时间花在能够增加客户价值的事情上。
    • 推迟决策:根据实际情况保持可选方案的开放性,但时间不能过长。
    • 加强学习:使用科学的学习方法。
    • 快速交付:当客户索取价值时应立即交付价值。
    • 打造精品:使用恰当的方法确保质量。
    • 授权团队:让创造增值的员工充分发挥自己的潜力。
    • 优化整体:防止以损害整体为代价而优化部分的倾向。

    对原则的理解

    杜绝浪费,浪费是可耻的,这个很好理解,但是在这条的描述中,精益提出“把所有的时间都放在能够增加用户价值的事情上”,这样太容易被曲解了,最值得考究的就是什么才算能够增加用户价值的事?及时交付对用户有价值的产品算是增加用户价值,那么我们要做的事就仅此一件了吗?显然太片面,我们需要做的远不止这一件事。健康的团队才能产出优秀的产品,“毕其功于一役”的大决战当然是一场拼尽全力的冲锋,但是“路漫漫其修远兮”,“上下求索”显然又是个长跑的过程,不健康的团队谈不到长远的发展,所以“所有时间”中必然要包括培养出一只有战斗力的团队。再有,概述中就提到的,我们需要通过什么手段消除浪费呢?通过不断地改良流程,敏捷宣言中说“个体的主观能动性以及个体之间的互动优于既定流程和工具”,这只是强调个体的主观能动性和互动更加重要,但是并没有抹消掉流程的重要性,而且敏捷非但没有忽视流程的重要,恰恰相反,在敏捷开发的原则中说“简洁是减少重复劳动的艺术”,而流程就是保持简洁有力手段,这一点在精益中被尤为强调,所以在制定更加简洁高效的流程上花时间绝不是浪费。
    推迟决策,就是提出尽可能多的可行方案,有利于针对实际情况做出选择。我们应该把重点放在后半句的“时间不能过长”上。假设我们把相当宽裕的时间留给了提出尽可能多的方案上,我们得到了相当多的可行方案,但是方案再多总要根据实际情况选择最行之有效的那一个,那么怎么评判是不是最行之有效的方案呢?简单点讲就是找到这些方案中最能满足“时间”、“范围”、“资源”三者之间平衡的方案,耗时太长显然就压缩了项目的可用时间,对“范围”和“资源”也必将产生影响。推迟决策是为了找到平衡“时间”、“范围”、“资源”的最佳方案,那么掌握不好“推迟”的时间就是在舍本逐末。
    加强学习,这和上面讲到的培养有战斗力的团队相呼应,学习是强化团队、保持团队活力的最佳方式,至于什么是“科学的方法”,我觉得应该是最适合自己团队的方法,是组建读书会、学习小组这类组织,还是搞黑客马拉松、分享讲座这种活动看你对团队的了解,哪种方法最有效,最能持续发展就选那种。
    快速交付,精益开发是敏捷开发的一种形式,既然是敏捷开发那就不能不提快速交付,在我们软件开发中的实践就是尽可能缩短迭代周期,并且在每次迭代中给用户提供稳定可运行的并且有价值的软件,这是敏捷开发的核心手段,精益中如此,其他的敏捷方式比如“极限编程(XP)”、“水晶方法”、“动态系统开发法(DSDM)”、“SCRUM”也是如此,只是各种方法都有自己具体实践,几种的方式对迭代的实践我会放到后续的文章中讨论。
    打造精品,“XX出品必属精品”,当一个公司被冠以这样的评价,如果这个评价是正面的而非带有讽刺意味,那么说明这家公司得到了用户极高的认可,“赢在用户”一语双关,既是说精品的受益者是用户,也是说只有精品才能在竞争中赢得用户。
    授权团队,团队,还是团队,好产品离不开好团队,好团队要培养也要被信任,授权团队可以最大化地激发团队中成员对产品的主人翁意识。用人不疑,疑人不用,需要的是睿智和胸襟,不能放任不管任由其自生自灭,也不能大权独揽,手里攥着大印把角都磨圆了,还怎么激发团队的主观能动性。
    整体优化,整体优化不应该被简单理解为全面优化,我认为对整体有利的优化就可以称之为整体优化,当局部优化的程度达到足以提升整体的成效时就是一次整体的优化,这条原则强调的是局部优化的投入不应该大到拖延整体的进度。当你跟上级说我要优化一下项目架构(不要以为架构层面的就是整体,说到底研发团队也只是整个项目的一部分),大概要花两三个月的时间时,可以让软件的执行效率提升20 ~ 30%,否则将来软件的执行效率会很差,一般情况下你会得到什么答复?糟糕一点儿当然是被一口回绝,好一点儿的可能会被问问“现在的架构有什么局限?”、“新架构能带来什么好处?”,多数人在多数情况下是争取不到这么长的时间去做这种拖慢产品进度的优化的,无关于这次优化是关乎局部还是整体。或许经过几个版本的迭代后你所担心的问题终于发生了,软件运行的效率大大降低,这个时候我们应该暗暗冷笑上级只顾眼前利益吗?我觉得我们应该考虑一下自己给出的方案是不是真的考虑了整体,方案够不够敏捷。其实张口就要几个月的时间本身就是没有考虑到整体,技术停下来优化各两三个月那让产品、设计、运营放三个月长假吗,或者你独立出来搞几个月,你确定几个月后你还追的上产品这几个月来的迭代?一个优化需要两三个月的时间这显然是不够敏捷的,甚至无法保证最终优化的框架是不是真能达到预期的效果,“不能达到预期效果”正是困扰瀑布流模式的问题,也是敏捷开发提出短周期提交可用软件所要解决的问题,当你坐在上级的位置上肯定也要考虑局部优化对整体利益的影响,既然我们是在敏捷开发这个大的项目开发流程下,那么局部的优化也应该遵循敏捷的原则,化整为零,逐步迭代。我想针对上面说的花两三个月的时间优化框架这个请求,如果我们提出的方案是三到五个迭代每个迭代两到三周,每个版本都可以让项目开发的效率提升5~10%,再跟上级讲讲不优化可能带来的软件运行效率问题,我想上级点头的可能性会大大增加吧。

    展开全文
  • 什么特殊的意思”, 后面@张克强-敏捷307,请我来回答。@张克强-敏捷307:回复@scmroad配置管理之路:lean的翻译是精益。agile的翻译就是敏捷。有观点认为,精益软件开发敏捷软件开发的其中一种。也有观点认为,...

    2012年12月的某日,@scmroad配置管理之路 发出了条微博 “求教,agile 和 lean, 请问这两个词在敏捷中都是是啥含义?有什么特殊的意思”, 后面@张克强-敏捷307,请我来回答。

    @张克强-敏捷307:回复@scmroad配置管理之路:lean的翻译是精益。agile的翻译就是敏捷。有观点认为,精益软件开发是敏捷软件开发的其中一种。也有观点认为,精益软件开发与敏捷软件开发是并列的关系。

    @scmroad配置管理之路:精益开发和敏捷开发的区别在哪里?我看到过很多人提敏捷开发,也提精益开发。

    @张克强-敏捷307:回复@scmroad配置管理之路:敏捷开发现在是个“超级大筐”,好东西都可以往里面装。精益软件开发是一个“小筐”,也能装不少东西了。不少东西既能装在敏捷的大框里,也能装在精益的小筐里。而精益当中的强度量强指标有些人认为不能装到敏捷大筐里

    @张克强-敏捷307:精益实践特征上更倾向于分工高效合作,与scrum的团队建设方向有差异,当然这里面有一个精益的理解问题,如果把精益理解为心法层面的东西,那就能兼容很多其他东西。

    @Thinker姜志辉: 以精益原则作为敏捷改进的指导性原则,以xp+scrum作为敏捷实践工具箱,是目前比较流行的一种做法
    @scmroad配置管理之路:精益原则指导敏捷?那敏捷原则呢?
    @Thinker姜志辉: 敏捷的目的是为了更好的开发软件,不是为了贴上敏捷标签。华山剑法就不能配太极心法
    @伍斌_Ben: Lean的本质是减少浪费,从丰田汽车制造而来。在软件开发里,lean的目标是提高ROI,面向公司高层;scrum的目标是迭代管理,面向项目管理;XP的目标是高效coding,面向基层;三个层次统称agile

    @agile123:好问题!越简单的问题往往越难。agile的反义词是迟钝,基本含义是积极应对变化,重点在adapt to change上;lean的基本含义是节省,要减少成本和浪费,利润是抠出来的。在敏捷开发中,适应变化和减少浪费这两个方面同时需要,例如用短迭代以避免过多的计划和预测产生浪费,同时又可以及时调整适应变化。

    @肖恩亦书:个人理解,精益是发现价值,杜绝浪费,从而实现精益求精,丰田借此登上世界第一的宝座;而敏捷是精益思想在软件领域的应用,不管宣言也好,守则也好,无不体现着尊重客户价值,减少沟通障碍,快速反馈等;还有XP,更是一种敏捷编程方法……

    @静水流深78:有人说敏捷来自于精益。从字面意思来讲,前者是快,后者是省
    @agile123:Lean源于70年前的丰田。敏捷的前身是IID,1970年代的Evo大概是最早成型的迭代方法,诞生于米国防部项目,再往前推两者有无交集就未知了。不过无论Agile还是Lean,都有个基础:Quality First,在好的前提下才能提快和省

    @难啊_上海: 这么讲,敏捷是包含精益的了?那为何《精益软件开发艺术》中说精益的视角比敏捷宽泛呢?


    我的编后语:最后的问题“那为何《精益软件开发艺术》中说精益的视角比敏捷宽泛呢?” 等了多天,没有人回复了。
    各家有各家不同的看法。能够写出《精益软件开发艺术》的人貌似更有权威些,但这并没有标准答案。


    以上是4年前的文字,前些天在微信群有相关的讨论,今天偶然在档案箱里翻到,把它重新发到这里吧,看起来仍然有现实意义。

    前天在微博上再次提问:精益软件开发与敏捷软件开发是什么关系?
    @王海鹏Seal:日本和欧美的关系
    @张克强-敏捷307:回复@王海鹏Seal:[思考]是互相交流学习的意思咯?
    @王海鹏Seal: 起源不同,XP起源于Kent beck研究心理学的老婆,精益源于丰田制造

    附注:王海鹏是《精益软件开发管理之道》的中文译者,王海鹏Seal是他的微博昵称。

    展开全文
  • 敏捷方法 - 精益思想

    2019-08-11 18:22:56
    精益(Lean)思想来自制造业,21 世纪初由Tom 和Mary Poppendieck 引入软件开发领域,精益的很多思想也被认为是对软件行业有参考价值。...当把精益制造的一些思想应用到软件开发中时,我们从敏捷开发的其他...

    精益(Lean)思想来自制造业,21 世纪初由Tom 和Mary Poppendieck 引入软件开发领域,精益的很多思想也被认为是对软件行业有参考价值。与Scrum所提供的的过程管理框架不同,精益更多体现为一种思维方式,精益的思维方式也常被称为精益思维(Lean Thinking)。

    1. 精益思想

    精益是敏捷开发的一个重要部分。当把精益制造的一些思想应用到软件开发中时,我们从敏捷开发的其他组成部分中借鉴了一些东西。和敏捷开发一样,精益思想也包含一些价值观,这些价值观中的一部分入尽快交付、增强学习等与敏捷思想完全一致,但也有有一些思想代表着精益的特有思维,最具代表性的就是消除浪费,即找出那些不能直接帮助你创造出有价值软件的工作,把它们从项目当中去掉。关于软件研发过程中的浪费现象可以总结为:

    • 部分完成的工作:部分完成但没有最终落地的工作 
    • 未应用特性:开发完成但没有被客户应用的特性
    • 额外过程:开发过程中不需要的流程和中间产物
    • 再次学习:人员、环节变动导致反复重新学习
    • 信息移交:隐性知识信息的传递总是伴随信息丢失
    • 任务切换:多任务工作会导致效率下降
    • 资源依赖:因任务或资源相互依赖而导致工作停滞
    • 系统缺陷:解决缺陷活动本身就是浪费

    对这些浪费现象的分析思想来自于丰田制造系统(TPS),并在软件行业中得到映射,精益软件开发过程的倡导者们虽然为我们总结了这些浪费现象,但对如何识别这些浪费进而消除和压缩这些浪费都没有提供很明确的实践方法。我们需要在日常研发过程中观察这些浪费现象进而找到消除和压缩实际研发过程浪费的工作方法。

    2. 精益中的管道管理

    在《敏捷软件开发工具》一书中推荐了一种简单的方法来帮助你找出浪费,这种方法就叫作价值流图(Value Stream Map)。跟其他精益技巧一样,价值流示意图源于制造业,但是它同样适用于软件团队,如图8-14所示的就是一个典型的价值流图。

    要想得到类似上图中的价值流图也比较简单,首先从团队已经开发并交付了的一个产品功能开始,回想这个功能单元从设想到交付经历了哪些步骤。在纸上为每一个步骤画一个方框,用箭头把各个方框连起来。接下来,估计一下完成第一步需要多少时间以及第一步完成后要等多长时间才能开始第二步。对每个步骤进行相同的估计,并且在方框的下方划线来表示工作和等待的时间。

    价值流示意图清晰地显示了该流程中涉及多少等待的时间,从团队开始改项目到最终交付,一共花了XX天。在这XX 天中,有XX天花在了等待而不是工作上。这些等待时间可能是多种原因导致的:需求文档可能需要很长时间才能送交所有的评审者;或者工时估计会议必须延后,因为大家已经有其他安排了等等。价值流示意图展示了对该特性的各种延迟所造成的累加效果,看到这种整体的影响,可以帮助你进一步探究哪些延迟是浪费,哪些是必要的。

    结合管道理论,实际上图中的每一个都可以看做是一个管道,所以价值流图就是各个管道的负载流转图。如果下一个管道处于等待上一个管道的结果,那么这个管道就处于空置状态,而如果某一个管道上的开发任务与其他管道上的开发任务比例严重不匹配,也就会导致因为管道之间数据流转不平衡导致浪费。我们可以经常看到开发过程中出现如下的不良现象:

    • 让每个人确认某规格文档要花很长时间,而与此同时开发人员则坐在那干等着项目开工。甫一开工,他们就已经落后进度了。
    • 开发到一半,开发团队意识到软件设计或架构的一个重要部分需要更改,但是这会导致非常严重的问题,因为有很多其他部分依赖它。
    • 质量控制团队要等到每一个特性都开发完毕才开始测试软件。质量控制团队发现了一个严重的bug 或者一个严重的性能问题,而开发团队不得不进行抢修。
    • 分析和设计花费的时间过长,导致进入编码阶段时,每个人都需要加班加点地赶工期。
    • 即使是对软件规格、文档或者计划的最小修改都需要经过一个冗长的修改控制流程。大家为了绕过该流程,于是甚至把大型的、颠覆式的修改都放到bug 跟踪系统里面。

    基于价值流图和管道理论,我们可以使用拉动式(Pull)系统帮助团队消除以上问题。所谓拉动式系统,指的是通过使用队列或缓冲区来消除约束的一种运作项目的方法或流程。它也源自日本的汽车制造业,但对于开发软件也非常有用,原因并不意外,跟它对制造业有用的原因相同。与其让用户、经理或者项目负责人把任务、特性、请求“推送”给开发团队,不如让他们把这些请求送入一个队列,由开发团队自己从该队列中拉取。当工作发生堆积并在项目中途导致分配不均衡时,他们可以创建一个缓冲区来解决。开发团队在整个项目中可能会用到好几个不同的队列和缓冲区。事实表明,这是一种减少等待时间、消除浪费的有效方法,同时也是帮助用户、经理、产品所有者和软件团队决定开发什么样软件的有效方法。

    下面我们举一个拉动式系统如何解决一个熟悉问题的例子:软件团队需要等待所有的特性都写入一个大型规格文档,而后者还必须要经过一个冗长的审核流程。或许该流程为的是征求每个人的意见;也许它不过是那些不敢真正承诺的老板或利益干系人的一种保护自己的手段;或者它干脆就是公司一直以来习惯的做事方法,从来没人想到它其实是一种浪费。如果我们用一个拉动式系统来替换它,会是个什么样子呢?

    建立一个拉动式系统的第一步是把工作分解成小型的、可供拉取的块。也就是说,不要编写一个大型的规格文档,而要把系统分解为最小可交付特性,比如一个个独立的用户故事,可能还有针对每个故事的少量文档。这些故事可以单独地进行审批。一般来讲,当一个规格文档审查流程长时间停滞不前时,原因通常是大家对某些特性有不同看法。对每个可交付特性进行单独的审批应该至少能够让一部分特性快速得到批准。只要有一个可交付特性通过了批准,开发团队就可以开始进入开发阶段。

    拉动式系统可以很好地消除工作的不均衡并防止团队的超负荷工作。上述关于拉动式系统的思想和做法体现的正是8.1.2节中介绍的管道负载分析方法,可以认为精益思想也是管理理论的一种具体表现形式。

    3. 识别浪费的其他方法

    除了价值流图,还有其他一些方法可以用于识别开发过程中的浪费:

    (1)项目输入过滤

    研发过程通常面向产品,而企业级应用或半互联网半企业级应用的产品最终通过项目进行实施和落地,这样项目线就成为研发过程的一个重要输入,而项目经理们站在项目线和客户的立场上提出来的需求和计划往往会和产品线、研发线有一定出入。如果本不应该进入研发环节的输入最终进入了研发环节就势必会导致浪费。如何通过规划和分析去把控来自项目上的输入,让项目线需求能够尽量和产品线一致是降低研发成本、消除浪费的一个重要方面,所以项目输入也是我们寻找浪费的一个来源。

    (2)会议聚焦

    我们不得不经常召开这种或那种会议,那开会是一种浪费吗?很多时候是的。会造成浪费的会议通常会有一些共性,典型的有:

    • 输入输出不明确
    • 缺少主持人或主持人不善于引导
    • 会议不是结果导向、无法形成有效决策
    • 会议议程空泛而不能收敛
    • 会议虽然能达成一致,但没有具体工作安排和责任人制度
    • 即使有工作安排但缺乏跟踪和监控机制
    • 会议相关的资料没有充分准备,也没有提前交付到参会人员

    具有上述特点的会议很大程度上不会有实质性的成果,开完一次之后还需要开第二次,如果把握不好浪费的不但是时间还是团队的气氛,需要进行分析和识别,看看我们每天的会议中是否具有以上问题。

    (3)数据传递有效性对比

    目前主流的研发管理方法论中普遍认为沟通和协作是研发成功的关键性因素,而沟通和协作的背后体现的实际上就是数据传递过程的有效性。如果有两个研发团队,其中一个团队中数据从团队中的一个人传递到另一个人的过程无论在时间上或空间上都比另一个团队有效,那两个团队的战斗力无疑是不一样的。数据传递在沟通模式、媒介、工具等各个方面都可能存在效率不高甚至不合理的地方,浪费也就在这些地方不断的滋长,从而消耗着研发团队的战斗力。

    (4)管理活动梳理

    有人说团队如果足够自组织(Self-Organization),那我们就不需要管理。这句话虽然听起来有一定道理,但未必太过虚无缥缈。但从管理工作本身入手分析其在工作流程、文档管理、任务分配等各个方面上是否存在冗余或者不合理的管理活动确实不失为一种识别浪费的实践。管理是需要成本的,管理做的好、做的精细更加需要成本,但管理过程本身也可能像代码一样需要随着研发过程和团队的演变不断进行重构,重构的前提也就是需要我们对管理活动进行分析和梳理,找出其中的浪费之处并进行消除或压缩。

    (5)流程执行力

    无论是好的管理模式和理念,还是适合团队的研发模型,要想取得令人满意的效果,归根揭底还是需要执行力。执行力来自很多方面,如合理的团队组织架构、优秀的人才、高效的工具、良好的团队气氛等,这些通常都不是技术所能起决定作用的领域,却实实在在影响着团队的执行力。流程本身可能是合适的,但因为执行的人不行、或因为工具使用不当导致效率降低,这通常都是属于无法避免但是需要进行压缩的浪费形式。

    通过识别,团队中的浪费现象已经摊在大家面前。其中有很大一部分的浪费属于存粹浪费,这些浪费需要通过一定的思路和工作模式进行消除;而对有些浪费通常是必要的,也是不可避免的,对这些浪费而言,我们的思路是尽量进行压缩。关于如何消除存粹的浪费以及如何如何压缩必要的浪费我们会另起一篇文章详细讨论。

     

    如果对文章感兴趣,可以关注我的微信公众号:程序员向架构师转型,或扫描下面的二维码。

    我出版了《系统架构设计:程序员向架构师转型之路》、《向技术管理者转型:软件开发人员跨越行业、技术、管理的转型思维与实践》、《微服务设计原理与架构》、《微服务架构实战》等书籍,并翻译有《深入RabbitMQ》和《Spring5响应式编程实战》,欢迎交流。

     

    展开全文
  • 敏捷软件开发工具——精益开发方法》 基本信息 作者: Mary Poppendieck Tom Poppendieck 译者: 朱崇高 出版社:清华大学出版社 ISBN:9787302078678 上架时间:2013-7-5 出版日期:2013 年7月 开本:16...
    《敏捷软件开发工具——精益开发方法》
    基本信息
    作者: Mary Poppendieck Tom Poppendieck
    译者: 朱崇高
    出版社:清华大学出版社
    ISBN:9787302078678
    上架时间:2013-7-5
    出版日期:2013 年7月
    开本:16开
    页码:168
    版次:1-2
    所属分类:计算机
    内容简介
    计算机书籍
      《敏捷软件开发工具——精益开发方法》特色:
       ·通过7个基本“精益”原则,并讲解了如何使其适用于软件开发领域。
       ·介绍22种“思考工具”,帮助您定制适合具体环境的敏捷实践。
       ·精益原则能帮助您通过迭代趋向完美:将软件开发看成一个不断探索的过程。
       ·精益原则能帮助您管理不确定性:通过将变更嵌入系统”尽量推迟决策”。
       ·精益原则能帮助您压缩价值流:快速开发、反馈和改进。
       ·精益原则能帮助您在保持协作的基础上授权团队和个人。
       ·精益原则能帮助您增强软件的完整性:提高一致性、可用性、可维护性和适应性。
       ·精益原则能帮助您着眼整体:解决开发人员分散多处的问题。
       精益思想已在制造、卫生保健和建筑等诸多行业取得了卓越的成效。敏捷软件开发更是让困境中的软件开发人员看到了曙光。本书揉合了两种思想的精髓,帮助读者将广为接受的精益原则转换为适应具体环境的敏捷实践,从而提高组织的软件开发能力。
       本书为软件开发领域的开发经理、项目经理和技术主管编写,为其提供了大量的实用技术和思考方法。
    目录
    《敏捷软件开发工具——精益开发方法》
    第1章 消除浪费
    1.1 精益思想的起源
    1.2 工具1:识别浪费
    1.3 工具2:价值流图
    1.4 实践
    第2章 增强学习
    2.1 软件开发的性质
    2.2 工具3:反馈
    2.3 工具4:迭代法
    2.4 工具5:同步
    2.5 工具6:基于集合的开发
    2.6 实践
    第3章 尽量推迟决策
    3.1 并发开发
    3.2 工具7:选择权思考
    3.3 工具8:最后负责时刻
    3.4 工具9:制定决策
    3.5 实践
    第4章 尽快交付
    .4.1 为什么要快速交付
    4.2 工具10:拉动系统
    4.3 工具11:排队理论
    4.4 工具12:延误成本
    4.5 实践
    第5章 授权团队
    5.1 超越科学管理
    5.2 工具13:自决权
    5.3 工具14:动机
    5.4 工具15:领导
    5.5 工具16:专业技能
    5.6 实践
    第6章 嵌入完整性
    6.1 完整性
    6.2 工具17:感知完整性
    6.3 工具18:概念完整性
    6.4 工具19:重构
    6.5 工具20:测试
    6.6 实践
    第7章 着眼整体
    7.1 系统思考
    7.2 工具21:度量
    7.3 工具22:合同
    7.4 实践
    第8章 说明和保证
    8.1 注意—按说明使用
    8.2 说明
    8.3 故障诊断指南
    8.4 保证
    图书信息来源:互动出版网

     

    展开全文
  • 广义而言,精益敏捷是两组具有高度兼容性的价值观和原则,都阐述了如何成功地进行产品开发。Scrum、XP和看板则是将这些原则运用到实践中的三种具体方法。换句话说,它们是精益敏捷软件开发里轻度重叠的三种不同...
  • 软件开发是一种非零和博弈,意思是某一方的获得不是建立在另一方的损失之上(赌 博就是一种零和博弈,获得和失去的总和等于零),所以软件开发必须实现双赢,[color=red]帮助客户成功的同时帮助自己成功[/color]。...
  •  精益敏捷开发以轻量级的文档与团队协作, 提高开发的效率◦ 另一方面, 许多人对于精益敏捷开发在轻量级的文档下, 如何保证开发的质量存在著许多的质疑与困惑◦  本文将从 “度量” 的角度, 运用一轻量级度量的...
  • 精益敏捷开发

    2014-11-16 20:26:56
    这是
  • 精益思想的核心 消除浪费——Eliminate Waste 嵌入质量——Build Quality In 创造知识——Create Knowledage 延迟决策——Defer Commitment ...精益敏捷软件开发的共同之处 目标都是要提高客户所感知到的...
  • 精益不了解, 敏捷开发则是一个到处都在谈论的话题, 我只是跳着看了一些在敏捷方面的做法和观点, 而且主要是scrum相关的, 当然本书的敏捷开发基本上可以等同于scrum. 算是增加了一层对scrum新的认识. 书不敢说是一...
  • 导读:精益求精是工匠精神实现的最佳方法,通过引入实践精益思想的原则和方法进行精益产品开发,打造对客户最好的产品进行交付,其次通过精益思想的理念降低企业的运营成本,提高企业的运营效率。阿里资深解决方案...
  •  本文主要探讨在产品外包的模式下, 精益敏捷开发如何能迅速, 有效的提升外包人员的能力◦   本文:  许多的产品当采用外包的开发模式时, 所面临的最大的挑战便是: 外包人员的能力, 素质参差不齐◦  精益敏捷...
  • 软件开发的基本步骤 需求分析编码 除了分析和编码之外,瀑布过程中的每一个步骤都是浪费 识别浪费 部分完成的工作【库存】 大量的需求和设计文档部分完成的软件 额外过程额外特性【生产过剩】任务调换...
  • 在几年前,我就对软件的敏捷开发有着很高的兴趣的。一直觉得,程序员应该是最自由,最轻松的一种职业!而且我也一直在向这个方向努力!我们应该如何做呢?一说到程序员,大家就公认的是脑力民工!为什么?在程序员...
  • 在 DevOps 的世界里,所犯下的最大的错误是:整天只知讲些文化、协作, 却完全将最重要、最关键,存储在 SVN, Git⋯内的开发人员的 “行为数据” 视而不见。在 DevOps 的世界里犯下这样的错误,将使得团队白白的耗费...
  • 敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流,往小了说是改进了开发方法,往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。我们使用 tapd 写 feature,流转、跟踪任务...
  • 读书笔记--精益敏捷开发大型项目应用指南>   【摘要】 3月份的时候,根据教练和其他多为项目经理的推荐,开始阅读这本书;本书共三大部分、12个章节,第一部分:思考工具,第二部分:组织工具;第三部分...
1 2 3 4 5 ... 20
收藏数 7,656
精华内容 3,062
关键字:

敏捷开发是什么意思 精益