评价敏捷

从成本和收益上分析是否要转向敏捷开发

高效地开发出有品质的软件对各个行业的企业都是至关重要的，对最终用户尤为重要。软件企业不再能忍受18个月的产品周期，它们正在寻求各种方式变得更加灵活和多变以适应不断变化的市场需求。

     尽管我们需要一个高效的软件开发计划，但目前多数的开发项目仍然在进行中并且按传统的模式要求事先定义下所有的需求，同时这些需求在日后几乎不允许改变。问题是按这种方式多数客户都不能准确定义出它们的需求。夹杂着技术进步带来的变化，结果是令人气馁的。美国的一家研究公司Standish Group发现百分之九十的软件项目延期，百分之六十六的可以认为失败，以及百分之三十的完全报废。

     敏捷开发是一个使公司能够更快速地提交软件产品的开发过程方法。 它一个渐进的，协作的方法，其目标是有效及时地生产出高质量的软件。

     在敏捷的初期，它适用于较小的范围和相对简单的商业应用项目。 如今，局面已发生了显著变化。 当公司想要把敏捷开发应用在更广泛的项目上， 那么敏捷开发就需要处理当前软件开发组织所面临的大量业务、结构、和技术的复杂问题。

     正确的分析出转向敏捷的代价，你必须权衡利弊，同时开了开发风险的减少。例如，实施敏捷方法需要改变工程师花费时间的方式和他们如何完成所有的软件开发活动。这里强调一些进行转换应该关注的要点。

• 个人和交互（针对流程和工具）
• 工作软件（针对全面文档）
• 客户的合作（针对合同谈判）
• 响应变化（针对遵循计划）

     经理们必须考虑他们扮演的角色。多数敏捷精益开发经理使用更加放手的方式。他们让队员在特定的方向作先锋从而培育出成功转向敏捷精益开发的环境所需要的。

     敏捷增加了团结的软件交付效率，从而转化为客户满意度和收益。效率可以消除在特定活动上的浪费，它可能也许不能对大的目标产生影响。但是，效率不会告诉你正在做的事情是否正确，或者告诉你正确的做事顺序。效率更重要的是它帮助你实现目标。

     和其它重要的敏捷开发原则一样的一条是开发阶段的客户介入，如同前面提到过的，持续的团队协作。相关人员关于可工作代码的反馈和测试驱动开发对成功推出一个项目至关重要。相关人员包括业务相关者、软件使用人、客户支持、和其它企业IT部门人员，需要他们尽早的多多介入到敏捷项目整个开发周期中，积极参与建模和测试，有时甚至是参与开发。这一层次的介入使得他们能够看到软件开发的内部工作。这样促使开发人员关注于客户的优先级上而不是个人的优先级，这样可以提高产品的可用性。

     这些敏捷开发指导方针为企业提供了一个基础，一个使企业知道如何快速响应并准备好应对需求变化的基础。例如使用Scrum（混战：一个敏捷开发借用橄榄球运动中的术语），一个每天举行的“混战”（也就是会议）邀请所有项目相关人员。 每天开发人员回答三个问题：

1. 从昨天到今天你完成了什么？
2. 从今天到明天你打算做什么？
3. 你遇到什么问题使你无法完成计划的目标？

     这个每日例会要求每个人清楚说明他所做的事情，这样其它队员可以在转为灾难之前指出错误和不兼容。它也可以确保在紧急情况出现时有人可以作出及时补救。

     敏捷开发常常被人批评为是过于随意的，这是不符合事实的。沟通交流和规则是敏捷开发的两个基本组成部分。敏捷最大的驱动原则是定期提交可工作的软件。提交周期越短，对规则的要求越高 － 例如，每次迭代都必须以可工作软件形式提供具体的可以度量的商业价值。

     虽然关于敏捷是否过于随意和无纪律的争论还在继续，但有一个事实：人们对敏捷模式和精益开发的关注兴趣越来越强。仅仅在IBM一家，过去的两年中，敏捷项目的数量从5个增加到了200多个。

关于作者

     休麦金尼是IBM的开发变革和整合副总裁。 她目前在IBM软件部负责开发变革行动。 她的主要工作重点是推动主流软件开发采用敏捷和精益原则。 休还致力于分享IBM的经验，帮助大客户看到他们变革活动的机遇。