JBI带来的新的学习点

http://architects.dzone.com/articles/fuse-esb-4-osgi-based

NSN成都这边终于呼吸到了一些新鲜的空气，未来的几个月可能有基于Mediation Framework的开发工作可能会拿到成都来开发。我们迫切要做的就是展现我们快速学习的能力，对Mediation Framework开发和底层实现的深入理解，希望我们组能够占先，为后来者提供咨询。

从JBI可以切入的地方还有很多，背景方面SOA,Integration Issue, 技术方面ServiceMix，OSGi，Felix , Maven , Model-Driven Tooling.

咸与敏捷，并且穿上了马甲

你以为我就不认识你了吗。

本来Scrum的Demo是相当重要的事件，Team向Product Owner和利益相关者演示可运行的程序，并允许他人使用操作。而现在的Demo就是充满PPT的Report和training，没有多少人真正关心内容，因为很不相关，但又必须参加，所以只能用手机来打发时间。

clipped from www.infoq.com Jim Shore的那篇广受欢迎的文章《The Decline and Fall of Agile》，该文指出在日益增长的敏捷社区中有这样一种倾向，组织只是在名义上采用“敏捷”，而没有采用如何真正成为敏捷的实践。 在Flaccid Scrum一 文中，Martin Fowler重复了Shore大部分的观点：许多敏捷实施缺少了极限编程中强调的技术实践，比如结对编程、持续集成、测试驱动开发。和Shore一 样，Fowler也承认组织实施敏捷时普遍会优先选择Scrum，但即使这样，这也不是Scrum本身的错。作为补救措施和对大家的提醒，他强调说那些领 导实施Scrum的人需要特别留心，要找机会推动合适的技术实践： 以我之愚见，“他们会逐渐采用技术实践”这种想法极其幼稚。大多数情况下，他们根本就不会采用技术实践，即使采用也是少之又少，就好像根本没采用一样。 所以我们需要承认好的流程依赖一些关键因素，而技术实践就是软件开发中最关键的因素。把它推迟到敏捷后期实施绝对是一个坏主意。 极限编程/敏捷/Scrum越来越流行，许多团队和个人都想这么做，或者想“成为”其一。这直接导致了称之为“环境相关”的一些敏捷方法。其意思是任何类型的敏捷都“太死板了”，“不适合我们的环境”。所以我们不得不修改敏捷实践，因为上帝也知道我们没法修改环境。 亲 爱的朋友们，真为你们感到难过。恰恰是你宝贵的环境拖累了你：是中央级别的执行官和高管们不能把职责和权利交给大家；是产品的人总是太忙，以致不能解释真 正要做什么；是管理设施的人不能创建适合工作的环境；是程序员不愿意学习必须的技术；是经理和产品负责人不断施压，直到对项目的质量没有任何关注。 太极敏捷有一个理论叫 CMT，文化决定管理，管理决定技术，因此太极敏捷认为只有具有先进文化的团队和企业，才能实现真正的敏捷变革，并从中获益