近几年来,敏捷作为一种很实用、上手快、轻量级的方法,被越来越多的开发团队所采用。然而,在很多大团队中,敏捷方法的实施带来了包括在人员管理、工作计划、沟通和文档记录等诸多问题。

2009年,有知名市场研究机构对美国的上千家企业做了开发方法的调查显示,有近30%的组织采用了敏捷方法,远远高过迭代、瀑布和基于度量的传统方法。然而,数据显示调查中称未使用任何方法的机构占最大比例,约占被调查企业总数的三分之一,无论是在中小企业(员工少于1,000人)还是大企业(员工超过1,000人)。更为有趣的是,在采访过程中发现,这些自称没采用任何方法的企业中,实际上很多采用了多种方法混合使用。

不难发现,越来越多的企业发现了单纯的敏捷方法的局限性,混合敏捷方法将成为未来ALM发展的趋势。2010年,TechExcel全球CEO、首席软件架构师周铁人博士在原有的需求驱动开发(Specification Driven Development,简称SpecDD)方法基础上,提出了整合的敏捷方法(Balanced Agile Development)。整合的敏捷方法遵从了敏捷的基本原则,融合多种敏捷方法和传统方法的元素,企业结合自身业务特点和企业文化,从而形成一种整合的敏捷开发方法。同时,整合的敏捷方法将项目管理和质量管理的元素融入到敏捷方法中,倡导需求驱动开发。

需求敏捷or任务敏捷?

整合的敏捷开发,结合了客户需求、功能点、Backlog统一管理。首先,将客户需求、内部需求和性能上的需求分解为功能点,基于功能点产生开发任务和Backlog,根据结构化的需求和任务,制定计划。

敏捷,是因为谁都不知道需要做什么。因此,在敏捷过程中,有两个产物:一个是可执行的软件,一个是由结构化的功能点所组成的概念产品。在开发的过程中,这两个产物都将随着开发的推进不断调整。每一轮迭代都会产生一个新的可执行产品,而可执行的软件会反过去影响概念产品,如重新调整功能点的优先级、新增需求等。整合的敏捷开发,不是追求任务的敏捷,而是需求的敏捷。

敏捷能计划吗?

有的人说,敏捷就不需要计划了。相反,敏捷是可以计划的,还可以有很漂亮的计划。整合的敏捷方法实现了产品、版本、里程碑、Sprint多个层次的项目规划。

针对每一个Sprint,计划的过程中都可以合理的安排团队和工作量,让项目经理、产品负责人充分发挥团队中的每一份力量。

敏捷如何保证质量?

使用敏捷方法如何保证产品质量呢。敏捷开发不同于传统的测试:

非常短的开发周期 缺乏完整的文档和测试方案 传统的测试方法和工具在敏捷中都不再使用 需要与客户和开发人员直接交流 及时针对需求的变化调整测试方案 针对这些特点,整合的敏捷开发倡导的SpecDD方法使得需求能够驱动测试,保证了测试模板和测试任务,保证了从需求到开发任务,到测试的可追溯性。

如何评判一个开发方法?

软件研发的本质是选择最佳的开发方法,保证开发的质量和效率。正确的开发方法,必然会会软件产品的以下指标带来影响:

高效性(efficiency)

可靠性(reliability)

可理解性(understandability)

可维护性(maintainability)

可重用性(reusability)

可修改性(modifiability)

可适应性(adaptability)

可移植性(portability)

可追踪性(traceability)

可互操作性(interoperability)

一种多元化、开放的敏捷开发方法将是现代企业的首选。敏捷开发顺应了软件开发的潮流,从开发方法上适应了需求的改变,能够不断进化并且适应新的需求。对于企业来说,最佳的敏捷方法必然是一种混合的方法,它融合敏捷和多种开发方法的元素,解决敏捷方法中对计划、资源和质量管理方面的不足,将各种元素融会贯通,从而形成符合企业自身业务特点的开发方法,使之最有效的服务于开发团队。