边界正在变的更加模糊，传统上办公室是工作发生的地方，我们需要内部网络来登陆邮件系统，访问公司的知识库，利用电话会议系统和处于世界各地的同事交流。随着移动设备的普及，网络速度的提升以及越来越多的内部系统被迁移到同时提供外部访问的云平台上，工作正在从办公室扩展到生活的每一处，在出租车上，我们用手机阅读和回复邮件；在机场，我们使用Goto Meeting来和各地的同事举行电话会议；在客户现场，我们用手机访问Jive。新技术正在让工作变的更加方便，同时它也对企业提出了挑战：
再看软件开发，传统上，需求纪录在内部的Jira上，代码被提交到公司内部的服务器上，测试人员利用公司的内部环境进行测试，再由运营人员安装到公司内部或者外部机房的服务器上，所有的工作都需要到办公室或者在虚拟内部网络上工作。现在我们使用 SaaS的Mingle，把代码提交到 Github Enterprise的仓库里，用 Snap-CI进行持续集成，测试人员用一条命令在 Amazon Virtual Private Cloud 上搭建出整套测试环境，运营人员最终把产品发布到同样处在Amazon上的云环境里。开发团队可以在任何地点进行全部的工作。除此之外一些有趣的工具比如， cloud9ide 和 screenhero 也开始进入大众的视野。
地理的边界也正在消失，随着网络带宽的提升和越来越多视频解决方案的出现，无间断视频正在把地理上分离的两地紧密的连接起来：
(参考去年8月CSDN上发表的 建设分布式敏捷团队经验分享)
技术间的相互借鉴正在加剧，在服务器端，采用log4j采集日志再利用Logstash或者Graylog对日志分析是很普遍的技术实践，目前前端开发也在采用这一实践， rescuejs, getsentry, log4javascript 都是把前端错误纪录下来发向后端进行后续分析的平台和框架。
从头手写css的时代结束了， SASS, LESS正在变的越来越流行，对象间的关系终于被借鉴到了css的领域，后端开发人员进行前端开发的难度进一步降低。
随着混合了Web页面的开发方式的流行以及 TestFlight和 HockeyApp这样测试平台的出现，持续交付在移动领域的门槛变的更低，考虑到持续交付是一个从需求，开发，测试、部署、使用、反馈的流程，目前在测试方面，移动开发测试的成熟度离web开发还有一段距离，用户使用移动设备的方式更多，网络的状况更加复杂，单进程系统都让测试不能很好的覆盖所有场景，这也是接下来需要努力的方向。
5年前，在开发 ThoughtWorks Go时，如果进行持续交付就必须对应用中的XML数据进行频繁的迁移，使它的格式与应用匹配，当时采取的策略是在应用启动时检测版本再寻找响应的xslt和java代码对目标文本进行迁移，这是把ruby社区的dbMigration迁移到java社区的一次尝试。随着NoSQL数据库的流行，一定会有类似的框架出现指导开发者采用最佳实践。
数据分析，用户正在生成更多的数据，分析家认为最近两年生成的数据占人类有史以来生成所有数据的90％。我们需要模式、技术选型来指导我们处理这些数据：
数据分析也会走出研究室，其中的专业术语和基本技能变成开发人员的一项必备技能。可以类比的是数据库技术，无庸置疑，程序员的数据库知识和DBA相距甚远，但所掌握的基础知识和术语让开发人员可以更方面的和DBA合作开展工作。未来一定会有数据分析专家加入团队，就像昔日的DBA和前端开发，数据分析也会卸去神秘的面纱被更多的人所掌握。
同时在应用设计的过程中，我们几乎要在第一时间考虑要记录哪些数据、如何记录以使数据对分析友好，它表明数据分析慢慢变成了应用设计的一等公民。
随着持续交付概念的流行， 基础设施的管理正在变的愈加成熟，puppet开始支持 windows平台，chef也 不甘示弱，多年以后，微软社区终于出现了包管理器 chocolatey ，Amazon向下游延伸，推出了 OpsWork 方便Ops管理自家云平台上的节点。在应用层面越来越多的象 pkgr 的工具把应用也作为系统的一种依赖来进行管理。
在持续交付领域，Monitor Driven Deployment也开始出现，通过在产品环境上的一组测试，在部署和产品运行的过程中不断的检测产品是否正常。
除了这些，一些有趣的架构比如 LMAX, microservice + microsite都开始让人觉得技术世界正在变的更加敏捷和激动人心。
参考：