学习的科学:适合大脑的最佳途径
为什么人们不明白你在会议上提出的想法?为什么你正在指导的开发人员仍然不理解你?为什么参加你的课程的学员只学到10%的内容?在某种程度上,我们都是老师,但只有专业教育工作者才接受过这方面的培训。本文讨论从神经科学学到的知识,以及如何把它们应用到敏捷软件开发及其他行业。
作者 Abel Avram 译者 王丽娟 发布于 2009年1月22日 上午1时37分
软件/企业架构师是一项很重要的工作。架构师的职责很多,要胜任的话,需要具备特定的领导、沟通、技术技能。
Gabriel Morgan在最近的一篇帖子里从Daniel Goleman的情感智能(EI)——自我意识、自我管理、社会意识和关系管理——切入,谈论了企业软件架构师应该具备的素质。
自我意识
自我管理
社会意识
关系管理
卡内基·梅隆大学软件工程研究所从不同软件工程师那里收集了很多他们对软件架构师的职责、技能及知识所持的观点。对于架构师必备的技能,一部分观点如下:
David Cornish(英国伦敦摩根大通公司的技术架构师):
跟技术团队和商务团队都有良好的沟通
丰富的设计经验和技术知识
分析思维和整合思维
冲突解决
Theo Gantos(美国密歇根弗林特TEKA公司的咨询师):
架构师是一位博学多才的人。在各种方法学领域都要有咨询、交际、组织、概念化、抽象思维、逻辑推理、数据建模的能力,自我检讨的能力,快速适应,演讲和沟通技巧,编程知识,写作技巧,销售技巧,个人魅力,金融和投资回报率计算技能,对付难弄、安于现状的人,有幽默感。
Venkatesh Krishnamurthy(印度班加罗尔市Valtech印度公司的技术架构师):
- 有创造力
- 艺术家
- 政治家
- 强有力的意志
- 优秀的沟通技巧
- 出色的演讲技巧
- 有人缘
- 成熟
- 表达能力强
- 勇于决策,并能坚持
- 挑战者
- 好的观察者
- 协商者
Victor Alejandro Baez Puente(墨西哥墨西哥城Grupo Nacional Provincial公司的CTO):
- 对带有财务审计、合同管理、企业工作流、业务流程整合、资产管理组件的企业应用,有设计经验。
- 有SOA相关经验。
- 作为首席架构师参与过J2EE项目成立到交付的整个过程。
- 有在高可用、集群化环境部署J2EE(富)Web客户端应用的经验。
- 专长于针对软件系统工件构建和文档化的UML。
- 宽泛的IT知识(应用开发、测试、部署、操作、文档、标准、最佳实践、安全、硬件、网络、操作系统、数据库管理系统、中间件等)。
- 擅长轻量级、快速开发、敏捷方法学,并有相关经验。
- 有估算、度量项目速度的经验。
- 有处理遗留系统和分阶段应用集成的经验。
- 对细节有敏锐的注意力。
- 书面、口头、图示沟通的技巧。
例子有很多。有些人把重点放在领导/沟通技巧上,而另一些人则重视具体的技术技能。亲爱的InfoQ读者,你认为软件/企业架构师应该必须具备哪些技能?
查看英文原文:The Qualities of a Software Architect
架构师难做啊
首先,作为一名软件架构师,对于软件开发的流程应该熟悉,软件开发技能应该有专长并广博,能够在架构设计时给予充足的技术指导;其次,架构能力,统观全局,处理好需求以及人的关系。因为,个人是比较中庸的一个观点,领导/沟通技巧以及技术技能都很重要,而实际对于软件架构师的需求应该会跟公司的业务发展方向有一定的关联。能够成为一名软件架构师的人,在我看来,这人已经很牛了~~~
我的个人理解:
首先,架构师要非常熟悉要架构的业务,而不是根据需求规格说明书来熟悉,毕竟说明书上的只是需求分析人员对需求的理解,不一定是客户的真实需求。不是有一句话吗,“客户的真实需求一般不变,变的是每个人对需求的理解”;
其次,架构师要在其应用的知识领域要有深入的研究,最好有过完整的项目经历,当然不见得是以架构师的角色参与
最后,架构师要有很好的沟通能力,你的设计成果要让客户、公司领导、同事和所在团队能理解并认可。
受益匪浅,好文章,该文章已经被伯乐族网站 www.ibole.cn 收藏。
伯乐族 www.ibole.cn -- 程序员的世界很精彩!
你确实这是架构师,而不是项目经理?
项目经理负责项目内部的管理多一些。(非技术上的)
但软件架构师负责项目架构上的设计,审核。
有一些共同之处,比如都要有良好的表达能力。
都要有比较好的交际能力。
直接看看MCA和SCEA的要求大概就知道了。
明明一个职务而以,怎么社区里有真么多山寨的说法。
架构师了解工程经济学和心理学倒是必要的。
至于项目进度这些破事项目经理作就好了,还用花那么大成本用A来管理,浪费么。
擅长轻量级、快速开发、敏捷方法学,并有相关经验。
有必要么?
這個條件我個人覺得因該是PM的條件
架構師因該Focus on技術,領導團隊開發為主
架构师和软件架构师 是有职责区分的,不能混为一谈
业务与技术的结合体~
也想成为一个架构师啊......
为什么人们不明白你在会议上提出的想法?为什么你正在指导的开发人员仍然不理解你?为什么参加你的课程的学员只学到10%的内容?在某种程度上,我们都是老师,但只有专业教育工作者才接受过这方面的培训。本文讨论从神经科学学到的知识,以及如何把它们应用到敏捷软件开发及其他行业。
Marc de Graauw对传输层的可靠消息机制(如WS-ReliableMessaging)存在的必要性提出了质疑。通过荷兰医疗保健中心的SOA项目案例他展示了特定业务逻辑如何在按序传达消息和一次且仅一次传输中表现得更为良好。
Java系统也可能会变成“遗留”系统。这篇文章探究了8个快速而相对低风险的办法,来帮助改善即使是锈迹斑斑的Java应用。之前那些奄奄一息的应用,在使用了这些可以改善性能、减少运营负载和加速开发周期的方法后,获得了新生。
大家都知道让一个人多任务工作是有害的,这会降低他的工作效率。新的敏捷或Scrum团队面对的一个重要挑战是同时应对多个项目。敏捷教导我们团队应该一次只做一个项目,不然就会遇到风浪。Roger Brown深度解析了这种现象的原因。
作为架构师和设计者,我们常把手头的事情作为工作焦点,很少反思过去如何。我们应该温故而知新。Andres Kutt这篇文章从他作为Skype架构组领导的经历中总结了6个经验,其中有技术方面的,另外一些是架构师较为软性一点的观点。
固定价格合同很有害,这是敏捷实践者经常说的。从另一个角度来说,这些合同是很多敏捷团队必须面对的现实。但是,如果我们试着去驯服它而不是去反对它,那结果又会如何?一个公司如何用敏捷实践执行这种合同来达到更佳效果和更低风险?这篇文章试图回答这些问题。
Bernd Ruecker探索了在开发BPM解决方案时如何才能更好地达到业务与IT的契合。他描述了一套使用基于BPMN流程模型为中心进行协作的方法论,该协作促进了用户间的讨论和交流,将需求、业务规则其他物件连接起来、使开发状态形象化、使业务驱动的测试场景得以细致地明确等等。
13 条回复
关注此讨论 回复