给敏捷团队中的架构师的10个建议

旧城等待， 2022-01-26 08:49 272阅读 0赞

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

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

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

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

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

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

综上所述，Hollander指出，架构师应该确保他从理论上和实践上都是团队的一分子。架构师不应该编写所有的代码，而只是其中一小部分，他不去测试或部署这些代码，但他要确保整个流程的顺利进行。

[Link 1]: http://www.msteched.com/2010/Australia/ARC204