软件开发平台 DevCloud软件开发平台 DevCloud

更新时间:2021/03/18 GMT+08:00
分享

敏捷回顾,只为更好地冲刺

在Scrum中,评审会是说在一个Sprint结束以后,进行Sprint评审,团队在此期间展示他们所完成的工作、可运行的软件。参加评审的应该有Product Owner、开发团队、Scrum Master,加上客户、项目管理者、专家和高层人士等任何对此感兴趣的人。

会议可以是10分钟,也可以持续两个小时。因为会议目的只是对所做工作结果的展示,并听取反馈。

为什么要演示?

演示主要是出于这样几个目的:

演示可以让那些虽然不直接参与Sprint的利益相关者,获得团队工作的最新进展。这里提到了利益相关者,就意味着你可以随意邀请任何没有直接参与Sprint工作的人,只要相关。

演示可以让客户或者Product Owner对你们所做的工作提供最直接的反馈,这样可以让Scrum团队,根据反馈更新产品Backlog,在下一个Sprint中融入新的需求变化,并将这些反馈带到下一个Sprint的计划会议上。

同时,演示是一个很好的机会,可以让团队庆祝他们在过去的Sprint中所取得的成就,鼓舞团队的士气。

团队不需要准备一个非常华丽的演示,只需要展示团队刚刚完成的最新功能即可。不需要额外修饰,只要让人印象深刻,就已经足够了。总之,这不是一个产品发布会,不需要制作一个非常炫目的演示。

不要仅仅从字面上理解“演示”这两个字,范畴可以更广一些。这里的“演示”,还可以是对下列事情的回顾:如一个新建的编辑页面、一个新写的小工具、一份说明文档或其他任何具体的、可以让该团队感觉到有价值的东西、或者是你们工作过程的截图等!

演示要安排在Sprint回顾会议之前。此外,更重要的是要让这个演示会议充满乐趣,不能搞成批斗会。

Sprint回顾会议

Sprint回顾会议与平常我们经常提到的项目总结会议不同,它不是要对项目进行盖棺定论,而是通过及时回顾,总结上一次冲刺中的得与失,找到改善与提高的办法,从而让下一个Sprint走得更好。第一点是找出在上一个Sprint中做得好的地方,并继续保持。分析那些成功的流程是非常重要的,这样我们才能有意识地保持下去。只有团队中的每一个成员都清楚什么是最佳实践,才能有效地保持这些实践。除了鼓舞士气外,还可以避免把回顾会议变成消极的抱怨会议。第二点是找出上一个Sprint中需要改进的地方,以及对应的改进措施。回顾的目的是持续不断地改进,这也是敏捷开发的主要理念之一。让我们想一想如何才能在下一个Sprint中更加有效率,想一想如何做才能与上一个Sprint不同。收集任何可以量化的数据,以便于做定量分析,推动改善。

  • Sprint回顾会议指导原则

    首先,一定要明确这样一个指导原则。即“无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源,以及现状,我们理解并坚信:每个人对自己的工作都已全力以赴”。

    对团队成员的绩效评估,当然不能采用这样的指导原则。我们现在谈论的是Sprint回顾,回顾的最终目的是学习,而不是审判。如果敏捷回顾没有坚守这样的“指导原则”,倡导团队成员首先要信任自己的伙伴,已经尽了最大努力,就会让回顾会议成为互相攻击、互相推诿的批斗大会,脱离了我们召开回顾会议的初衷。

    “指导原则”就是为回顾会议竖立一个标杆,那就是在项目开发中没有破坏者,没有替罪羊,没有关键人物,只有整个团队的利益。虽然某个人或许在上一次迭代中出现了错误,但我们会善意地相信此人之所以犯下错误,并非有意为之或者消极怠工,而是囿于当时之识见、经验、技能。我们的回顾会议必须指明这些错误,并试图寻找到最佳实践以避免在下一次迭代中犯同样的错误,而“指导原则”则能够消除因为指出他人错误时给成员带来的负疚感,消除同事之间可能因此出现的隔阂与误解。换句话说,回顾会议提出的所有批评都应该“对事不对人”。

  • 组织Sprint回顾的方法

    组织Sprint回顾最简单的方法是找个白板纸,在上面注明“哪些项工作顺利”“哪些项工作不成功”或者“哪些项工作可以做得更好”,让与会者在每一类别下增加一些条目。当条目重复时,可以在该项旁边画正字累计,这样普遍出现的条目就一目了然了。最后团队成员共同讨论,找寻这些条目出现的根本原因,就如何在下一个Sprint中改进达成一致意见。

    其实,敏捷回顾的主要目的就是明确目标、持续改进和处理问题。敏捷开发之所以采用迭代的方式,实际上是利用蚕食方式逐步完成开发任务。将一个宏伟的目标切割为一个个小目标,会给予团队成员更大的信心,并且能够更加清晰地明确目标。而每次迭代后的回顾,使得团队成员可以更加清晰地明确我们在这个征途中,已经走到了哪里,未来还有多远的路程。当然,也可以用ORID(Objective Reflective Interpretive Decisional,焦点呈现法,一种沟通引导方式),结合“心情曲线”、4F、4R等玩法,要让你的回顾会多样化,避免形式上的千篇一律。另外,地点的选择也可以多样化,不一定总是在公司会议室开,可以去咖啡厅、水吧,甚至是公园的草坪,团队建设的饭桌上。关键就是要灵活多变。

敏捷回顾的要点

  1. Sprint评审会议不是让开发团队做成果“演讲”:会议上不一定要有PPT,最好是直接做产品演示。会议通常不需要超过30分钟的准备时间,只是简单地展示工作结果,所有与会人员可以提出问题和建议。
  2. 在Sprint评审之后,开发团队会进行Sprint回顾。有些开发团队会跳过此过程,这是不对的,因为它是Scrum成功的重要途径之一。这是提供给开发团队的非常好的机会,来讨论什么方法能起作用,而什么不起作用,就改进的方法达成一致。
  3. Scrum开发团队,Product Owner和Scrum Master都将参加会议,会议可以由外部中立者主持;一个很好的方法是由Scrum Master互相主持对方的回顾会议,可以起到各团队间信息传播的作用。
  4. 敏捷回顾不能是一场没有主题的讨论会,这样的形式对于项目进展没有任何帮助。
  5. Scrum回顾会议的参考议程。
    • 在白板上写上主要指导原则。
    • 在白板上画上一个至少三页纸连在一起长的时间轴。
    • 在第一页上写上“我们的成功经验是什么”。
    • 在第二页上写上“有什么能够改进”。
    • 在第三页上写上“谁负责”,然后分成两个区域,分别是“团队”和“公司”。
  6. Scrum回顾会议的指导原则。即“无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源,以及现状,我们理解并坚信:每个人对自己的工作都已全力以赴”。
  7. 在项目过程中,问题处理得越早,那么付出的代价与成本就越小。通过回顾会议,利用团队成员互相善意地“敲击”,或者反复“锤炼”开发过程与方法,就能够让每一位成员练就“火眼金睛”。
  8. 进行Scrum回顾时,发现问题仅仅是第一步,我们还要在回顾会议中合理分析这些问题出现的原因、所属类别,并因此划定问题的“责任田”。我们要明确这些问题是团队内部的,还是由于外在因素导致的,也就是说要明确“责任田”的归属,指定责任人和处理时间,一定要SMART。
  9. 在每个Sprint开始的时候,我们都要明确,当Sprint结束的时候需要演示的是哪些东西。很多时候,如果一个Scrum开展得不是很顺利,在Sprint演示的时候我们常常会听到这样的理由,“因为某些原因,这个功能我没有办法展示给你,但是这个功能是有的,我只需要改动小小一点东西就可以了”,或者是“这个部分与另一个系统相关,我代码已经写好了,但我要一起改好了你才可以看到”。如果放任的话,这些理由到后期会泛滥成灾。我们所能做的,除拒绝通过这些相关的需求之外,在每个Sprint开始的时候还应该帮助团队了解到我们需要在Sprint演示会议上看到什么东西。强调我们重视的是可交付的软件版本,而不是一个口头上的功能实现。
  10. 回顾会议要灵活多变,可以采用ORID技术,结合心情曲线、4F和4R等玩法, 一定要让你的回顾会多样化 !

评审会议与回顾会议

评审会议的目的是获取相关人员的反馈,是迭代进度展示,同时给业务方,以及高层领导以信心(这点很重要,要想清楚谁是团队的投资人),是团队进行阶段成果展示以及进行庆祝的机会,“鸡类”角色与“猪类”角色都要参与。评审的目的是获取反馈,回顾的目的是学习改进。

演示并不是评审会议中最重要的一环,更重要的则是审视,调整计划以适应当前的情况。

两个会议都是仪式感的体现,是每个Sprint不可或缺的。两个会议纪要都应该有专人记录,并通过邮件公开发出,如果有可能,通过工具记录在本Sprint的信息中。

两个会议都是必要的,如果两者一定要比较,我认为回顾会议会更重要一些。评审会是针对业务层面的,面向结果的;回顾会是针对团队层面的,是面向过程的;磨刀不误砍柴工,从长期来讲,持续的学习和改进,最终对业务输出会产生根源的影响。科恩(Mike Cohn)说:“有时,我以为衡量一个团队敏捷实施质量的最好标准是看他们对待回顾会议有多认真。”

另外的一个例证是,关于回顾会议,有专门的一本《敏捷回顾》来讲如何开回顾会议, 而评审会议则没有专门的图书。

安全度检查

回顾会议中,最重要的是要能听到真话,要为团队成员创造一个敢于畅所欲言的氛围, 即安全感。

安全度检查,是回顾会议中很容易被忽视的一个环节。安全度检查,是将安全性从“愿意畅所欲言”到“想保持低调”分成几个不同的等级。会议开始时,所有团队成员将其自身感觉所处的等级,匿名写在一张纸片上,折好交给会议组织者。由组织者统计安全度。如果等级都比较高,回顾会议可以继续开;如果有较低等级出现,哪怕是个别人,会议组织者需要考虑是否取消本次会议,或者采取一些措施,让大家放松下来, 直到安全等级都比较高以后,再进行会议。

如同Blameless Post Mortem(无指责的事后分析会议),关键是营造安全的氛围和文化。每个人都不用担心自己会承担风险,可以自由地表达意见,并提出不会被评判的问题。需要提供一种保护文化,使团队成员可以畅所欲言,大胆尝试。在这里,管理者起到至关重要的作用。

安全文化的营造,也与学习型组织和个人成长型思维等密不可分。

持续改进

回顾会议是Scrum中进行检视与调整的一个重要的环节。

会议应该面向未来,而不是简单的对过去进行回顾,回顾主要的目的还是为了改进。

改进不宜太过贪心,建议每个人针对每个方面,不超过三条,但不能一条不写。如果安全度较低,也可以尝试不记名的方式。针对提出的问题,可以用计点投票法,得票高的三个问题进入讨论环节。可以进行头脑风暴,进行五指表决法等;对回顾会议输出的改进点,可以统一维护到产品Backlog,作为特殊类型的需求,与技术故事对应的技术债务一样,流程也存在债务,需要定期偿还;团队可以决定每个迭代固定做多少比例的流程改进故事,多少比例的技术故事。回顾与改进,应该变成团队承诺,每个迭代,都必须有所改进,积少成多,聚沙成塔。

此外,回顾会应该尽量保证会议聚焦,并且高效;但偶尔举行大团队的回顾会也是有益的,可以保证在更大范围内获取改进建议和经验分享;这类会议开销较大,通常以季度为周期即可。

回顾会议也有一些小的游戏环节,例如心情卡片,用一个词形容你现在的感受;或是感谢环节,每个人通过写卡片的形式感谢他人对自己的帮助,或是对团队做出的贡献。

本文内容节选自《敏捷无敌之DevOps时代》,作者:王立杰、许舟平、姚冬(清华大学出版社)。

分享:

    相关文档

    相关产品