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

　　在谈到架构师的角色时，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指出，架构师应该确保他从理论上和实践上都是团队的一分子。架构师不应该编写所有的代码，而只是其中一小部分，他不去测试或部署这些代码，但他要确保整个流程的顺利进行。

（责编：陈广成）

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。