以故事为焦点的站立会议

作者 Chris Sims 译者 郑柯 发布于 2008年9月30日

领域

过程 & 实践

主题

敏捷技术 ,

敏捷

标签

用户故事

每日站立会议是被广泛接受的敏捷实践。团队成员在其中分享：

• 上次站立会议后他们做了什么
• 在下次站立会议前要做什么
• 目前面临哪些障碍

Mike Cohn最近分析了站立会议的一些不同方式，这些会议将完成各个用户故事作为会议进程的一部分。

变种之一，是逐个报告各个故事的状态，而不是逐个人说明。Mike建议为每个故事指定一个“故事负责人”，即使有多人开发同一个故事，也由此人负责跟踪故事的工作进展。此人要在每次站立会议上说明故事的进展情况，至少要知道谁负责提供故事的最新状态。

另一种与故事状态联系起来的方法，是让团队成员指出他们的工作与哪个故事有关。要想推进这种方法，可以让大家在任务板前开会。任务板上的故事和任务之间的关系要保持清晰，当大家谈及自己的工作时，可以让他们指出自己处理的具体工作条目。

您的团队是否为了将注意力放在用户故事上，调整过每日站立会议的形式？请留下您的评论，告诉我们你们的具体方法以及产生的效果。

查看英文原文：Story-Focused Standups

译者 郑柯 InfoQ中文站总编。做过开发，当过PM，干过销售，搞过市场，最终还是回到媒体。实用的理想主义者，相信：每天改变一点点，这个世界会更好。

1. 返回顶部

   stand up meeting 上，是否真的需要每个人都说一遍自己昨天干了啥？

   发表人 Chan Jackei

   作为经常被提到的敏捷和精益，是否真的需要每个人都说一遍自己昨天干了啥？
   
   如文中所说：指定一个“故事负责人”，即使有多人开发同一个故事，也由此人负责跟踪故事的工作进展。此人要在每次站立会议上说明故事的进展情况，至少要知道谁负责提供故事的最新状态。 ──团队规模或者项目的复杂程度到了这个地步吗？team leader 自己无法跟踪全部的进度情况？还需要在一个敏捷团队中再指定一些负责人？
   
   另外，文中提到“让团队成员指出他们的工作与哪个故事有关”。既然敏捷实践对于每个迭代周期都会控制的比较短，那么作为 team leader，不清楚前一天 team member 做得事情跟哪个故事有关吗？
   
   如果一个 team leader 如上面所提到的工作，那说明他/她太不称职了！
   
   一个称职的 team leader，应该在每天早上的 stand up meeting 上，通过与 team member 确认上一日工作和未完成的工作，来确认如下问题：
   1.确认进度是否偏离，是否已经找到了偏离的原因和解决的方法;
   2.确认质量是否超出可接受的下限，是否已经找到了原因，是否准备立即解决;
   3.是否存在需要team leader来协调解决的问题;
   4.明确当前工作目标。
   
   但是作这个事情的时候，对于已经包含在计划中的工作，尽量避免反复的让 team member 来重复。

   回复

2. 返回顶部

   Re: stand up meeting 上，是否真的需要每个人都说一遍自己昨天干了啥？

   发表人 Chan Jackei

   不过文中提到的思路，关注“故事”而不仅仅是完成了什么，是有益的，避免开发人员只关注代码完成，而忽略了“故事”作为一个工作任务的整体性。

   回复

• 更早的 >