我们需要理解,在这里程碑可以是一个迭代,也可以是多个迭代,这和我们的规划相关。为了方便,我们在这里视一个里程碑为一个迭代,即“库存管理上线”为一个迭代。
团队管理
Scrum 框架下有三种常见角色:产品负责人(Product Owner)、Scrum 主管(Scrum Master)、团队成员(Scrum Team)。
根据我们开发中的实际情况将角色分为以下四种:
1.项目经理:相当于 Scrum 主管,负责协调团队内部合作,召集站立会议,把控项目整体进度;
2.产品经理:相当于产品负责人,负责决定应该做什么工作,明确工作项、评定优先级,拟定待办事项 Backlog 清单的内容,确定各个事项的优先顺序;
3.开发人员:开发人员是项目开发任务具体的实施者。他们负责完成开发任务,及时反馈开发进度;
4.测试人员:测试人员是项目测试任务具体的实施者。他们负责制定测试计划,编写测试用例,创建以及回归缺陷。
[attach]133693[/attach]
在 Gitee 的「项目成员」中可对参与项目的成员进行分组和权限管理
需求梳理
项目开始前,由产品负责人收集来自各方需要、期望和诉求,明确工作项、评定优先级,整理出 Backlog 待办事项列表,常见的条目信息表达形式为用户故事。在冲刺计划会议上,Scrum 团队从产品待办列表中挑选其中事项组成 Sprint Backlog。
[attach]133694[/attach]
产品负责人对需求任务设置优先级,结合自身情况自定义需求状态,利用「子任务」进行细化和拆解,设置任务归属于不同的资源池,形成完整的故事结构。
迭代计划
在迭代开始前,我们需要有一个迭代计划会议。在会议中安排迭代中要做的工作以及确定迭代目标。在迭代计划会上,产品负责人需要告诉团队迭代待办列表中条目实现的优先级顺序。团队承诺在迭代中他们能够完成多少个条目。在迭代的过程中,任何人不能单方面擅自变更冲刺内容。最终的计划是由整个 Scrum 团队协作完成的。
[attach]133695[/attach]
Gitee 中的迭代待办条目列表
在每个迭代/版本开始前,交付团队和需求方就应当在计划会议上针对下一个迭代/版本要交付的范围进行讨论,交付团队就讨论结果,做出 在迭代结束时一定会交付约定范围的需求 的承诺。
跟踪迭代进度
迭代目标明确后,即将进入迭代冲刺。一般迭代周期为1至4周左右。在整个迭代过程中,需要由 Scrum Master 确保团队在无外界干扰的情况下全力以赴的冲刺。在冲刺的过程中,建议采用可视化管理方式将迭代过程和工作必须对执行工作的人员和接受工作的人员都是可见的。
[attach]133696[/attach]
Gitee 中的任务状态看板模式
每日站会
迭代开始后,团队在每日站立会议(Daily Scrum Meeting)中对每天工作进行迭代跟踪。各成员快速汇报昨任务进度、是否需要修改计划、遇到的困难等,保证 Scrum Master 和团队成员可以快速处理障碍,集中精力进行目标冲刺。同时建议站会结束后,将比较有价值的信息同步到 Wiki 中。
[attach]133697[/attach]
关注团队进度
除了应用可视化看板、每日站会可以监控项目进度和风险以外,还有一个特别好用的实践,即燃尽图。
燃尽图以图形化方式展现了剩余工作量与时间的关系。要求团队每日更新工作进度,养成良好的更新习惯。从图中可以了解团队计划,把握团队进展以及知晓工作步调是否一致。同时可以及时发现问题并做出改进。
[attach]133698[/attach]
Gitee 中的燃尽图
通过甘特图能随时查看迭代的具体进度以及每个项目成员的任务分工情况,做到分配合理。
[attach]133699[/attach]
Gitee 中的「甘特图」功能让项目排期可视直观,进度一目了然
迭代评审
迭代冲刺的结果是潜在的可交付的产品增量,那么如何来评估冲刺目标完成的结果呢?接下来要进行另外一个事件,即迭代评审会议。
迭代评审的目的是检视迭代冲刺的成果并确定未来的适应性。团队向关键利益相关者展示他们的工作结果,并讨论产品目标的进展情况。在迭代评审期间,团队和利益相关者将评审在这次迭代冲刺中完成了什么,以及环境发生了什么变化。基于这些信息,与会者可以就下一步的工作进行协作。 PBI也可能会进行调整以适应新的机会。这里需要注意,迭代评审是一个工作会议,团队应避免将其仅限于展示。