互联网消费金融项目敏捷开发实施研究——基于Scrum方法的单案例研究

(中国人民大学 北京 100000)

一、引言

我国居民生活水平逐渐提高，消费需求比较旺盛，超前消费意识也逐渐增强，接受新型金融产品的能力较强。使用消费信贷手段来缓解由于预算约束带来的消费不足的理念日渐深入。银行、电商平台等各互联网公司纷纷加入互联网消费金融大军，市场日益竞争激烈。如何快速且更有针对性的满足用户需求，快速响应环境得变化，不断优化迭代产品成为各家互联网金融公司研究得重心。

二、文献综述及理论背景

(一)国内外研究现状

1.国外研究现状

在国外软件企业中，几乎将近一半企业已采用敏捷方法的，一些著名的公司如 Google、Microsoft、Yahoo 以及很多中小公司都已经采用敏捷开发，其中Scrum方法最为流行，而且很多公司已经采用了很长时间。他们通常做法是先选择几个开发团队来试用敏捷开发模式，然后再将开发经验推广到其他的开发团队中去。中小型软件公司以其灵活创新的特点，更加适合敏捷开发，许多公司都已经把开发团队完全转型到敏捷开发模式下。

2.国内研究现状

敏捷开发出现并传入中国已经有是五六年年历史了，根据云栖社区发布的《2017开发者调查报告》中有一项数据：45%开发者所在的组织采用了敏捷开发方法，在各种开发方法学中位居第一。在通讯行业，2005年底，诺基亚在杭州的研发中心开始试点敏捷；2018年诺西多个产品也开始大面积实施敏捷，同年爱立信也开始使用Scrum方法运作项目，并引入持续集成。华为公司2006年小试点后，至2010年也全面推广使用。互联网毕竟身处时代大潮的前沿，时刻关注海量用户的真是反馈，每一点的转变都有可能影响到经济效益，所以促使互联网行业更有动力推广敏捷。当互联网行业迅猛发展时，其他行业CIO也纷纷加入敏捷大军，比如汽车、金融、零售、教育等。

(二)敏捷开发方法理论及思想

敏捷开发方法不是某一种方法论、过程或框架，而是一种价值观和原则。这些价值观和原则由17位软件开发领域的领军人物在2001年通过《敏捷宣言》传递给世界，也在那个时候宣告了全球敏捷开发运动的开始。敏捷宣言和价值观如下：(1)个体与交互重于过程和工具；(2)可用的软件重于完备的文档；(3)客户协作重于合同谈判；(4)响应变化优于遵循计划。

敏捷开发目前应用比较多的主流开发方法有：(1)Scrum，Scrum讲究以人为核心，是一个迭代式的增量开发过程，迭代即不断优化需求，增量即将整个项目进行拆分成多个子项目。Scrum包括了一系列实践和预定义角色的过程骨架，三个角色主要是产品负责人、敏捷主管、开发团队。(2)XP极限编程，XP极限编程是1996年由KentBeck提出，是一个轻量级、灵巧的软件开发方法，其主要目的是降低需求变化的成本。XP强调开发人员与业务人员之间的紧密协作、面对面沟通，开发过程频繁交付软件版本，团队建设紧凑而自我组织型，能够更好的适应需求变化。极限编程规定了一些实践和简单规则，包括：编写用户故事、架构规范、迭代计划、代码开发、单元测试、验收测试等。(3)精益软件开发，精益思想来源于丰田公司的软件开发方法。和其他敏捷方法相比，精益软件开发更重要的是不断完善开发过程，因此，将精益模式与其他敏捷开发模式一起使用将会取到比较好的效果。

三、案例研究方法

(一)选择案例

A公司是一家专注于智能产品自主研发的移动互联网公司。2015年开展互联网金融业务成立金服事业部，面向个人提供金融服务，包括但不限于:投资理财、贷款、证券、保险等。“XX贷款”是其迈向个人消费金融的开端，也是打造“从行为到金融”新型征信模式的关键一步。

选择A公司作为研究对象公司得原因有如下几点：

1.A公司是金融事业部专注互联网消费金融的发展，近几年风口浪尖的一个业务就数互联网金融了，16和17年发展迅猛，暴漏出很多问题。18年监管收紧、经济形式下滑，导致业务出现缩水。如此大起大落的环境变化，对软件开发的响应能力要求更高。

2.恰逢A公司也在逐步拓展更加适合互联网金融公司发展的新的技术和软件开发管理路线。

3.公司现有软件开发方法中也暴露出了很多问题，比如软件质量问题、进度问题、团队建设问题等。

如果将敏捷开发方法应用在A公司互联网金融项目中，会不会解决公司目前的问题。本文作者开始了互联网消费金融项目中敏捷开发的实施研究，基于敏捷方法之一的Scrum方法进行研究。

(二)收集数据

数据收集是案例研究方法非常重要的内容，做好数据收集工作可以为后面的研究提供有力的支持。数据收集第一阶段主要是查找与我研究相关的文献资料，包括单不限于知网别人研究的内容，相关的理论课程。文献查找主要在于本文研究内容相关的项目管理、敏捷开发和互联网金融三个领域。第二阶段主要是基于现在公司中项目管理的材料收集。包括但不局限于公司组织架构、项目管理文档、历史项目管理文档。第三阶段直接参与项目中，通过实践方式收集资料。

(三)分析资料

通过数据收集进行整理分析，发现公司内比较突出的问题有以下几点：

1.组织架构复杂，导致流程比较长，比如产品部门和研发部门分开，就会导致两个部门人员之间不够团结，产品提了需求研发虚报工作量等。

2.公司内开发流程繁琐，从研发到测试到上线验证，跨部门垮机构，需要很长时间。

3.项目进度管理不受控，项目延期情况频繁发生，大约有90%的项目没有按照评审计划的时间点上线。

4.项目质量管理不当，频繁出现问题，导致上线后的产品Bug多，严重影响用户的体验，时间久了用户就会不断的流失。

经过分析A公司金融部门现在内忧外患，内有项目管理中存在的诸多问题，外有竞争对手的压力。因此，A公司金融部门目前急需一套可靠的软件开发流程，本论文作者在此引入Scrum敏捷开发管理方法，根据Scrum开发模型结合A公司金融部门的实际情况形成一套个性化的Scrum流程，将很有效的解决了以上一系列问题，具体的改进方案将在第四章中详细介绍。

四、A公司基于Scrum流程优化

(一)团队组建

根据第三章对A公司项目管理中存在问题的提出和分析，通过改善其组织架构，使其更加适合敏捷开发。应用Scrum敏捷方法对A公司金融部门建立一个自组织、跨职能、灵活的敏捷团队。团队中定义了三个角色，分别是产品负责人、Scrum主管、开发团队。Scrum教程里倡导的Scrum团队的理想人数是7人，即1个Product Owner和1个Scrum Master，开发团队应有5人，三个开发人员，两个测试人员。

(二)开发流程重构

前面章节分析了A公司项目管理流程中出现的问题，为了解决这些问题引入敏捷开发方法，在本章节中，主要应用敏捷开发方法中最常用的Scrum开发方法对公司的管理流程进行优化，形成基于A公司的Scrum模型。

Scrum开发全生命周期工作流程，如图1：

图1 Scrum工作流

首先，需要确定一个目标，所有团队成员，包括产品负责人、敏捷主管、开发团队一起确定。目标确定后，产品负责人(Product Owner)会维护一个文档即Product Backlog，产品负责人维护好Product Backlog，并且将Backlog 按照需求优先级进行排序。每次计划会议时根据优先级顺序挑选优先级高的需求，然后把需求拆分成一个个的开发周期即一个Sprint。每一个Sprint开始的时候，需要进行一个Sprint计划会。Sprint计划会需要全部成员参加，通过Backlog从优先级最高的需求开始进行阐述。然后将Backlog 拆分成更细粒度的任务，每个成员在每日站会中领任务并完成。为了让大家对整个项目有个全局观，每日站会时，大家围在白板前明确项目进度和任务完成情况。团队人员可以在这个会议上了解整个迭代的进展情况，然后Sprint结束后团队开一个Sprint评审会大家一起交流本次Sprint中哪做得好哪做的不好。最后敏捷主管再开一次回顾会。整个过程都由敏捷主管组织和把控，这样每一个团队人员都清楚项目的目标、项目整体进展等情况。

(三)项目会议制设计

Scrum敏捷开发四个会议分别指，Sprint计划会议、Sprint评审会议、每日站会、Sprint回顾会议。

1.Sprint计划会议

在Scrum中，Sprint计划会需要参会的人员包括开发团队、敏捷主管、产品负责人，产品负责人向开发团队介绍排好序的产品待办事项，由整个Scrum团队共同理解沟通这些工作。根据优先级选择本次Sprint需要做的产品事项。Sprint中需要完成的事项数目完全由开发团队决定。每天做多少工作也由开发团队成员决定，产品负责人或任何其它人都不能给开发团队强加更多的工作量。

2.每日站会

开发团队是自组织的，通过每日站会来确认他们可以实现Sprint的目标。站会顾名思义就是站着开会，团队成员围城一个圈，每一个开发团队成员需要提供以下三点信息：(1)我完成了什么？(2)我计划完成什么？(3)有什么阻碍了进展。每日站会时间一般情况下不超过15分钟，每日站会中可能有简要的问题说明和回答，但是不应该有任何话题的讨论。会上敏捷主管需要修改燃尽图，对迭代的任务进展情况进行跟踪，并根据实际情况对迭代计划进行细微调整。

3.Sprint评审会议

Sprint结束时，Scrum团队和相关人员一起评审Sprint的产出。所有Scrum会议都是限定时长的，Sprint评审会议的推荐时长是Sprint中的每一周对应一个小时。团队每个人都可以在Sprint评审会议上发表意见。产品负责人会对未来做出最终的决定，并适当地调整产品待办事项列表。通常都会在Sprint评审会议中调整产品待办事项列表，Sprint评审会议向团队中每个人展示了当前产品增量的情况。

4.Sprint回顾会议

在每个Sprint结束后，Scrum团队会聚在一起开Sprint回顾会议，目的是回顾一下Sprint过程中，团队在流程、人以及工具方面有没有什么问题，做的如何，需要团队成员全部参加。团队识别出哪些做得好，哪些做得不好，并找出改进事项，为将来的改进制定计划。Sprint回顾会议的推荐时长也是两小时。

(四)辅助工具组建

工欲善其事必先利其器，敏捷开发方法的持续交付，在一定程度上导致了交付的碎片化，这样就需要引入好的管理工具。

下面逐一介绍下使用到的工具

1.JIRA：敏捷管理神器

JIRA被广泛应用于敏捷管理中，完美支持了Scrum和看板方法，易用性、灵活性、扩展性都得到业界的广泛认可。JIRA配置灵活、功能全面、部署简单、扩展丰富等，彻底贯彻了敏捷开发方法所倡导的去中心化、灵活、透明、集体讨论、信息共享等原则。

2.文档管理工具

敏捷并不是说不需要文档，它认为文档应该少且精炼，不需要冗余的文档。文档也是作为细化部分，在每个迭代过程中不断重构。文档是用来准确传递信息，帮助理解事物，沉淀知识。Wiki是一种在网络上开放且可供多人协同编辑的超文本系统，Wiki站点可以有多人维护，每个人都可以发表自己的意见，或者对共同的主题进行扩展或者探讨。wiki对于团队成员的学习和技能的提升有着非常重要的作用，它可以帮助公司和团队不断积累业务和技术知识。

五、研究结论

通过联合贷项目验证A公司Scrum开发模型，有如下几点变化：

1.响应变化的速度变快，当市场有变化需要调整时，及时响应，最重要的总是排在最优做。

2.可持续向用户交付有价值软件产品，不停的通过每次迭代和升级，进行产品的优化和提升，用户借款体验越来越好，投诉数量减少。

3.团队更透明，产品和研发之间已经没有明显得隔阂，也不会出现产品与研发的撕战，大家都是为了一个目标，团队内成员不仅可以了解自己的项目也可以了解其他成员的工作。

4.软件成本降低，Scrum敏捷开发方法带来的价值就是允许产品快速试错，即使错了，浪费的最多也是一个迭代的资源，而不像传统瀑布开发方法，浪费的可能是好几个月的资源。

5.投资回报率提高，成本降低，开发模式高效，回报率自然就会提高了。

最后，Scrum敏捷开发方法不能杜绝问题，只是帮助团队减少出现问题的概率，敏捷开发方法的核心是人，是团队的敏捷意识和对工作的责任感。敏捷开发方法不是万能的，不能解决掉所有的问题。Scrum敏捷开发方法只是解决办法之一。