敏捷架构的系统故事

9
在尝试将敏捷原则应用于我们的开发过程中,特别是Scrum原则和类XP用户故事时,我们遇到了关于架构的问题。
也许我们仍然过于注重以架构为中心的开发,但我们正在努力保持强大的基于组件的开发,结合敏捷建模原则。我们的目标是有一个小的设计前期,可以在开发过程中进行演化。
我正在寻找的是一些能够让我把关于我的架构和其中组件的故事放入我的待办列表中的东西:开发故事,而不仅仅是使用故事。系统故事可能是一种不同类型的用户故事,它讲述的内容与业务价值并不严格相关,而是与系统的架构和质量问题相关。
编辑:我发现奥尔堡大学有关“开发者故事”的这项研究
你有任何经验、想法或反对意见吗?
提前感谢!(这是我的第一个问题! :D)
5个回答

11
我认为积压不应该包括开发人员的故事。任何产品负责人都无法在业务功能旁边合理地优先考虑这些故事。如果产品负责人认为其中一个不重要并将其从积压中移除,那会发生什么呢? 如果团队坚持保留该故事,您就会陷入所有权不清的境地。
然而,我确实认为团队需要在项目早期建立架构。我项目的一个问题是,在前几个冲刺中我们过于专注于功能。
让我们把“架构债务”(类似于技术债务)看作需要花费时间来构建基础设施和架构的时间。与技术债务不同(它从零开始,并在团队没有进行适当重构的情况下产生功能时增加),一个团队从架构债务开始,并必须努力减少它。花费时间减少架构债务意味着花费更少的时间来生成功能,即较低的团队速度和减少的冲刺输出。从这个角度来看,架构债务类似于技术债务。如果出现不符合当前架构的需求,则架构债务的水平将增加。
请记住,团队应该决定(并能够向产品负责人证明)他们将如何使用时间。因此,他们可以自行决定在功能、技术债务和架构债务之间分配努力。
然而,架构工作仍应由功能引导。换句话说,团队应该建立基础设施,以支持和启用特定的用户故事。不是因为他们认为将来会有用。这种方法适用于YAGNI原则

令人愉悦的评论!谢谢!你真的让我清醒了 :). 我进行了搜索,并找到了一些有关技术债务的定义的有趣文章(http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx - http://codeartisan.blogspot.com/2008/08/cracking-down-on-technical-debt.html)。我认为,控制债务并采用一些设计优先的方法可能是我们的正确选择。 - Marco Ciambrone

2

这里适用于我的回答

在进行架构工作和更具体的功能工作之间存在一个非常具有挑战性的平衡。从技术上讲,两种方法都是有效的,并且都可以使用,但是您延迟一些可用产品(Sprint结果)的时间越长,您就承担的风险越大,即您正在构建错误的产品(用户要求、性能要求等)。尽早达到一个可以执行系统级测试以证明产品正常工作并且您可以向利益相关者展示产品的价值和方向的点。


1
我认为这更多与“Sprint 0”方法有关,即在实际开始开发之前,您可以识别可能的瓶颈和技术挑战,并将它们放入测试中。这不会完全消除风险,但会大大减少它。 - Francisco Aquino

1
在我们的团队中,我们称之为“IT卡片”,这是一种形式的卡片:“作为开发人员,我想重构xyz组件,以降低维护成本并增加灵活性。”
团队成员可以自由选择任何他们认为重要的IT卡片,而不是从优先级排序的待办事项中弹出“功能卡片”。
我发现这种方法在保持技术债务处于可接受水平并允许健康的创新步伐方面工作得相当好。
但我发现它在重新架构系统方面有些欠缺。很难证明离开功能生产流程的时间过长。
当我写这篇文章时,我正在思考可以通过主题化故事来处理架构问题。确定史诗级别的架构目标,并将其分解为一个主题来关注。

1

这很简单,就像把一个“确保会员组件可以从所有其他组件中脱机测试”的用户故事放入您的待办事项列表中一样。只要与产品负责人的实现愿望同步,您的待办事项列表应该包含系统/开发故事。

这就是我们通常在待办事项列表中放置非功能性需求的方式,例如“域模型必须在负载平衡下在不同的数据中心运行”等。


0
我发现一个有用的角度来看待开发人员故事的方法是考虑任何给定故事的“用户”是谁。仅仅因为你不是在编写将被公司外部人员看到的功能,这并不意味着没有该工作的用户。你可能正在为走廊对面的团队编写代码。在某些情况下,用户就是你自己。这通常是开发人员故事的情况。想想“作为一名开发人员,我拥有可扩展的架构,以便我可以轻松地添加新功能。”通过指出特定的用户,它为产品所有者提供了一些洞察力,了解谁会看到故事的价值。同时指出“为什么”也有助于传达故事希望实现的好处。正如其他人所提到的,待办事项的管理归结为产品所有者和团队之间的协商。而且,无论流程教条如何,您都需要找出最适合您的团队的方法。每个团队都有不同的情况,对一个团队有效的想法并不总是适用于另一个团队。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接