Scrum 的每日例会 和 故事墙

项目组一直在推敏捷开发，但发现一个关于每日例会的问题。

 

场景：

　　每日例会是早上9：00, 把大家召集起来，这时有个主持人（每日轮流), 一个一个询问团队成员昨天做了什么，今天做了什么， 并记录在一个本子上。

　　有时大家比较忙时，主持人会一个个去询问团队成员工作状况。

 

问题：

     每日例会不应把每日的进度放到一个本子里，这会导致没有多少人去会关心进度问题，想了解进度的人（比如上级领导）也只能找项目经理，而他也只能凭个人感觉说出来；

     不应该有个主持人，这会导致主持人过于繁忙，而其他人投入度降低（只关注自己的问题），建议每人个人主动去讲解自己的工作和计划，主动，自发和自组织，这才是关键；

     最糟糕的是，主持人挨个询问，这压根就不能叫站立会议（只有主持人站着），只能叫任务跟踪。

     总结：站立会议 没有 故事墙，是没办法把站立会议的成果 贡献出来，这样会导致反馈不足。

 

解决办法：

     建立故事墙，把故事分解成一个个小任务，并按优先级从上到下排列。标明未处理， 正在处理，已完成的任务。

     团队成员必须都到故事墙前，轮流讲解。  自己昨天做了哪些任务；完成了那些；未完成的任务（为什么没完成？，需要什么帮助？，或换人认领？），今天打算干什么（把一些未处理的任务移到正处理栏），最后如果有什么心得可以分享给大家，如果有苦难也要及时求助。（任务标签也可以写上checkout 的名字，不是为了跟踪，而是为实时知道谁在做哪个任务好及时沟通）。

故事墙更进一步的思考：

故事墙过高：

     有些项目把故事墙放到很高，为什么要放这么高？我总结为：这个跟他们的位置有关系，因为他们是做成一条线的， 为了让远处的成员也能看到，就把故事墙放高了。

　　这里有个问题是：他们的座位不合理，坐成一条直线，不利于最好的沟通 ；

     故事墙放过高也不好，看不清楚，修正故事 也不方便。

 

可升降故事墙：

      使用可升降的故事墙；如果高优先级的故事完成了，可以上升故事墙；人们就可以关注到现在要关注的故事，而不是已完成的。

      想想这也有问题，为什么要升降，是不是说明当前sprint中的故事太多了呢？ 这应该是提示.

      如果sprint 可以完成，说明sprint 周期太长了，可以缩的更短些（缩短反馈周期);

      如果sprint 不能完成，说明sprint 承诺的太多了。

      sprint 能不能完成可以从 burndown 燃尽图看出来，如果曲线在 计划斜线的上方，说明是承诺太多了，要减少故事。