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)早上举行
可以让所有人按时来,按时工作。
可以让每个人更清楚今天自己该干什么。
晚上每个人进度不一,作息时间不一样,早上说昨天干了什么更准确。