文章目录
  1. 1. 站会的形式
  2. 2. 个人的更新
  3. 3. 一些tips

Stand up meeting作为敏捷项目开发中的一个重要实践不可或缺。站立会议每天都要发生,在会议上大家可以了解到每个人的工作进展、项目遇到的concern和issue,从而做出适应的资源调整和措施,保证项目交付的顺利进行。如何让站会变得高效,本人总结了一些tips,希望对大家有用。

站会的形式

一般站会分为两个形式。一种是在站会上每人轮流进行各自的状态更新,另一种是以story wall上的user story为主进行更新。
第一种好处是每人都有更新机会,但是更新的内容稍显混乱,第二种好处是通过卡片追踪能更清晰的了解到当前的状态,不好的地方是如果有人的工作任务没体现在卡片上,可能就没机会得到更新。

我个人比较倾向于第二种更新方式。一个典型的story wall有这些列: BACKLOG->BA->DEV->TEST->UAT->DONE。站会开始的时候,由一个facilitator按照从DONE->UAT->TEST->DEV->BA的顺序依次念出这些故事卡,被点到的故事卡则由工作在这张卡上的人进行相应的更新。之所以采用倒序是出于精益的思想。我 们敏捷的迭代式开发就是要将story card尽量的往done column里挪,采用倒序过卡的方式就是要突出这一点。当将墙上所有的卡都过完后,facilitator可以再问下有没有其他人有update,这样可以防止有些人由于工作不能体现在卡片上而漏掉更新。比如迭代经理可以此时做出自己的更新。最后facilitator再问还有什么问题或风险没,此时可以把自己的一些想法表露给团队,好借团队之力拿出应对方案。

个人的更新

个人的更新注重言简意赅,突出重点。一般更新需要包括下面三点。

  1. 昨天做了什么。这个只需2句话带过,切忌陷入细节。

  2. 有没有遇到问题,需不需要资源或帮助。如果遇到什么困难,可以大概描述下,并指出需要什么样的帮助。

  3. 今天打算做什么。

一些tips

  1. 站会一定要站着开。凡是坐着的会议都短不了。

  2. one conversation. 站会上的时候一定要保证同一时刻只有一个人说话,切忌变成了群体讨论。做法可以是将一个小玩具作为token,只有拿着这个token的人才可以说话。

  3. 限制每个人更新的时间。有些人在更新自己工作状态的时候喜欢讲的很细节,无形中浪费了很多时间。这时候facilitator就需要适时的打断他,可以告诉他只要给出大概的内容进行,细节部分可以会后再讨论。

  4. 团队中成员轮流当facilitator。一般团队中喜欢固定一个人当facilitator,一当就当到了项目结束。其实更好的做法是每天站会时都要更换facilitator,这样保证每个人都能充分参与到团队中。

  5. 站会不能迟到,也不要定在刚上班时。刚踩着点进办公室就迎来站会略显紧张,很多人还没调整好状态。
    一般可以将站会定为早上上班15分钟后。

  6. 凡是可能花时间的讨论都不要发生在站会上。站会只是专注状态更新,暴露问题,而不是解决问题。针对会上暴露的问题可以再组织相关的人商讨解决方案。

  7. 切忌将站会流于形式,失去原有的意义。站会注重的是team间横向的沟通,并且每天都会发生,如果不能坚持就说明了团队间配合出现了问题,失去了快速反馈的意义。

文章目录
  1. 1. 站会的形式
  2. 2. 个人的更新
  3. 3. 一些tips