少数IT项目会像敏捷软件开发和业务灵活性那样具备多层面、令人困惑及普遍性的特点。正如一个应用程序开发记者所说，我所采访的软件开发项目各具特色。许多敏捷实践的使用、业务的需求及开发的敏捷性这些话题在这些采访对话中几乎都会出现；开发项目敏捷性宣传活动中也同样会遇到这样的问题。被称为“敏捷性”的这个专栏最先报道了中间件技术发展、云计算和移动计算、业务流程管理等其他项目的敏捷性，这样的报道确实起到了宣传的作用。

如今的专栏有所不同，甚至完全相反，即敏捷开发项目重视业务敏捷性的培养。大型软件开发组织通过获得先进的商业智能报告，而实现敏捷性。另一方面，当使用软件的时候图书馆出现错误，并且发现开发方法是产品选择的关键准则。

先进的敏捷指标可解决协作中出现的问题

在上周召开的2013年敏捷联盟会议上强调了敏捷开发的增长问题，不仅仅是要求用户数量的增长，而且在展现方法成熟的新实践和技术方面也要所有增长。2013敏捷年会发言人Raziel Tabib介绍了惠普软件内部项目的超越基础敏捷案例研究，为了提升敏捷开发实践，达到产品发布频率的目的。

前期准备会议上，Tabib认为敏捷改进项目是以业务敏捷性需求为导向的。惠普软件之所以失去竞争力，是因为其还维持着传统的18个月产品功能交付模型。惠普软件产品总监Tabib说：“我们必须每个月要发布一个新功能，而且是首要业务。”因此，该公司放弃了6年前的瀑布式开发方式，而采用敏捷开发方式。

敏捷迭代开发模型为每个月发布一个新功能提供了一种模式，但是另外一个应用于跨职能开发团队中的敏捷流程却发生了停滞现象。合作会受到营销部、开发部和其他部门使用的不同语言所影响。大多数的会议是让每个人都理解其他人现阶段所做的事情，而不是制定下个阶段的活动。Tabib说：“目前所遇到最大的问题是‘如何让每个会议成员都理解和清楚其他人的工作内容的重要性？’因此我们必须找到一种提升组织透明度的方法。”

Tabib团队专注于业务智能化，为每个开必团队成员提供一份自定义报告。报告是为团队成员量身订做的，因此不存在术语障碍。Tabib说：“有了这份报告，我们就在一个水平线上，因此我们就不会在更新问题上浪费太多时间。节省下来的时间我们可以探讨重要的事情。”

毫不奇怪，为了内部应用而构建的这项技术如今已经成为惠普应用程序开发工作的一部分了，应用于开发的敏捷生命周期智能产品中。显然，软件的优势在于可以将公司业务智能报告转化成相似的用法。

首次尝试敏捷开发

未销售的产品已经调离出普吉国王县的图书馆系统(KCLS)而转入敏捷开发项目中，但是由于在线图书和信息供应商的存在而使其非常具有竞争性。像其他图书馆系统一样，KCLS不得不与亚马逊这样的电子书供应商竞争，并且在线上调研资源中呈现出惊人的增长。

开源项目专家Jed Moffitt是KCLS的IT总监，开始探索先进的图书馆系统软件以应对互联网带来的挑战。他所遇到的挑战与惠普软件遇到的挑战完全不同：除了他自己，没有内部开发人员；项目发展缓慢；传统主义用户即图书管理员。

Moffitt的团队对于选择新图书馆系统有一系列的标准。事后，他发现遗漏了一个关键的评估点。所选择的系统——Evergreen Project软件是一个开放资源，具有较大的特性集，与之前的系统相比更具灵活性。不幸的是，项目开发所用的方法并不符合选择条件。

那时候Evergreen Project采用的是瀑布式开发方式，其长达几个月的功能发布计划使得KCLS图书管理员和客户对等待新功能失去了耐心。Moffitt说：“出资方的认是成败的驱动因素，认可的程度因发布的构造良好和可用的产品速度而异。”

KCLS转向敏捷开发，选择Catalyst IT作为开发项目服务的提供者。尽管这对承诺的产品发布速度有促进作用，但是用户在快车道上也会遇到困境。通过快速的反馈，敏捷项目授权于用户，但是快速授权是必要的。Moffitt说：“即使用户抱怨软件，但是也很难让其参与到解决方案中。敏捷性是敏捷项目必备的条件，我们的用户却不能顺利地完成。”

一旦图书管理员发现了参与敏捷反馈回来所带来的好处，那么他们就会参与到改善中。如今KCLS根据业务需求和用户反馈会每周进行软件更新。

建立合作关系

没有有效协作的敏捷开发不能达到其敏捷性的目的。合作有助于企业定义业务需求、竞争挑战等等，并改善业务敏捷性的流程。虽然技术可以促进合作，但是人的因素对合作也非常重要。