我的团队使用看板系统来跟踪日常进度，并且对于理解功能（捕获为用户故事）的进度非常有效。随着我们开发功能的发展，直到最近，我们在很大程度上允许我们的系统设计出现。在过去的两周中，我们就与性能和可修改性质量属性特别相关的架构取舍进行了多次讨论。
我认为正在发生的事情是在实现功能和设计系统时，我们在隐式地做出有关体系结构的决策，而不是根据我们已知的质量属性要求来考虑这些决策。如果我能够跟踪/捕获/直观地描述这些重要的设计决策是如何做的，那么团队成员将有更好的机会在实施系统时不给系统架构带来额外的压力，这真是太好了。当然，更复杂的是，我们板上的功能并非仅能发挥功能，有时会掩盖架构的复杂性！
如何在团队看板上直观地跟踪质量属性（或其他与体系结构相关的决策）的进度？
Answers:
我们在暗中做出有关架构的决策，但没有根据我们已知的质量属性要求考虑这些决策。
我认为您可以通过在工作流程中创建“架构审查”步骤来形象地看到这一点。该步骤将由具有自己的WIP限制的Kanbad板列表示。在制品的限制将取决于您必须参与这些评审的建筑师/设计师的数量。
开发团队负责用户故事的水平，从左到右的流动。在大多数情况下，建筑师只有在建筑/技术评论栏中的故事才会接触。圆柱与水平泳道的交点可视化了开发人员和建筑师的会议。
我工作的一个团队中有一个类似的步骤，他们与首席数据架构师进行数据库架构审查。他们不使用看板，但是如果使用了看板，则很可能会将此专栏纳入讨论范围。
已知的质量属性可以表示为：
补充：“架构审查”工作流程步骤可能会被怀疑为公地悲剧的问题。 这是一篇很棒的博客文章，介绍了看板可视化如何帮助其处理以及可能的解决方案。
这个问题实际上有两个部分。一部分是：我们如何知道何时更改体系结构。第二部分是：我们如何知道该体系结构仍然很好。
对于第一部分：您如何知道何时更改体系结构？
这里的目标是采取隐式完成的工作并使之明确
如果可能需要审查许多卡片，或者如果架构师不是团队的一员而需要交接，或者审查的细节足够详细，那么您可能会选择前者，这需要花费一些时间来跟踪董事会。如果只有很少的卡接触到架构，则后者是一种选择，并且可以轻松按需找到一对。
现在来看第二个问题：我们如何知道该体系结构仍然很好？
我是可视化的忠实粉丝。您可以在白板上有一张图表，上面有描述组件和体系结构的便笺。
也有静态分析器将分析代码库并生成具有各种组件依赖关系图的图像。您可以每周运行一次，取出打印稿并将其粘贴在墙上。也许最近的两个打印输出可能在墙上，所以您可以查看上周是否有任何更改。
这些允许您做的是使您的体系结构和设计可见。团队成员会不时浏览一下，如果可以更改，重构或以更好的方式进行操作，则对此进行评论。
我也看到了这个问题。隐式决策！如果隐含性是问题，将其尽可能明确地解决就可以了吗？我的建议是对体系结构过程进行一些调整，以“开始明确”逐步发展为决策的隐含思想。该过程中附加步骤的目的是使团队成员了解每个人都容易做出隐含的体系结构决策。此步骤只会使隐式决策脱离轨道。
对于每种情况，将“显式隐式决策”保留为看板的一部分可能会有所帮助。
我要提出的建议可能很麻烦。但是，如果将流程映射到一组看板项目，并且针对每个主要场景将其放在板上，那么它将无法帮助您进行跟踪。我建议您也可以将它们映射到六部分方案模板，并临时看板以适应发现，可以跟踪质量保证。
维克拉姆
这是延迟敏捷团队的架构决策的风险之一。显然，敏捷最负责任的事情是将架构决策推迟到最后一个负责任的时刻。但是机会是可以（或必须）尽早发生的最后责任时刻。
可以帮助您解决的一件事是尽早明确描述您的关键驾驶要求；您明确知道必须具备的功能（但不必立即实施）。不断发展的架构（试图做到简约和灵活）应适应现有或将来对此类要求的支持。
但是，更重要的是，您不断发展的体系结构绝不能实现以支持此类关键驾驶需求的方式获得（或可以得到）的工件，即使这些工件旨在解决当前的需求。我们可以将这些工件称为干扰工件，这些工件可以提供真实的价值（因为它们实现了对现有需求的解决方案），但是它们的存在使实现将来的关键驾驶需求变得困难/昂贵。
在必须实施干扰工件的情况下，您的任务是计划在某个时间点将其移除（以便您可以实施受到干扰的关键驾驶要求）。
显然，这都是深奥的，没有实际的，有形的上下文（例如真实的项目）。但是，您的开发过程模型和不断发展的架构或多或少必须考虑这些因素。
隐式需求是架构的死角，必须明确所有内容，包括关键驱动需求和辅助需求。您无需尽早实施要求。您只需要能够解决它。
PS。所谓需求，是指系统级别的体系结构需求，而不一定是无需对体系结构进行实质性更改即可适应的临时应用程序级别的需求。希望能帮助到你。