给敏捷团队中的架构师的10个建议_研发效能_Abel Avram

HarmonyOS开发者限时福利来啦！最高10w+现金激励等你拿~ 了解详情 



 写点什么

微软澳大利亚的解决方案架构师 Tom Hollander，在 TechEd Australia 大会上举行了一场题为“敏捷团队中的架构师角色”的演讲。在演讲中，他讨论了他作为领导敏捷团队的架构师所做的工作。

在谈到架构师的角色时，Hollander 指的是“解决方案架构师”或者应用架构师。他不是指企业架构师或者其他的专业人士（专精于特定的领域，例如消息或基础设施）。

Hollander 的团队采纳了由 4 周迭代以及最后的稳定阶段（几天代码冻结的时间）组成的流程，实施了每日站立会议、每日构建与自动化测试的持续集成等实践，并采用了许多角色：

PjM——项目经理，类似于 Scrum Master，确保团队遵循了流程
PdM——产品经理，也被称为客户或 Product Owner，决定产品应该是什么样子
架构师——解决方案 / 应用架构师
开发人员——开发团队
测试人员——测试团队
用户体验设计人员（UX）——用户体验团队
发布人员——承担构建和发布的职责，负责维护构建的流程

Hollander 针对解决方案架构师如何在敏捷团队中取得成功，提出了最重要的十件事情：

“正好足够”的预先设计——除了非常简单的项目，一定时间的预先设计（例如，1 到 2 周）是绝对必要的，其时间长短会取决于应用的类型——网络应用程序、智能客户端（smart client）、移动或批处理，基本的功能需求是什么，是长期的解决方案抑或是折衷的、暂时的方案，都要弄清楚。预先设计的目的是要决定：使用什么技术——例如，ASP.NET 或 MVC，应用程序是什么类型——2 层、3 层抑或是面向服务的应用，如何访问数据库——存储过程、实体框架、LINQ、依赖注入（DI）。一篇简短的文档就可以包含所有这些信息以供大家参考。
从垂直分片开始——是指从一小块功能开始（例如登录页面），尽可能地在垂直方向把它切分为很多层，从而把前一阶段所决定的所有技术结合在一起。这将验证设计决策的正确性，而且所有的技术可以一起工作，并且将向开发者展示在开发新代码时可以遵循的模式。如果发现最初的设计决策不当，此时是一个合适的修改时间。
在每次迭代中的 Just-in-time 设计——在每个 4 周迭代的中段，项目经理、产品经理和架构师应该聚在一起讨论在下一个迭代中要完成的需求，确保他们每一位都同意这些需求，重要性更高的事情放在了前面处理，而且每个人对一切事情都非常清楚。这些讨论在当前迭代中会以不太明显的方式延续一个星期。接下来的一周，也即当前迭代的最后一周，架构师复审下一次迭代的需求，作出必要的设计决策，以便团队可以在下一个星期基于这些决策开展工作。如果需求与以往相当不同，那么，架构师会开发一些原型，编写一些代码来证明概念，绘制一些图表，然后把所有这些东西集编为 5 页的文件以供参考。这不是为了制定出有利于开发人员的详细设计方案，而是要确保新的需求满足全局的要求。
信任你的团队…但要跟他们在一起——这关乎架构师与开发人员的关系。架构师需要确保他没有逾越自己的角色，没有独占所有“做决定”的乐趣，使得开发人员的工作变得无聊。与此同时，架构师需要给团队提供指导，解决那些可能会导致开发人员停顿的困难问题。架构师每天都应该与每位开发人员接触，获悉他们在做什么，并且在他们遇上编程问题的时候给予帮助。特别是当开发人员不喜欢寻求帮助，试图花上整整一个礼拜的时间来自行解决问题的时候，这种帮助尤为需要。这种关系也适用于 PjM 和测试 / 构建 / 发布团队。
编写代码！——架构师应该知道代码的质量如何，这样才会对他做出的决定所产生的影响有更好的理解。他也可以整明白何时重构是必须的。编写代码的架构师在开发团队中有更好的声誉。也就是说，Hollander 并不认同（设计和开发）职责的泾渭分明。他还认为，架构师仍然是架构师，他不一定要像普通的开发人员一样擅长于编写代码。
参与一切——架构师参与所有与项目有关的会议：设计、开发、代码评审、需求规划等，这是有好处的，因为他能够以更广阔、更清晰的视角看待正在发生的事情，而且他能够通过告知产品经理其决定的潜在后果，从而帮助他 / 她避免在早期阶段做出错误的决定。
推动质量文化——一个成功的团队，一个人人都想成为其中一分子的团队，是建立在质量文化之上的：没有人偷工减料；没有人提交拙劣代码；如果设计中有一个重大的缺陷，它绝不会不知不觉地混过关；所有人都是诚实和开放的，寻求整个团队达到最佳的结果。Hollander 承认，建立这样一个团队很难，但并非不可能。首先，架构师应该在一开始就创建一些规则，这些规则不会因为开发人员不喜欢就随着时间而改变。比如决定编写单元测试，再比如在每次提交以前都要进行代码评审，包括由架构师提交的代码。如果评审人员（可以是团队中的任意一位）不认可代码，代码就不能提交。
知道何时需要改变——架构师应该非常灵活，随时准备好在设计需要改变的时候去改变设计。早期的解决方案也许不再适合，抑或是新的需求需要不同的方法。
屏蔽来自外部的随机请求——虽然这通常是项目经理 /Scrum master 的职责，但架构师可以保护团队不受外部请求的影响，这些影响往往会分散团队的精力和浪费真正工作的时间。举个例子：业务团队可能想要以某种特定的方式完成某些特定的事情，而他们的请求并不全然合理，也并不是必须实现。
撰写文档…但只有当有人需要阅读它们的时候——Hollander 并不提倡记录一切，也不提倡根本不撰写任何文档。他认为有必要取得一个平衡——只编写一定数目真正有帮助的、有人会去阅读的文档。文档在记录详细设计的决定（比如数据模型）方面是很好的载体。迭代的设计决定，虽然它们由整个团队在迭代开始之初讨论得出，但我们仍然建议将它们记录在 5 页的文档之中，以备开发人员日后不记得架构师言论的时候进行查阅。而当最开始的开发人员和架构师离开项目、加入其他项目之后，新加入项目工作的人也能借助于这些文档理解某些决定的来龙去脉。