敏捷架构的系统故事


9

在尝试将敏捷原则应用于我们的开发过程时,特别是Scrum原则和类似XP的用户故事时,我们遇到了有关架构的问题。

也许我们仍然与以架构为中心的开发有太多的联系,然而我们正在努力维护一个强大的基于组件的开发,并且混合了敏捷建模原则。我们的目标是预先设计一个小型设计,在开发过程中容易发展。

我正在寻找的东西可以让我放入关于我的架构及其内部组件的积压故事:开发故事,不仅仅是使用故事。 系统故事可能是一种不同类型的用户故事,它告诉与商业价值没有严格关联的东西,但是这与系统的架构和质量问题有关。

编辑: 我找到了奥尔堡大学的this research约 “开发商故事”。

你有任何经验,想法或反对吗?

预先感谢您! (这是我的第一个问题!:D)

11

IMO积压应该包括开发商故事。任何产品负责人都无法明智地将这些业务功能排在前面。如果产品负责人认为其中一个不重要,并因此将其排除在积压之外,会发生什么情况?如果团队坚持保留这个故事,那么你处于积压的所有权变得不清楚的情况。

但是,我确实认为团队需要在项目早期构建架构。我的项目中存在的一个问题是,我们过分强调前几次冲刺的功能。

让我们考虑“建筑债务”(类似于技术债务)作为构建基础架构和架构需要花费的时间。与技术债务(从零开始并随着团队在没有正确重构的情况下产生功能而建立起来)不同,一个团队开始与建筑债务,并且必须努力减少它。花在减少建筑债务上的时间意味着花在生产功能上的时间减少了,即较低的团队速度和减少的冲刺输出。通过这种方式,建筑债务与技术债务相似。如果出现了不符合当前架构的要求,那么架构债务水平将会增加。请记住,团队应该决定(并且能够证明产品负责人)他们将如何花费时间。因此,他们可以在功能,技术债务和建筑债务之间分配他们认为合适的努力。

架构工作仍应该由功能来驱动。换句话说,团队应该建立基础设施来支持和启用特定的用户故事。不仅仅是因为他们认为这将在未来有用。 The YAGNI principle适用于这种方法。

  0

喜悦的评论!谢谢!你真的清除了我的想法:)。我进行了一次搜索,并找到了一些有关技术债务定义的有趣文章(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)。我认为,控制债务,混合一点设计第一方法可能是我们的正确选择。 03 12月. 092009-12-03 11:39:58


2

我的回答here适用。

在架构工作和更多功能特定工作之间存在着非常具有挑战性的平衡。从技术上讲,这两种方法都是有效的方法和工作,但是延迟一定数量的可用产品(冲刺结果)的时间越长,您未构建正确产品(用户需求,性能需求等)的风险就越大。尽早,您可以进行系统级测试以证明您的产品能够工作,并且您可以向利益相关方展示产品的价值和方向。

+1

我相信这更多与'Sprint 0'方法有关,在这种方法中,您可以确定可能的瓶颈和技术难题,并在实际开始开发之前将它们置于测试之中。这不会使风险为零,但会大大降低风险。 02 12月. 092009-12-02 11:57:03


1

就像投入一样简单确保会员组件可以从所有其他组件中拔出测试'用户'故事,您的积压应该有系统/开发故事,只要它是同步的与产品所有者的这种实施愿望。

这就是我们通常把非功能性需求的积压,像“域模型对负载下的不同数据中心的平衡运转”等


1

我认为对于开发人员故事有用的一个镜头是考虑给出的故事是谁的“用户”。仅仅因为你没有写出公司以外的人可以看到的功能,并不意味着这项工作没有用户。您可能正在为大厅下面的团队编写代码。在某些情况下,用户就是你自己。开发人员故事通常就是这种情况。想“作为一名开发人员,我有一个可扩展的架构,以便我可以轻松添加新功能。”通过呼叫特定用户,它可以让产品拥有者了解谁将看到故事的价值。并指出“为什么”也有助于传达故事希望实现的好处。正如其他人所提到的,积压的管理确实归结为产品所有者和团队之间的谈判。与往常一样,无论过程教条如何,您都需要制定出最适合您团队的模式。每个团队都有不同的情况,而对于一个团队来说运作良好的想法并不总是转化为另一个团队。


1

在我们的团队中,我们称之为“IT卡”,它的形式为:“作为开发人员,我不想重构xyz组件,以降低维护成本并提高灵活性。”

团队成员可以自由挑选他们认为重要的任何IT卡,而不是从优先级待办事项中弹出“功能卡”。

我发现这种方法能够很好地工作,使技术债务保持在可接受的水平,并且保持健康的创新步伐。

我发现它有点缺乏作为重新设计系统的方法。很难证明长时间偏离功能生成流程是合理的。

在我写这篇文章的时候,我想可以通过主题故事来处理建筑。用史诗分辨出建筑目标,将其分解为一个专注的主题。