敏捷宣言：软件架构师的视角（下）
有时候团队成员可能更倾向于“先让程序能用，以后再改得更漂亮”，但这会冒“降低内部质量和增加技术债务”的风险。类似的倾向可能还有：“时间紧，任务急，现在别花时间琢磨最佳解决方案了，先对付一个能用的。”或者“排除已知的未来用例，只关注当前的sprint需求。”从敏捷的角度来看，这都有道理，但却可能与良好的架构观点相矛盾。
由于技术或经济上的原因，被低估、被忽视和错误的设计决策可能会使事倍功半，甚至无法做任何补救。没有有效的计划，没有正确的愿景和现实的预期，构建软件很容易失败。编写代码成本很高，丢弃代码片段并不断地重写代码会导致更多的麻烦和延迟。一个好的架构师不应该做出有可能降低内部质量的妥协，除非结果是能够被业务需求理解和认可的。
我认为，架构师应该始终考虑未来处于关键路径上的用例，因为它们可能在技术设计中增加制约因素。虽然敏捷团队可能着眼于现阶段的sprint工作，但是架构师需要向前看，当好“舵手”，以确保项目进展朝着更大的目标前进。
如果在业务功能和清晰的目标之间做出更精准的预设，就能够事半功倍，因为架构师可以做出更准确的决策，并把当前不必要或不清晰的环节延后处理。评估未来的技术参数和指标，衡量它们在当前架构中的影响，并将风险传达给利益相关者，这对于产品的成功至关重要，也是架构师的关键职责之一。
例如，我正在审查团队在即将到来的sprint中将要处理的业务技术参数和指标，我会特别关注那些有可能对架构产生影响的部分。这种方法适用于开发需求高而稳定的长期项目，对于那些处于维护或支持阶段的产品，这种方法是不适用的，因为变化和调整可能异常频繁。
然而，响应变化并不意味着不需要计划，或者始终处于重新设计或重新构建系统的状态。在某种程度上，体系结构的大部分在很大程度上是不宜变动的，特别是对于比较老旧的产品。架构师应该始终有一个计划，并为团队提供指导和愿景。然而，架构计划又必须足够灵活(随时准备拥抱变化)，并且能够促进未来的业务需求。
在敏捷环境中，理解客户的需求比合同中协商的内容更重要。开发满足客户需求的软件需要在整个开发生命周期中进行定期的协作。在实践中，每次sprint结束时都是好机会，当收到反馈时，优先级可能会被打乱，这使得在开发过程的早期就有机会确保最大的开发价值。
架构师必须同时处理来自不同利益相关者(例如客户、开发团队、产品负责人、scrum master等)的外部和内部请求。尽管所有人对于系统的成败都有共同的利益关系，但他们通常有不同的关注点，他们都希望系统能够保证或优化这些关注点。他们都是架构师的客户——对系统实现感兴趣的任何人，而不仅是为软件付费的人。
在这种情况下，架构师必须以可行的方式在业务、技术和人员之间找到适当的平衡，然后，将这种平衡传达给他的客户和利益相关者，在开发过程中维护系统的完整性，并促进从模型到生产系统的转换。
与定义交互规则相比，协作工作重要得多。对于架构师来说，沟通和谈判技巧都非常重要。在实践中，无论是关于为技术任务提供sprint配额、与团队协作以找到适当的技术解决方案，或者在定义代码评审策略或内部质量检验关时达成团队共识……谈判和权衡无处不在。而架构师总是能够在不同的技术解决方案上与客户、产品所有者、业务分析师、scrum master甚至开发人员讨论并达成协议。
架构师不应该笃信或遵循任何方法论(如SCRUM、SAFe等)，因为它们都有优缺点，有时在实践中应用得并不好。所有的方法在某种程度上都是有漏洞的。敏捷架构师不应拘泥于任何模式或教条的角色，而必须务实、灵活，并深入参与软件开发生命周期的全过程。他们必须具备良好的沟通和谈判技巧，不断寻求改进，并为团队提供指导和愿景。
敏捷宣言的价值不是二进制的，不仅是“软件”,“个体和交互”、“响应变化”或“客户协作”,而是取决于一个架构师的平衡能力，与其他利益相关者在团队中的协作，根据利益相关者的关注点、开发团队、技术环境以及他们的专业知识，时时进行适当地调整和校准。
注：本文译自InfoQ
敏捷之美 ∣在这里发现