敏捷团队在一种高度合作的自组织环境中相互协作。个人适应新方法和流程的能力为其在团队中的成功奠定了重要基础。对同一项目组成员的行动做出及时反馈确实可以帮助我们作出正确反应以达成项目目标,并且可以有助于维持团队内积极互助的良好氛围。
在年终或半年评估的晚些时候所提供的反馈对帮助个人在同样一个项目中取得成功的效果微乎其微。在自组织团队中,进行持续反馈可以为个人大幅缩短反馈路径,并使他步入持续改进的正轨。同时还可以促进在团队成员间形成开诚布公的健康范围,这对于一支敏捷团队去学习和快速适应,从而将其潜能发挥至极致至关重要。
如何组织反馈?
反馈可大致定义为:有关过去的行为在现时的反映,并可能对未来的行为产生影响。
人际间的反馈可能是对反馈信息接受者行为的正面或者具有建设性的建议。正面反馈相对更容易分享,但是迫于项目交付过程中的压力往往会被忽略,而这些正面反馈对于鼓励团队成员继续努力工作往往会非常重要。
从另一方面来说,对于一个人的建设性反馈意见往往是比较难以分享的,需要找一个合适的时间和地点来做适当的表达。
组织良好的反馈应该是有关接收者在过去行为表现的信息。反馈者应根据实际情况客观地描述接收者过去行为的一些影响,并提供他 / 她自己的意见看如何能够更好的处理相关问题。关键点在于不要对行为本身做判断。
组织形式欠佳的反馈示例
反馈者:“你每天的更新都没什么用”
较好的反馈示例
反馈者:“我觉得你是不是能够在每天的更新中提供对前一天的更清楚的总结。对故事的进展有一个更高层次的更新,并且讲一下你需要帮助的一些障碍,这样的话可能会在内容上有个好的开端。”
交流反馈的最佳时机
找准时机互相交流反馈与反馈的内容本身一样重要,因为这有关反馈所收到的成效。在某个典型的敏捷项目中,很多情况下可以会实现一对一的及时反馈。
两个开发人员直接的反馈最好是发生在配对编程过程中,此时发送者和接收者都同时面对代码。反馈者可利用配对的机会来为接收者演示如何改进有关代码形式、规则、技术设计等。
在一个跨部门的团队中,不同角色的成员相互交换有关流程进展的反馈同样重要。例如,某开发人员可能会觉得用户故事的接受标准或许可以再做进一步细化,或者可以将用户故事分成若干个更小的部分。这样的反馈对于业务分析人员或产品所有者可能就很有用处,这些人员进而可以适应开发团队的工作方式或偏好,反之亦然。
Fred(开发人员)对产品所有者说:“这些用户故事范围太广了,很难去开发。”
Fred(开发人员) 对产品所有者说:“我觉得这些用户故事的范围太广,可以将他们拆分成几个相对小点的故事。小故事可以有助于我们更快的进行开发并且我们可以定期地向你反馈开发进展。”
反馈不宜在关键事件发生后拖延太久再进行。但很重要的是,在反馈提出之前要在正确的时间找到接收反馈信息的人。
但是当团队工作紧张压力巨大的时候可能这样的反馈未必能及时进行。这时候团队就应该利用 Sprints 或是 Release 的最后阶段作为相互之间交换反馈信息的契机。
例如,我曾经工作过的一个团队,大家利用临近冲刺回顾的 15 分钟时间相互进行了积极的反馈交流。然而,我不鼓励经常直到回顾时间才进行交流反馈。
交流反馈的技巧
在交换反馈意见的时候可以有多种形式,包括正式的和非正式的。
一对一反馈
与团队成员进行一对一的会议或许是进行反馈的最佳方式。这种方式可以在项目的某些固定时间点进行。有些团队就觉得维持这种一对一的会议来跟踪反馈的方式非常管用。
集体反馈
对于团队来说很重要的一点是大家都能坦然接受在集体讨论之前所相互反馈信息的基本内容。团队可以在集体会议(如回顾)上开始交换一些积极的反馈意见。而建设性反馈意见最好是在集体讨论之外进行。
书面反馈
有些人可能无法立刻接受彼此间口头交流的反馈意见。这在新人中比较常见,他们还不是很熟悉高度合作和开发的环境(如敏捷)。鼓励他们进行定期的反馈练习很重要。作为第一步,他们可以选择将反馈以书面形式记录下来与其他团队成员分享。
团队可以在 Sprint 或 Release 阶段抽出一些时间来交流书面反馈(以大家认可的形式),可以使用 email 甚至可以用封好的信封。
例如,有一个小窍门就是,你可以使用两张卡片纸,一张粉色一张绿色,分别代表建设性反馈意见和积极反馈信息。每个人依次分发两张,每天选一名队员,要求大家对他写下反馈意见。接收者就可以直接收集这些卡片或者可以选一名队员(如果他 / 她愿意的话)让他 / 她读出自己的反馈意见。
反馈训练
训练大家持续反馈之道是建立团队或组织良好反馈氛围的关键。让大家都意识到怎样才算“组织良好”的反馈很重要。
一支团队往往由不同个性的人组成。外向型的人会比较擅长发表自己的意见,而内向的人则会觉得有些困难。有些人对批评持开放态度,而另一些人一听到建设性意见反馈就显得比较抗拒。
身体语言在决定反馈信息如何被理解方面也相当关键。例如,如果你要传达的信息要表示其严重性和可靠性时,眼神的交流就很重要。
选择恰当的时机来交流反馈意见同样很重要。某个团队成员可能已经经历了繁忙混乱的周一工作时光,这种时候他可能不愿意聆听有关我们如何改进他技能的相关反馈意见。应该为反馈者和接收者找一个恰当的时间来进行详细的讨论,而不被外界打扰。要做到“给意见之前先询问”非常重要,从而将其转化为一种善意的询问,以下就是个很好的例子:
Chris:Steve, 我想跟你谈谈有关昨天配对的一些事宜。你现在方便来讨论吗?或者你觉得什么时间比较方便?
训练还应包括提供一种安全的环境,不同个性的成员可以在其中练习如何交流反馈意见。在团队成员中进行模拟反馈或是角色扮演可以作为训练的一种框架。
从长远角度看在敏捷团队中营造持续反馈的氛围非常重要。所收到的反馈意见对于那些真正关心接收者工作和职业发展的人来说应被视为一种礼物。通过一段时间的交流,团队成员间应养成互相反馈意见的习惯。
参考书目
What did you say : The art of giving and receiving feedback - Seashore, Weinberg
关于作者
Anand Vishwanath (你可以在 Twitter @anand003 联系他) 是 Thoughtworks 的一名敏捷培训师及项目经理。他的职业生涯始于 2002 年,担任 Java 及.Net 的开发人员。Anand 为全世界敏捷项目的客户提供积极咨询服务和实施方案。有关他的相关经历请参见其博客。
英文原文链接: http:/www.infoq.com/articles/continuous-feedback-teams
感谢侯伯薇对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。
评论