敏捷SCRUM:水平与垂直分裂

时间:2017-01-17 17:35:20

标签: agile scrum

我们有一个项目将持续约5次冲刺。

该项目涉及许多用户故事,每个故事涉及不同开发人员的工作:Web(AngularJS& ASP.NET MVC)和CRM(Dynamics)。因此,它是“垂直拆分”的。

每个用户故事都建立在最后一个上:更多字段被添加到UI,而更多字段必须由CRM工作流程选取。因此,测试每个用户故事需要多次重新访问用户界面和后端并测试刚刚添加的新字段。

不同寻常的是,我们被要求用两种不同类型的任务来处理冲刺:用户故事被放在一个便条上,故事被进一步分解为每个开发人员所需的活动(UI / CRM) 。结果我们实际上结束了两次烧毁:考虑到我们还没有为各项任务提供估算,这是我不明白的事情。

我理解垂直分割用户故事意味着您总是会提供有用的东西,但我无能为力,但我认为这并不总是最有效的项目交付方式,尤其是当您考虑您一次又一次地重新访问应用程序的相同部分。

在scrum agile中是否存在水平分割是可接受的情况,因为在我们的案例中,它允许CRM开发人员在单独的用户故事中实现他们的工作?毕竟,如果它在sprint的早期,那么在开发人员各个层中不实现功能的风险就很小。此外,不需要将用户故事分解为更多的任务'。

在这种情况下,通过将任务分解为水平(架构)任务,我们可以在几天内完成UI更改,然后让CRM开发人员在单独的故事中获取我们发送的数据。我认为这也会使测试变得容易得多,因为您正在测试每个完整的功能'在它的各自环境中,而不是在几个用户故事中构建它......

显然,如果你是一个完整的堆栈开发人员,那么实现垂直分割会容易得多。但是这个项目的情况并非如此......

建议的方法是什么,您的应用程序不断增加字段/ UI的数量?是否允许在敏捷中水平分割任务,或者它始终是禁止的?

2 个答案:

答案 0 :(得分:1)

我不确定即使你横向分割任务,你也会实现你想要的。让我们举一个极端的例子,UI开发人员完成100%的任务,而CRM开发人员完成他的任务。

是否会发布任何功能(或完成任何用户故事)?我猜不是。

因此,我建议将UI和CRM开发人员作为一个单元(具有常见的燃尽)来解决,并在他们之间内部拆分任务。
优选地,它们将以类似的速度工作,因此它们可以彼此提供完成的任务。 此外,这种合作可能是一件好事,因为UI和CRM开发人员都会对项目有更多的承诺,因为他们有一个共同的目标并且作为一个共同的单位来衡量。

希望听起来合理,并帮助您做出决定。

答案 1 :(得分:0)

这就是群集概念的来源。假设您的Scrum团队由具有涵盖用户故事所有方面(例如UI,CRM,数据库等)的技术能力的成员组成,那么您的Scrum团队可以首先集中精力用户故事一起工作,同时完成所有方面。假设您的团队中嵌入了测试人员,他们也可以同时为其编写测试用例。在一两天内,故事已经完成,您可以获得功能齐全且可向您的产品所有者/利益相关者证明的内容。然后团队蜂拥着下一个用户故事。为了能够有效地完成这项工作,团队需要一段时间,大约6-12个月的经验,对于没有这方面工作经验的团队来说,这需要6-12个月。

此外,通过预先完成整个垂直路径,您可以尽早了解需要的内容,并且可以在有大量代码重构之前快速进行更改。如果你先做一个整个图层然后再做下一个图层,除了还不能测试第一个图层之外,你最终会在实现下一个图层时发现它会导致你必须返回并重做第一层。这导致额外的工作或创建不可维护的代码,因为事情被黑客入侵以满足最后期限。