不了解Scrum模式的可以查看敏捷开发流程总结
看完后就可以实战起来了，本人经过2月的实战后发表一些自己四个会议步奏上的一些问题和心得：
1.迭代计划会议。每个迭代启动时，召集整个开发团队，召开迭代计划会议，所有的团队成员畅所欲言，明确迭代的开发任务，解答疑惑。
实战问题：畅所欲言会导致一个人拖延很长的时间。
我的答案：尽量明确到可落实的点，减少对其他无关人员的时间浪费，细节会后说。
例子介绍：商家列表有个排序的功能，有人提出是否可以用置顶来代替此功能？可以作为替换方案，具体方案细节会后讨论。（记录下来点子）
重点：明确迭代的开发任务，解答疑惑。让所有人理解上达到一致，才能做出想要的产品。
2.站立会议。每天早上，所有的团队成员围在Story Wall周围，开一个高效率的会议，通常不超过15分钟，汇报开发进展，提出问题，但不浪费所有人的时间立刻解决问题，而是会后个别沟通解决。
实战问题：因为每天都开，所以也许执行力度不高，或者说有可能团队只会在有任务的情况下开此会议。
我的答案：我建议是每天都开，把这种会议养成一种习惯最好了，没有任务的情况下，可以让下面的研发，对已有的功能模块进行优化或者重构，还可以叫研发自主学习新的技术（以后可以分享给团队）或者研究下个项目需要的功能等。
重点：汇报开发进展，提出问题，但不浪费所有人的时间立刻解决问题，而是会后个别沟通解决。
3.总结和反思。每个迭代结束以后，项目组成员召开总结会议，总结好的实践和教训，并落实到后续的开发中。
实战问题：每当开这个会议的时候大家一般会一言不发。
我的答案：这时候应该提出几个问题，让每一个人员都参与进来，一个一个说。这个会才有意义。
4.演示。每个Story开发完成以后，开发人员叫上测试人员，演示软件功能，以便测试人员充分理解软件功能。
目前没有开过这个会议，都是走测试流程。。。
以上都是我个人的一些心得，有异议的可以留言我会及时回复，我的答案并非标准答案，不喜勿喷。
接受失败，是我们不常听到或看到的一个命题，
