敏捷 架构
有一个误解，认为架构在敏捷方法论中没有地位，或者敏捷主义者没有架构。 我认为敏捷与体系结构之间没有冲突。 实际上，与通常的看法相反，大多数敏捷团队在其项目中执行架构建模。 就像传统的开发实践一样，体系结构是敏捷软件开发的重要方面，对于扩展敏捷方法以满足现代系统的实际需求至关重要。
体系结构提供了构建系统的基础。 这是必须在项目早期进行的一组设计决策。 它包括核心技术选择，总体高级结构以及复杂问题的解决方案。 大型前期设计（bufd）通常可解决关键问题，但过高 。 在编写代码之前拥有无数的类和交互图可能无法达到预期目的。 一个好的架构应该务实，针对测试而设计，模块化，没有意外的冗余并解决性能，可用性方面的问题。
在传统的开发项目中，我们过去曾由建筑师或建筑团队开发的象牙塔架构与项目团队的日常开发活动相对隔离。 孤立的建筑师开发一个或多个描述该体系结构的模型。 这些都是非常美丽的东西，有很多精美的图表，有据可查。 从理论上讲，这些架构可以完美地工作。 然而，在实践中，它们遭受重大问题。
- 可怜的开发人员不太可能对这种体系说服，因为他们在其开发中没有发言权。
- 架构通常未经验证。 一个重要的原因是架构师很少弄脏他们的手来编写代码，因此与实际情况几乎没有什么联系。 他们没有从技术原型提供的具体反馈中受益。
- 由于体系结构反映了架构师所涉及的任何系统所要求的每一个功能，而不仅仅是实际所需的功能，因此促进了软件的过度构建。
- 每个客户都需要所有宏伟的功能吗？ 答案是不。
但是，象牙塔建筑方法在敏捷项目中不起作用。
敏捷不要求遵循开发工具/实践。 我已经看到项目团队将此作为空白检查，以避免编写测试计划，代码审查等操作。另一个伤亡是体系结构。 虽然敏捷当然是一种可以缩短产品周期的工具，但是应该区分敏捷和冲动。 在急于发布功能时，项目团队避免解决建筑视觉问题。 敏捷一直向人们挑战古老的问题– 先期设计多少？
敏捷强调简单性，持续改进，团队合作，沟通，信任和满足利益相关者需求的设计价值
架构是任何项目的重要组成部分，无论其方法论如何。 每个交付团队都需要以某种方式解决解决方案体系结构。 因此，我们何时以及如何在敏捷项目中进行架构工作。 该项目应首先定义适当的技术策略。 通过纪律，敏捷团队应该继续以增量方式在整个项目中发展架构。
当敏捷项目开始时，会有一个预游戏阶段。 在初始阶段，您需要组织项目并朝正确的方向发展。 其中一部分是最初的需求构想和体系结构构想，以便照顾项目的关键方面，例如范围，成本，进度和技术策略 。 从体系结构的角度来看，目标是确定团队的潜在技术方向以及任何技术风险。 此时，不需要详细的技术规范。 实际上，在一开始就创建这样的规范可能是徒劳的。 最初的构想应该与小组一起传播，以提供反馈和后续发展。
敏捷团队致力于产品积压中定义的功能。 在每个sprint计划中，都会提取功能（用户故事）的子集进行处理。 这成为冲刺积压。 应当进行预冲刺的故事回顾或梳理会议 。 该会议应在冲刺开始前一周举行。 产品负责人召集会议并邀请“高级鸡” （架构师，用户体验负责人，开发和测试负责人）。
在进行冲刺计划的前一周，资深人士与产品负责人可以进一步梳理故事。 可以通过改进描述和接受标准，将故事分解为较小的子故事，增加约束条件来进行改进。 建筑师在此过程中起着关键作用。 冲刺中可能会有体系结构峰值 ，这有助于进一步完善体系结构的视野。 根本性的变化可以在包含在系统中之前先进行尖峰试验。
因此，成功的体系结构的关键是与开发团队合作并以演进的方式更新体系结构。 请注意，最终的体系结构文档或工件不会太大以至于对希望阅读它的人起到威慑作用。 总而言之， 不要过度设计，不要在Architect之下 。 体系结构应有助于不断开发可带来客户价值的功能 。
翻译自: https://www.javacodegeeks.com/2015/09/agile-vs-architecture.html
敏捷 架构
