1）定期发布
定期发布上线，把整个项目划分为一个个迭代，每个迭代时间大小固定（基本固定），迭代结束时上线交付一次。
（2）迭代规划
迭代规划相当于整个迭代的计划，帮助我们管理并保证每个迭代的交付。
A.迭代规划的前提：
story沟通及验收条件的补充完成。
PM给出story的优先级
RD、QA给出story的估点，估点可取范围为（1、2、3、5），若有大于等于5点的story，尽量拆分成更小的story。
B.迭代规划
估算团队交付能力（通常经历几个迭代，团队的交付能力就会很明了了）：基于“昨天的天气”（很可能他们在当前迭代完成的工作量与上一个迭代相同，除非工作 环境或是团队构成发生重大变化）和常识，估算自己能够在当前迭代中完成多少工作。然后团队就会基于自己的工作交付能力，选择当前迭代要开发的工作。
有了团队交付能力值，便进行以下步骤安排本迭代的工作：
按照优先级顺序，列出story，并注明它们的故事点数大小。
判断一个迭代中可以交付多少故事点数。
考虑团队需要完成的非用户故事工作可能产生的影响，比如在早期的迭代中，由于工具和工作环境不到位，工作效率会受到影响。
向计划中加入一个新的迭代。
向迭代中加入故事，直到用掉所有的工作能力。
询问：是否所有的故事都已经解决、版本发布目标是否达成。
如果没有，那么向计划中加入新的迭代，并重复步骤5和步骤6.
一旦所有的故事都已经分配完成，与大家就计划进行交流，并征求他们的反馈，看看这些计划是否现实并且可以完成。
PS：通常只会进行到第五步，剩余的stroy放入需求池，下个迭代启动时再规划。
（3）每日站会
站会的目的有三个：
（1）周知进度
仅从用户故事和任务的层面周知进度，任务进度只有两种状态：完成或未完成（完成百分比）。
（2）周知计划
你将会在下次会议之前做哪些工作？
（3）抛出问题
哪些东西阻碍你的进度？（“没有问题”，意味着你能够交付自己当前的任务，而且符合估算的时间范围）如果遇到需要解决的问题，可以在每日立会之后处理。
实现一项目的必要前提：
1.站
2.敏捷项目必须提供能够“安全失败”的环境，团队成员不会因为没有达成任务承诺遭受惩罚。
大家要能够安全说出任务状态的真实情况，并且了解项目环境的现实情况。有时，我们的估算可能很糟糕（只是估算而已，又不是承诺），又或者某些事情的发生让某些成员无法完成任务，整体环境必须让他们能够说出真实情况，这样团队成员就能调整他们的日程表，将任务排序，并调整适应项目的现实。
站会的主要内容：
从PM、RD到QA，每个人发言，内容为：1. 昨天干了什么，2.遇到什么问题，3.今天准备干什么。如果有想要分享给大家的知识，也可以在此分享。
最后主持人总结一下，然后根据实际遇到的问题，少数人进行线下沟通、跟进、解决。
站会的时间尽量控制在十分钟左右。
开站会的一些技巧
（a）轮流主持
轮流主持能提高团队成员的参与度，且如果主持人临时有事，也不会因此无法开展，通常每次站会结束时指定下次站会的主持人。
（b）解决问题不放在会议中
会议中仅抛出问题，解决问题放在站会结束后，相关人参与。目的是避免浪费大家的时间。
（c）早上举行
可以让所有人按时来，按时工作。
可以让每个人更清楚今天自己该干什么。
晚上每个人进度不一，作息时间不一样，早上说昨天干了什么更准确。
