1. 需求澄清会 顾名思义，就是澄清需求，但是人家就会问了，你没有 PRD 你澄清什么需求。简单点说，就是这个用户故事是有一定的颗粒度的，但是它在所有产品的设计者、开发者和使用者的理解下是没有歧义的。只要我们大家都确定了，我们要做的就是这样的一个东西那就没有问题。 因为用户故事都比较多，我们一般会把用户故事排一下优先级，然后根据优先级把用户故事分成几次 sprint 来做，就是不断地迭代。每次迭代的周期很短，一般是一周或者是两周，还有迭代出来的一定是一个可以使用的产品，可能功能有点缺陷，但一定是可以正常使用的产品。 2. 计划分析会 计划分析会，就是根据原型还有用户故事分 task。这个会议一般由 SM 来主持， 因为之前已经开过需求澄清会了，开发人员也知道了需要开发什么样的产品，这时候就可以根据每个用户故事对着原型分任务了。 需要注意的是：这里的每个任务都是开发人员自己分给自己的，比如：后端开发看到这个页面，需要写几个接口，每个接口大概需要多少小时，需要前端人员如何配合，这都是需要在这个会议搞清楚。所以为了后续的正常开发，这个会议一般都会比较长，大概需要 4-5 个小时左右。 3. 站立会 这个是每天都需要开的会议，每个项目成员都说一下自己昨天做了什么工作、今天做了什么工作。 这个会议的话主要是前端开发和后端开发之前的互相配合，就是为了避免前端已经撸好了一个界面但是没有接口对的尴尬情况。 4. 评审会 主要是进行本次迭代的功能评审，对照用户故事，我们是不是已经完成了这几个用户故事所说的内容。 5. 回顾会 分析这次迭代我们团队有什么优点、有什么缺点、可以怎样改进，产出对应的改进措施。
许可协议
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。
分享文章
