今天有幸邀请到什马金融公司的CTO 汪晓明 为我们介绍敏捷开发的实践。

一、主题分享：敏捷开发分享

首先介绍一下我们什马金融公司，我们的网站是www.shenmajr.com，目前的主业是消费金融+供应链金融。未来的定位是做面向农村的互联网金融服务平台，当然离这个目标还有很远，但是我们从消费金融起步，的确是踏踏实实在往这个方向走。我们的IT团队目前大概80人，计划在Q2到100出头，现在办公地点在虹桥凌空SOHO，下周会新开一个位于张江的研发办公室。技术研发这一块，主要围绕三方面的工作展开：渠道及客户关系管理、贷前信审和风控，贷后运营及清结算。我们的大部分系统现在都是自主研发，而研发管理体系是基于Scrum方法来构建的。Scrum是当今最适合落地的敏捷方法。

敏捷这个名词背后，更多的是一些原则性的东西，落实到实践层面，一直缺乏细节，即便是Scrum，也只是一个骨架，真正实施的时候各有各的做法。这个跟CMMI很不一样，CMMI是一个非常细致的指导框架。

我大概1年前来到什马，接手当时30个人左右的研发团队，一步一步把敏捷研发管理体系建立起来，到现在为止实现了一些最基本的元素，可以称得上一支合格的农民武装了，但是我们也明白还有非常多的欠缺，离正规军还有较大的差距。

不过我们团队还挺自豪的，因为我们是一个创业公司，业务的压力非常巨大，时间表基本上没有商量的余地，996是家常便饭，而且每个月都有不少人员变动，在这样的情况下，我们能够一边打仗一边练兵，把工作方法一点点改进，大家都挺有成就感，认同度也越来越高。

我们自称为“激流中的敏捷”——这个氛围和路程跟大公司搞敏捷完全不一样。先给大家讲讲敏捷的收益：

  1. 良好的协作——大家非常明确各自的角色和职责 ;
  2. 透明的管理——任何事情只要我想跟，能够一跟到底，研发内部所有的问题都会及时暴露出来
  3. 实现对外的承诺——我们能够做到任何需求3天内完成详细分析和项目计划，小需求平均交付周期在10天左右，项目交付准点率接近80%
  4. 业务系统故障率持续降低，目前已经降低到每千次交易仅有1次故障，跟很多成熟公司还有很大差距，但是我们内部都能看到IT团队巨大的进步。

我们内部新员工入职的时候，帮助他们快速理解我们的敏捷方法核心骨架，我都会给他们做一个关于高铁的比喻。
高铁

我们研发人员和测试人员，按Scrum团队混编，每个scrum团队负责一个或者多个系统的迭代维护。我们把这样一个scrum团队比喻为一列高铁，scrum master就是列车长。为什么类比为高铁呢？有几个含义：

  1. 他们的工作计划，应该像高铁的列车时刻表一样，精准，有固定的节奏；
  2. 他们的工作能力，应该像高铁的座位容量一样，数量明确，可以计算，不能随便超载；
  3. 他们的运载的东西，也就是团队的工作任务，不是由他们自己的决定，而是由买了票的乘客决定的；
  4. 他们要定期维修——偿还技术债务

那么谁是顾客呢？在我们这里，产品部的产品经理，就是买票上车的乘客。但是实际上，为了更好地组织工作，我们IT内部还成立了一个PMO，承担售票处的角色，把不同的乘客分配到不同的列车班次里面。这种组织方式，是以高铁的运输能力为核心的，一切的安排，都是为了能把运力最大化。有的公司喜欢搞灵活的项目制，很灵活，但是研发人员调整非常频繁，团队效率不可能高，我把那种组织方式类比为出租车队，或者大巴车队——我们在部分创新项目上也会搞出租车队模式，但是绝大部分的人员会以高铁模式运作。
高铁

技术团队对外的沟通非常重要，以上是一个图，说明研发流程中必须的对外沟通点，主要是跟产品部。我们以JIRA为中心组织研发流程，原始需求都以Epic的形式提交到JIRA中，然后PMO会把需求分解，其实是做了一个系统分析的工作，把业务需求分解到各个系统上去实现。PMO根据各个研发组的排期情况，会汇总成一个项目计划，对外沟通，确定联调事件、UAT时间、试运行时间和正式上线时间。

我们的项目分为4类，其中I类项目是比较大的，通常会涉及到很多子系统，由多个scrum团队分担的项目。通过这种组织方式，我们基本上能做到把敏捷流程运用到几十人协作的比较大的项目上去，其实沿用这样的理念，我觉得10个scrum团队，100个人，协作一个项目应该都没有问题。更大的项目我还没试过，不敢妄言。
高铁

我的QA负责人，除了管理测试工作之外，还要负责流程改进，同时也担当了敏捷教练的角色。这是我们的敏捷流程健康度检查表：
高铁

在研发过程中，虽然我们强调轻设计，其实并不是没有设计，设计过程在整个沟通框架里面自然而然的做了。例如，我们的scrum planning meeting要求把每个需求讨论到详细设计的程度，只是不用落下文档而已，其实具体的实现细节是必须讨论清楚，然后通过扑克牌游戏来估算它的规模。

高铁
以上是我们对每个用户故事的DoR定义 – 需求必须分解到这个程度，才能进入Sprint迭代。

高铁
以上是我们的DoD定义，scrum团队必须完成清单中所有动作，才能达到上线标准。

我们对QA团队非常重视，QA团队有随时拉停生产线的权力，QA评审不通过，CEO下令，也不能上线。为了跳出传统的轻视QA的怪圈，我们甚至矫枉必须过正，明确要求QA有独立的汇报线，不能听命于开发。其实本质上的目的，是希望从需求开始，一个头，两条线，分别负责，最终在SIT环节对齐，确保不会出大问题。所谓敏捷，落实到执行层面，必须保证需求是小粒度的，同时，QA和开发的工作是并行交织在一起的，开发开始写代码的时候，QA同时在做测试案例和测试数据，做完一个需求，验证一个需求，不能等到一个版本所有需求开发完成，再交给测试人员去验证。有很多团队，把敏捷做成了小型瀑布模型，其实并不能实现非常灵活的拥抱变化。我们基本能够做到在过程中随时调整，从版本里面拿进拿出需求，整个计划不会乱，过程中非常通透，决策非常快，团队无论面对何种变化都有信心，从系统里面能很快得到细节的信息，跟需求方一起权衡调整。敏捷方法其实不是银弹，没法让一个人产能翻倍，甚至对需求比较平稳的项目来说，效率还不如瀑布模型，但是的确比较适合我们这样的快速变化的团队。

二、Q&A

Q1：请教个问题，任何公司的产品开发规范都是从无到有的过程， 如果公司的决策层都是销售、市场出身，您觉得如何能够将这套开发规范落地？
A：我们什马金融其实是非常典型的， 公司的决策层都是销售、市场出身，原来对技术团队非常不信任。那我怎么办？其实刚开始啥都不用说，他们也不关心你的工程管理方法，他们只要结果，你必须交付结果，才能得到他们的信任，他们才会给你足够的施展空间。例如，我们现在能做到及时响应需求，准时准点发布，上线不出大Bug，时间表从来不讨价还价

Q2：我先说一个问题，在你的敏捷开发工作中，肯定会和PM打交道。你觉得该如何和PM接触或者PM如何与你们沟通才能做的更好？
A：我前面发了一张图，跟PM沟通的方式，你往前翻翻看看

Q3：在敏捷的过程中一个系统的多项需求的并行中，出现变动是由Pmo协调么
A：是的，PMO协调解决

Q4：新人如何接手老系统？
A：新人对老系统接手的问题，不是敏捷流程能解决的，这个只能从人员管理的角度想办法

Q5：我们以前都是直接忽视PMO的，因为有了他们更乱
A：我们的QA人员，跟研发一起开计划会，直接听产品经理讲需求，基本上比研发更懂产品，因为他们还要做反向测试计划

Q6：沟通成本这么低，意味着团队之间会有相互妥协，开发质疑产品需求理的不够细，产品抱怨开发Bug多， 性格倔一些的人估计开始时都不适应这套， 您们是如何解决这种团队协作问题的？
A：你说的相互抱怨，是个文化问题，对于这种问题，敏捷也解决不了，研发负责人，以及相关负责人，必须有非常强的领导力，及时喝止味道变坏的文化

Q7：pmo 多少人?
A：PMO的定义，比较模糊，我的做法跟教科书做法也不一样。不过我们的原则很简单，PMO搞定所有项目计划和资源协调的事情，也包括外部供应商的管理。你只要明确了职责范围，叫什么名字不重要，我要是某天把PMO改名叫CTO办公室，也一样能玩。关键是你要分析整个团队中，哪个环节的职责需要由谁来承担，我这里PMO的职责，在许多公司，是由研发经理来承担的

Q8：敏捷开发中缺少文档的问题怎么解决：
A：关于敏捷不重视文档的认识，是错误的。敏捷对于文档的态度是不搞形式主义的文档，定一个参考框架，类似DoD，DoR这种，然后让团队自己决定写多少，通常必要的文档，团队中比较成熟的工程师，都会提出来这个我们还是要写的

Q9：日常你们估算需求，单位是什么？
A：我们用人天，叫标准人天。团队目前还不成熟，用故事点的话大家反而无所适从，变成了削足适履

Q10：敏捷唯一违反的就是老板的原则，反而对团队来说，目标明确
A：敏捷并不违反老板的原则，我前面说过，老板根本不关心是不是敏捷，他们只关心：1）速度 2）线上质量 3）成本。敏捷有助于实现老板三大目标

Q11：如果sprint目标不可能达成 你们会立即终止？
A：sprint跟高铁的列车时刻表一样，到点必须终止

Q12：是否有专职的敏捷教练？
A：QA总监兼职敏捷教练。
Q13：两周sprint，一周后发现大问题，还继续吗？
A：当然继续，sprint就是个时间盒子的概念，不承载任何更多的东西，时间无法停止。大家要区分sprint和version，要终止的只有version，如果发现问题，可以取消。Sprint是不取消的，就像高铁发了车，哪怕是空车，哪怕装错了人，也得继续往前开。

Q14：当一阶段目标错误或者方向改变？也不终止？
A：从sprint里面拿掉有问题的需求，然后重新装载没问题的等量需求进去。Sprint的唯一作用，只是成为团队的计时器，和工作量容器。如果紧急变更需求插入进来，例如我们经常碰到线上紧急bug需要立即解决，我们的做法是马上召开scrum团队会议，评估工作量，插入该bug fix需求，拿掉一个工作量差不多的业务需求。

Q15：性能指标依据是什么
A1：性能指标是来自需求，不过在需求阶段，系统的性能没有转化成单元模块的性能，这个通常在详细设计阶段完成。在敏捷开发中，就是所谓的单元测试用例阶段细化。
A2：我们的性能测试指标只是一个范围，或是平均值，视业务复杂度而定，单元测试阶段我们只做功能，性能测试我们带着压力测试一块做.

三、自由讨论

一：对账
Q1：目前各位对账都是用大数据平台做的吗？
A1：很少使用大数据来对账，大部分还是数据库跑批。
A2：银行都还是传统的方式做，例如中行是oracle跑的。

Q2：数据库跑批是否需要单独库吧？
A1：是的

二：版本控制
Q1：如果现在线上版本是1.0；但生产出问题了，我现在需要修复，重新出个版本；产品研发团队正在做V1.1的开发； 这个时候重新上线的版本需要怎么定义？
A1：补丁版本
A2：一般版本是三位数， 1.0.1， 1.0.2这样。 第一位是不兼容升级，第二位是增加新功能，第三位是bug修复。

Q2：当迭代需求特别多时，要如何处理呢？例如很短时间就成了V 1.24.N
A1：为了不失控，我们这边还是控了下版本号，但是版本号递增快，单次需求量不大；由于节奏快，bug率也高起导致后两位递增特别快
A2：QA团队一定要给力，加大QA的资源配置。版本号按群主说的三位，再加上daily build NO.应该可以比较完善地解决问题。
A3：软件开发是个异常复杂的事情，开发和QA两条线一起配合，分别为需求负责，有配合有制约，才能确保又快又好，否则没戏。
A4：业务与需求的问题，在设计阶段就要解决的，不是在编码阶段解决。

三：代扣渠道
Q1：有哪些代扣渠道对农行和邮储银行支持比较好的？
A1：银联。但是接入不容易
A2：银行通道
A3：银生宝
A4：易宝

四：微信支付宝错误返回消息
A1：支付宝微信，错误返回信息，商户这边能获取到么，还是单方面展示给用户的，不给商户拿的？
A2：正常来说如果你们做了聚合支付的话 最终是否成功要以你们通知商户的状态为准。聚合支付是把错误码做了包装和自定义。
A3：实际上只有成功的和未支付的。支付宝一张卡余额不足会再换一张所以只有最终结果，不会产生多笔失败原因的样子。
A4：一般是在前端单方面返回给用户，商户只能拿到终态的结果。

五：支付清结算基础数据
Q：谁知道支付清结算，涉及的基础数据有哪些，及响应的国际/国家标准。
A：参考金标委（金融标准化信息委员会）的国家标准

六：退费对敏感信息的保护
Q：退费时对敏感信息的保护有什么好的办法吗 ？
待解答

七：二维码标准
Q1：目前市面上用于支付的二维码用的是什么标准？
A1：三国鼎立：微信、支付宝、银联。还有少部分银行自建，最近人行也出了二维码标准。

Q2：目前做一码付的话， 生成的二维码用微信和支付宝都能扫，能不能理解为微信支付宝用的都是同一制码标准？
A1：不是的，是银行或者第三方支付包装了下。扫码的时候用微信公众号或者支付服务号调用起来。
A2：当前线下的聚合二维码，其实不是支付宝、微信、银行等收单方生成的二维码。市面上的二维码编码规则，支付宝和微信有意识的区分开了，分别以1打头和2打头，
A3：一码多付是通过一些参数信息进行识别的 其实内容只是一个url，https://xxxx.com.cn/+商户token 这就是内容。
A4：银联技术部之前向前司了解聚合支付码原理时，给他们提供过一个建议，把62占据下来
A5：银联的二维码标准是结合了自身tsp一些功能作的。他们把一些付款码等信息 是用TSP作过支付标记化产生出来的 但是TSP里面的功能具体用了多少，就不太了解了
A6：银联二维码只是云闪付的一种方式，不同于卡片的入口而已，能分辨清楚发卡、收单方即可
A7：应该是区分发卡方和APP应用方。全渠道跟小微商户的接入不太一样。
A8：银行和非银机构接入银联二维码，后台走的信息流不太一样。
A9：银联的二维码，除了集结银行外，也想收编支付宝、微信等第三方，不过目测难度很大。

Q3：微信浏览器打开支付宝wap支付，会唤起支付宝应用吗？
A1：不行，两者互斥

八：在线支付订单，线下录入完成
Q1：业务场景上有很多客户不会用在线支付 需要线下支付给服务人员 然后服务人员来完成代收的动作 这部分收款现在都是人工录入单据 且流程易出错 是否有类似场景的更好解决方案？
A1：用扫码支付

Q2：我所指的是不会使用微信支付宝的老年人
A1：代付，让雇主完成支付。两种方案：1.雇主直接线上支付 2. 雇主给钱保洁，保洁代付

Q3：主要在监管，如何防跳单。用户付给保洁，怎么保证保洁阿姨一定会代付？
A1：你要根据业务去看怎么界定服务完成，订单没完成，不结算不分配新订单
A2：你们是否有保洁阿姨的系统商家账户，在服务完成时，自动扣除商家账户的钱，通过商家代付补足这部分钱，然后根据商家账户金额进行工资发放。
A3：嗯，比如你们如果抽佣，那订单完结的时候，直接抽佣，他们再代付补足

九：客户身份识别
Q1：有谁做过客户身份识别，具体有哪些？
A1：证件，指纹，面部
A2：现在有成熟的服务商和产品，如face++

Q2：指纹怎么弄的？
A1：ios的home键，这是一种采集。
A2：活体检测

Q3：活体检测h5页面能调起来吗？
A1：建议直接咨询face++，我们现在用的活体检测，必须是原生app中调起控件。

本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。