敏捷培训总结 第1篇
【要点】理解精益思想,理解敏捷思想、价值观、原则及若干实践
精益思想(Lean Thinking)源于20世纪80年代日本丰田发明的精益生产(Lean Production)方式。
以丰田的大野耐一等人为代表的精益生产的创始者们,在不断探索之后,终于找到了一套适合日本国情的汽车生产方式:及时制生产、全面质量管理、并行工程、充分协作的团队工作方式和集成的供应链关系管理,逐步创立了独特的多品种、小批量、高质量和低消耗的精益生产方法。
什么是精益管理?精益企业到底是怎样的面貌呢?xxx·沃麦克(James Womack)和xxx·琼斯(Daniel Jones)在他们精辟的著作《精益思想》中提炼出精益管理五原则,顾客确定价值(Customervalue)、识别价值流(Value stream mapping)、价值流动(Value flow)、拉动(Pulling)、尽善尽美(Perfection)。精益管理的核心思想可概括为消除浪费、创造价值。
精益管理是精益生产理论的扩展,是精益思想在企业各层面的深入应用,精益管理是以精益思想为指导、以持续追求浪费最小、价值最大的生产方式和工作方式为目标的管理模式。
精益思想的核心就是(消除浪费)以越来越少的投入——较少的人力、较少的设备、较短的时间和较小的场地创造出尽可能多的价值;同时也越来越接近用户,提供他们确实要的东西。精确地定义价值是精益思想关键性的第一步;确定每个产品(或在某些情况下确定每一产品系列)的全部价值流是精益思想的第二步;紧接着就是要使保留下来的、创造价值的各个步骤流动起来,使需要若干天才能办完的订货手续,在几小时内办完,使传统的物资生产完成时间由几个月或几周减少到几天或几分钟;随后就要及时跟上不断变化着的顾客需求,因为一旦具备了在用户真正需要的时候就能设计、安排生产和制造出用户真正需要的产品的能力,就意味着可以抛开销售,直接按用户告知的实际要求进行生产,这就是说,可以按用户需要拉动产品,而不是把用户不想要的产品硬推给用户。
精益原则:根据客户需求,重新定义价值;识别价值流,重新制定企业活动;使价值流动起来;依靠客户需求拉动价值流;不断改善,追求尽善尽美。
从推动式系统转向拉动式系统:
拉动系统避免了浪费,对客户需求的响应很灵活。那么作为上游的部分,什么时候来生产,生产多少呢?这就是个问题了。看板是为了达到JIT准时生产方式而控制现场生产流程的工具。
拉动价值:客户拉动层层传递到最底层供应商,实现恰好够用的生产。按用户需要拉动产品,而不是把用户不想要的产品硬推给用户。
精益思想屋:
精益屋屋顶介绍的就是我们为什么做精益,精益的出发点是什么? 出发点是:成本要低一点、质量要好一点、交货期要短一点、现金要充足一点、安全系数要高一点。 精益思想是由4个基础组成:第一标准化作业,第二均衡生产,第三持续改进,第四到现场,因为现场是创造价值的地方,发生问题的地方,我们的管理者、做精益的员工,都要在第一线。这个屋子有两个支柱:一个叫准时化、一个叫自动化,在这两个大字下有很多的工具和方法,举例说5S、安灯系统。精益有三层含义,什么是精益?精益的第一层含义就是发现浪费,分析产生浪费的原因,然后采取措施来减少甚至消除浪费,因此精益是关于浪费的;精益的第二层含义是关于价值,就是创造价值,通过提高质量、降低成本、提升利润、缩短交货期,来给市场、给社会,给员工创造更多的价值;精益的第三层含义,讲的是文化,精益讲究的是实事求是,就是从流程上持续改善,讲究的是尊重客户、尊重员工,这是非常重要的一点,叫文化。
精益的八种浪费:
1.生产过剩(Overproduction):生产出尚未有订单的项目,造成人员过多和过多存货导致的储存与输送等成本的浪费。
2.在现场等候的时间(Waiting):员工只是在一旁监看自动化机器,或必须站在一旁等候下一个处理步骤、工具、供应、零部件,等等,或是因为存货用完、整批处理延迟、机器设备停工、产能瓶颈等因素造成员工暂时没有工作可做。
3.不必要的运输(Transportation):长距离搬运在制品;缺乏效率的运输;进出仓库或在流程之间搬运原物料、零件或最终成品。
4.过度处理或不正确的处理(Extra-Processing):采取不必要的步骤以处理零部件;因为工具与产品设计不良,导致不必要的动作及产生瑕疵而造成缺乏效率的处理;当提供超出必要的较高质量产品时,也会造成浪费。
5.存货过剩(Inventory):过多原料、在制品或最终成品,导致较长的前置期、陈旧过时品、毁损品、运输与储存成本及延迟。此外,过多存货还会造成其他隐性问题,如生产不均衡、供应者延迟递送、次品率上升、机器设备停工、拉长整备期(setup time)。
6.不必要的移动搬运(Motion):员工在执行工作的过程中,任何浪费、不必要的动作,如寻找、前往取得,或是堆放零部件、工具等。此外,走动也是浪费。
7.瑕疵(Defects):生产出次品或必须修改的东西、修理或重做、报废、更换生产、检验等,意味着成本、时间与精力的浪费。
8.未被使用的员工创造力(Non-Utilized Talent):由于未使员工参与投入或未能倾听员工意见而造成未能善用员工的时间、构想、技能,使员工失去改善与学习机会。
批量大小:
精益、敏捷与看板:
精益思想是一个超集,看板方法是用于管理软件开发流程的新技术。看板方法源自丰田的“及时生产”(JIT=just-in-time)系统(在前文中我对JIT解释如下:Just-In-Time努力将生产过程中每一步的库存量尽量降到最低,最好为0。换句话说,这意味着只需要在合适的时间、合适的地点,提供适量的原材料。去除库存带来很多好处:不仅可以节省成本,还去除了商品被废弃或者损坏,久置的可能性。)
敏捷诞生的历史背景:
敏捷方式可以追溯到1620年Francis Bacon科学方法的发源时期。更合理一点的起点可能是在20世纪30年代,那时候贝尔实验室的物理学家和统计学家 Walter Shewhart开始使用计划-执行-研究-检查(PDSA)循环对产品和过程进行改善。Shewhart把这种反复渐进的开发过程教给了他的学员xxx( Deming), 后者在二次大战后的日本大量使用了该方法。丰田公司雇用了xxx来培训公司中数百名经理。最后在他的经验之上创立了著名的丰田生产体系——这也是如今”精益“思想的最初由来。这种反复渐进的方式对于20世纪50年代的X-15 超音速飞机的制造也是贡献巨大。
2001年雪鸟会议,敏捷概念的提出:
2001年2月,Martin Fowler,Jim Highsmith等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地,举行了一次敏捷方法发起者和实践者的聚会。在这次会议上面,他们正式提出了Agile(敏捷开发)这个概念,并共同签署了《敏捷宣言》。
虽然Agile的概念是在2001年被提出,但这并不等于敏捷开发实践是在2001年才被提出。雪鸟会议是对之前几十年中软件开发实践探索的总结,是水到渠成的一个结果。
敏捷开发前后的历史:
csdn整理了一篇文章,比较系统的介绍了敏捷开发前后的历史,可以参考:《 敏捷十年简史回顾——影响敏捷开发历程的27件事(精美大图)》。在此摘录片段:
>> 1991年,DeGrace和Stahl在《Wicked Problems, Righteous Solutions》一文中将所谓整体方法命名为Scrum。
>> 1995年,在OOPSLA‘95 会议上,Sutherland和Schwaber共同发表论文介绍Scrum方法。
>> 1997年,Alistair Cockburn提出Crystal方法。
>> 1996年,Martin Fowler,Kent Beck,Ward Cunmingham将XP方法引入C3项目,是第一个被正式的XP项目。
>> 1998年,Jeff DeLuca正式提出FDD方法。
敏捷从根本上来说是一种思维模式,由价值观来定义,受一系列原则的指引,通过许多不同的实践得以实施。敏捷实践者基于他/她们的特定需要,来选择适合的实践。
敏捷宣言(Agile Manifesto)
敏捷宣言( 2001年)是敏捷起源的基础,由上述4个简单的价值观组成,敏捷宣言的签署推动了敏捷运动。
敏捷宣言本质是揭示一种更好的软件开发方式,启迪人们重新思考软件开发中的价值和如何更好的工作。
敏捷宣言中包含的若干原则( 12 Principles ):
除了《敏捷软件开发宣言》内所提到的价值观和原则以外,敏捷开发并没有一个完整的方法列表,因为所有的敏捷开发方法都是广大开发人员在日常的工作中摸索出来的,针对某种特定场景适用的方法。也就是说,以下所列出的敏捷开发方法并不一定适用于你的团队或者你的问题,但是敏捷鼓励所有人按照自己的方式尝试任何的方法,只要这种方法遵循以上价值观和原则,那么它就是一种敏捷方法。
对敏捷的常见误解:
统一对敏捷的认识:
敏捷培训总结 第2篇
团队:协同、高绩效、Backlog(积压项)、方法论、模型、高效沟通(内四外八+五问法)
项目规模:依赖于产品需求的描述详细程度
①FPA法
②ISO IFPGU(FPA国际化标准)
③ISO COSMIC
④COCOMO ii(成本构造估算法)
⑤UCP法(立足于UseCaseModel)
敏捷项目计划(Sprint Backlog)
甘特图、故事列表、估算工具、时间粒度(正向法、倒推法)、小组模型、风险计划、交付物计划、质量计划
项目管控中搭建“反馈渠道”
面对面沟通、执行任务前确认、个人执行计划
计划会议、估算会议、站会、评审会、回顾会议(总结会)
项目任务执行
看板管理:公信力任务、可比性任务、任务绩效落差、任务卡片...
敏捷培训总结 第3篇
Sprint Backlog( 迭代待办事项列表)即此次冲刺周期内规划要完成的内容。 Product Backlog在得到了PO和团队的认可后会交付给团队进行开发,就变成了sprint backlog,这个过程可能很复杂(比如包含多层分解、涉及多个子产品/组件、多个团队协作),也可能很简单;转换成sprint backlog的过程一般还包括了任务分解和工期估算的工作内容。
敏捷培训总结 第4篇
产品经理:产品构想》论证》定义产品》联合Master研发产品》联合市场销售卖给客户》联合产品售后服务》产品运营数据分析
产品分析模型
①IBM差异化模型
②价值工程模型(产品成本价值分析)
③波特价值链、企业价值链模型(过程工艺竞争力)
④产品多层次市场模型、xxx市场价值模型
⑤客户满意度模型、KANO模型
⑥SWOT模型、矩阵表决策
⑦竞品分析模型(技术+功能+体验)
⑧波特五力模型、竞争力模型
产品工作流程
想法(期望、痛点、需求)->EPIC(商业+市场+用户+社会价值)->Feature(产品用户领域范围、模型定义、故事价值排序、版本发布计划、故事分组)->用户故事地图->ATDD(验收测试驱动、验收标准)->Given-When-and-then(逻辑路径分解、行为驱动开、场景分解)->UI集合->研发与测试
敏捷培训总结 第5篇
Scrum 团队由一名产品负责人、开发团队和一名 Scrum Master 组成。Scrum 团队是跨职能的自组织团队。自组织团队自己选择如何以最好的方式完成工作,而不是由团队之外的人来指导。跨职能团队拥有完成工作所需的全部技能,不需要依赖团队之外的人。Scrum团队模式仍是设计用来提供最佳的灵活性、创造力和生产力。Scrum 团队(自身)已经证明,对于所有之前所述 Scrum 的应用以及任何复杂工作来说,它都是越来越有效的。
Scrum 团队迭代增量式地交付产品,籍此最大化地获得反馈的机会。增量式交付“完成”的产品保证了一个可工作产品的潜在可用版本总是存在。
敏捷培训总结 第6篇
【要点】Scrum定义,Scrum价值观,Scrum团队,Scrum事件,Scrum工件,DoD,Scrum规则总结,Scrum检查清单
Scrum是跨职能团队以迭代、增量的方式开发产品或项目的一种开发框架。它把开发组织成被称为Sprint的工作周期。这些迭代每个都不超过4周(最常见的是两周),并且无间歇地相继进行。Sprint是受时间箱限制的,无论工作完成与否它们都会在特定日期结束,并且从不延长。
实施Scrum框架的好处:降低变更对系统造成的风险;提高ROI(投入产出比);帮助我们持续改进;持续快速的发布可用的软件产品;所有人对真实可用的软件产品都有明确的认识,并在迭代过程中不停的改进。
敏捷培训总结 第7篇
【要点】看板的定义及作用,六项核心实践,看板实施原则,看板建模
看板方法(Kanban)源自丰田的“及时生产”(JIT=just-in-time)系统。尽管生产软件是一项创造性活动,与批量生产汽车有所不同,但是生产线管理背后所蕴含的原理仍然适用。看板方法是用于高效管理软件开发流程的新技术。
看板定义了一个增量和渐进的改变技术开发和组织运营的方法。它的核心机制是限制在制品数量的拉动系统,通过它暴露系统运作或流程中的问题,并激发协作以改进系统。
看板系统的作用:
看板方法的六项核心实践:
看板实施原则:
看板建模:
参考书籍:
敏捷培训总结 第8篇
Sprint 评审会议在 Sprint 快结束时举行,用以检视所交付的产品增量并按需调整产品待办列表。在 Sprint 评审会议中,Scrum 团队和利益攸关者协同讨论在这次 Sprint 中所完成的 工作。每次迭代开发结束时举行,通过演示可工作的软件检查需求是否满足客户要求;由Scrum Master组织, PO和用户代表(外部或内部利益相关人)负责验收、Team负责演示可工作软件。
迭代评审/验收会议的关键要点:
展示“真实”的产品:Team 应在真实环境中展示可运行的软件,判断是否达到“完成”标准;
收集反馈:PO 根据验收情况及客户反馈意见,及时调整产品Backlog。
敏捷培训总结 第9篇
迭代计划会议由团队共同确定迭代交付内容和完成标准。每轮迭代启动前,团队共同讨论本轮迭代详细开发计划的过程,输入是Product Backlog(产品待办事项列表),输出是Sprint Backlog(迭代待办事项列表)。
多团队迭代计划会议要分层召开:
迭代计划会议内容:
迭代计划会议的关键要点:
充分参与:Scrum Master确保PO和Team充分参与讨论,达成理解一致;
相互承诺:Team承诺完成迭代Backlog中的需求并达到”完成标准“,PO承诺在短迭代周期不增加需求(2-4周);
确定内部任务:Team和PO协商把一些内部任务放入迭代中(例如重构、持续集成环境搭建等),由PO考虑并与其他外部需求一起排序 。