【转】敏捷开发：拥抱变化的产品开发流程

本文作者: 陈序明(chenxm21@gmail.com)
摘要：随着Agile 敏捷开发流程的流行，越来越多的公司采用敏捷开发流程用于软件产品和应用的开发。
作者的产品开发团队近两年前开始采用敏捷开发方法，一直实践到现在，并取得了不错的成果，比如：产品功
能更加符合市场和业务人员的需求，开发效率也有了提高。文章从实践的角度介绍作者所在团队的产品敏捷开
发过程，和作者的敏捷开发的体会。
1. 产品中进行敏捷开发的体会
敏捷开发近两年来，对在产品开发中应用敏捷开发有了很深刻的体会。首先说下产品背景，我参与的产品
是面向行业的产品，在全世界都有客户，有10 年历史，和一百多个基于不同版本的客户，我们的团队完全负
责产品的未来发展方向、发布计划、架构、设计、开发进度、测试、客户支持等。在这样一个面向全球的产品
和自主的团队环境中进行敏捷开发体会尤其深刻。
1) 敏捷开发中，注重概念和架构设计，而轻详细设计
这里的概念设计，可以看成是为什么要做这个产品或模块，强调的是产品的路线规划，市场趋势，客户价
值，技术的趋势等。架构设计，可以看成从整体上看，概念设计应该用什么方式实现，分几个层次，多少组件，
不同层次和组件之间关系是什么。详细设计，是具体的设计和做法，API 接口等。
一个产品，特别是面向行业的产品，概念设计和架构设计非常重要，需要考虑行业未来的发展方向，产品
在市场中横向和纵向的比较，技术的发展方向，和每个模块的投入和收益的比例等，这样才能尽可能保证产品
沿着正确的方向前进。在产品中新增或删除一个模块需要非常谨慎，因为一旦新增模块被客户使用，以后就很
难在产品中去掉这个模块，因为你需要考虑产品各个版本之间的兼容性，以及客户的升级迁移。所以在开始正
式开发之前，通过概念设计和架构设计，梳理思路是非常必要的。
2) SWOT 分析
以前在做项目时，大多是从技术的角度来考虑哪一些功能模块需要做，哪一些功能模块先做，而没有一个
系统化的分析方法。造成的结果是有一些功能模块投入了很多资源，但却并不一定是客户最想要的。
在敏捷开发中，更加注重客户需求，如果对产品进行SWOT 分析，就能选出能够付出最小的工作量，但
能获得最大价值的模块。
SWOT 分析阶段会在概念设计和架构设计之后进行，输入是概念设计和架构设计，输出是模块的重要度，
和需要的时间。这样按照性价比可以进行排序，选出最能符合市场的模块。
一款产品哪个模块重要，哪个先做，需要花多少资源和时间投入，花这么多时间和资源的模块是否在客户
心中有相应的重要程度等等，这些都是由这款产品的市场策略来决定。所有产品都是为了市场和赢利为目的，
在Agile 中，更好的帮助企业实现了这一点。
3) 业务和客户驱动，而非技术驱动
这点说是体会，也可以说是教训。在我们产品开发过程中，在某一新版本中重新设计了老版本的某一个重
要模块，而引发了几个问题：一是，新版本的模块和老版本模块的兼容性问题，导致老版本客户无法平滑的迁
移到新版本。二是，新版本的改进是纯技术方面的重新实现，不管对客户而言，还是对内部的架构而言，都没
有明显好处。最后导致的结果是我们花了很多资源和人力去重新实现，但是在最后由于种种考虑还是废弃了重
新实现的模块，依然沿用老模块。
在产品的敏捷开发中，虽说拥抱变化，但不以为着盲目的变化，产品的改动需要经过概念设计、架构设计
以及SWOT 分析后，三思而后行。敏捷开发中也强调“在整个项目开发期间，业务人员和开发人员必须天天
都在一起工作”，确保技术人员能够开发出客户需要的产品。
4) 时刻考虑版本兼容性
敏捷开发，废除了过多冗余的文档和繁杂的设计，强调拥抱变化。但作为产品，敏捷开发不意味着盲目的
去变化。
当设计变动、API 接口重构、配置文件变更时，要时刻考虑产品的架构和规划路线图，和老版本的兼容性
及迁移平滑性。否则，随着版本的增多，必将面对着大量的维护工作。
5) 轻文档，但非无文档
敏捷开发强调沟通的重要性，而轻冗余文档。但敏捷开发并不意味着无文档。在敏捷开发过程中，适量的
文档还是很有帮助。有助于整理思路，加快沟通和讨论。
我们产品中的文档包括：概念设计文档，架构图，当前版本要实现的功能列表，以及SWOT 分析。
这些文档在每个产品版本开始之前会有产生，在每个迭代的过程中根据业务人员和市场的反馈也会有一些变
更。通过我们实践证明，这对产品的思路，沟通讨论都非常有帮助。
而且这些文档，大多是几页PPT，书写和维护工作都很小。
2. 产品敏捷开发过程
敏捷开发改进了产品的开发流程，提高了整个团队的效率。下面分析敏捷开发前和敏捷开发后的产品开发
的各个阶段。
1) 敏捷开发“前“的产品开发过程

图1 敏捷前开发流程
上图是敏捷开发前我们产品一个版本的开发流程，整个开发大概持续一年左右。从图中可以看出，流程中
的大多数活动都是串行进行。这样的一种类似瀑布的开发流程，前提是需求在产品的初始阶段就完整的被捕获
并正确的分析，这样才能保证最后交付的产品是客户所需要的产品，但通常这样的理想状况很难实现。
类瀑布的开发流程缺乏灵活性，无法通过开发活动来发现不够确切的需求，导致产品无法随着业务人员和
市场的反馈而随需应变，开发出符合业务人员需求的产品。
2) 敏捷开发“后“的产品开发过程

图2 敏捷后开发流程
上图是敏捷开发“后”我们产品一个版本的开发流程，整个开发大概也是持续一年左右。但每个迭代都是
1 个月时间。和敏捷开发前相比，有很多的区别和优点，下面是其中几点：
?? 市场和需求驱动，拥抱变化。
在我们产品敏捷开发中，每个迭代结束，都会有一个产品迭代演示大会，把这个月的开发结果演
示给组员，业务人员，售前，甚至客户，并收集反馈，并。此外，在开发的过程中，产品的业务人员
和售前时刻保持和产品开发团队的沟通和工作。保证开发出来的产品是符合业务需求。
?? 充分利用资源和时间
敏捷开发前，产品的需求设计阶段占用了整个开发流程的35%左右的时间，这段时间只需要几个核心
的架构师和设计人员，无法充分的利用开发和测试人员的时间。敏捷开发后，跌待开发，强调沟通，缩减
文档，在每个迭代的初期就可以充分的利用开发、测试人员的时间，达到效率最大化。
?? 每日交付
产品开发过程中，每天都会做自动化Build，并生成可以交付的产品。业务人员，客户都可以试用并
提供反馈和新需求。
?? 充分自动化
敏捷开发强调拥抱变化，这必然带来动荡的产品代码变更，每一个新的功能和修改的功能，都可以影
响到其他功能，造成副作用，所以需要自动化去支持变化，在变化的同时保证质量和开发速度。如：编译
自动化，单元测试自动化，功能测试自动化，UI 测试自动化、集成测试自动化等。
3. 产品敏捷开发中架构师和Scrum Master的重要性
流程的变化必将带来岗位和职责的变化，下面是在产品敏捷开发中两个重要的人物角色：
1) 产品架构师
在产品的敏捷开发中，特别是我所参与的产品是面向行业的产品，架构师是个举足轻重的角色，需要有深
厚的行业背景，创新能力，以及架构能力。
产品是为了解决一类客户需求而纯在。但是客户的需求往往是会随着业务的发展而变化，而且竞争对手也
会有类似产品的推出。所以一个产品推出市场后，所具有的功能模块慢慢的会越来越成熟，并且拥有越来越多
的竞争对手，并且慢慢的失去竞争力。一个好的产品，特别是面向行业的产品，要具有长期的生命力，需要具
有下图所示的产品模型：

图3 产品发展模型
?? 成熟的模块：指的是推出市场有一段时间，这些功能模块满足了客户的需求而被广泛使用，而且市场
趋于稳定，大量竞争对手的产品也推出了类似的功能。这些成熟模块，都是产品的基本模块，不代表
产品的竞争力。产品中如果只具有这一些功能模块，那随着需求和竞争的激烈，慢慢会走向灭亡。如
90 年代的BP 呼机一样，当手机一旦推出，这个产品也就走向灭亡。
?? 发展中的模块：指的是刚推出市场并且具有强劲的市场生命力，符合客户当前几年的业务发展需求，
正在被跟刚大客户所接受。这些功能模块是产品占领市场的动力，是续成熟的功能模块后，产品的增
长动力。
?? 研究中的下一代产品方向：指的是还没有推出市场，正在研究中的，符合未来行业五到十年发展方向
的模块。当然如果能创造出未来的发展方向，则是最高境界。如任天堂的Wii，苹果公司的Iphone。
一个行业软件产品要保持长期的生命力，在整个产品的生命周期架构规划中，需要考虑到这三种模块和特
性，只有这样才能保持产品的先进性和长久生命力。
敏捷开发也强调拥抱市场变化，这对产品架构师提出了很高的要求– 深厚的业务背景，创新能力，技术
洞察力，和架构思想。
2) Scrum Master
Scrum Master 虽然是敏捷开发的新名词，但是工作内容和开发组长没什么太大的区别。安排任务，协调资
源，进度，解决难题。
架构师根据对行业的理解和创新，设计出产品的架构。架构中包含的组件，以及不同组件之间的关系。Scrum
Master 则是去进一步分解和实现这个架构中的每个组件。如果形容“奥运会开幕式”是一个产品，架构师则设
计整个开幕式的主题，创意，架构和包含的主要环节，而Scrum Master 就是整个盘大工程的详细设计者和协调
者。
在我们产品中有三个Scrum Master，各自负责架构中的不同模块，并和开发人员一起把模块分解成一个一
个单独的、可以衡量的用例，然后协调开发人员高质量的完成任务。
此外，每天早上需要主持小组成员进行一个10 分钟左右Scrum 会议。每个组员汇报昨天完成的任务，是
否完成任务以及碰到的问题，最后是今天打算完成的任务。Scrum Master 会协调解决每天碰到的问题，确保产
品进度和质量。
4. 总结
在作者的理解中，敏捷开发是一种思维方式和软件过程方法论，以及一系列的最佳实践，它能帮助团队开
发出更加符合市场需求的产品。我们团队在产品两个版本的敏捷开发历程中，不断的摸索，找到了一条适合自
己的产品敏捷开发流程，我们还需要继续用敏捷的思想改进我们的敏捷开发流程，和大家讨论探索，持续改进。