IT 与业务间的分歧日增：敏捷是出路吗？

最近一项调查表明企业中IT 与业务间的分歧日增，这可能是企业内部对技术的运用方式改变的一个信号。越来越多的报告宣称IT 无法满足业务需要。敏捷能解决这个问题吗？如果说能，又有什么依据呢？

itWorldCanada 的调查报告认为目前 IT 和业务之间需要更好的沟通和相互理解：

……未来 IT 专业人员将不再作为企业的重要支持系统或者负责创新的部门而存在，而是作为“工具”存在。根据他（Michael O’Neil，Info-Tech Research Group 研究员，同时也是此报告的作者）的说法，当技术越来越成为企业的一个内在组成部分，IT 作为一个独立的顾问团体的角色将会消失；他说，除了那些“字节脑袋”类型的会想要做基础的 IT 工作（诸如网络管理员或者编码人员）外，大部分 IT 专业人员将会融入与业务过程及策略相关的领域。

一篇标题耸动的文章《炒掉你的 CIO：如果他不能实现企业战略，让他走人》也持同样的观点：

“新 CIO”不光是一个执行者，还要是一个战略家。他或她首先需要理解业务流程，其次才是最新的技术。通过与 CEO 以及其他关键的领导一起工作，他应该快速地弄清组织必须面对的关键战略要点。然后“新 CIO”将这些战略上的必要任务转换成严格按照投资回报确定的技术规划，他必须关注改进业务效率而不是实现特定的系统。

那么，这些跟敏捷有什么关系呢？首先是对客户和业务价值的关注——至少是在字面上。但当涉及到战略上的重点时，敏捷是否仍然能够发挥作用呢？就我们所知，这完全取决于你怎么看。

大多数关于敏捷过程和实践的一般建议都是内向型的和针对项目级别的。普通的敏捷方法关注如何让项目成功，寻求让作为团队一分子的客户满意。虽然有许多“检查然后调整”的循环，但他们主要关心项目的状态的进展。每日短会、演示和评估的迭代、以及回顾（retrospective）都是内向型的实践，除了有客户或者产品所有人的参与之外，这些实践并没有明确地将外部的业务价值纳入考虑。

不过，业界中确实已经有人建议关注外部的业务价值——即软件项目能给业务带来什么好处。在我们上周的报道正确的敏捷度量：运用指标和诊断来达成业务价值一文中，则告诉我们如何选择好的度量方法。这篇论文没有说明这些是外向型还是内向型的指标。我们的一位读者评论说：

我已经干了这一行 30 年，不好意思，我还没在任何正式的出版物上见到过关于项目完成后是否达到投资回报率（ROI）要求的研究成果。这是否就是人们正在寻求的度量？这里有哪位是经常做这种研究的吗？

另外，关于如何在敏捷开发中结合组织的业务价值并进行度量，Agile Journal 刊登了一系列的文章，请参见 2006 十二月、 2007 一月和 2007 年三月的刊物。这些文章涵盖了“如何得知一个敏捷项目是否成功”的问题，按照业务上的必要性来安排日常活动方面的建议，以及结合精益、敏捷和局限理论（Theory of Constraints）来在你的特定条件下满足业务需求。Liz Barnett 写到：

你如何得知一个敏捷项目是成功的呢？我通常得到的答案是两眼发直或者一阵沉默，看是面对面的会谈还是通过电话。而且如果对方真的做出了回答，通常都伴随着“我们刚刚开始这样做”的解释。这个难题有两重意思：开发组织在收集他们的项目的度量指标和报告方面的弱点是众所周知的，另一方面，当采用敏捷过程时，许多团队都要面对如何证明这种从传统方法的转变是否值得的难题。当 IT 成本和业务压力飞速上升，开发团队能否证明它在业务上的价值就变得非常关键。

那么，我们达到目标了吗？大概还没有，但我们正在正确的方向上前进。问题是——这能够解决 IT 组织中出现的问题和正在扩大的分歧吗？这些 IT 部门知道什么是敏捷开发吗？还是他们已经尝试过但失败了呢？敏捷社区能够做些什么来明确地解决这些问题呢？

查看英文原文： A Growing IT-Business Gap: Agile to the Rescue?