回顾会议(retrospective)中最容易被忽视的一个环节

很长时间没有更新博客了,一直在上海,上星期刚从客户现场回Office。在很多刚刚开始实践Agile的团队中,有这么一种想法:“Retrospective太花费时间了,所有成员在那里开上一两个小时的会议。在会议上,要么大家发发牢骚,要么项目经理讲讲话,强调一下后续工作中的注意事项。还不如回写座位上写代码来得直接呢。”

其实,如果有这样的认识,说明团队还不成熟。如果没能发挥这一实践的重要作用,那么可能比"不会做TDD"有更严重的后果。

什么是 Retrospective ?

What is a retrospective?

在敏捷开发的上下文中,Retrospective翻译成中文就是回顾会议。回顾会议可以鼓舞士气,发现改进点,使团队在接下来的迭代或 Release更有效且高效地交付价值,一般在每个迭代或release之后进行。

Retrospective (from Latin retrospectare,“look back”) generally means to take a look back at events that already have taken place.

In the software world,a retrospective is a meeting held with a project team at the end of a project or process to discuss what was successful about the project,what could be improved,and how to incorporate the successes and improvements in future projects.

In the agile software world,a retrospective is a meeting held by the project team at the end of every iteration/sprint to discuss what we learnt as a team,what we can improve as a team and plan the future iteration/sprint based on this learning.

Safety check(安全检查)──回顾会议中最容易被忽视的一个环节

什么是安全检查?为了达到回顾会议的目的和积极效果,会议组织者有必要在会议开始之前做一次“检查”,确保团队所有成员真正认为在这个会议上的任何发言都不会影响到个人声誉与绩效,不会受到鄙视等,即“在这个会议上发言是安全的”。

如何做Safety check?

做Safety check有很多种方法,其中一种就是:

1 在会议开始之前,会议组织者可以分别与团队成员沟通,讲清关于回顾会议的目标与过程。

2 将安全性从“愿意畅所欲言”到“想保持低调”分成几个不同的等级。在会议刚一开始,由所有团队成员将其自身所处的等级写在一张纸片上,折好交给会议组织者。由会议组织者统一计算各等级所得的票数。

3 如果等级都比较高的话,回顾会议可以继续开始。如果有较低的等级,会议组织者可以考虑取消本次会议,再定时间开会,或者采纳一些活动,让大家放松下来,直到安全等级都比较高以后,再进行会议。

对于一个成熟的Agile团队来说,一段时间后做一次Safety check是非常必要的。对于一个不成熟的Agile团队,最好每次都做Safety check.

另外,牢记“不要把Safety check做成形式主义,请想各种办法达到Safety Check的目的”。

至于“每次回顾会议到底应该花多长时间?”这个问题,很难给出一个标准。不过,一般来说,如果每个迭代时间都比较短(比如一个星期),可能只花15分钟就够了,因为大家很容易回想起刚过去的五天里都做了什么。如果每个迭代时间较长(比如一个月),可能就需要两个小时,甚至更多一些,因为大家要回想一个月中都做了什么,而且对于同一件事,每个人所记忆的内容可能也不相同,讨论之前的同步过程还需要时间 ;D。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结;使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性;设计模式使代码编制  真正工程化;设计模式使软件工程的 基石脉络, 如同大厦的结构一样;并不直接用来完成代码的编写,而是 描述 在各种不同情况下,要怎么解决问题的一种方案;能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免引
单一职责原则定义(Single Responsibility Principle,SRP)一个对象应该只包含 单一的职责,并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强烈推荐。原文截图*************************************************************************************************************************原文文本************
适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题,总结出来的一套通用的解决方案。
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容易使用。
单例模式(Singleton Design Pattern)保证一个类只能有一个实例,并提供一个全局访问点。
组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构,使得客户可以用一致的方式处理个别对象和对象组合。
装饰者模式能够更灵活的,动态的给对象添加其它功能,而不需要修改任何现有的底层代码。
观察者模式(Observer Design Pattern)定义了对象之间的一对多依赖,当对象状态改变的时候,所有依赖者都会自动收到通知。
代理模式为对象提供一个代理,来控制对该对象的访问。代理模式在不改变原始类代码的情况下,通过引入代理类来给原始类附加功能。
工厂模式(Factory Design Pattern)可细分为三种,分别是简单工厂,工厂方法和抽象工厂,它们都是为了更好的创建对象。
状态模式允许对象在内部状态改变时,改变它的行为,对象看起来好像改变了它的类。
命令模式将请求封装为对象,能够支持请求的排队执行、记录日志、撤销等功能。
备忘录模式(Memento Pattern)保存一个对象的某个状态,以便在适当的时候恢复对象。备忘录模式属于行为型模式。 基本介绍 **意图:**在不破坏封装性的前提下,捕获一个对象的内部状态,并在该
顾名思义,责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为
享元模式(Flyweight Pattern)(轻量级)(共享元素)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结