我在一家小型服务公司工作,我们开始实施Scrum实践,我们也开始使用JIRA和greenhopper进行问题跟踪.我们的团队将"完成"定义为:
我想弄清楚是否应该为每个"任务"使用上面列表中每个项目的单独问题,或者是否应该在故障单工作流程中实现其中一些项目,或者只是将它们集中在一起一个问题是最好的方法.
我不愿意制作任务的这些子任务,因为只有一级问题嵌套,我担心这种能力有更好的用途.
我也对修改工作流程并不太兴奋,因为这种方法已被证明是我们在其他系统中的负担.
如果所有这些项目都是同一张票的一部分,那么这对我来说似乎很奇怪,因为这项工作很可能在多个团队成员之间传播,并且很难完成包含所有这些事情的16小时以内的任务.
我觉得我理解所有问题,但到目前为止我还不知道最好的解决方案是什么.
有最好的做法吗?还是一些强烈的意见?
已完成 - 它必须是您定义的所有内容,但是使用错误跟踪器明确地将它们视为步骤可能会产生不希望的副作用,即鼓励团队内部的分裂并将内容扔到墙上.因此,一旦机票被标记为"已编码"和"单元测试",测试人员在标记测试时等,他们就会声称他们已完成.
这与Scrum打算做的完全相反 - 整个团队承诺做故事,以便他们最终满足完成的定义.因此,尽管实现完成的一些要素确实是步骤,但是应该非常小心地在任何类型的定义的工作流程中巩固这些步骤.
(这个btw很好地说明了为什么使用bug跟踪器作为scrum工具是一个坏主意.这些是不同的工具,应针对不同的事情进行优化 - 即使通过某些API链接在一起.)
- 编码的
- 单元测试
恕我直言,这些属于在一起,因为两者应该由同一个人处理(最好是 TDD,这实际上使得不可能将它们分开)。
- 集成测试
在我们的团队中,这通常由同一开发人员完成,因此我们通常将其作为上述任务的一部分来完成。其他团队可能会采取不同的做法。
- 评论了
你的意思是代码注释吗?那么,对我来说,这不值得一个单独的任务。否则请澄清。
- 同行评审
单独的开发人员(或更多)的单独任务。
- 质量保证测试
测试人员/质量检查人员的单独任务。
我会添加文档- 它可能并不总是需要,但通常是需要的。同样,这应该是一项单独的任务,通常由负责实施的同一个人完成(但并非总是如此)。
迄今为止与我合作过的几乎所有 Scrum 团队最关心的一个主要问题是确保上述内容没有被遗忘。划分为不同的任务可能会有所帮助。然后您可以在积压工作中清楚地看到还需要做什么。将所有这些集中到一项任务中很容易忘记这个或那个小细节。对于我们来说,最典型的是忘记代码审查和文档,这是我们将它们转变为独立任务的主要原因。
| 归档时间: |
|
| 查看次数: |
12852 次 |
| 最近记录: |