Mar*_*one 9 architecture agile backlog user-stories
在尝试将敏捷原则应用于我们的开发过程,特别是scrum原则和类似XP的用户故事时,我们遇到了有关架构的问题.
也许我们仍然与以体系结构为中心的开发有太多联系,但是我们正在尝试维护一个强大的基于组件的开发,并与敏捷建模原则相结合.我们的目标是预先设计一个小型设计,在开发过程中容易发生变化.
我正在寻找的东西可以让我在我的积压故事中加入我的架构及其内部组件:开发故事,而不仅仅是用法故事.系统故事可能是一种不同类型的用户故事,它讲述的是与业务价值并不严格相关的内容,而是与系统的架构和质量问题相关联.
编辑: 我发现这个研究的丹麦奥尔堡大学的关于" 开发者的故事 ".
你有经验,想法或反对意见吗？
先感谢您!(这是我的第一个问题!:D)
Joh*_*ner 11
IMO积压应不包括开发者的故事.任何产品负责人都无法明智地将这些优先级与业务功能放在一起.如果产品负责人认为其中一个不重要并因此将其从积压中删除,会发生什么？如果团队然后坚持要保持这个故事,那么你就会面临积压的所有权变得不明朗的情况.
但是,我确实认为团队需要在项目早期构建架构.我项目的一个问题是我们过多地关注前几个sprint中的功能.
让我们考虑"建筑债务"(类似于技术债务)与需要花费时间来建设基础设施和架构.与技术债务(从零开始并随着团队在没有适当重构的情况下产生功能而建立)不同,团队从建筑债务开始并且必须努力减少它.减少建筑债务所花费的时间意味着花费更少的时间来产生功能,即更低的团队速度和减少的冲刺输出.通过这种方式,建筑债务类似于技术债务.如果出现了不符合当前架构的要求,那么架构债务的水平就会增加.
请记住,团队应该决定(并且能够向产品负责人证明)他们将如何花时间.因此,他们可以在他们认为合适的功能,技术债务和建筑债务之间分配他们的努力.
尽管如此,架构工作仍应由功能驱动.换句话说,团队应该构建基础架构以支持和启用特定的用户故事.不只是因为他们认为将来会有用.YAGNI原则适用于这种方法.