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

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

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

精益开发

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

概述

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

精益开发的基本原则

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

对原则的理解

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

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

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

    7009 人正在学习 去看看 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, 而不是改变自身的问题.
2014-04-19 09:02:40 u011790275 阅读数 1477
  • 产品研发敏捷统一过程2.0

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

    7009 人正在学习 去看看 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.  平均多长时间可发现一个新的缺陷:驱动测试人员提升自动化测试与手工测试的效率。唯有测试效率提升了, 产品质量方能获得保证。

 

结论:

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

2019-08-11 18:22:09 lantian08251 阅读数 97
  • 产品研发敏捷统一过程2.0

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

    7009 人正在学习 去看看 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响应式编程实战》,欢迎交流。

 

2019-03-05 10:57:48 weixin_39835036 阅读数 223
  • 产品研发敏捷统一过程2.0

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

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

广义而言,精益与敏捷是两组具有高度兼容性的价值观和原则,都阐述了如何成功地进行产品开发。Scrum、XP和看板则是将这些原则运用到实践中的三种具体方法。换句话说,它们是精益和敏捷软件开发里轻度重叠的三种不同风格。

精益与敏捷软件开发概述

 

Scrum、XP和看板都有很具体的技术,如Sprint规划会议(Scrum)、结对编程(XP)和限定在制品(看板)。这些技术都可视作流程工具。这三种工具的功能都有相当程度的重叠,例如,三种工具都建议使用真实的任务板将当前工作以可视化方式展现出来。

1、敏捷软件开发(Agile Software Development)

出现于2001年。当时,来自软件开发界的十七位思想领袖聚集在美国犹他州的一个滑雪度假胜地,探讨软件开发如何取得成功。研讨会期间,他们总结出一些强大的共同观点,形成了软件开发如何成功的共有愿景,即后来人们熟知的《敏捷宣言》 。

精益与敏捷软件开发概述

 

《敏捷宣言》内容如下:

我们正在通过亲身实践以及帮助他人实践,探寻更好的软件开发方法。通过这项工作,我们建立了如下价值观:

  • 个体和互动胜过流程和工具。
  • 可以工作的软件胜过详尽的文档。
  • 客户合作胜过合同谈判。
  • 响应变化胜过遵循计划。

也就是说,虽然右项也具有其价值,但我们认为左项具有更大的价值。

研讨会结束后,他们就支撑这些价值观的以下十二条原则达成共识:

  1. 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
  2. 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,要通过敏捷过程掌控变化。
  3. 经常地交付可工作的软件,比如相隔几星期或一两个月就交付,倾向于采取较短的周期。
  4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  5. 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  6. 不论团队内外,传递信息效果最好、效率也最高的方式是面对面的交谈。
  7. 可工作的软件是进度的首要度量标准。
  8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
  9. 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
  10. 以简洁为本,它是极力减少不必要工作量的艺术。
  11. 最好的架构、需求和设计出自自组织团队。
  12. 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

虽然敏捷一词正式出现于2001年,但多数敏捷方法都是在20世纪80年代到90年代形成的。敏捷只是一个描述了共同特征的统称。凡遵循上述价值观和原则的方法或方式都可视为敏捷方法。

2、精益概述

精益起源于日本丰田公司的“TPS”(丰田生产方式),即助力丰田成为全球最成功汽车制造商的生产方式。实践证明,TPS的基本原则“丰田之道”几乎适用于所有行业,包括软件开发。

敏捷与精益可以看作是一对拥有共同价值观但起源不同的兄弟。精益起源于制造业,敏捷起源于软件开发。两组原则都能与对方完美契合,而且适用范围都非常广泛。越来越多的软件开发组织在探索如何将两组原则完美结合,从而应用于从产品创意到交付的完整开发链。

1)全局优化

局部的优化长期来说,会对系统整体优化不利。

  • 专注于整体价值流:从概念到现金。从客户需求到软件部署。
  • 交付完整产品:客户不要软件产品,他们要解决问题。完整的解决方案是由完整的团队构建的。
  • 着眼长期:警惕导致短期思维和优化局部业绩的治理和激励体系。

2)消灭浪费

浪费指所有那些不能增加客户价值的事项。软件开发中的三大浪费如下:

  • 构建错误的功能:“没有什么比高效完成根本不应做的工作更无用。”
  • 拒绝学习:我们有很多策略都干扰了我们学习,例如,只按计划行事、频繁移交、决策与工作分离等,而学习则是开发的精髓。
  • 辗转现象:那些干扰价值顺利流动的做法,例如,任务切换、请求清单冗长、大堆未完成的工作等等,都只能达到事倍功半的效果。

3)品质为先

如果在验证过程中总是能发现缺陷,那流程就有问题。

  • 最终验证不应发现缺陷:所有软件开发流程的根本目的都是尽早在开发阶段发现并修复缺陷。
  • 采用测试先行的开发模式让流程具有防误机制:测试(包括单元测试、端对端测试和集成测试)必不可少,以此建立信心,保证系统在任何层次、在开发阶段任何时间点都始终正确无误。
  • 打破依赖:系统架构应当支持随时添加功能。

4)不断学习

规划工作非常有用。学习则必不可少。

  • 可预测的性能来自于反馈:可预测的组织不会猜测未来并称之为计划;反之,他们会培养能力对未来做出响应。
  • 保持选择方案:视代码为实验——使其具有容变性。
  • 最后可靠时刻:在做出不可逆转的决策之前尽可能学习。不要提前做出纠正代价高昂的决策,也不要事后才做出决定!

5)尽快交付

从一开始就深入了解所有干系人看重的价值。然后基于这样深入了解的价值观,创建稳定、连贯的工作流。

  • 快速交付、高质量和低成本是完全相互兼容的:以速度竞争见长的公司拥有很高的成本优势,他们可以交付优质的产品,而且对客户需求更为敏感。
  • 排队理论同样适用于开发,而不仅仅是服务行业:专注于使用性会造成交通堵塞,反而降低了使用性。以较小的批量、限制同时进行的工作数来缩短周期时间。大力限制等待清单和队列的长度。
  • 管理工作流比管理进度表要容易得多:建立可靠、可预测交付物的最佳方式是通过迭代和看板建立可靠、可重复的工作流。

6)人人参与

聪明、有创造力的人员的时间与精力,是当代经济的稀有资源和竞争优势的基础。

获得公正薪资的人员在自主性、成长性和使命感等方面受到激励。

  • 自主性:最有效的工作小组是半自治团队,有一个内部主管从头到尾负责完整、有意义的任务。
  • 成长性:对人员的尊重意味着提供挑战、反馈和让所有人都能够发挥潜能、表现卓越的良好环境。
  • 使命感:将工作与价值挂钩。只有相信自己工作的意义,团队成员才会全心投入工作,实现这种使命。

7)不断提高

结果不是重点——重点是培养人、发展体制,使之能够交付结果。

  • 失败是个学习机会:即使是非常小的失败都会被深入调查并纠正的,做到一丝不苟的时候,才可能获得最可靠的性能。
  • 标准存在的目的就是要被质疑和提高的:将现行的、最知名的做法纳入人人都遵循的标准,与此同时鼓励所有人质疑并改变标准。
  • 使用科学方法:教团队建立假设、开展大量快速实验、创建简明文档并实施最佳方案。

3、Scrum概述

Scrum是由杰夫•萨瑟兰(Jeff Sutherland)和肯•施瓦伯(Ken Schwaber)于20世纪90年代早期共同创建的一种软件开发过程。Scrum核心内容如下:

1)按优先顺序排列的产品需求清单

将产品分割成一组小而具体的可交付物,即产品需求清单。产品负责人对产品愿景进行定义,并按商业价值以及风险和依赖关系等其他因素对需求清单进行排序。

精益与敏捷软件开发概述

 

2)跨职能团队

将产品所有人员划分为多个小规模、跨职能、自组织的开发团队。每个团队都有一位产品负责人负责定义愿景和总体的业务优先顺序,以及一位Scrum大师专注于改进团队、消除障碍。

精益与敏捷软件开发概述

 

3)Sprint

将整个开发时间划分成多个短小的、固定的迭代周期或Sprint(通常为两周或三周)。开发团队自行决定每个迭代周期要完成多少个产品需求清单项。每个迭代周期最后都要演示已通过测试、能够发布的版本。

精益与敏捷软件开发概述

 

4)持续调整版本发布计划

产品负责人与客户一起合作,在每个迭代周期之后仔细检查发布版本,根据所得的结果,不断优化版本发布计划,并更新优先排序。

5)持续调整流程

开发团队通过每个迭代周期之后的回顾会议不断优化开发流程。所以,Scrum开发模式意味着:不是由一个大团队用很长的时间来开发一个大产品……而是由一个小团队用很短的时间来开发一个小功能。但定期集成,以构成整体。Scrum模式不会硬性规定任何具体的工程实践——这些都由团队自行决定。不过,在实践中,不纳入XP的核心工程实践而通过Scrum模式取得成功是非常困难的。

4、XP概述

极限编程(XP)是肯特•贝克(Kent Beck)于20世纪90年代中期创立的软件开发方法。该方法以简洁、沟通、反馈、勇气和尊重等价值观为基础。XP方法是与Scrum并行发展的,实际上包含了大多数相同要素。例如,XP中的现场客户(on-site customer)就大致等同于Scrum中的产品负责人(product owner)。

精益与敏捷软件开发概述

 

从这个意义上而言,Scrum可被视作XP的“包装纸”,专注于结构问题和外部沟通。而XP除多数理念都与Scrum相同以外,还增加了一些团队内部的工程实践,包括以下内容:

  • 持续集成:拥有一个随着团队的开发可自动编译、集成并测试代码的系统。这样就能尽早为开发团队提供有关产品质量方面的反馈。
  • 结对编程:在一台工作站上进行结对编程,从而使学习效果最大化、设计质量最大化、缺陷最小化。
  • 测试驱动开发:采用测试代码驱动系统的设计。编写自动化测试脚本,然后编写刚刚足够的代码以使其通过测试,然后从根本上重构代码,提高其可读性,移除重复代码。清理并重复这一过程。
  • 集体代码所有权:允许(实际上是鼓励)开发团队的任何人编辑代码库的任何部分。这样可营造出团队所有权的意识,确保整个系统的设计都一致、易于理解。
  • 增量式设计改进:从最简单的设计开始,然后运用重构等技术持续不断地改进设计,而不是从一开始就做好完整的设计。

上述许多实践都互为基础。例如,如果系统的自动化测试覆盖范围不足,那增量式设计改进就很难实现、令人生畏且风险很高,而若要测试覆盖范围足够,则需要通过测试驱动开发和结对编程才可实现。不过,如果所有的测试都必须手动触发,而且只能在开发人员的本地工作站上运行,问题就会让人更头痛,所以,我们就需要一个持续集成系统在后台自动完成上述工作,等等。

5、看板概述

看板是敏捷软件开发的精益方法。实际上,看板有着多方面的意义。从字面上看,看板是日语单词,是“可视卡片”(或标志)的意思。在丰田,看板专指将整个精益生产系统连接在一起的可视化物理信号系统。看板的规则很简单。不过,跟象棋一样,规则简单并不意味着游戏简单。

可视化工作流:把产品切分成小块,将每一块写在一张卡片上,然后将卡片贴到墙上。墙上的每一栏都有名称,以此显示每张卡片在工作流中所处的位置。

精益与敏捷软件开发概述

 

这就基本上直接实施了精益拉式生产调度系统。Scrum专注于结构和沟通,XP增加了工程实践,看板则专注于将工作流可视化,并对瓶颈进行管理。

如何理解敏捷开发

阅读数 168

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