学习的科学:适合大脑的最佳途径
为什么人们不明白你在会议上提出的想法?为什么你正在指导的开发人员仍然不理解你?为什么参加你的课程的学员只学到10%的内容?在某种程度上,我们都是老师,但只有专业教育工作者才接受过这方面的培训。本文讨论从神经科学学到的知识,以及如何把它们应用到敏捷软件开发及其他行业。
作者 InfoQ中文站 发布于 2009年8月20日 下午8时39分
软件开发方法学的泰斗,极限编程XP的创始人,敏捷宣言的创始人之一Kent Beck首次来到中国,分享其35年来在架构设计方面的最新总结。Kent Beck说“我现在终于有点想清楚架构是怎么回事了,我希望能这次能将我的心得分享给中国的架构师们”。据悉,这也是Kent Beck首度对外公开本次演讲内容。
Kent Beck是谁?对敏捷软件开发方法有所了解的开发者多有了解,简单介绍来说他是多本书的作者,比如《Smalltalk最佳实践模式》、《解析极限编程:拥抱变化》、《规划极限编程》、《测试驱动开发》、《Contributing to Eclipse中文版》、《JUnit Pocket Guide》、《实现模式》等;另外,他还是敏捷软件开发潮流的领导者,1996年他在戴姆勒-克莱斯勒启动的一个软件项目,开启了影响软件开发的方法学——极限编程(XP,eXtreme Programming),后来和另外一个软件开发大师Martin Fowler合作的《规划极限编程》奠定了XP的地位,此后他又通过《解析极限编程:拥抱变化》和《测试驱动开发》推动极限编程的流行。
值得一提的是,Kent Beck还是敏捷宣言的17个签署人之一,和其他软件开发全文如Alistair Cockburn、Robert C. Martin,以及另一位敏捷中国大会2009演讲嘉宾Dave Thomas等一起进一步普及了敏捷开发方法学。
在这次的名师讲堂上,Kent Beck将和与会者分享其在架构设计方面的多年心得,主题为“响应式设计:何时做,如何做,以及做什么?”:
当软件需求发生了变化、开发人员对技术的理解更深、或技术平台发生进步的时候,软件的设计也需要相应的发展和变化。掌握及管理这种变化的过程是软件开发人员一种非常重要的技能。好的设计能够实现更容易的测试、更低的成本、更快的开发速度、更少的缺陷,以及更高的客户满意度。本次培训将讨论如何实现一次只设计一小块软件,如何安全有效的进行修改,以及如何理解软件设计的内部结构并将其应用于日常工作。本次培训将仅面向有经验的开发人员。
在和Kent Beck的电话沟通中,他提到对于本次能够来到中国分享他的研究心得,很是期待。而且这对他本人来说也是一个很好的机会,因为他也是最近才对架构或者说设计究竟是怎么一回事有了顿悟的感觉。其实在从前有开发人员问Kent Beck是否乐意到中国来指导一些软件公司,他说他很希望能访问中国:
我非常希望能访问中国。我辅导的团队包括整个美国及欧洲许多地方。现在我开始在亚洲的工作。我发现在不同文化当中找寻什么比较困难或者什么比较容易是很有趣的。瑞士日耳曼人喜欢编写测试,墨西哥人喜欢双人编程,重构在美国中西部非常流行。
本次活动日程为9月10日全天,现在起开始接受报名,为让更多的朋友(包括学生)聆听这位敏捷大师的讲座,组委会配合9月11日~12日的敏捷中国大会,拟定票价如下:
此外,在9月9日和9月10日,我们还安排了三场超值的培训,包括LeanScrum培训课程(Scrum & 精益开发、用户故事暨敏捷估算与规划演练工作坊,以及面向敏捷开发者的UML技能等,期待您的参与。9月11日~12日的敏捷中国大会2009现在还有少量门票,欢迎大家继续报名,和400位架构师、产品经理、项目经理、高级软件开发人员一起完成这次”实效敏捷“之旅。现在团体报名,依然可享受多种优惠。
为什么人们不明白你在会议上提出的想法?为什么你正在指导的开发人员仍然不理解你?为什么参加你的课程的学员只学到10%的内容?在某种程度上,我们都是老师,但只有专业教育工作者才接受过这方面的培训。本文讨论从神经科学学到的知识,以及如何把它们应用到敏捷软件开发及其他行业。
Marc de Graauw对传输层的可靠消息机制(如WS-ReliableMessaging)存在的必要性提出了质疑。通过荷兰医疗保健中心的SOA项目案例他展示了特定业务逻辑如何在按序传达消息和一次且仅一次传输中表现得更为良好。
Java系统也可能会变成“遗留”系统。这篇文章探究了8个快速而相对低风险的办法,来帮助改善即使是锈迹斑斑的Java应用。之前那些奄奄一息的应用,在使用了这些可以改善性能、减少运营负载和加速开发周期的方法后,获得了新生。
大家都知道让一个人多任务工作是有害的,这会降低他的工作效率。新的敏捷或Scrum团队面对的一个重要挑战是同时应对多个项目。敏捷教导我们团队应该一次只做一个项目,不然就会遇到风浪。Roger Brown深度解析了这种现象的原因。
作为架构师和设计者,我们常把手头的事情作为工作焦点,很少反思过去如何。我们应该温故而知新。Andres Kutt这篇文章从他作为Skype架构组领导的经历中总结了6个经验,其中有技术方面的,另外一些是架构师较为软性一点的观点。
固定价格合同很有害,这是敏捷实践者经常说的。从另一个角度来说,这些合同是很多敏捷团队必须面对的现实。但是,如果我们试着去驯服它而不是去反对它,那结果又会如何?一个公司如何用敏捷实践执行这种合同来达到更佳效果和更低风险?这篇文章试图回答这些问题。
Bernd Ruecker探索了在开发BPM解决方案时如何才能更好地达到业务与IT的契合。他描述了一套使用基于BPMN流程模型为中心进行协作的方法论,该协作促进了用户间的讨论和交流,将需求、业务规则其他物件连接起来、使开发状态形象化、使业务驱动的测试场景得以细致地明确等等。
3 条回复
关注此讨论 回复