深度参与的架构师会见证第一手反馈信息并且与团队紧密合作以缓解各种缺陷。反馈可能源自于各处，如企业标准的变化，持续变化或发展的功能性/非功能性需求以及在实施和测试过程中所发现的各种挑战。
能够越早识别这些缺陷，架构师就能够越快改进系统架构。如果架构师没有积极参与到交付团队中，那么这个反馈可能会花费数周甚至数月才能够上报给架构师，这时通常已经处于交付周期的晚期了。
鉴于架构决策通常会包含一些非常重要或者难以改变的内容，如果需要重大的架构性调整，这一反馈方面的延迟只会加重。
在交付周期的晚期发现架构性缺陷通常会采取变通方案以"暂时熬过这一版本"，与此同时也会留下技术债务。然而，越早捕获和评估这一反馈的架构性影响，整个项目就会越敏捷，风险累积也会更少。
领导力
架构师所承担的另一主要职责就是领导力。领导力有多种形式，所有这些形式对于成果及其底层架构的成功实现来说都是至关重要的。
为了团队的成功实现，架构领导力要求架构师能够有效地与团队沟通"大局观"。传递这一信息的最佳方案就是与交付团队紧密合作并进行若干次相关讨论，而不是仅仅通过一篇文档、一次会议或一场演讲。架构方向必须在工作过程中反复调整。太过于陷入交付的热情中，很容易忽视整体目标。一个持续参与的架构师可以帮助维系愿景的一致性。
技术领导力源于这样的事实：架构师通常在开发和交付方面具有丰富的经验。架构师的目标之一就是教育开发团队帮助其成长。有些情况下有专门的技术领导人担当这一角色，但为什么要让架构师所获得的经验浪费掉？这种交互不仅能够让整个团队受益，也能够让架构师更好地了解开发团队所遭遇的常见问题。
导师是架构师可以向团队传递的非技术领导力的一种形式。如何与非技术人群合作，拥抱敏捷原则，定义架构以及架构建模等话题都是对开发人员和潜在架构师成长十分重要的技能。与更加正式的，课堂式的教育机会相比，架构师这一角色的训练和知识多数都源于在职经验。架构师应该拥抱这一趋势并让架构学习更加主动而非被动。
Read full article from 架构师是否应该写代码：架构师的认知误区
No comments:
Post a Comment