在尝试将敏捷原则应用于我们的开发过程,特别是scrum原则和类似XP的用户故事时,我们遇到了有关架构的问题.
也许我们仍然与以体系结构为中心的开发有太多联系,但是我们正在尝试维护一个强大的基于组件的开发,并与敏捷建模原则相结合.我们的目标是预先设计一个小型设计,在开发过程中容易发生变化.
我正在寻找的东西可以让我在我的积压故事中加入我的架构及其内部组件:开发故事,而不仅仅是用法故事.系统故事可能是一种不同类型的用户故事,它讲述的是与业务价值并不严格相关的内容,而是与系统的架构和质量问题相关联.
编辑: 我发现这个研究的丹麦奥尔堡大学的关于" 开发者的故事 ".
你有经验,想法或反对意见吗？
先感谢您!(这是我的第一个问题!:D)
我即将在我们公司启动一个试点项目,以引入敏捷实践,包括使用用户故事.在阅读了Mike Cohn的两本书,特别是Agile Estimating and Planning和User Stories Applied之后,我现在对如何继续进行了更清晰的了解.我有信心在练习中改进我们的技术.
然而有一件事并没有让我信服.在这篇博客文章中, Mike Cohn定义了一种特定类型的用户故事,他称之为约束,可用于定义所谓的非功能性需求.就个人而言,我不喜欢单词约束,甚至使用经典模板"作为...,我想......,所以......".
相反,我会尝试让客户写,总是在卡片上,也许是上面的模板,Nick Rozanski和Eoin Woods所称的那些,在他们出色的书籍软件系统架构中,架构原则:
"建筑原则是指导建筑定义的信念,方法或意图的陈述."
(他们还将这些原则划分为商业原则和技术原则,我认为我们不应该关注这种差异.)
我想用这些原则卡做的是将它们放在我们的积压卡板旁边,以便在用户故事定义和规划活动期间始终存在它们.我还鼓励客户和开发人员拿起它们,并在每次认为卡片可用作团队提醒时将它们放在迭代板旁边.
你有没有试过任何类似的方法？你出于任何原因劝阻它吗？你对这件事有什么建议吗？