Answers:
Scrum中的一个主要想法是团队应该就“完成的定义”达成共识。理想情况下,这类似于一组客观标准,任何人都可以通过检查清单进行验证。
但是,为了减少漏掉某些东西的机会,最好有一条规则:验证“完成”操作的最主要人员是实施项目的人以外的人,或者是像您这样的指定质量检查人员(但这可能会使您瓶颈)。
如有疑问,请与团队和Scrum Master讨论并共同决定。
我认为这个问题有一个隐含的假设。当产品负责人宣布积压的项目或任务使产品所有者满意时,“已接受”与“完成”之间有区别,“完成”表示与积压项目相关的所有工作均已完成。
但是,任务的任务通常比产品所有者可见,通常是最好的半技术人员,包括(自动和手动)测试,文档编制和审查。产品负责人很少能够了解技术方面,更不用说它们是否完成了。
因此,最终由团队决定“完成”是什么意思。组织可能有标准,不同的利益相关者将有自己的要求。Scrum主管或相关经理通常负责整理和执行清单。
在您的示例中,作为质量检查/测试经理,您将说出测试是否完成。但是,您可能不是最好的人,无论您是否已审查代码,是否满足安全要求,产品是否已国际化,文档是否完整或是否构成“完成”。
“完成”的唯一概念是整个故事是否完整。团队应该已经创建了完成的定义,可以说他们何时觉得故事还没有完成。这通常包括诸如“已审查代码”,“已进行每晚测试”,“已满足所有接受标准”之类的事情。完成这些事情后,团队可以确信他们已完成所有工作期望他们完成一个故事。
在冲刺期间,如果您要确定完成的定义中的那些项目之一是否已完成,请询问。Scrum和敏捷都是关于开放式沟通的。如果您是团队的一员,请询问您的队友是否有人编写了测试,运行了测试或创建了夜间工作等。如果您是涉众,请询问Scrum管理员。
如果您坐在团队之外,但仍必须审查测试,请让团队添加“必须由用户user3251930审查测试”作为完成定义的一部分。如果这是完成一个故事所需要的,请诚实对待它并使其成为过程的一部分。“完成定义”的重点是使团队可以肯定地知道他们已经完成了交付高质量软件所需的工作。如果其中的一部分是外部审查,那就这样吧。
最终,是产品所有者在某个特定故事上签字,因此最终,他或她将最终决定整个故事是否完成。
同意这是开发/测试团队需要定义的内容,具体取决于您自己的实践。一些项目运行得如此敏捷,以至于他们愿意冒险将bug释放到其alpha流中。有些人认为任何在开发团队之外的错误都是流程失败。
我正在从事的项目需要对代码更改进行同行审查,并且要求编写代码的人要么提供/更新回归测试,要么解释为什么不能这样做。(他们和他们的审阅者还必须证明他们已经检查了已知的不良做法。如果他们能够证明他们运行了完整的测试套件并获得了明确的结果(或明确的模数,则通常会更高兴)。然后,代码必须幸免于在多个平台上进行的大量自动化单元和功能测试中,以证明它不会导致对它们的任何退步,并且可以通过自动化代码分析系统进一步检查常见的反模式。然后我们是否将其接受到主要开发流中并标记工作项已完成。
显然,这不能保证没有人能找到新的失败方法,但是它可以将风险降低到可接受的水平,而又不会大大影响开发速度。
Done
和Undone