写点什么

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

  • 2010-09-23
  • 本文字数:2462 字

    阅读完需:约 8 分钟

微软澳大利亚的解决方案架构师 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 指出,架构师应该确保他从理论上和实践上都是团队的一分子。架构师不应该编写所有的代码,而只是其中一小部分,他不去测试或部署这些代码,但他要确保整个流程的顺利进行。

查看英文原文 10 Suggestions for the Architect of an Agile Team

2010-09-23 21:313891
用户头像

发布了 76 篇内容, 共 26.9 次阅读, 收获喜欢 3 次。

关注

评论

发布
暂无评论
发现更多内容

YouTube音频提取 4K YouTube to MP3 for Mac激活中文

胖墩儿不胖y

Mac软件 音频提取工具 音频处理软件

使用LlamaIndex构建自己的PandasAI

3D建模设计

人工智能 ChatGPT

电气设计软件有哪些?EPLAN让你成为专业工程师

智造软件

EPLAN 电器辅助设计 电气设计

工业互联网的破局密钥——低代码开发

力软低代码开发平台

为什么当下MES如此火热,各大制造业工厂都在推行?

万界星空科技

MES系统

“智算聚芯力 津彩新未来”天津市人工智能计算中心200P上线仪式暨天津人工智能应用创新论坛成功举办

彭飞

算法AB实验平台进化历程和挑战

得物技术

后端 实验 企业号9月PK榜

基础设施SIG月度动态:「龙蜥大讲堂」基础设施系列专题分享完美收官,容器镜像构建 2.0 版本上线

OpenAnolis小助手

开源 容器 云原生 龙蜥社区 KeenTune

购买国外站群服务器快速实现SEO优化效果

一只扑棱蛾子

站群服务器

建议收藏!Harmony应用配置文件概述(Stage模型)

HarmonyOS开发者

HarmonyOS

Python数据结构5步入门

3D建模设计

Python 数据工程

OpenHarmony—应用间HSP开发指导

OpenHarmony开发者

OpenHarmony

一文秒懂!腾讯云ES HTTPS 集群访问通信最佳实践

腾讯云大数据

ES

代码审查真的已经过时了吗?

树上有只程序猿

敏捷开发 代码审查

电子行业云MES解决方案

万界星空科技

MES系统

喜讯!广通优云两大产品入选软博会“年度优秀创新软件产品推广目录”

广通优云

Numpy和Pandas简介

3D建模设计

Python 数据科学

Python数据科学入门

3D建模设计

Python 生成式AI

Python 基础知识:语法、数据类型和控制结构

3D建模设计

Python 数据工程

昇腾 AI 创新大赛2023河北区域赛成功举办,22支优秀团队脱颖而出

彭飞

HTTPS的安全体现在什么地方?

巨量HTTP

https HTTP

未来3-5年,前端开发往哪个方向发展更好就业?

互联网工科生

前端 前端开发 低代码

夯实金融云基础设施底座,天翼云助力金融行业释放发展新活力

天翼云开发者社区

云计算 安全

文心一言 VS 讯飞星火 VS chatgpt (90)-- 算法导论8.3 3题

福大大架构师每日一题

福大大架构师每日一题

给敏捷团队中的架构师的10个建议_研发效能_Abel Avram_InfoQ精选文章