最近几年中，很多开发人员进行其工作的方式发生了醒目的变化。由新型工具像是分布式版本控制系统支持的、由像 Ruby on Rails等系统激活的 敏捷方法学, 已经向开发人员针对过去的整体式开发方法学提供了替代选择。对于从事Web应用程序的开发人员来说，这些方法和工具是合法的选项，但它们会一直存在下去吗？还有哪些正在改变着开发人员进行其工作的方式呢？

  在云中工作

  云不仅仅影响那些我们合并到产品中的技术或我们如何交付产品的技术，其同时影响我们的工具箱。举例来说，我们团队的服务器没有真实“存在的”，我们也没有内部的IT团队，因此就低于平均IT人员的薪水，我们有大量的来自Rackspace 的服务器，其覆盖我们的生产、开发和测试环境。 我们的办公室并没有服务器堆栈 — 它们有一个基本的开关和连接到光导纤维互联网接点的路由器。我们在许可证、员工和硬件方面节省下来的资金可以用来聘用更多的开发人员。

  同样地，我看到其他的团队使用产品像是 GitHub或Bitbucket 用于他们的版本控制，这使得他们除去其服务器，具有遍及全国的（如果不是全世界的话）的最好的最聪明的团队，而不是局限于他们当地的人才库。

  采用敏捷技术

  敏捷方法学肯定不会适合所有地方，但敏捷方法学对于由富有经验的开发人员和允许快速原型设计和迭代的系统组成的团队进行的Web项目来说是很有用的，我们正在见证着越来越多的呆板系统像是.NET 和 Java 使用新型工具作业和架构进行更新以使敏捷方法能够被使用。甚至像Team Foundation Server的系统也正开始把敏捷带到企业中。

  您可能会提出质疑企业不会轻易不能改变其自身的开发方式，可能您是正确的。在企业职场上的经历告诉我：当一小部分的环境可以拥护支持并运行新技术的时候，大多数时间这仅仅是人们在管理忘记新技术之前对这些新想法所作的表面文章。但是作为主流，大品牌供应商不仅仅能够提供用于敏捷的工具集，同时也显示出想要拥护支持的迹象（例如微软公司在一些项目中已经开始这样做），至少一些团队将要采用这些新技术。

  合并用户反馈

  将用户反馈合并到开发过程中的驱动力已经变得流行，并有希望提高其流行度。对于较长的开发周期来说，开发团队很容易与用户隔离，决策则很容易会在更多的时间出现僵化，并且变得不可改变。对开发团队来说，新型工具像UserVoice的出现使得提供给用户支持和收集反馈并将其合并到其开发过程规划的方式变得更加简单。这已经起到了压缩开发周期甚至是大量产品的效果。

  尽管一些项目工程 (像 Linux distros 和 Chrome)从历史上来看已经移动地非常快速，但是我们已然开始见证一些项目像 Windows正加快速度。 随着消费者的期望变得越来越习惯于Web应用程序开发的速度，甚至那些预置软件也将不得不保持速度。为什么？因为新一代Web应用程序有在更多领域匹配本地应用程序的能力，同时消费者正快速地采用这些新一代的应用。 如果您现在的应用程序不能及时地保持更新，那对消费者来说就没有理由继续使用了。