敏捷开发中的pdca_pdca中do和action有什么不同 - CSDN
  • 笔者认为持续改进、PDCA在团队应用可以帮助团队具备造血并且自我成长的能力。 关于持续改进、PDCA可以百度一下就有详细的说明, http://baike.baidu.com/view/280963.htm?fromId=205386 PDCA循环又叫戴明环,是...

    如何使团队有生命力?如何才能使团队自己成长并具有?笔者认为持续改进、PDCA在团队中应用可以帮助团队具备造血并且自我成长的能力。

    关于持续改进、PDCA可以百度一下就有详细的说明,

    http://baike.baidu.com/view/280963.htm?fromId=205386

    PDCA循环又叫戴明环,是美国质量管理专家休哈特博士首先提出的,由戴明采纳、宣传,获得普及,从而也被称为“戴明环”。它是全面质量管理所应遵循的科学程序。

    PDCA是英语单词Plan(计划)、Do(执行)、Check(检查)和Action(处理)的第一个字母,PDCA循环就是按照这样的顺序进行质量管理,并且循环不止地进行下去的科学程序。P(plan)计划。包括方针和目标的确定以及活动计划的制定。D (do)执行。具体运作,实现计划中的内容。C(check)检查。总结执行计划的结果,分清哪些对了,哪些错了,明确效果,找出问题。A (action) 处理。对检查的结果进行处理,对成功的经验加以肯定,并予以标准化;对于失败的教训也要总结,引起重现。对于没有解决的问题,应提交给下一个PDCA循环中去解决。

              

     

    持续改进 continual improvement(见 http://baike.baidu.com/view/543263.htm

    ),增强满足要求的能力的循环活动。制定改进目标和寻求改进机会的过程是一个持续过程,该过程使用审核发现和审核结论、数据分析、管理评审或其他方法,其结果通常导致纠正措施或预防措施。持续改进 continual improvement,增强满足要求的能力的循环活动。制定改进目标和寻求改进机会的过程是一个持续过程,该过程使用审核发现和审核结论、数据分析、管理评审或其他方法,其结果通常导致纠正措施或预防措施。

       目前团队正在试行敏捷软件开发,在敏捷软件中有一重要环节:Sprint回顾会,这个回顾会很好体现了PDCA、持续改进这些团队自我造血环节。在回顾会中,团队要做的一件事就是总结刚结束的Sprint的一些情况,如Good、Could be better 、Improve等。

    根据上一个Sprint的完成情况,总结团队一些优秀的行为(Good),这些优秀的行为需要持续的维持;找出一些还可以做得更好的的地方(Could be better);下一个Sprint要做得更好我们有什么好的改进措施(improve)。

    下面是团队Sprint回顾会的一些图片

    在试行敏捷软件开发模式后,团队的持续改进意识有了进一步的提高,主要体现在以下几方面:

    1.          会议效率的提高,有效沟通也提高:之前一个普通的会议可浪费1个小时,为了提高会议的效率,缩短会议时间,团队成员自发提出不同的改进建议,如会议前提早将会议主题发出,以便做足准备,进行有效的讨论;又如会议主持权利赋予,可以打断与会议无关的讨论,是大家回归主题等。

    2.          制度与责任心结合:为提高团队的生产效率,提高执行力是重要环节,为此团队进行了多次讨论,也提出了不少建议,如将不同的任务交由专人推进监督实施,例如Code Review,由专人组织并负责进行问题及改进建议收集,统一规范团队的代码,提高团队的产出质量;如一些触发制度,当团队某个成员某事由于个人原因未能完成时,专职推进人员有权处罚执行不力的成员,例如买点水果犒劳犒劳大家等。

    3.          团队的培训与知识积累:团队中安排专人进行此方面的工作,如知识积累,安排专人跟进,要求团队每个人定期编写进行总结性文章或者技术干货等;培训方面由专人统一收集培训需求安排培训计划,当然为了提升团队的综合实力,培训讲师还是团队的成员,要求团队每个成员定期准备培训资料(或者分享资料),给团队所有成员上课。

     

    团队的成长离不开所有成员,集思广益,持续改进、PDCA等的实施离不开所有成员,更加离不开坚持,使持续改进成为团队的习惯,也只有成为习惯,团队才能一直改进,变得优秀,变得卓越。
    展开全文
  • PDCA循环,也称戴明环,是由美国著名质量管理专家戴明(W、E、Deming)首先提出的一套管理理论。 这个循环主要包括四个阶段:计划(Plan)、实施(Do)、检查(Check)和处理(Action),及八个步骤。八个步骤是四个阶段的...

    PDCA循环,也称戴明环,是由美国著名质量管理专家戴明(W、E、Deming)首先提出的一套管理理论。

    这个循环主要包括四个阶段:计划(Plan)、实施(Do)、检查(Check)和处理(Action),及八个步骤。八个步骤是四个阶段的具体化。
    1、计划(P)阶段 计划是质量管理的第一阶段。通过计划,确定质量管理的方针、目标,以及实现该方针和目标的行动计划和措施。计划阶段包括以下四个步骤:

       第一步,分析现状,找出存在的质量问题。

       第二步,分析原因和影响因素,针对找出的质量问题,分析产生的原因和影响因素 。

       第三步,找出主要的影响因素。

       第四步,制定改善质量的措施,提出行动计划,并预计效果。 在进行这一步时,要反复考虑并明确回答以下问题:

          1)为什么要制定这些措施(Why)?

          2)制定这些措施要达到什么目的(What)?

          3)这些措施在何处即哪个工序、哪个环节或在哪个部门执行(Where)?

          4)什么时候执行(When)?

          5)由谁负责执行(Who)?

          6)用什么方法完成(How)?

          以上六个问题,归纳起来就是原因、目的、地点、时间、执行人和方法,亦称5W1H问题。

     2、实施(D)阶段

          该阶段只有一个步骤,即just   do  it   第五步 第五步,执行计划或措施。

    3、检查(C)阶段

    这个阶段也只包括一个步骤,即第六步。 第六步,检查计划的执行效果。通过做好自检、互检、工序交接检、专职检查等方式,将执行结果与预定目标对比,认真检查计划的执行结果。

    4、处理(A)阶段

    包括两个具体步骤。

    第七步,总结经验。对检查出来的各种问题进行处理,正确的加以肯定,总结成文,制定标准。

    第八步,提出尚未解决的问题。通过检查,对效果还不显著,或者效果还不符合要求的一些措施,以及没有得到解决的质量问题,不要回避,应本着实事求是的精神,把其列为遗留问题,反映到下一个循环中去。 处理阶段是PDCA循环的关键。因为处理阶段就是解决存在问题,总结经验和吸取教训的阶段。该阶段的重点又在于修订标准,包括技术标准和管理制度。没有标准化和制度化,就不可能使PDCA循环转动向前。

     

    展开全文
  • 敏捷开发中的持续构建实践 在08年的STP第6期杂志,Glenn Jones在《Fly into agile development with agile testing》一文与我们分享了他们的敏捷项目的持续构建的做法: (1)每当有开发人员签入代码,...
    敏捷开发中的持续构建实践
    在08年的STP第6期杂志,Glenn Jones在《Fly into agile development with agile testing》一文中与我们分享了他们的敏捷项目中的持续构建的做法:
    (1)每当有开发人员签入代码,不管是多小的修改,都会执行持续构建。如果在构建过程中有人提交了代码更改,则会在下一轮的构建中包括进来。
    (2)持续构建后会运行部份的单元测试、部分的功能测试和部分的界面测试,用于确保主要路径和关键的界面都是正常工作的。
    (3)每隔20分钟运行一次构建,因此需要选择一些测试用例来执行,每个模块选择一些测试,对于那些复杂的模块、由于依赖其他模块而容易失效的模块,则会选择多一点测试用例。
    持续构建为开发人员节省了时间。
    因为开发人员都在持续不断地重构代码、添加代码,以便应对新的需求,以及由于其他开发人员的代码更改造成的影响。如果持续构建的频率降低,例如一天才一次,这样的话,某些开发人员修改了代码可能破坏了某些功能,其他开发人员可能因此而不能够测试他们新添加的代码。很多开发人员会花费很多时间在看到底是什么原因导致了错误。
    相反,持续构建可以通过快速地定位问题,从而帮助节省这些时间,让开发人员可以很快地修正自己代码种的错误,从而减少对其他开发人员的效率造成的影响。
    展开全文
  • 以前,当讲到我们团队采用敏捷开发进行APP迭代的时候,我会把“敏捷”二字打上引号。但是最近总结、反思、参加TAPD分享会、公司组织的敏捷培训以及系统的学习了敏捷的理论知识后,我觉得应该把这个引号给去掉。 本文...

    以前,当讲到我们团队采用敏捷开发进行APP迭代的时候,我会把“敏捷”二字打上引号。但是最近总结、反思、参加TAPD分享会、公司组织的敏捷培训以及系统的学习了敏捷的理论知识后,我觉得应该把这个引号给去掉。
    本文将从 什么是敏捷、待优化的地方及建议 及 总结 三个方向阐述。

    什么是敏捷,我们敏捷吗?

    个人认为,敏捷的核心就是:“小步快走、迭代优化”
    “小”:指Stroy要小、落地开发的Task要小,要可独立提测。这个APP团队逐步做到了。
    “快”:当落地开发的Task足够小,对于整体工作的评估会更加准确,团队对于需求的考虑会更充分,需求变更的可能性会更小,当开发的兄弟专注于开发的时候,快是水到渠成的结果。这个我们有一定进步,但是没有找到方法去衡量速度。
    “迭代优化”:这个是核心中的核心,一直抱着优化的心态对待迭代制度、对待我们的产品、对待我们的代码。。。我们的迭代由两周优化调整成为三周;我们通过持续沟通,需求变更的频率有所减少;开发基本每个迭代都有优化重构的任务规划落地;晨会效果不是很理想,但一直在调整优化方案。。。经过17及18年的持续优化,我们迭代的可控性、可预期性是有很大进步的,开发对于18年迭代的满意度是比17年更高的(没有跟产品、设计聊过这个话题)。
    综上,我认为我们是在落实敏捷开发的。
    是,并不代表好,实际上我们有很多地方需要提升,且提升空间非常大。其主要原因在于,大家对于敏捷的理论并没有深入系统的学习,对于其背后的本质更没有了解。

    待优化的地方及优化建议

    团队互信、团队负责

    • 问题
      当产品、设计不完善、或者产品、设计发生变更的时候,开发的兄弟往往会抱怨PM、设计师的输出质量差,PM、设计师也会质疑开发的开发效率、开发质量。
    • 目标
      产品、设计有问题的时候,开发应该主动去帮忙完善,提建议,一起提高产品、设计的质量;PM、设计师觉得开发效率低、质量差的时候,需要的是帮忙一起分析,差在哪里,能做什么去帮助开发得到提升。出现问题的时候,没有产品、设计、开发、测试,只有我们。这是我们需要构建的核心文化。
    • 如何做
      任何时候,我们不应该强调 产品、设计、开发、测试,而应该强调 我们,我们一起对这个Story、对这个产品负责。如果违背,可以请喝奶茶、或者罚划一周的船等等

    产品目标及价值

    • 问题
      很多兄弟对于产品的整体规划了解不多,PM团队也没有给出便于查阅的年度规划、季度规划,以及做这个产品、需求的价值到底在哪
    • 目标
      有方便查询的年度规划、季度规划,对于PM、设计师、开发、测试,看到之后,知道自己开发产品价值所在,提升大家的价值感
    • 如何做
      • 持续维护的产品目标及价值文档,重点说明产品、需求价值所在。
      • 对于实现了的产品,持续补充维护产品已经体现出来的价值

    敏捷是适应变化的

    • 问题
      很多人认为,敏捷是适应变化的,那我们在迭代中对于需求变更支持不够好,就是不够“敏捷”,这是对于敏捷的误解,对于变化一词的误解。
    • 目标
      • 明确 “敏捷是适应变化的” 含义:在当前需求确定的情况下,我们快速迭代交付产品,根据用户反馈调整产品、优化产品。进入迭代后是不允许有、也不应该有需求变更的。
      • 三周一个迭代,刚进入迭代的需求,就提需求变更,说明该需求质量还达不到进入开发的阶段,该需求应该被打回,而不应该误解“变化”,要求迭代很好的支持这种“变化”。这种“变化”,会导致极大的资源浪费(会影响后端、Android、iOS、测试等),还会让大家的士气受到影响。我们应该一起努力,在进入迭代前优化、完善这类需求。
    • 如何做
      • 加强敏捷理论学习,明确变化的含义。
      • 团队一起努力,提高各阶段交付物的质量(需求文档、设计稿、开发产品、测试质量)

    需求评审会

    • 问题
      我们现在需求评审会,过分强调这个需求是什么样子的,很少说明需求的价值,而说明需求价值的重要性不亚于说明需求是啥
    • 目标
      需求评审会后,大家对于需求有比较清晰的认识,对于需求的价值非常了解
    • 如何做
      需求评审会要明确两个目标:需求是什么需求价值。这个会上不讨论需求该如何实现类问题。

    晨会

    • 问题
      APP团队开晨会,所有人加在一起,差不多15+,如果有产品、设计师参加,得超过20人,这明显是有问题的。而我这样安排的初衷是,APP业务间基本都有交叉,不希望团队开发资源上出现单点问题。升哥有建议过分 阳光物业 和 社区 两块,但是我觉得不合适。只是在晨会频率上做变化调整,很多问题也确实通过晨会沟通尽早发现、尽早解决了。但始终无法改变效率低下的问题。
    • 目标
      晨会中,每个人需要说明的三个核心问题是:1. 昨天做了什么推进迭代 2. 今天准备做什么去推进迭代 3. 在推进迭代过程中遇到了什么问题。核心是参与晨会的人要对其他人的这三个问题听进去,如果有就给出自己的建议,帮助其他人更好的推进迭代。
    • 如何做
      研究表明,一个人同一时间,最多记住七件事情(后来进一步研究表明是四件),为了达到晨会高效的目的,建议晨会人员在 7-2/7+2,即5-9个人。比如APP迭代,结合结对编程思路,后端2人、Android2人、iOS2人、测试1-2人 组建一个迭代落地小组,每个迭代周期,有两个开发迭代小组,推进二者形成良性竞争。

    迭代速度

    • 问题
      我们通过 小步快走中的 提高了评估的准确性,对整个团队的速度有了一定提高,对于团队按期交付产品有了更好的把控。但是对于如何持续提高团队的迭代速度,持续提高团队迭代产出,是没有衡量标尺的。而Scrum中是采用点数去描述Story/Task的工作量,点数是工作量的一个标准度量单位。通过关注一个团队在一个迭代中能够完成的点数,反应团队的迭代速度。通过持续提高一个团队在一个迭代中完成的点数来提高团队的迭代速度
    • 目标
      • 找到自己团队/小组的标尺:点数
      • 可度量的持续提高团队的迭代速度
    • 如何做
      • 需求池中需求优先级是唯一确定需求开发先后顺序的标准(和老板达成一致,老板需求也要纳入这个需求池)
      • 采用统一标尺 点数(类似长度“米”)来评估需求的点数
      • 信任大家,按优先级主动领取需求,通过晨会跟进落实,经过三、四个迭代,大家就知道咱们团队的速度了
      • 有了度量速度的标尺,持续改进影响速度的点,提高迭代速度

    透明

    • 问题
      在整个团队层面,APP团队在透明度方面做的工作是最多的。每个迭代基本都会给全员发 需求评审会通知、需求启动通知、迭代周总结、迭代总结(一两个迭代发一次)。团队所有成员通过查看邮件,基本可以知道当前迭代的进展情况。
    • 目标
      透明的目的在于大家时刻能知道自己团队当前的状况,增加自主意识。通过透明,不同小组间可以相互促进,持续提高。
    • 如何做
      以PDCA或者Scrum的思路推进工作,并透明化所有相关事项,小组内部实现良性循环,小组间、团队内相互学习、实现良性竞争。所有事项包括但不局限于(所有事项都欢迎任何感兴趣的人查看、参加):
      • 产品年度规划、季度规划
      • 产品预期价值、以上线产品已实现价值
      • 团队技术规划、所有技术分享
      • 团队各种会议

    迭代总结会

    • 问题
      迭代总结会的核心是总结好的经验继续保持,总结问题并落实解决,实现持续优化。APP迭代总结会我们做到了把所有问题拿到台面上讲,但是在落实解决上我们做的不好。
    • 目标
      • 总结好的经验,作为团队文化进行传承
      • 总结问题,并讨论落实方案,在新迭代中落实到位,持续优化迭代
    • 如何做
      • 高效发现问题:下个迭代团队做什么,可以让你效率更高。每个人必须回答。
      • 讨论确定最高优先级的问题,并讨论决定可执行的落实方案,以及落实计划、验收计划
      • 讨论问题,绝对禁止针对个人(老板除外),要针对流程、制度去讨论

    关于团队成员技术成长

    • 问题
      我们有很多“大佬”,但我们的大佬基本都是在某方面业务开发中做得出色或者大家认为其技术比较厉害而被称为大佬的。但是我们有哪些大佬在团队层面去持续帮助其他人提高技术的呢?在营造团队技术氛围上有贡献的呢?把一个人的技术提高一倍所需的时间 远超 把团队的能力提高一倍的时间
    • 目标
      “大佬”们要把自己的一部分精力放在持续提高团队成员水平的事情上,营造越来越浓厚的互助氛围
    • 如何做
      • 持续的、有广度的、有深度的 分享坚持下去
      • 打造持续追求更高、更好的氛围
      • 我们有基于产品的开发团队,如APP、Python业务、Python平台、友邻、装修、公共资源等; 也需要有基于职能的团队,如Android、iOS、H5、Java、Python等。基于产品维度和基于职能维度的团队交流同等重要。

    制度上如何保障

    公司大的制度环境,对于 Scrum 并不是完全合适的,那如何在制度上去保障我们团队落地?明确KPI考察方向、采用OKR。。。这个问题需要大家和HR一起思考,“We are a term”,我们一起去解决!

    总结

    敏捷开发,其实就是PDCA方法在软件开发领域的应用,以期实现高质量、可控、可预测的交付产品。其核心在于一个持续优化的闭环。让我们-主动-迭代优化

    参考

    展开全文
  • 敏捷开发笔记整理

    2019-01-07 21:14:45
    敏捷开发宣言: 1.个体和交互胜过过程和工具 2.可工作的软件胜过面面俱到的文档 3.客户协作胜过合同谈判 4. 响应变化胜过遵循计划,从上面的宣言可以看出,敏捷开发的核心是人 、协作、时刻可运行的软件、变化。 敏捷...
  • 敏捷开发大会总结

    2012-09-20 14:08:29
    9月份的12日下午、13、14两天,参加了第七届敏捷开发大会,虽然自己没有做过敏捷项目,但因为现在“敏捷”是流行词,想看看自己公司的项目能不能用,所以就拿着领导的大洋,风风火火的参会去了,接受各位牛人的轮番...
  • 大型软件的团队有效协作对项目成功起到越来越关键的作用,“敏捷之旅广州站——精进之旅”的活动,请来了业界敏捷项目管理的专家做了几场公益性的讲座,涉及敏捷开发应用和互联网项目管理的一些实用的方法,本文结合...
  • 文章目录0. 软件的生命周期1. 瀑布模型2. 螺旋模型3. 迭代模型4. 增量模型5....  瀑布模型是最早出现的软件开发模型,是所有其他软件开发模型的基础框架。与软件的生命周期不同的是,它缺少了软...
  • CMMI与敏捷开发模式

    2014-12-31 10:31:16
    1) CMMI 开发模式 优点是开发流程制度化和重视过程(设计,文档,编码,测试,原因分析),强调项目的可控性( Risk 管理),缺点是开发周期长,灵活性差。   CMMI 体系适用范围的特征:产品 / 项目创新要求...
  • 转载至:http://developer.51cto.com/art/200909/151058.htm
  • 我们现在看敏捷开发总觉得它很先进,但敏捷实践有很多是来源于传统的日本工业界最佳实践的,尤其是丰田推行的TPS。仔细分析,常见的敏捷实践都能对应到TPS的实践。TPS是由丰田开发的,通过消除浪费来获得最好质量...
  • 敏捷web开发概述

    2020-04-17 22:27:11
    瀑布开发模型 定义阶段:软件计划、需求分析 开发阶段:系统设计、编码开发、测试 维护阶段:维护 项目成功的定义:按期交付、在预算内、交付所有功能 项目失败原因:需求变化、缺乏用户参与、资源不足、不现实的...
  • 第三章 敏捷软件开发

    2019-07-12 17:34:03
    第一节 敏捷软件开发敏捷早于devops适用于DevOps的软件工程...·当前公认的适合于DevOps的软件过程方法是敏捷软件开发(包括Scrum、eXtreme Programming、Kanban等),尤其是敏捷软件开发中的Kanban(看板)方法。·...
  • 敏捷革命--提升个人创造力与企业效率的全新协作模式》 第二章 SCRUM的由来提及敏捷...基于敏捷PDCA的关系,就意味着,这种应用并不局限于软件项目的开发,同样可以应用于个人学习、企业管理、硬件项目开发、财务、
  • 敏捷思想深受日本工业界最佳实践的影响,尤其是丰田推行的TPS,常见的敏捷实践都能对应到TPS的实践,所以这里对TPS做个简介。 TPS实践 Agile实践 实时管理系统 时间盒 ...
  • 软件开发模式对比(瀑布、迭代、螺旋、敏捷) 1、瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型, 瀑布式开发是一种老旧的计算机软件开发方法。 瀑布模型式是最典型的预见性的方法,严格遵循预先计划的...
  • Scrum 敏捷开发 基础及失败成功案例分析 什么是敏捷开发方法?何谓Scrum? 看到敏捷,想到的是什么? 有人说是动作敏捷、反映灵敏,速度快; 有人说是多快好省; 有人说是没有制度,松散的工作方式;...
  • Agile,敏捷开发被越来越多的开发企业和团队所接受。敏捷恰当,可以显著提高开发效率和产品的开发周期。问题是,“敏捷”方法是否能适用到软件外包行业,这个争论由来已久,各有说辞。最典型的争论就是,作为外包的...
  • PO 角色 负责需求的管理、产品路径规划、组织版本验收。维护好产品代办列表、梳理需求优先级排序,对需求ROI负责。 “Product Owner(PO)——用户/客户/业务的代言人,就是可以做出业务决策的人,所谓业务决策包括...
1 2 3 4 5 ... 20
收藏数 654
精华内容 261
关键字:

敏捷开发中的pdca