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