2019-12-02 19:51:59 feiyangyang980 阅读数 16
  • 产品研发敏捷统一过程2.0

    产品研发敏捷统一过程2.0视频教程,该课程介绍一种极轻量级又能涵盖整个产品研发生命周期的敏捷开发框架,包含了产品创新、敏捷需求建模与分析(QUML)、精益创业、Scrum等体系,全程无缝连接。 讲师介绍:陈勇,IIOM(无锡英特奥盟科技有限公司)CTO/CIO/技术副总裁/总工程师。

    7019 人正在学习 去看看 CSDN讲师

精益开发

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

概述

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

精益开发的基本原则

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

对原则的理解

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

2011-08-02 21:48:29 iteye_14294 阅读数 181
  • 产品研发敏捷统一过程2.0

    产品研发敏捷统一过程2.0视频教程,该课程介绍一种极轻量级又能涵盖整个产品研发生命周期的敏捷开发框架,包含了产品创新、敏捷需求建模与分析(QUML)、精益创业、Scrum等体系,全程无缝连接。 讲师介绍:陈勇,IIOM(无锡英特奥盟科技有限公司)CTO/CIO/技术副总裁/总工程师。

    7019 人正在学习 去看看 CSDN讲师
[align=center][img]http://img3.douban.com/lpic/s4085157.jpg[/img][/align]
对精益不了解, 敏捷开发则是一个到处都在谈论的话题, 我只是跳着看了一些在敏捷方面的做法和观点, 而且主要是scrum相关的, 当然本书的敏捷开发基本上可以等同于scrum. 算是增加了一层对scrum新的认识. 书不敢说是一本好书, 只能各取所需吧.


======================我是读书笔记的分割线==================

如果在同一个办公区域, 你记不清所有人的名字, 那么这就是一个大型团队了

产生非最佳决策的原因是错误的假设和不充分的理由

守破离法则
第一步, 守, 遵守规则直到充分并将其视为习惯性的事.
第二步, 破, 对规则进行反思, 寻找规则的例外并"打破"规则.
第三步, 离, 在精通规则之后就会基本脱离规则, 抓住精髓和深层能量.

团队定期反思如何使自己变得更高效, 然后根据反思结果调整行动.

5个为什么: 帮助培养解决问题和分析根源的能力.

问题:开发人员没有进行代码重构来保证代码的可维护性
为什么? 我们对加快工作速度感到有压力
为什么有压力? 因为我们工作速度慢
为什么工作速度慢? 因为代码很复杂, 很难开展工作.
....

在scrum中, 优先准则是选择可以提前实现和测试那些具有不确定性或有风险的事物. 因为不可预测的事物可测试性比较低, 所以反馈的价值比较高.可预测的事物不能给我们带来更多的经验.

工作有节奏可以提高预测, 计划和协调的能力.

scrum:五项价值
承诺:愿意对目标做出承诺
scrum的根源是自组织的团队, 在sprint计划会议上, 团队自己从产品负责人给出的清单中, 选出要做的事情. 没有一项工作是强加给团队的, 没有一个团队被告知要怎么做事. 这样才能做到真正的承诺, 如果你自己可以决定, 在两周或者4周的迭代中能够合情合理的做完哪些工作, 如果你自己能决定完成这些工作, 你才会更愿意做出承诺, 也才能有能力实现诺言

专注:做你的工作, 把你的心思和能力都用到你所承诺的工作上去, 不管任何其他的东西.
不完全参与意味着不完整的结果

开放:scurm把项目中的一切都开放给每一个人看.scrum不存在秘密会议或是隐蔽的项目管理信息.

尊重:每个人都有他独特的背景和经验, 我们应当尊重组成这个团队不同的个体.
它要求团队有一个共同的, 清晰的目标(当前迭代要完成的特性);

勇气: 有勇气行使scrum的规则去改变组织, 或者是一个自组织团队发挥自己的主动权. 不管是个人工作还是团队工作将要前功尽弃的时候, 要有勇气把现状完全公开.

scrum团队成员除了"团队成员"之外没有其他特别的称谓. 团队中不会强调"开发人员"跟"测试人员"称呼上的不同. 团队的目标是鼓励团队学习更多的技能和"整个团队进行完整特性的开发."

如果没有接触过大量不同的代码, 这就会阻止他们学习优秀设计的机会

当我们每时每刻看到这种复杂模糊的1万多行的代码时, 它们开始很自然地变得熟悉和"清楚", 由于长期的接触, 你就不觉得它们有多复杂, 也不会因此一筹莫展, 更没有想深入改进它们的动力

对卓越技术和良好设计的不断追求将有助于增强敏捷能力.

无法排除障碍的最常见的原因是"这是我们一直以来的工作方式", "我们不会改变的, 我们已经投入很多"

scrum是揭露组织问题的简易框架

scrum是理解容易但很难使用的实践方法, 因为它使组织的所有弱点彻底曝光.

好的想法和建议随着开发的进展不断涌现, 如果整个开发过程不允许变化的产生, 那么将会遏制创新.

scrummaster帮助产品团队学习和应用scrum以获得商业价值.

scrum会使许多干扰团队与产品负责人效率的障碍和危险呈现出来, 这就需要由ScrumMaster全心全意协助铲除这些障碍, 否则团队或产品负责人将会感觉到取得成功非常难.

优秀的ScrumMaster可以从任何背景和学科产生出来.

与项目经理不同, ScrumMaster不是简单的分配工作, 他们协助过程顺利进行, 并支持团队自组织和自管理.

scrum重要实践原则: 团队决定承诺完成多少任务, 而不是产品负责人安排工作, 这就使得任务的交付更可靠, 团队根据自己的分析和计划来承诺工作量, 而不是其他人"安排"交给他们的工作量

每日例会不是向经理汇报工作进度, 而是自组织的团队互相交流, 某位团队成员会将障碍内容记录下来, ScrumMaster负责协助团队铲除障碍

每日例会不允许讨论

通常最好不允许经理或其他管理层参加每日例会, 这样使团队感受到"被监控", 在压力下汇报每日的进程, 而且抑制了问题的汇报. 这些会消弱团队的自组织能力. 如果能协助团队解决问题, 那么参加会议会更有意义.

如果在sprint计划会议中还包含很多问题, 疑惑, 新的发现, 就说明团队没有进行提炼研讨会(或者会议没有达到目的)

scrum的核心原则之一是sprint的周期不可以延长: 它结束于指定时间, 不论团队是否完成承诺的任务.

固定的周期可以帮助团队了解他们的实际工作效率, 以便进行正确的估算和制定长期的发布计划. 同时也可以帮助团队保持工作节奏.

scrum要求准备演示的时间不超过30分钟, 否则就说明团队的工作出了问题.

scrum回顾会议的最简单方法就是在白板上画出两栏: 分别注明"哪些工作顺利", "哪些工作可以做的更好", 然后让与会者轮流在每一栏下添加条目. 当出现重复条目时, 可以在该条目旁边记正字累计. 并计划在下一个sprint中尝试少量的变更, 改进, 并在下一个sprint回顾会议上评审结果.

彻底解决问题的第一步就是让问题显现出来, scrum对此正是有强大的促进作用.

产品负责人和团队应该在每个sprint都进行产品待办事项列表的提炼, 从而不断的为未来工作做准备.

没有人可以预知未来, 因此工作的重点就应该放在创建和调整计划上来, 以给予发布一个总的方向, 并明确如何对决策做出权衡(范围vs.计划).

scrum并不解决实际问题, 它只是使问题显现出来, 并提供人们以短周期和小范围改进尝试来探求解决问题的框架.

一个错误的做法: 让scrum挑战团队固有习惯的时候, 他们会改变scrum, 而不是改变自身的问题.
2019-08-11 18:22:09 lantian08251 阅读数 100
  • 产品研发敏捷统一过程2.0

    产品研发敏捷统一过程2.0视频教程,该课程介绍一种极轻量级又能涵盖整个产品研发生命周期的敏捷开发框架,包含了产品创新、敏捷需求建模与分析(QUML)、精益创业、Scrum等体系,全程无缝连接。 讲师介绍:陈勇,IIOM(无锡英特奥盟科技有限公司)CTO/CIO/技术副总裁/总工程师。

    7019 人正在学习 去看看 CSDN讲师

精益(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响应式编程实战》,欢迎交流。

 

2016-07-08 09:06:40 zhangmike 阅读数 7839
  • 产品研发敏捷统一过程2.0

    产品研发敏捷统一过程2.0视频教程,该课程介绍一种极轻量级又能涵盖整个产品研发生命周期的敏捷开发框架,包含了产品创新、敏捷需求建模与分析(QUML)、精益创业、Scrum等体系,全程无缝连接。 讲师介绍:陈勇,IIOM(无锡英特奥盟科技有限公司)CTO/CIO/技术副总裁/总工程师。

    7019 人正在学习 去看看 CSDN讲师

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是他的微博昵称。

2014-04-19 09:02:40 u011790275 阅读数 1479
  • 产品研发敏捷统一过程2.0

    产品研发敏捷统一过程2.0视频教程,该课程介绍一种极轻量级又能涵盖整个产品研发生命周期的敏捷开发框架,包含了产品创新、敏捷需求建模与分析(QUML)、精益创业、Scrum等体系,全程无缝连接。 讲师介绍:陈勇,IIOM(无锡英特奥盟科技有限公司)CTO/CIO/技术副总裁/总工程师。

    7019 人正在学习 去看看 CSDN讲师

2016, 深圳, Ken Fang 


前言:

   精益敏捷开发以轻量级的文档与团队协作, 提高开发的效率。另一方面, 许多人对于精益敏捷开发在轻量级的文档下, 如何保证开发的质量存在著许多的质疑与困惑。

   本文将从 “度量” 的角度, 运用一轻量级度量的方式, 确保团队在精益敏捷开发的过程中, 可同时确保效率与质量。

 

本文:

   此轻量级的度量方式主要的目的是希望: 通过度量驱动团队去做该做的事; 包括:测试用例先行, 逐步提升效率, 同时兼顾效率与产品质量。

1)      测试用例先行 (流程指标)

精益敏捷开发, 期望以表格式的测试用例, 使开发人员可清楚的明白到底要开发什么? 避免开发人员在不完全理解 User Story 的需求或是 User Story 需求不明确的情况下, 进行无谓的开发, 形成不必要的浪费。

所以, 必需经由度量 “开发前测试用例覆盖率”, 以驱动团队需先有测试用例再进行开发。

开发前测试用例覆盖率开发前已有测试用例的 User Story总数 / User Story总数 

另一方面, 为避免测试用例的设计会形成版本开发的瓶颈, 所以, 必需经由度量 “测试用例设计平均人天”, 以驱动团队提升设计测试用例的效率。

测试用例设计平均人天测试用例设计总人天 / 测试用例总数


2)      逐步提升效率 (效率指标)

精益敏捷开发, 团队的效率并不能仅从 User Story 开发的速度来衡量。因为, 仅提升 User Story 开发的速度, 并无法保证版本的整体开发效率的提升。 为何?

当团队的 Sprint Backlog 中代办事项 (User Stories) 的工作量, 远远超出团队所能负荷的工作量时, 则即使 User Story 的开发速度提高了, 但, 也会因各 Sprint 的工作量过重, 而使团队在各 Sprint 中, 能完成所有 User Stories 开发与测试的时间, 依旧会过长, 因而, 导致版本的整体效率无法提升。

精益敏捷开发是以 “平均等待时间 (平均处理周期)” 来衡量开发的效率, 且同时衡量:

1)     Sprint Backlog 的 User Story 数 (工作量)

2)     User Story 开发, 测试的速度

 平均等待时间  Sprint Backlog  User Story数目 / 每周平均可完成 User Story 的数目 (完成是指开发测试完成)

举例: Sprint Backlog 的 User Story 数目: 30

            某团队每周平均可完成开发, 测试的 User Stories 数目: 15

            平均等待时间: 30/15 = 2 周

所以, “平均等待时间” 便会驱动项目经理要逐步提升效率时; 降低平均等待时间; 除了需提升团队的开发, 测试效率外, 更重要的是, Sprint Backlog 中代办事项 (User Stories) 的工作量 (数目) 需合理化。


3) 同时兼顾效率与产品质量 (质量指标)

   精益敏捷开发的质量指标, 主要是以 “缺陷” 驱动团队的开发质量与测试效率。

I.           开发质量:

              i.  平均多长时间可修复一个新的缺陷:驱动开发人员不可只开发新需求的 User Stories, 而忽视或不处理缺陷的 User Stories。

              ii.   缺陷重新被激活总数目: 缺陷重新被激活指的是开发人员将一缺陷标记为 "已解决", 但实际上并未解决根本, 真正的问题。 缺陷重新被激活总数目, 可驱动开发人员真正针对造成缺陷的根因去解决问题。

II.         测试效率:

             i.  平均多长时间可发现一个新的缺陷:驱动测试人员提升自动化测试与手工测试的效率。唯有测试效率提升了, 产品质量方能获得保证。

 

结论:

  精益敏捷开发的度量指标主要目的是希望, 项目经理不要再追求浮而不实的表象数据, 而能真正经由轻量级的度量指标, 做好 “数据管理”, 驱动团队去做真正该做的事。

如何理解敏捷开发

阅读数 169

没有更多推荐了,返回首页