20170531交流记录和专题

凤凰牌老熊 · 公众号 · Java · 2017-06-04 17:30

正文

请到「今天看啥」查看全文

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

一、主题分享：敏捷开发

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

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

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

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

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

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

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

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

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

那么谁是顾客呢？在我们这里，产品部的产品经理，就是买票上车的乘客。但是实际上，为了更好地组织工作，我们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同时在做测试案例和测试数据，做完一个需求，验证一个需求，不能等到一个版本所有需求开发完成，再交给测试人员去验证。有很多团队，把敏捷做成了小型瀑布模型，其实并不能实现非常灵活的拥抱变化。我们基本能够做到在过程中随时调整，从版本里面拿进拿出需求，整个计划不会乱，过程中非常通透，决策非常快，团队无论面对何种变化都有信心，从系统里面能很快得到细节的信息，跟需求方一起权衡调整。敏捷方法其实不是银弹，没法让一个人产能翻倍，甚至对需求比较平稳的项目来说，效率还不如瀑布模型，但是的确比较适合我们这样的快速变化的团队。