精华内容
下载资源
问答
  • 通过回顾会议可以使团队每个迭代都能比上个迭代做得更。在很多敏捷团队中,最容易忽略该活动,很多团队没有意识到该活动的重要性。为什么呢?最主要的原因是开了会议,没有实际效果,大家认为没用,所以也就不开了...

    迭代回顾会议是Scrum五个仪式之一,是在迭代评审会议之后对本次迭代的优点与改进点进行复盘的一个活动,其最主要的目的是提升团队的整体能力,持续改进,形成一个自学习的团队。通过回顾会议可以使团队每个迭代都能比上个迭代做得更好。在很多敏捷团队中,最容易忽略该活动,很多团队没有意识到该活动的重要性。为什么呢?最主要的原因是开了会议,没有实际效果,大家认为没用,所以也就不开了。实践中,在开迭代回顾会议时常犯的错误有:

    • 把回顾会议开成了吐槽大会,大家只提意见,不提改进措施;
    • 把回顾会议开成了表彰大会,大家只提优点,不提改进措施;
    • 把回顾会议开成了给领导的汇报会,不提改进措施;
    • 开了回顾会议,但是没有对改进措施实际落地执行;

     

    回顾会议要开好,我认为要遵循以下5个原则:

     

    1 对事不对人

    回顾会议不是批评和自我批评,而是识别团队的改进措施,不是追究责任,而是要传递正能量,如何让我们做的更好,如何让我们持续进步。

    在敏捷团队中要承认个体差异,要充分发挥团队的作用,聚焦团队中个人能力的互补,实现1+1>2的效果,因此不能在回顾会议上批评某人做得不好,而是要考虑如何充分利用团队的力量来预防错误、及时发现错误。我们可以在回顾会议上表扬某人的优点,鼓励大家学习某人的优点,激发正能量。大家在回顾会议上使用的主语应该是“我们”,而不是“你”“我”“他”。

    如果在会议中发现有甩锅的言论时,主持人要及时出面引导。

    在回顾会开始之前,可以明确该原则,建立心理安全。

     

    2 人人平等,全员参与

           回顾会议不能一言堂,不能被少数人左右。团队成员是对等的,Scrum Master不是行政领导,与团队成员不存在上下级关系。回顾会议不能成为Scrum Master有意无意地树立、展示自己权威的舞台。团队中资深大佬的发言也往往带有倾向性的引导作用,善于演讲的人也往往会花费较多的时间陈述自己的观点。有的人不善于当众表达自己的观点,因此在会议上羞于发言。每个人都应该充分分享自己的观点,在回顾会议上希望是给所有人分享尽可能全面的、不同视角的信息。 回顾会议的主持人应该设计一些活动,比如三五法、海星法、圆点投票法等等,让大家都参与进来,活跃气氛,充分发表自己的意见、参与决策,而不是少数人左右了大多数人的观点。

     

            我曾经看到的一种典型错误做法就是:在回顾会议上由Scrum Master点名要求每个与会人员发言,然后Scrum Master结合自己的经验对每个人的发言进行点评。

           管理者的参与通常会让与会人员失去安全感,员工守着领导不敢发言,因此,提倡无管理者参加的回顾会议。主持人可以在会议之前,让大家对安全感进行不记名打分评价,如果安全感比较低,可以取消本次会议或取消管理者的参与。

         缺乏安全感的回顾会议,往往会导致大家不敢直言团队的问题,有些大的、根本性的问题被忽略了。会议识别出的措施效果不显著,这样就会导致大家对回顾会议的价值产生怀疑,久而久之可能就流于形式。

    3 可视化团队的绩效

         在回顾会议上可以采用燃尽图、燃起图、折线图等展示:

    • 本次迭代与上次迭代相比,交付速度是否提升了?整个团队的交付速度是否在持续上升?交付质量是否维持在原有水平或者得到了持续提升?回顾团队的速度可以激励团队成员看到整体性能的变化,激励大家做的更好,或者可以反思问题所在。
    • 截止到本次迭代,我们累计实现了哪些改进措施?我们是否可以看到我们的行为在变化?回顾历史上我们已经落地的措施,可以建立起团队成员对回顾会议价值的认可。
    • 质量有关的或其他数据。根据本次迭代与整个项目的目标达成情况,团队也可以采集其他数据在本次会议上进行分享。    

         通过可视化历史的绩效与行为变化,让大家对上次迭代的状态建立起客观的、一致的理解,在这个基础上进行讨论,有助于团队快速统一思想。

    4 改进措施要落地

    回顾会议一定要有一个输出,即下个迭代要落地的改进措施是什么?这样才能使下次迭代比本次迭代做的更好在回顾会议上要识别出的措施可以根据实施的主体区分为组织级的措施、团队级的措施与个人级的措施。组织级的措施是提交给团队以外的领导去解决的;个人级的措施是需要团队成员要注意的,不需要改变团队的做法;团队级的措施是本项目组要关注的,要从中筛选出下次迭代团队要落地的至少一条措施。不要试图解决在回顾会议上识别出所有的问题,要聚焦短板,重点突破,一次只做一件事效率最高。识别的措施要在下次迭代中可以见效,不要追求措施的高大上,要追求措施的简单易行。可以通过询问多个“如何落地”,确保识别的措施可以在下次迭代中落地。

    确定下次迭代要落地的措施应该体现在下次迭代的计划中,为实施这些措施计划出相应的时间。在下次回顾会议上要检查这些措施的落实情况。

    很多团队敏捷回顾会议没有坚持下去,主要是因为大家没有看到敏捷回顾会议带来的好处,如果在敏捷回顾会议上没有识别出应该落地的措施,则大家就会对敏捷回顾会议丧失信心与兴趣,不愿意参与敏捷会议,从而导致敏捷回顾会议无法坚持下去。

     

    5 引导正能量

    主持人在整个回顾会议上需要注意引导大家积极参与,聚焦于讨论的议题,活跃气氛,并且要传递正能量。主持人不要评判大家观点的正确与错误,使会议陷入争论,可以抛出一些问题引导大家在别人的观点之上寻找更优的解决方案,而不要否定成员的观点。主持人也不要把自己的观点,自己的判断强加给团队的成员。有些改进点是需要在组织级进行解决的,是团队运行的外部条件,在回顾会议后可以给组织提交这些改进点,在回顾会议上不要抱怨外部环境,要聚焦于在这些限制条件下,如何更好地提升团队的效能。在回顾会议上不但要发现改进点,也要发现优点,发现进步,发现受大家欢迎的成员和做法,让大家建立起对团队、对产品的信心。

    我在参与某项目的迭代回顾会议时,发现团队成员都在找改进点,而没有人去发现团队的进步,气氛有些沉闷。于是我就抛出了一个问题:我们项目到目前为止,大家看到了哪些令人欣喜的变化呢?有的成员就讲,我们原来是1周发布1次,我们现在可以发布5次了!大家听完之后,都很兴奋,会议的气氛马上变得热烈起来。

    也有很多团队在回顾会议结束前发起感谢活动,让大家感谢其他人对自己的帮助,给回顾会议一个温暖的结束。

     

    掌握、应用好上述的5个原则,才能避免回顾会议开成:吐槽会、空谈会、争论会、表彰会,充分发挥回顾会议作用,建立一支自学习、自组织、持续改进的团队!

    展开全文
  • 敏捷实践之如何开好scrum回顾会议

    千次阅读 2018-12-16 15:35:32
    scrum中的5个活动分别是: -产品代办事项列表梳理(product backlog) -sprint计划会议(sprint plan meeting) -每日站(scrum daily meeting) -sprint 评审(sprint ...回顾会议是scrum的几个会议中相当重要的一个...

    scrum中的5个活动分别是:
    -产品代办事项列表梳理(product backlog)
    -sprint计划会议(sprint plan meeting)
    -每日站会(scrum daily meeting)
    -sprint 评审会(sprint review meeting)
    -sprint 回顾会议(retrospective meeting)

    回顾会议是scrum的几个会议中相当重要的一个会,但是在很多团队中,retro的会议被无限期的延期。即使回顾会议如期举行,也大多流于形式,回顾会议如何才能开好,是这五个活动中最需要花心思的,甚至scrum master需要根据团队的状态以及团队融合的阶段来设置回顾会议的过程。
    老生常谈,回顾会议是一个纠偏的会,是一个固本培元的会,放弃回顾会议虽然不能完全等同于让团队自然存活,但确实放弃了整个团队一起总结->成长->总结的好机会。
    我们经常看到一些团队,一上来就由scrum master宣布,我们今天来开始回顾我们上个sprint中的工作,大家看看我们有什么地方做的好,需要保持,有什么地方做的不好需要改进,现在我们挨个发言。也有一些scrum master在和我聊他们的回顾会议所遇到的问题,他们觉得经常没有什么可以说的,所以他们由一个sprint变成两个sprint开一次,由两个sprint变成三个sprint开一次,慢慢的,回顾会议就省了。
    对于回顾会议的参与者,不同的组织范围不同。我一直有一些自己的想法,我见过邀请一堆PO PM 各种boss老板的回顾会议,然后回顾会议开成了汇报会,各种祖国山河一片大好,问题一堆一堆得不到实质的处理。回顾会议是以人为本,以提高产能,提升团队工作效率以及团队精神面貌为目的的会议。我认为从这个点出发确定出回顾会议与会人员的范围。具体情况具体分析,不过我怎么觉得也能写篇文章来说,哎,这个点上我痛过。
    在开发理念以及团队管理上我是特别主张套路的人,套路一定是得人心的,一定是被证明过正确可行的,所以我们按套路来,
    《Agile Retrospectives》把回顾会议分成了5个阶段:
    1. 准备
    2. 数据收集
    3. 产生见解
    4. 确定改进项
    5. 结束会议

    我前面提到了,回顾会议是需要scrum master费心来设计过程的一个会,虽然大的阶段是固定的,但是根据团队的阶段,其实是需要在回顾会议里安排很多细小的点来达到scrum master管理团队的目的。

    -第一阶段-准备
    1. 回顾会议的主持人会和scrum master讨论一个大家都感兴趣的话题,放在会议的最开始大家讨论一下,内容是sprint内大家都比较关心的事情。
    2. 回顾会议主持人整理上次retro大家决定的改进项。
    3. 回顾会议所需要的ppt,。
    -第二阶段-数据收集
    数据收集相对比较复杂,我们会有四个方面的信息来收集
    1. 大家感兴趣的话题 free style
    目前我的团队会找一个团队的同事来背诵敏捷宣言,然后背诵敏捷的5个价值观(专注,勇气,公开,尊重,承诺)。其实团队在最开始三次回顾会议上是大家一起朗读的,这个一起读看似洗脑的过程,逐步在消除团队同事觉得一起读很奇怪的感觉,“那个感觉很奇妙,有融入的感觉”,我的一位同事后来反馈给我说。
    2. 用一个词来描绘大家在上个sprint中的心情
    大家把一个能描绘自己在上个sprint心情的词写再卡片上,然后每个人来解释一下自己为什么沮丧,高兴,或者 …en 各种千奇百怪的心情。这个环节是想让大家放飞自己,这样的环节让大家觉得回顾会议是一个参与感很强的会,参会者来不只是“听会”,作为主持人的你,除了控制时间外,尽量让大家飞~~~
    3.绘制大家在上个sprint的心情曲线
    目前我们团队一个sprint是三周,大家去回忆自己在这三周里的心情并在白板上绘制一个心情曲线,其实这个过程依然是让大家畅所欲言的过程,大家会描述自己在这个sprint中各个心情的拐点。这个环节的目的有两个,第一:将大家的思绪带到过去的三周中去,让大家去回忆过去一个sprint所经历的事情。第二:团队成员之间相互了解其他人在过去一个sprint中的经历, 并且了解团队成员各自的点(生气,高兴),从而达到后期的有度有效沟通。第三:scrum master或者主持人已经可以在这个过程中拿到一些数据,更多的是团队的士气数据。
    -第三阶段-产生见解
    什么做的好,需要加强,什么做的不好,需要改进
    这个环节是回顾会议的核心,有很多的玩法,我想后面再起一个专门的文章来整理一下,大家可以先参考传统的做法:
    传统的做法是用贴纸的方式收集大家觉得团队中好的以及不好的点,这个过程一定要背对背
    对于收集上的的卡片我们首先进行分类
    对于好的,我们进行整理归类,并和之前好的以及不好的backlog进行比较,鼓励整个团队继续保持。
    对于不好的,我们也是在整理归类后,选出来不超过2条进行改进,如果选的改进项太多,团队往往无法是从,最终导致所有的改进全部失败。
    -第四阶段-确定改进项
    针对每个改进的点,我们要具体分析导致该问题的根本原因,然后根据根本原因提出改进措施。
    找问题的根本原因用什么方法呢? 问度娘,用科学的方法找问题的根本原因哦。好多理论知识可以用的。

    -第五阶段-结束
    好了,最后,让我们结束这次回顾会议。
    我一本的结束方法是感谢团队中的一个人,感谢的方式是在纸片上写: “感谢xxx在上个sprint中xxxxxxxxxxxxxxx。某某人”
    这句话在回顾会议中念出来,然后将纸片送给你所感谢的那个人。
    这个环节要求只能感谢一个人。
    这个环节设计的好处是可以让团队之间相互信任,相互帮助。结束环节的内容也可以根据团队状况去设计,scrum master一定要用心去感受整个团队的变化。

    说在最后:
    让我们把改进项也加进下个sprint的story里面一起跟踪吧!
    完结~~~

    展开全文
  • 相信只要做好以上的每一个环节,一定可以开好一个迭代回顾会议。怎样才能做好以上所有环节呢?前准备必不可少,前准备不是简单地发通知、定地点、按模板写会议PPT。好的前准备有些甚至要花一两天的时间。极端...
        上篇文章向大家介绍了一个通用的迭代回顾会议议程,它可以应对大部分情况下的迭代回顾会议。相信只要做好以上的每一个环节,一定可以开好一个迭代回顾会议。怎样才能做好以上所有环节呢?会前准备必不可少,会前准备不是简单地发通知、定地点、按模板写会议PPT。好的会前准备有些甚至要花一两天的时间。极端地说,对迭代回顾会议的主持人来说,迭代过程中的每一天都要为迭代回顾会议做准备。

    为迭代回顾会议做准备

        本节所介绍的会前准备都是针对上述的通用议程而言。好的准备应该做好三件事情:寻找主题、收集数据、选择工具。

      寻找主题

        作为敏捷教练或者迭代回顾会议的主持人,要在迭代过程中时刻观察迭代工作的开展情况,并思考以下问题:
    1. 团队之间的沟通、协调、协作有什么不足的地方?
    2. 日常工作中有哪些值得记录的瞬间?
    3. 整个迭代期间,团队成员的心理状态如何?
    4. 迭代工作是否顺畅?
    5. 迭代过程中是否有违背按照敏捷框架的?
    6. 迭代过程中团队对质量的关注程度如何?
    7. 迭代过程统计数据有能发现什么问题?
    8. 团队的产出物如何?
        也可以与一些团队成员或者PO沟通他们的看法。他们在本迭代期间对什么感兴趣?迭代过程中有什么令他们烦劳的事情?
        将这些观察和思考的结果、与沟通的内容记录下来,尝试从中找到一两个主题供迭代回顾使用。

      收集数据

        目前,在收集数据上很多项目管理工具给我们提供了强有力的支撑,但是也给我们带来的极大的限制。大家收集数据基本上都是从项目管理工具上直接获取统计数据表。更极端的是从第一次迭代回顾会议到最后一次迭代回顾会议用的都是同一个模板。
        事实上,面对不同的会议主题,我们最好收集有针对性的数据,并使用合适的数据统计格式。项目管理工具上的数据只能用来作为基础数据,不要僵化地采用上面的数据。

        基础数据

        基础数据是客观存在的,主要有用户故事、缺陷、燃尽图等基础数据。在做回顾时,用户故事要更多地关注上轮迭代的计划完成情况;缺陷要更多地关注于未解决的缺陷;迭代燃尽图可以更好地复现迭代的过程;发布燃尽图能帮助大家对整个项目的状况有一个更全面的认识。
        不是所有的基础数据都要在某一个迭代回顾会议上全部展示,正确的做法应该是选择与本次回顾主题联系紧密的数据。在选定的基础数据上,采用不同的展示形式,多角度的对比分析,让数据能反应更深层次的问题。

        数据对比

        数据对比主要是横向对比和纵向对比两类。横向对比是指与同行业、同公司、同项目组的其他团队进行对比;纵向对比是指与本团队前期多个迭代的情况进行对比。当然也可以二者结合。

        数据展示

        好的数据展示不但可以让数据看起来不那么枯燥,还可以更直观地反应问题。常见的统计数据展示方式有很多。如:折线图、直方图、雷达图、饼状图、散点图、曲线图等等。

        数据分析

        数据分析是在迭代回顾会上的事情,但是作为会议主持人,特别是敏捷教练,在会前一定要先对数据进行分析。两个目的:验证是否能通过数据分析出一些问题;事先对数据有深入的认识,方便会议引导。
        数据分析能力是每个敏捷教练都必须具备的技能。可以从量、势、复、特、度五个角度进行分析。量是指数值的大小(有时还要关注某些曲线的包络面积)、势是指数据发展趋势、复是指类似数值、类似数据形状的重复情况、特是指与众不同的特殊数据、度是指数据影响广度、深度。

      选择工具

        这里的工具是指在迭代回顾会议过程中所使用的图片、音乐、视频、游戏、思考方法等等,而不是简单地表示实体工具。这些工具将分别在营造氛围、定位问题、寻找方案和承诺等环节上使用。下面给大家一一罗列一些典型工具。一个好的敏捷教练或者会议主持人需要对这些工具有充分的掌握,并能合理地使用它们。

    迭代回顾会议常用方法与工具

      破冰游戏

        开始迭代回顾会议时,部分成员可能还没有从紧张的迭代开发中走出来,因此主持人可以选择合适的游戏破冰。
    合适破冰游戏有三个要点:所有人都参加、规则简单、耗时短。比如说自我介绍、感恩、成语接龙、看图说文、看视频等等。
        好的破冰游戏除了可以营造会议氛围,甚至能在一定程度上激发灵感,为后续的各议程打下坚实的基础。

      头脑风暴法

        头脑风暴法一般可用于进行定义问题和寻找方案。分为直接头脑风暴法(简称为头脑风暴法)和质疑头脑风暴法(也称反头脑风暴法)。前者用于群体决策尽可能激发创造性,产生尽可能多的设想的方法;后者则是对前者提出的设想、方案逐一质疑,分析其现实可行性的方法。
        采用头脑风暴法组织群体决策时,要集中有关专家召开专题会议,主持者以明确的方式向所有参与者阐明问题,说明会议的规则,尽力创造在融洽轻松的会议气氛。一般不发表意见,以免影响会议的自由气氛。由专家们“自由”提出尽可能多的方案。
        头脑风暴法有6大原则:延迟评判、自由畅想、以量求质、综合改善、禁止批评、限时限人。

      MECE

        MECE,是Mutually Exclusive Collectively Exhaustive,中文意思是“互斥,完全穷尽”。 也就是对于一个重大的议题,能够做到不重叠、不遗漏的分类,而且能够借此有效把握问题的核心,并解决问题的方法。
        该方案有助于管理者进行问题或解决方案的排序、分析,并从中找到令人满意的解决方案。通常的做法分两种:
        一是在确定问题的时候,通过类似鱼骨图的方法,在确立主要问题的基础上,再逐个往下层层分解,直至所有的疑问都找到,通过问题的层层分解,分析出关键问题和初步的解决问题的思路;
        另一种方法是结合头脑风暴法找到主要问题,然后在不考虑现有资源的限制基础上,考虑解决该问题的所有可能方法。然后再往下分析,每种解决方法所需要的各种资源,并通过分析比较,从上述多种方案中找到目前状况下最现实最令人满意的答案。

      六何分析法

        也称"5W1H"法:是对选定的项目、工序、操作或者问题,都要从原因(何因Why)、对象(何事What)、地点(何地Where)、时间(何时When)、人员(何人Who)、方法(何法How)等六个方面提出问题进行思考。
    常常被运用到制定计划草案上和对工作的分析与规划中,并能使我们工作有效地执行,从而提高效率。在寻找方案时运用可以让解决方案更具备实效性。

      举手表决

        举手表决有允诺确认和共识确认两种表决方式。
        允诺确认是在所有人都已充分发表意见,团队已达成共识时使用,用于突出承诺使用。常用的方式是“不同意的请举手”。
        共识确认则是部分人因为各种原因没有能充分表达出自己的看法的情况下使用。常用的方式是“展示1~5根手指,5表示非常赞同,1表示有严重疑虑,邀请展示1到2根手指的成员发言”。
    这两种举手表决法在达成承诺上有奇效。

      鱼骨图

    鱼骨图也称为因果图、因果分析图或石川图。它看上去有些像鱼骨,问题或后果标在"鱼头"外。在鱼骨上长出鱼刺,上面按出现机会多寡列出产生生产问题的可能原因。
    鱼骨图有助于说明各原因之间如何相互影响。也能表现出各个可能的原因是如何随时间而依次出现的。这有助于将复杂问题清晰化、逻辑化,并迅速找到关键点着手解决。

      思维导图

        又叫心智图,是表达发射性思维的有效的图形思维工具,是一种简单却又极其有效的思维工具。
    思维导图运用图文并重的技巧,把各级主题的关系用相互隶属与相关的层级图表现出来,把主题关键词与图像、颜色等建立记忆链接,思维导图充分运用左右脑的机能,利用记忆、阅读、思维的规律,协助人们在科学与艺术、逻辑与想象之间平衡发展,从而开启人类大脑的无限潜能。

        思维导图在用于解决问题和寻找方案时跟头脑风暴法配合使用将具备神奇的效果。

    小结

        如何开好迭代回顾会议(1)(2)所介绍的通用迭代回顾会议,都是从解决问题出发而使用的回顾议程与工具。事实上,并不是每次迭代回顾会议都必须是解决问题。你偶尔可以帮团队换换口味。

        另外,作为一个敏捷教练来说,不能全程把控迭代回顾会议。敏捷教练要坚信,团队能自己开好迭代回顾会议。但是,这并不表示敏捷教练在迭代回顾会议上就什么都不用做。

        《如何开好迭代回顾会议(3)教练、不同的口味》将希望给你带来新的启发、新的视角。


    展开全文
  • 开好一个迭代回顾会议,不论是敏捷教练还是团队成员,都要牢记迭代回顾会议的目的。 检查并调整  迭代回顾可以让团队在紧张的迭代开发工作结束之后,喘一口气,并回头看看迭代过程中究竟发生了什么。 下次做得更...

    迭代回顾会议目的

        迭代回顾会议作为迭代化开发中的一个重要活动,为保证敏捷团队的高绩效运作发挥着着不可或缺的作用。要开好一个迭代回顾会议,不论是敏捷教练还是团队成员,都要牢记迭代回顾会议的目的。

      检查并调整

        迭代回顾可以让团队在紧张的迭代开发工作结束之后,喘一口气,并回头看看迭代过程中究竟发生了什么。

      下次做得更好

        这是迭代回顾会议的根本目的。团队要承诺,下一个迭代将继续发挥之前的优良传统,同时纠正之前的一些错误做法,以便做得更好。通过一次次的迭代回顾,团队在高绩效之路上不断前行。

    通用迭代回顾会议议程

        凡会议必有议程,不同的团队、不同的迭代环境下可以使用不同的会议议程。这里主要是向大家介绍一种比较通用的迭代回顾会议议程,大家可以在该议程的基础上根据需要进行裁剪、补充、调整。

        这个通用的议程按顺序罗列如下:确定会议基调、营造会议氛围、分析数据与定义问题、寻找方案、承诺。

      确定会议基调

        在确定会议基调这个环节主要是要做以下几件事情:主持人开场、宣布目的、确定议程、确定时间框、强调纪律。

        主持人开场

        迭代回顾会议必须有主持人,可以是Scrum Master,也可以是轮流担任。会议开始前主持人可以采取简单的一两句话,如致欢迎辞进行开场。通过开场将如菜市场般的会场平息下来,把所有人的注意力吸引到主持人身上。

        宣布目的

        所有迭代回顾会议的目的都是“检查并调整、下次做得更好”。那是不是每次会议宣布会议目的的时候都这样说就可以了?答案是显然的。这个目的很粗放,不同的迭代回顾会议的其实都是围绕着不同的主题开展,通过对特定主题的深入展开,解决针对性的问题,达到“检查并调整、下次做得更好”这个目的。

        因此宣布会议目的的时候应该突出本次迭代回顾会议的主题。如“本次的迭代回顾会议将讨论并解决我们在迭代质量中存在的问题,帮助我们在后续的迭代中提升迭代质量”。

        确定议程

        在这个环节中,主持要向所有人宣布会前定义的会议议程。如果大家都没有疑义,就按照该议程进行;如果有异议,可以当场利用简短的时间进行协商调整。

        确定时间框

       时间框在Scrum中应用非常普遍,如迭代长度、站会时长。一个好的、执行到位的时间框可以让大家在当前时间框内全神贯注。确定下来会议时长后,就要严格执行时间框规定:时间到后,不论是否有决议都应该结束会议。

    这个时候有三种选择:

    1. 随它去、没有决议没什么大不了的
    2. 必须有决议,所有人都认为很快就可以达成决议了,可以延长时间;
    3. 必须有决议,但今天是出不来了,回去好好想想,明天再开个专题会议吧。

        强调纪律

        会议纪律简单点说就是会议过程中不要开小会、手机要静音、不要玩手机等等。

      营造会议氛围

        好的氛围应该是所有人都积极参与会议讨论,在讨论过程中会经常提出有建设性的意见。

        营造好的会议氛围有很多种方式。比如游戏、比如看视频再评论(切勿只看不评)。比较简单有效的一种方式,就是让每个人都用一个短语或者词语,描述下当前的感觉或者对当前迭代的感觉。

        营造氛围的环节中要保证每个人都发言或者参与实际活动。

      分析数据与定义问题

        团队中的每个成员都会对在迭代过程中发生过的事情有自己的认识,对迭代的结果也有自己的看法。但是,很少有人会对这些有一个全面的认识。数据分析可以为大家进一步认识迭代过程,提供一个更客观、全面、统一的基础。有了这个基础之后,大家才能更清晰地发现迭代过程中存在的问题。

        当前,我们在进行数据分析的时候存在一个普遍的问题。那就是每个迭代都用的是一个覆盖面广、程度浅的统一模板数据。事实上,每轮迭代的情况不同,所需要的数据也不同,否则很难通过数据分析对迭代状况有非常深入的认识。具体如何收集数据,后续章节将进行详述。

        至于的定义问题时,我们常采用的方法是:“每人说3条做得好的,3条可以改善的,再从其中选取最高优先级的几条进行改善”。这是一种简单的方式,在短时间内也非常有效。随着时间的推移,这种方式也逐渐成为形式。其实定义问题还有很多其他的办法,后面也会给大家做相应介绍。

      寻找方案

        寻找方案就是要为前面定义的问题,寻找到一个解决方案。好的方案应该是:可执行性强、改善效果可度量、有阶段性目标、责任清晰。

      承诺

        承诺是自组织团队的基石。迭代回顾会的最后一个环节,就是围绕之前形成的方案进行承诺。每个人都要承诺“认同这些方案、支持这些方案的执行、身体力行地坚持这些方案”。

    小结

         本部分简单介绍了下迭代回顾会议的目的和议程,如何开好迭代回顾会议需要充分做好这些环节。具体如何做,请见下篇:如何开好迭代回顾会议(2)准备、工具

    展开全文
  •  如何开好迭代回顾会议(1)(2)所介绍的通用迭代回顾会议,都是从解决问题出发而使用的回顾议程与工具。事实上,并不是每次迭代回顾会议都必须是解决问题。你偶尔可以帮团队换换口味。  学习型  学习型迭代...
  • 回顾2016

    千次阅读 2017-02-22 00:15:22
    已经年快三周了,心里总感觉特别扭,想来想去,还是给自己的2016年写个总结,这样心里也好过一些。总的来说,在2016年里,各个方面做的并不是那么理想,可能是自己到了这个年纪,需要考虑的方面比较多了,遇上了...
  • 敏捷回顾会:经验教训的总结

    千次阅读 2017-11-02 21:02:59
    敏捷回顾会:经验教训的总结 原文:Agile Retrospectives: Lessons Learned 在一个sprint中哪些方面做得,哪些方面做得不好,哪些方面需要提高?在每一个敏捷回顾会中都应该回答这些问题。 ...
  • 02.敏捷回顾——为团队量身定做回顾检视笔记 00.如果你是一名教练或迭代开发团队负责人,你可能在每个迭代开发结束后组织你们自己的回顾检视,或许你们在团队成员之间轮流做回顾检视的主持人。无论哪种情况,...
  • C语言基础回顾

    千次阅读 2020-03-09 16:22:40
    想来想去,移动端 音视频肯定火,你想想,你坐着高铁着用不完的 流量看着 4k 甚至是清晰度更高的视频,什么感觉。 所以不用多说,音视频很重要。 Android音视频开发需要C/C++语言基础,故写此文章回顾C/C++内容...
  • Redis回顾

    千次阅读 2017-01-18 15:10:42
    之前有两篇文章着重介绍了redis集群的搭建和redis与spring的整合,一个月过去了,现在有些忘记了,今天又拿过来稳固一下,发现有很多的东西都忘记了。...这样避免版本冲突问题。解压最新版本的rub
  • 回顾存储过程

    千次阅读 2013-07-16 23:34:34
    回顾存储过程    存储过程( stored procedure )如果使用的是存储过程那就很方便来修改 sql 语句,直接在服务器上修改,而不用再到程序中修改,然后再保存,存储过程可以一定程度的保证数据的安全性。 ...
  • 2011 IT娱乐界回顾

    万次阅读 2012-01-06 18:21:14
    2011 IT娱乐界回顾1、前端浏览器 WIN7迅速普及是好事。至少IE8越来越主流了。这个稍微靠标准的家伙,不会也像IE6在未来10年不死? 不过也无所谓,反正PC和手机以后一半一半天下。 当然,手机iphone\android...
  • 回顾2013,展望2014

    千次阅读 热门讨论 2014-02-07 21:22:14
    终于在今天痛下决心,一定要完成年终总结这个任务,拖了太久的时间,再不写确实有点不合时宜了,这篇博客算是对我2013年的总结,同时是对新年的回顾 感恩 2013年在我人生中应该都算是重要的一年,因此更需要感恩 ...
  • 2007 开发语言技术回顾

    万次阅读 热门讨论 2008-02-18 16:52:00
    但一回顾就吓了我一跳。这种技术的繁荣,不亚于2002年。2002年的COM+、EJB、设计模式、ORM、MVC、软件工程、UML、自动测试、BUG跟踪、发布配置、项目管理,讨论了大一堆企业级开发技术和企业级开发过程管理。2007...
  • Sprint回顾会议的一种简单玩法

    千次阅读 2016-02-28 16:43:25
    sprint回顾会议的一种简单开法——只须问团队成员3个问题:他们想开始做什么?他们想停止做什么?他们想继续做什么?
  • 2013中国电商盘点回顾

    万次阅读 2013-12-16 16:06:52
    2013中国电商盘点回顾一、巨头1、阿里淘宝天猫支付宝:菜鸟仓储干线物流、大家电日日顺最后一公里物流、余额宝/互联网金融、淘品牌衰落/刷单/暴动、双十一350亿、美丽说/蘑菇街/逛导购类被打击、来往PK微信揭开移动...
  • 2018年回顾和收获

    千次阅读 2019-01-01 08:20:16
    现在时刻已经是2019年开始了1个...在大环境的寒冬来到,互联网行业没有以前那么了,每天都看到大厂裁员,小的公司倒闭。 在工作的技能方便,没有学到什么新的技能,还是靠以前的技术解决工作中的问题。买了几本书...
  • 拿了这套模板,边做边总结,做完再回顾,成长加速,快人一步。
  • 敏捷开发-回顾会议

    千次阅读 2017-06-22 14:52:44
    保持透明性、检视与调整是Scrum的三大支柱, 以此作为支撑我们才可以对整个开发过程进行持续的改善。回顾会议是Scrum检视与调整的一个重要的环节,在这个会议上,ScrumMaster鼓励团队在Scrum过程框架和时间范围内,
  • 回顾2017:谈谈过去一年的成长

    千次阅读 2018-01-07 22:54:09
    2017过去了,回顾2017希望能够看清楚现在的自己,在2018遇见更的自己。前不久支付宝的年度账单刷屏朋友圈,作为一名程序员,我也来晒晒我的2017年度技术“账单”。 2017年度成长“账单” Github:89 stars, 37 ...
  • 一年工作回顾及总结

    千次阅读 2012-10-15 17:30:03
    看到别人的工作总结,不错,分享下。 一年回顾: ...去年7月4号入职到现在已经有一年零2个月了,一直...昨天一个大学玩的比较的同学跟我讲起了他的创业,我也趁今天好好回顾总结下过去的一年,想到哪就写到哪吧。
  • Xamarin Evolve 2016 Keynote回顾

    千次阅读 2016-04-28 01:00:42
    Xamarin Evolve 2016 Keynote回顾
  • 我的2020年终回顾:人生,海海,破浪前行

    千次阅读 多人点赞 2020-12-30 21:26:35
    虽然没有静坐,也未曾三省,但是转眼一年过去了,按照惯例,还是要好好回顾一下这一年。 ✍ 写作 统计了下过去一年在 CSDN 发表的文章数,从年初疫情封印在家开始,到现在大约写了 90+ 篇,当然其中有不少 “水文” ...
  • 2018年前端开发回顾

    千次阅读 2018-12-21 09:22:36
    2018年前端开发回顾 摘要: 前端发展迅速,非常快! 原文:2018年前端开发回顾 作者:前端小智 Fundebug经授权转载,版权归原作者所有。 本文将回顾2018年一些重要的前端新闻,事件和JavaScript趋势。 ...
  • 回顾这一年

    2013-01-09 16:05:55
    回顾自己这一年多的工作,充满了辛酸,有各种无奈,也有些的事情。本人是2011年10月底在一个培训学校毕业的,学校名字就说了,免的说我打广告。毕业一个星期就进了一家公司,好像跟用友有点什么关系吧,具体不清楚...
  • 2018数学建模国赛回顾(国一)

    万次阅读 多人点赞 2018-11-18 10:30:14
    作为计算机专业的,其实一开始并没有想到要参加这个比赛,甚至一度认为这比赛特别高大上,特别难,而我数学学得又不太(虽然高数线代都是90+,但知道自己只是做题而已),所以潜意识里有点不敢参加。...
  • 保研夏令营回顾

    千次阅读 热门讨论 2018-08-09 12:52:17
    从去年十一月份开始打算保研,到现在...先说明一下我的情况,四川大学软件学院2015级本科生,其实大一大二的时候我是没有想到过保研,我是打算直接工作的,毕竟软件的本科生工作也那么找,但是大二下的时候辅导员...
  • 一个码农的2015回顾和2016展望

    千次阅读 2016-01-22 14:02:10
    一个码农的2015回顾和2016展望 前言 最近各地降温比较狠,面对霸王级寒潮大魔王,唯有解封封印多年的霸王级秋裤方可应对!大家注意保暖! 忙这忙那的,不过还是感觉啥也没忙,心里还是空空的,也许是件好事,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 105,368
精华内容 42,147
关键字:

如何开好回顾会