领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
给敏捷团队中的架构师的10个建议
作者 Abel Avram 译者 金明 发布于 2010年9月23日
微软澳大利亚的解决方案架构师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页的文档之中，以备开发人员日后不记得架构师言论的时候进行查阅。而当最开始的开发人员和架构师离开项目、加入其他项目之后，新加入项目工作的人也能借助于这些文档理解某些决定的来龙去脉。
综上所述，Hollander指出，架构师应该确保他从理论上和实践上都是团队的一分子。架构师不应该编写所有的代码，而只是其中一小部分，他不去测试或部署这些代码，但他要确保整个流程的顺利进行。
查看英文原文：10 Suggestions for the Architect of an Agile Team
译者 金明 是ThoughtWorks咨询师，SCJP，系统分析师。关注敏捷方法学，特别是敏捷实施和项目管理的实践。
受益了～
发表人
Yao Scott
发表于
说起来容易，做起来难呀
发表人
Tarzan Wang Tarzan Wang
发表于
我们team做的方法跟上面的差不多呀。
发表人
陈 国栋
发表于
。。。
发表人
coder bloody
发表于
4 条回复
关注此讨论 回复