敏捷开发实践 拥抱变化的产品开发流程

随着Agile敏捷开发的流行，越来越多的公司采用敏捷开发用于软件产品和应用的开发。笔者的产品开发团队在两年前开始采用敏捷开发方法，一直实践到现在，并取得不错的成果，包括：产品功能更加符合市场和业务人员的需求，开发效率获得提高。本文从实践的角度介绍笔者所在团队的产品敏捷开发过程和作者的敏捷开发体会。

敏捷开发体会

实施敏捷开发近两年来，我对在产品开发中应用敏捷方法有着深刻的体会。首先说下产品背景。我参与的产品是面向行业的产品，在全世界都有客户，有10年历史，和一百多个基于不同版本的客户，我们的团队完全负责产品的未来发展方向、发布计划、架构、设计、开发进度、测试、客户支持等。在这样一个面向全球的产品和自主的团队环境中进行敏捷开发体会尤其深刻。

1) 注重概念和架构设计，而轻详细设计

敏捷开发中，注重概念和架构设计，而轻详细设计。这里的概念设计，可以看成是为什么要做这个产品或模块，强调的是产品的路线规划、市场趋势、客户价值、技术趋势等。架构设计，可以看成从整体上看，概念设计应该用什么方式实现、分几个层次、多少组件、不同层次和组件之间关系是什么。详细设计，则是具体的设计和做法、API接口等。

一个产品，特别是面向行业的产品，概念设计和架构设计非常重要，需要考虑行业未来的发展方向，产品在市场中横向和纵向的比较，技术的发展方向，和每个模块的投入和收益的比例等，这样才能尽可能保证产品沿着正确的方向前进。在产品中新增或删除一个模块需要非常谨慎，因为一旦新增模块被客户使用，以后就很难在产品中去掉这个模块。还需要考虑产品各个版本之间的兼容性，以及客户的升级迁移。所以，在开始正式开发之前，通过概念设计和架构设计，梳理思路是非常必要的。

2) SWOT分析

以前在做项目时，大多是从技术角度来考虑哪一些功能模块需要做，哪一些功能模块先做，而没有一个系统化的分析方法。造成的结果是有一些功能模块投入很多资源，却并不一定是客户最想要的。

在敏捷开发中，更加注重客户需求。如果对产品进行SWOT分析，就能选出付出最小工作量，但能获得最大价值的模块。

SWOT分析阶段会在概念设计和架构设计之后进行，输入是概念设计和架构设计，输出是模块的重要度和需要的时间。这样按照性价比可以进行排序，选出最能符合市场的模块。

一款产品哪个模块重要，哪个先做，需要花多少资源和时间投入，花这么多时间和资源的模块是否在客户心中有相应的重要程度等，这些都是由这款产品的市场策略来决定。所有产品都是为了市场和赢利为目的，Agile方法更好地帮助企业实现了这一点。

3) 业务和客户驱动，而非技术驱动

这点说是体会，也可以说是教训。在我们的产品开发过程中，在某一新版本中重新设计了老版本的某一个重要模块，而引发了几个问题：一是，新版本的模块和老版本模块的兼容性问题，导致老版本客户无法平滑的迁移到新版本；二是，新版本的改进是纯技术方面的重新实现，不管对客户而言，还是对内部的架构而言，都没有明显好处；最后导致的结果是我们花了很多资源和人力去重新实现，但是在最后由于种种考虑还是废弃了重新实现的模块，依然沿用老模块。

在产品的敏捷开发中，虽说拥抱变化，但不盲目变化。产品的改动需要经过概念设计、架构设计以及SWOT分析后，三思而后行。敏捷开发中也强调"在整个项目开发期间，业务人员和开发人员必须天天都在一起工作"，确保技术人员能够开发出客户需要的产品。

4) 时刻考虑版本兼容性

敏捷开发，废除了过多冗余的文档和繁杂的设计，强调拥抱变化。但作为产品，敏捷开发不意味着盲目地去变化。

当设计变动、API接口重构、配置文件变更时，要时刻考虑产品的架构、规划路线图，老版本的兼容性，及迁移平滑性。否则，随着版本的增多，必将面对着大量的维护工作。

5) 轻文档，但非无文档

敏捷开发强调沟通的重要性，而轻冗余文档。但敏捷开发并不意味着无文档。在敏捷开发过程中，适量的文档还是很有帮助，有助于整理思路，加快沟通和讨论。

我们产品中的文档包括：概念设计文档、架构图、当前版本要实现的功能列表，以及SWOT分析。

这些文档在每个产品版本开始之前会有产生，在每个迭代的过程中根据业务人员和市场的反馈也会有一些变更。通过我们实践证明，这对产品的思路、沟通讨论都非常有帮助。

而且这些文档，大多是几页PPT，书写和维护工作都很小。

敏捷开发过程

敏捷开发改进了产品的开发流程，提高了整个团队的效率。下面分析敏捷开发前和敏捷开发后的产品开发的各个阶段。

1) 敏捷开发"前"的产品开发过程

图1 敏捷前开发流程

上图是敏捷开发前我们产品一个版本的开发流程，整个开发大概持续一年左右。从图中可以看出，流程中的大多数活动都是串行进行。这样的一种类似瀑布的开发流程，前提是需求在产品的初始阶段就完整的被捕获并正确的分析，这样才能保证最后交付的产品是客户所需要的产品，但通常这样的理想状况很难实现。

类瀑布的开发流程缺乏灵活性，无法通过开发活动来发现不够确切的需求，导致产品无法随着业务人员和市场的反馈而随需应变，开发出符合业务人员需求的产品。

2) 敏捷开发"后"的产品开发过程

图2 敏捷后开发流程

上图是敏捷开发"后"我们产品一个版本的开发流程，整个开发大概也是持续一年左右，但每个迭代都是1个月时间。和敏捷开发前相比，有很多的区别和优点，下面是其中几点：

市场和需求驱动，拥抱变化

在我们产品敏捷开发中，每个迭代结束，都会有一个产品迭代演示大会，把这个月的开发结果演示给组员、业务人员、售前，甚至客户，并收集反馈。此外，在开发的过程中，产品的业务人员和售前时刻保持与产品开发团队的沟通和工作，保证开发出来的产品是符合业务需求。

充分利用资源和时间

敏捷开发前，产品的需求设计阶段占用整个开发流程35%左右的时间，这段时间只需要几个核心的架构师和设计人员，无法充分地利用开发和测试人员。敏捷开发后，迭代开发、强调沟通、缩减文档，在每个迭代初期就可以充分地利用开发、测试人员的时间，达到效率最大化。

每日交付

产品开发过程中，每天都会做自动化Build，并生成可以交付的产品。业务人员、客户都可以试用并提供反馈和新需求。

充分自动化

敏捷开发强调拥抱变化，这必然带来动荡的产品代码变更。每一个新的功能和修改的功能，都可以影响到其他功能，造成副作用。所以，需要自动化去支持变化，在变化的同时保证质量和开发速度，包括编译自动化、单元测试自动化、功能测试自动化、UI测试自动化、集成测试自动化等。

架构师和Scrum Master的重要性

流程的变化必将带来岗位和职责的变化，架构师和Scrum Master是在敏捷开发中两个重要的人物角色：

1) 产品架构师

在产品的敏捷开发中，特别是我所参与的产品是面向行业的产品，架构师是个举足轻重的角色，需要有深厚的行业背景、创新能力，以及架构能力。

产品是为了解决一类客户需求而存在。但是，客户的需求往往是会随着业务的发展而变化，而且竞争对手也会有类似产品的推出。所以一个产品推出市场后，所具有的功能模块慢慢地会越来越成熟，并拥有越来越多的竞争对手，慢慢地失去竞争力。一个好的产品，特别是面向行业的产品，要具有长期的生命力，需要具有下图所示的产品模型：

图3 产品发展模型

成熟的模块：指的是推出市场有一段时间，这些功能模块因满足客户的需求而被广泛使用。随着市场趋于稳定，大量竞争对手的产品也推出类似的功能。这些成熟模块都是产品的基本模块，不代表产品的竞争力。产品中如果只具有这些功能模块，随着需求和竞争的激烈，慢慢会走向灭亡。如90年代的BP机一样，当手机一旦推出，这个产品也就走向灭亡。

发展中的模块：指的是刚推出市场并且具有强劲的市场生命力、符合客户当前几年的业务发展需求，正在被大客户所接受的功能模块。这些功能模块是产品占领市场的动力，是继成熟的功能模块后，产品的新的增长动力。

研究中的下一代产品方向：指的是还没有推出市场、正在研究中的、符合未来行业五到十年发展方向的模块。当然如果能创造出未来的发展方向，则是最高境界。如任天堂的Wii、苹果公司的iPhone。

一个行业软件产品要保持长期的生命力，在整个产品的生命周期架构规划中，需要考虑到这三种模块和特性，只有这样才能保持产品的先进性和长久生命力。

敏捷开发也强调拥抱市场变化，这对产品架构师提出了很高的要求――深厚的业务背景、创新能力、技术洞察力和架构思想。

2) Scrum Master

Scrum Master虽然是敏捷开发的新名词，但其工作内容和开发组长没什么太大的区别：安排任务、协调资源、控制进度和解决难题。

架构师根据对行业的理解和创新，设计出产品的架构。Scrum Master则是进一步分解和实现这个架构中的每个组件。如果形容"奥运会开幕式"是一个产品，架构师则设计整个开幕式的主题、创意、架构和包含的主要环节，而Scrum Master就是整个庞大工程的详细设计者和协调者。

在我们产品中有三个Scrum Master，各自负责架构中的不同模块，并和开发人员一起把模块分解成一个个单独的、可以衡量的用例，然后协调开发人员高质量的完成任务。

此外，每天早上需要主持小组成员进行一个10分钟左右Scrum会议。每个组员汇报昨天完成的任务，是否完成任务以及碰到的问题，最后是今天打算完成的任务。Scrum Master会协调解决每天碰到的问题，确保产品进度和质量。