导读：

最近几年，敏捷交付已经渗透到每个产品和项目，我们逐渐摸索出适合我们自有的模式，本文将讲解佣金产品的敏捷交付。首先我们说明一下敏捷开发，敏捷开发并没有定义具体的开发过程，而是起源于一个简单的理念，那就是《敏捷宣言》。

而之后的各种方法论，其实都是为了践行这个原则。简单来说敏捷开发是一种应对快速变化的需求进行迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目（子任务），各个子项目的成果都经过测试，具备集成和独立可运行的特征。敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本。然后在后续的生产周期内，按照新需求不断迭代升级，完善产品。

敏捷交付特性

传统的项目研发管理首先是做好全面的的规划，就像登山一样，首先确定山顶高度；从各个角度设定最佳攀登坐标；收集最近天气变化情况，以及预测未来登山的天气；提前预备遇到风险以及规避方案，以及登山人力挑选等；一切准备就绪，择日登山。

敏捷方式则是以现有的装备以及人力，立即出发，先登上一个小山峰，然后总结经验，再继续下一个山峰，时刻拥抱变化，根据变化随时调整路线，最终登顶。

两种方式目标都是为了登顶，但敏捷方式会更快、更优，为什么？我们需要讲一讲敏捷交付带来的特性：

• 持续的集成测试：在以往的一个版本交付周期中，使用敏捷交付可以完成 5-6 个迭代周期，测试在前期需求调研分析到版本交付持续投入跟踪，并在每个迭代周期中，完成集成测试；

• 版本迭代变更快：在每一个版本迭代过程中，需求变化得到及时改造，及时的纠正前期需求差异，保障版本需求完整性；

• 降低风险：在周期短的交付中，遇到方案的差异，可以及时纠正，规避了后期整体方案的调整，降低了版本重构的风险；

• 得到用户早期反馈：用户可以提早接触到产品，可以提前体验产品功能的使用，产品研发侧也可以尽早的完善产品功能，保障产品的可用性；

• 提高复用性：快速产出可使用的产品是敏捷的最初理念，在这过程中可以避免重复造轮子，提高功能以及代码复用能力。

为了快速提升佣金产品交付，产品线充分利用敏捷的特性，融合到项目研发过程中，对研发过程进行变革，团队上下贯彻敏捷交付方法：

• 做对的事情 - 拥抱变化、紧密和客户沟通、敏捷计划会都可以认为是保证团队在做对的事情，适应市场的不断变化；

• 把事情做对 - 确定了产品需求，接下来是把事情做对，通过站立会议、敏捷评审会快速测试来保证；

• 把事情做的有效率 - 迭代、story points（用户故事）、敏捷回顾会属于这个范畴，只有使用迭代和 points 才能评价团队的效率、持续改进团队内的沟通和工作方法，最终提升团队整体战斗力。

敏捷交付实战

敏捷初体验-广西佣金交付

在以往佣金结算系统上线过程中，从（需求分析->设计->研发->测试->集成测试->版本发布）一个周期，满足系统全流程出账（采集-预处理-拣重-批价-合账）需要将近两个月的时间。版本交付到现场，客户接收测试后经常需要再一次进行需求澄清或是需求变更，进行下一轮的优化改造，基本耗时一个月的时间完成整改，整体耗时需要三个月的时间完成全量版本交付。

传统项目研发交付周期长主要体现：

• 需求变更重复研发 – 传统项目研发过程中，大版本交付周期长，客户对交付的版本功能如果存在需求理解差异时，导致整个需求方案重新研发，进一步拉长交付时间。

• 研发人力投入不集中 – 大版本交付过程中，来回耗时周期长，研发人员前期版本研发完成后，在后续交付过程中，可能已投入其他项目，对已交付到现场的版本需求优化以及需求变更的改造，研发又要进一步评估投入，拉长整体项目交付周期。

• 测试交付人员投入太晚 - 系统研发过程中，大专题需求研发过程中，测试交付人员前期只能投入需求分析以及案例输出，无法快速投入具体功能迭代测试，对后续整体系统的测试需要消耗大量时间。

针对以上问题，我们在广西佣金结算系统上线首次采用敏捷交付试点，对整体系统进行拆分，按流程模块进行研发、测试、交付，同时每天进行站会，总结当天输出、风险、需求变化，及时落实到研发团队。

在一个月的周期中，完成六次版本迭代交付，保障了客户第一时间验收系统功能。历经两个月的时间完成广西佣金结算系统的交付上线，比以往传统交付上线缩短一个月时间。

敏捷带来的快速迭代交付，也给研发团队带来了很大的考验，主要体现在：

• 从局部效率到高效交付 – 敏捷研发时间压缩，高频的小版本交付，对版本研发质量要有保障，需要做到顺畅高质量交付。小版本高频率的验收测试驱动开发，确保高质量的准入准出。测试团队从需求分析开始全程投入，前期输出分析文档和案例，研发过程中就参与到具体功能模块中单元测试，保障版本质量。同时测试团队介入方案技术预研测试，降低需求方案返工率，提升研发效率。在每一次版本迭代发布后，对该短周期的研发过程问题进行复盘，总结提升要素。持续交付实践的实施、定期复盘、反馈分析等，即时发现和解决问题，团队对外的交付响应能力随之增强。

• 产品升级频率成倍增长 -敏捷研发带来的快速迭代交付，小版本高频率的打包、发布给测试人员和现场实施人员带来的重复枯燥的繁琐升级部署工作。对此，我们对现有系统统一 docker 化镜像部署进行改造，系统版本都以镜像方式自动构建，充分利用了公司 ZCM 平台进行自动化持续构建部署，一键构建、一键发布、一键部署，有效的解决敏捷带来的小版本迭代高频率版本交付、升级的问题。

敏捷开展-重庆 &辽宁佣金交付

敏捷交付在广西佣金结算系统交付体验过程中，充分展示了快速迭代的优势，保障项目实施进度。接下来在重庆和辽宁佣金研发过程中，我们进一步完善迭代的计划会议，总结广西佣金结算系统在敏捷交付过程的优缺点，逐渐形成了一套更加成熟的佣金产品敏捷开发模型和过程分析：

佣金研发团队版本研发过程

◉  第一步：获取需求

佣金产品经理从现场客户、现场项目经理、佣金研发团队以及其他使用过佣金系统的干系人处首先获取到初步的需求，这个时候的需求可能是明确的，也可能是笼统的（可能是佣金系统干系人还没有想清楚的需求）。

◉ 第二步：拥抱需求

佣金产品经理整理所有的需求并分解需求到 Product Backlog（产品需求列表，又可称作产品待办事项列表或需求积压列表）列表中，并对列表中的任务进行优先级排序，开发团队根据列表中制定的优先级进行研发。其中，最重要的需求显示在 Product Backlog 的顶部，确保佣金研发团队知道这就是要先交付的成果。因此，佣金研发团队不是按照佣金产品经理规定的节奏开展工作，佣金产品经理也不会是开发团队完成工作的驱动者。相反，佣金研发团队根据 Product Backlog 中的顺序推进工作，通过看板的持续改善或 scrum 的迭代来完成这些需求。

◉ 第三步：迭代计划会议

在迭代计划会议之前，佣金产品经理会提前将优先级高的、大颗粒的需求细化为单个迭代可以交付的多个用户故事。迭代计划会议前半场一般是由佣金产品经理先讲下原型、用户故事，研发团队成员提出疑问、细节问题。会议后半场是研发团队对本次迭代列表中的用户故事进行工作量评估。最后，佣金研发团队根据本次迭代任务的复杂度、任务量来决定一个迭代周期。通常，迭代周期在 1 周到 4 周，不宜太短也不宜太长。在迭代会议上，佣金研发团队根据开发功能的优先级定义出本次迭代（比如 1 周）能完成的任务量，并形成 Sprint Backlog（迭代任务：就是本次迭代内应该完成的任务列表）。

◉ 第四步：每日站会

每天早上佣金研发各小组都会开每日站会，每日站会是一个简短的会。站会开始前，佣金研发团队成员会更新看板上的任务状态，开会时每个人都可以看到当前的进展情况。团队一般会利用 15 分钟左右的时间，站在看板前，每个人讲述一下昨天任务完成情况，今天的计划和遇到的问题，在这个过程中察觉和消除潜在的风险。

◉ 第五步：需求列表不断更新

在 Product Backlog 列表中也会有很多不明确的需求（通常是优先级较低），都会在开发的过程中渐渐清晰，当需求明确后，反过来再查看目前分解任务，就会发现需求变化了，新的需求来了，但是敏捷是拥抱需求，所以我们会把需求更新到 Product Backlog（产品需求列表）中，待下一次迭代的时候再进行迭代会议讨论、排优先级进行开发。

◉ 第六步：小版本发布

佣金系统每次迭代的版本功能可以需求不完整、有缺陷，但是必须是可视可运行可操作。佣金研发团队以小版本发布的节奏，保证团队在固定周期对电信客户有交付，交付不是承诺某功能一定在某天上线，而是确保需求功能按优先级顺序开发、测试并在迭代上线日上线。这正是佣金研发团队利用敏捷中小版本发布的优势：

• 总体风险比较少：小版本总是在上一个版本基础上局部调整和增加，变化小使得技术复杂度低；由于规划的功能较少，工作量也易于估算，所以其总体风险比较少，常常能如期发布。

• 提升需求接纳能力：由于小版本快速实现并发布测试，然后就进入下一个小版本的周期，这样新需求一旦提出就能快速进入开发视野和尽快实现。而且在变更大的时候，小版本控制能随时将程序恢复到以前某一时间点状态。

• 测试和开发高效协作：小版本能将开发环境与测试环境进行有效的隔离，使得开发和测试可以并行工作。例如，当开发实现第一个版本后，开发人员就进入下一个版本周期；测试人员测试新发布的版本并提交 Bug，开发人员就可以在下一个版本结束时修正所有上一轮发现的 Bug，然后发布新版本。如此循环往复，开发和测试实现高效协作。

• 开发进度可控：频繁的小版本发布可控制软件开发的进度，通过小版本发布能使佣金产品各负责人对整个佣金产品的进度、程序的编写、修改情况有一个整体的了解。

◉ 第七步：反思会

佣金研发团队在每次迭代周期完成后，会召开简短的反思会，反思在上一次迭代版本开发中哪些做的好，哪些做的不好，总结经验教训，并给出改进计划，再在下一个迭代中改进。

敏捷交付成效

佣金产品的研发团队并发多省交付，提前沟通确认的需求故事在团队中迅速溶解，团队节奏快而紧凑、推进迅速，一个月内发布交付最高达到 10 个版本以上，灵活调配促进了团队内部、团队与客户之间的互动。满足用户不断变化的需求，在每一次迭代周期结束时,都能交付用户一个可用的、可部署的系统。随时收集用户意见和需求，在随后的迭代周期中，这些意见和需求一起在产品中实现和集成。需求故事的变更也快速落地到版本，和客户达成共同利益。

敏捷使得整个佣金产品在忙而有序、从容有度、高质快速的迭代中演进。

得益于敏捷交付，现在佣金结算 3.0 产品已经完成 8 省电信佣金、移动集团 12 个省份结算、3 省移动酬金、1 省联通酬金的上线，未来还有移动集团 20+省份，电信佣金 2 省份上线。