在敏捷开发这个词越来越火之后,我们的研发团队也逐渐向敏捷方向转型。前段时间团队用 teambition 来帮助进行敏捷开发,今天把我们团队如何以 Sprint 为分类进行敏捷开发的方法分享给大家。首先我们从产品的需求管理开始说起。
以我们公司正在进行的 iOS 客户端开发为例,在名为“iOS app 开发”的项目中,产品负责人(以下简称 PO)会创建一个 Product Backlog 的任务分组,用来收集产品的需求和用户故事。PO 会按优先级顺序排列来帮助自己管理需求。
研发团队用 Sprint Backlog 的任务分组,来进行工作量的预估和安排。
通过 Sprint 计划会议,PO 从 Product Backlog 中选出需求点作为本次迭代的目标,将其移动到 Sprint Backlog 中。
这个目标的时间周期一般为 1-4 个星期,研发团队将这个目标细化成一个个可执行的任务,以此来建立完整的 Sprint Backlog。
任务的进度条可以展示整体的 Sprint 排期完成情况。
每个 Sprint 都会有一个新的 Sprint Backlog 任务板,任务板的阶段可以设置为“需求 计划中 进行中 测试中 已完成”,如下图所示: 当任务需要进行下一阶段时,可以通过拖拽任务卡片,将其移动到下一阶段。同时,你可以通过修改执行者,来告诉对方可以进行下一步的工作了。
当一个需求目标所涉及的所有任务都完成时,该目标会被移动到“已完成”,表示该目标已实现。 这样操作的好处,我认为有以下几点:
1 对于不同类型的事情,只需要进行头像的拖拽,就可以快速分配出去; 2 可以给每个需求设置截止时间,当任务完成的时间超过预期时,会用红色标注显示;
3 所有的讨论和任务状态的变化,任务相关者都可以看到。将产品的功能参数填写在备注中并进行更新,备注中永远呈现最新的内容; 4 上传的文档,会与任务附着在一起,找寻方便。
虽然 teambition 并不是专门为敏捷开发而设计的产品,但是对于需要经常、快速、高质量地发布软件的研发团队而言无疑是非常适用的,在高效的团队协作的基础之上,帮助我们打造高质量的敏捷团队。