天天硕士研究生论文网

硕士论文范文

基于用户參与的X银行软件项目敏捷开发流程改进设计

作者:admin1 日期:2022-06-19 15:43:37 点击:79

第4章基于用户參与的X银行软件项目敏捷开发流程改进设计

本文在上一章中对x银行的软件项目开发的问题进行分析和总结,得出用 户参与是改进流程的核心因素。本章将结合x银行的企业战略原则,突出用户 参与的必要性,设计一套新的适用于X银行的敏捷开发新流程。

4.1用户餐与X银行软件项目开发的必要性

一方面,可以结合上一章节的结论,即通过专家打分的定量分析结果,对用 户参与X银行软件项目开发的必要性进行佐证。通过专家访谈的剖析以及专家打 分法确认,都可以得到用户参与是非常重要的一项因素,是影响X银行敏捷开发 的质量效果的重要内容,能够将现有资源的能量最大化发挥,从而提升软件产品 质量,大力建设科学现代的金融产品,给企业带来巨大利益。

另一方面,从过往的案例分析中,我们也不难看出,由于缺乏用户与开发者 的互动,时常会出现需求偏差,也令沟通协调的成本提升。产品开发是一个试错 的过程,只有在不断地试用、反馈中,才能得到产品需求的最优解。这个阶段必 须要面向用户,让用户参与其中,进行大范围的意见收集,不断地进行调整。否 则,即使投入了大量的人力和物力资源,也只是在做表面功夫,并不能解决根本 性的问题。此外,近年来的X银行业务规模还在不断增大,对产品的要求越来 越高,不论在规模和时间跨度上都提出了新的挑战。这样的产品需求会随着时间 进程反复更新,需求的模糊导致开发出的软件往往不成功,而且维护起来也很困 难。因此,将用户参与引入开发流程因是X银行在流程改进中的重要举措。

4.2 X银行软件项目开发原则

在设计新的流程前,还需要充分了解企业的战略和优化原则,以此作为新流 程设计的理论保障基石。

充分理解企业的战略规划是选择正确的软件开发方向的基础,X银行的战略 方向是稳定的中国市场份额和有效的对外链接。因此,在最基础的安全性之上, 兼顾系统便利性、稳定性和内外兼容性,改变叹往的繁琐冗余等问题,能令用户
满意并维系长期的各尸关系,都是软件开发的核心方向。

4.3基于用户參与的X银行软件项目敏捷开发流程改进设计

4.3.1 X银行软件项目开发改进流程思路

基于此前专家打分后的结论,用户参与将是目前流程改进的核心。因此,新 流程的思路,比对原流程(第2章图2.3)差别主要体现在用户参与的过程中。 在开发方案设计、开发迭代、迭代评审、测试的环节都添加用户,使得用户反馈 提前,每一步都在用户参与下进行,如若发现需求的偏差,可即刻做出调整。也 就是在原有的大循环中,增加了三个小循环,如图4.1所示,有助于最终的产品 发布,减少错误的发生。

image.png

图4.1 X银行软件项目开发新流程思路图

同时将优化流程中每个流程节点对应的参与部门与用户对象,如表4.1所示。

表4.1 X银行软件项目开发新流程主要参与部门与用户对象

阶段            流程节点                                主要涉及部门

启动与计 业务需求、需求分析

业务部门、产品部门、项目部门、内部用户

划阶段

开发方案设计

产品部门、开发部门、项目部门、内部用户


开发迭代

开发部门

执行阶段

迭代评审

产品部门、开发部门、内部用户

测试阶段

测试

测试部门、内部用户

交付阶段

部署、发布

产品部门、项目部门、业务部门、内部用户、外部用户

4.3.2 X银行软件项目开发中用户的定义

用户是一个十分宽泛的概念,可以简单理解为使用者。而细分到银行的软件 开发中,用户的对象则很多。一般来说,可以简单被分为内部用户和外部用户。 内部用户可以理解为除开发人员以外的全部群体,甚至开发人员本身也可以被定 义为用户。内部用户,主要可以被分为:银行员工、产品经理、测试人员以及产 品负责人等银行内部人员。而外部用户一般则可以简单理解为银行客户或其他会 使用到软件的用户。

在开发流程的不同阶段,运用好不同的用户,让用户加入到开发中来,能改 善用户体验,推动流程的优化。解决各式各样因用户与开发者因需求表达不明确 导致的问题,增强产品与用户的黏性,从而推动用户与银行之间的黏性。

本文在设计基于用户参与的软件项目开发流程中,倾向于实操性更强的做法。 即“用户参与” 一词中的“用户”是指使用参与银行软件开发的内部用戶,也就 是银行员工,以下流程中是特指银行业务线工作人员,特此说明。

4.3.3基于用户参与的X银行软件项目敏捷开发流程改进设计

在充分考虑企业的经营战略、风险控制、流程管理要求等优化原则的基础上, 设计方案构建的核心是在整个迭代过程中,增加用户、用户参与的理念,让整个 迭代过程中所涉及的包括产品设定、目标分解、冲刺直到交付在内的每一步都符 合用户的需求。这种基于用户参与模式上的方案构建,更为明确目标性,更注重 团队间的合作和共赢。每次的每日站会、评审会议、回顾会议都逼迫开发团队对 内容作出调整与反馈,让每次交付的最小可行产品MVP都更为逼近用户的真实 需求,确保每次迭代都实现效用的增量。

用户较开发团队来说,是一个很广阔的群体。客户、银行员工、产品经理等, 都可以被认为是用户。而本文在开发环节中加入用户参与的用户角色,是指熟悉 银行业务的员工,他既能够提供专业需要上的指导,又能提供用户体验的反馈, 是参与用户开发流程的最佳人选,本文之后将不再对此进行赘述。

在敏捷开发模式环境中,加入用户参与会增强迭代效果,优化冲刺速度和产 品质量。提出基于用户参与的X银行软件项目敏捷开发流程图,如图5.2所示。

image.png

图4.2基于用户参与的X银行软件项目敏捷开发流程改进图

4.3.4基于用户参与的需求收集阶段改进

在敏捷开发模型中,用户的作用非常重要,特别是在开发需求和迭代需求的 确定环节。如图4.3所示,在产品代办列表和冲刺代办列表中,一般我们都会采 用用户故事来描述和展示需求。“故事”在字典中的定义是:通过叙述的方式讲 一个带有寓意的事情,它注重在事件发展时的过程描述⑹]。应用到软件开发流程 中,用户故事,就可以理解为是叙述用户在使用软件功能时的过程。也就是说, 只要产品需求和目标明确,越是细化用户故事,就越能开发出符合用户需求的产 口口 o

image.png

那么在需求阶段我们应该有效地和用户合作,通过用户故事的方式来收集用 户需求。达到缩短软件项目的开发周期,提升开发团队效率,提高用户满意度的 目的,具体操作方式如下。

1) 识别用户角色

首先,需要配合用户进行用户的需求梳理。通过先发散后收敛的方式进行角 色识别,然后对用户的角色进行建模,最后设计出对应的用户画像。不同的用户 角色拥有不同层次的用户需求,产品经理可以基于用户角色的划分有针对性地做 需求收集和调研,同时产品经理也只会记录与修改用户角色相关的需求,这样的 方式可以较大地提升用户需求的准确度,保证开发项目需求边界非常清晰。

2) 梳理用户需求

其次,梳理用户的需求,基于之前整理出的画像,在用户的协助下,编写出 一个个用户故事。同时,邀请用户参与项目会议,尽可能通过面对面访谈的方式 与用户进行沟通。因为已经具备了用户角色的识别,所以用户所提需求的关联性, 优先级,准确性已经有了依据。往往用户提出的需求会比较多,所以产品经理必 须根据角色进行需求的梳理,只保留该用户角色相关的需求,并且进入需求池。 剩余的和用户角色无关的需求,可以暂时存放在项目文档中作为资料保存。

3) 需求评估

这个阶段最重要的是梳理需求清单列表,即对用户故事进行评估,对所有的 需求都进行估算时长,特别是在重要的故事点,有助于理解开发优先级和开发顺 序,以及预估开发的总周期。

4) 需求评审

在完成需求评估后,产品经理会整理好下一个迭代的开发需求,并且召集需 求评审会议,同时也必须邀请用户来参加。在需求评审会上产品经理会十分详细 的介绍下一个迭代的产品原型、界面、交互和业务逻辑等,让用户充分的了解下 一个迭代将会开发的产品功能。用户在需求评审上评估是否符合自己的需求,确 认产品实现方式是否符合用户的使用习惯,以及确保业务逻辑是正确的。在评审 会上如果用户提出较大异议,则需要产品经理重新评估和修改产品原型,然后择 期重新召集需求评审会议。只有当用户对需求评审通过时,才会进入代码开发环 节。

5)制定发布计划

在制定发布计划时,需要去确认的是用户故事的优先级、当前项目的状态, 且保证每次冲刺的开发速度是清晰的,保证清楚地看到工作量进度。首先对于优 先级的评估方式分为优先级、应该有的、可以有的、不需要有,一般在软件项目 中80%的人只会使用其中20%的功能,而这20%的功能就是最重要的优先级。 因此,它至关重要,不是随意决定,必须根据此前与用户沟通的内容,对于用户 提出的需求、用户的角色以及用户故事,评估每个故事的估算值来排序。同时需 结合估算的迭代速率,即通过计算估算值来决定每次迭代多少个故事点。

4.3.5基于用户参与的迭代开发与测试阶段改进

迭代开发的中心是一个又一个冲刺,冲刺作为开发的关键环节,也需要用户 的参与,如图4.4所示。但迭代开发的核心还是在开发团队本身,包括设计、编 码和测试[62】。用户可以参与设计和测试的部分环节,具体分工如下。

image.png

图4.4用户参与的迭代开发与测试阶段

1) 迭代设计

为保证敏捷开发可能出现的不断需求变更,设计时需要预留一部分空间,以 保证按时发布。针对可能出现的情况,要做提前的设计分析和设计评审,用户作 为需求提出者,可以完善用户故事,开发团队对于故事理解不清的部分可以与产 品负责人或用户进行直接沟通。迭代结束后,由产品负责人、专家和用户对产品 进行评审,并将设计文稿上传文档工具。

2) 编码

包括持续集成、代码重构和代码检查等环节,由开发团队独立完成。

3) 测试

敏捷开发中测试也是一项难题,快速迭代对于测试人员来说也是挑战。一方 面,需要顾及已有系统的回归测试,一方面又要兼顾新功能的测试。

这就需要在开发过程中让用户与测试人员结对进行软件测试。在故事开发完 成后与用户和开发团队一起对故事进行验收,在通过开发前确定好的验收测试后 故事卡才算正式从开发人员手中移交给测试人员。此时测试人员再进行验收测试 中没有提及的探索性测试,确保在故事卡完成前发现缺陷,及时修复。从整个实 践可以看出,需要测试人员尽早介入,与用户和开发人员一同澄清需求,确定验 收测试。然后通过验收测试后再进行下一阶段的探索性测试。而质量内建又提倡 团队中每一个人在每一个环节都关注软件质量,而不仅仅是测试人员的工作。全 流程的用户参与是不可或缺的,因为用户非常清楚自己提出的业务需求,能够确 保测试和验收的结果不会发生偏差。此外,还可以邀请用户做用户体验测试用例, 挖掘可能存在的涉及业务法规、业务流程、逻辑性错误或其他错误问题,并提出 改进建议。

4.3.6基于用户参与的验收阶段改进

在敏捷开发模式中,设定验收标准是又一重要环节。用户是项目的终端,当 用户认为完成才是完成。开发人员眼中的“需求交付”或“可以运行”或“没有 BUG”都不能被认为就完成。因此,以上几点只是交付基础,最终需要获得用 户认可才是验收标准。通常在回归测试基础上,能够功能联合运行,让用户获得 最终价值,才算完成。所以敏捷开发模式中的验收完成,应当是从用户使用确认 得到的,而不是通过QA工程师测试得到的。验收阶段如图4.5所示。

image.png

图4.5用户参与敏捷开发验收及用户需求进化阶段

1) 用户故事验收标准的定义

验收标准能够更明确产品的价值主张、用户使用的流程以及解决方案的内容。 验收标准必须是可检验的准则,并能给出更详尽的需求使用范围,以帮助开发团 队了解用户故事的价值并作出合理的拆分。而一旦详细定义了检查和考核准则, 那么团队就可以更好地对用户故事作出评价,进而使开发的周期减少、避免资源 浪费。

2) 用户故事验收标准编写

用户需要配合产品负责人对用户故事验收标准进行编写。这是一种用户的检 查清单列表,用作确定用户故事中的各项参数。对于工作周期、工作量完成日期 等需要讲清楚。确保整个流程按照这个用户故事的走向进行,并满足它的各项设 定标准。一个高质量的用户故事,需要配合以有效的用户故事的验收,一般由产 品负责人完成,帮助发现漏洞和问题。

3) 敏捷开发验收标准示例

一般来说,Scrum是没有验收标准的模板示例,或者说它没有一个统一的标 准。它是一种对用户故事的检验标准,一般由用户配合产品负责人对于需求的仔 细描绘。验收标准需要在性能和满意度有所体现,如该功能与其他已运行功能间 的影响情况、用户感受度、功能运行时的负面场景、功能与非功能性的用例和端 到端的用户流等。

4) 用户参与验收

在实际项目中,用户提出的验收思路:

如:“作为一个用户,我希望我有一个界面让我看到交易的选择按钮,可以 申购、赎回和转换,可以打开产品说明书进行阅读和确认,还能够输入申购、赎 回和转换的金额和份额,并为我计算总金额。”

当用户用以上当思路来做验收时,会全面的对于当前交付的功能进行全面的 测试,验证交付的功能是否和自己提出的需求一致,用户交互体验是否符合使用 习惯。

4.3.7基于用户参与的用户需求进化阶段改进

敏捷开发的本质是使用迭代渐进开发方式,并注重以用户的需求为核心,因 此是一种注重用户的需求渐进变化的开发方式。用户需求进化是用户最终满意度 的提升的核心,用户的需求不可能一成不变。在敏捷开发模式中我们一般通过回 顾会议来完成用户需求的进化,让用户的需求随着项目的推进成长,逐步完善, 最终完全达到甚至超出用户的预期。用户需求进化阶段如图4.6所示。

所谓需求的进化,就是分析前一个迭代中遇到的难题,选择其中最棘手的、 优先级前列的问题先去解决,思考解决问题的应对方案,将它放入下一次的迭代 中。这需要用户参与在回顾会议中,提出问题和一同寻找思路,重新回顾用户故 事。之后,会发现由于重难点都在前面考虑到,后面的开发将会顺畅,产品也会 更好用,因为前面开发的功能是整个功能的基石,大多数用户需要使用的功能都 已设定好。回顾会议实践方法如下:

1)设定一个安全舒适的环境

虽然敏捷开发是一个小规模团队开发模式,团队间一起工作,团队内的关系 较为简单和轻松,但这并不就等于大家都能打开心扉。但在迭代过后,有了一共 开发出来的果实,是真切地在一起工作过后,才会有的信任感。用户需要通过自 己的能力,激发出团队的凝聚力,让成员间相互认可。需要通过一定的氛围营造, 让成员找到安全感和集体感。因此,回顾会议就是需要去创造和渲染这种气氛。 用户参与的过程中,要将回顾会议的基调定在赞美和夸奖,而非传统的批评与自 我批评。主要是为了讨论和解决本次迭代中遇到的问题和难点,通常以感谢作为 开头最为合适。

2)收集项目数据

一个迭代中发生的事件很多,无论是用户、开发团队成员、产品经理、Scrum Master或产品负责人,没有一个人完全了解一个事件的方方面面。所以用户将数 据汇总到一起,把内容拼凑成一幅完整的画卷,让内容丰盈起来也是很至关重要 的。让团队成员运用不同的色彩卡片描绘在此次迭代中的心路历程,一般会是先 抑后扬的方法,先赞美后找原因和困难。在回答问题中,让成员相互理解感受其 他人的情绪起伏,并落实到每个事件中:

如:“开发中有什么事情使你感到压力? ”

因为如果不定位到事件,后续无法准确的去挖根本原因。这里特别要注意, 在描述事件时,一定是描述事件的现象,而非描述事件的解决方案。比如用户可 以提出:

如:“我一开始认为画面展示应该是自上而下的,但是在验收时我发现需求 要的是从左至右。”

3) 决定接下去做什么

回顾会议除了回顾上一次迭代外,另一个重点就是决定下一次的迭代做什么, 除了需求文档以外,那就是从用户和开发成员的反馈来确定下一个优先级。对现 有阶段价值最大的事,就是确认下一个要做的事。这样的迭代效果才更有效果和 意义。

收集完数据之后,通过将各个开发成员的数据进行分类,然后汇集用户和所 有开发成员进行探讨,找出其中的一项是目前最有价值的事。团队成员时常由于 敞开心扉,提出过多的待解决问题,想要一次性都解决。很明显这做不到,因此 更需要用户与团队成员深入探讨,从众多问题内挑选出一个,最多两个内容,作 为优先级放入下一次迭代。以避免什么都想做,却什么都没做好的尴尬处境反复 发生。

4) 回顾和制定新的团队规则

回顾会议后如果团队做不到按照计划真正地贯彻执行,就失去了回顾的意义, 也浪费了投入的时间和金钱。为此,还需要制定一定的应对方案来解决。通过制 定团队规则,并到下一次迭代会议中来确认是否有效。当大多数成员都觉得有效, 就证明我们花费的时间是有成果。我们会发现通过这样的方式持之以恒地执行, 整个项目的开发周期会得到很好控制,最终的交付成果与用户需求的偏差会越来 越小,用户满意度也会进一步提升。

4.4本章小结

本章主题是解决问题。首先,解释用户参与的必要性。其次,在X银行开 发原则的基础上,构建基于用户参与的软件项目流程优化方案,将用户放入敏捷 开发流程中,并对每个阶段用户的作用进行细致阐述。

第5章基于用户参与的开发流程改进方案实施

上一章阐述了用户参与的X银行软件项目敏捷开发改进流程,本章以X银行 的C软件项目作为案例,围绕实施流程以及实施效果探讨。

3.1     X银行C软件项目概况

3.1.1     C软件项目的产品背景

为快速占领国内市场,抢占国内市场份额。X银行充分研究国内政策,以服 务大众的政务便利为根本导向,以双向嵌入模式为主,统建、共建模式为样本, 打造X银行“金融服务+行业应用”的“智慧政务”品牌。通过渠道融合、产品 整合、数据赋能,实现银行与政务场景融合的业务模式。目前,X银行敏捷开发 的C软件项目已实现对接地区政务服务平台。

C软件项目的产品定位是丰富X银行的非金融功能,通过“银政互动”合 作模式,实现政务部门、银行两方信息互通,服务共享和客户互认,为掌银客户 提供便捷政务服务,实现掌银与政务平台的双向引流。面向的客户主要是银行工 作人员、政务部门工作人员和广大相关业务的掌银客户。针对不同的业务流程, 分别设计了不同的功能,并加入了智能操作辅助提示等,辅助不同客户的不同需 求。

3.1.2     C软件项目开发业务流转方式介绍

X银行C软件项目已开发完成并上线应用,处于发布初期阶段,因此还需 长期的功能更新与缺陷修复。目前c软件项目涉及的开发业务主要有三类:

①   针对部分业务流程修改的功能,进行功能修改或更新、界面优化、流程 优化等。

②   根据政务部门、银行两方业务部门提出的新的需求,设计新的界面并增 加新的功能模块。

③   由于疫情影响,政务部门或银行业务由线下办理转为线上办理或先线上 申请后线下递交材料的模式,需构建与其他的系统交互的新接口,配合业务的正
常流转。

考虑到C软件项目的客户为主要是银行工作人员、政务部门工作人员和广 大相关业务的掌银客户,不同客户对于C软件项目的操作熟练度和对业务流程 的了解度不同,故所有功能模块设计均遵循智能辅助的方式进行设计。目前主要 的业务流转方式分为三类:

①    客户可足不出户,在客户端根据智能辅助提示进行业务操作。

②    银行工作人员或政务部门工作人员在C软件项目上对部分客户数据进 行业务操作后,数据流转至外部客户进行智能辅助确认。

③    银行工作人员或政务部门工作人员在C软件项目上对部分客户数据进 行业务操作,无需外部客户进行确认。

X银行开发团队根据C软件项目的开发业务和业务流转方式,对开发流程 进行分析后,形成了初步的开发流程,如图5.1所示。

图5.1 C软件项目开发业务流程图

目前,C软件项目的主要客户包括以下三个方向:

在政务部门客户端,政务部门数字化建设成效和大数据分析能力在疫情影响 下快速进步,政务部门信息化、数字化、智能化建设将全面提速。

在银行客户端,X银行致力于实现政银战略协同,同时要从方便内外部客户 操作的角度出发,打造“金融服务+行业应用”的“智慧政务”整体品牌,将政 务服务嵌入行内服务场景,实现金融服务与政务服务融合。

在外部客户端,由于疫情的影响及全国数字化接受水平不断提高,客户更倾 向于线上进行业务操作,如遇到软件存在的问题,积极反馈与进行意见建议的意 愿较高,开发团队可及时获取软件存在的问题与不足。

5.1.3基于用户参与的C软件项目新模块开发

1)新模块开发内容

C软件项目作为一个已具一定规模成效的软件产品,在其中选取一个小模块 功能进行方案实施是合适的。此次涉及的一个新的功能需求变更具体为综合模块 中新增某项政务费用代收页面,因疫情影响,此项业务提供线上代收功能,涉及 的业务流程图,如图5.2所示。

image.png

图5.2 C软件项目新增功能模块业务流程图 

2)新模块开发迭代思路

从迭代开发的角度,可以从下图5.3中出可以看出,由于用户参与开发,每 一次的迭代都加入了用户的智慧,用户对于业务流程思路的考虑和一些监管要求 的理解,都会被增加到开发者的思路里。大量的问题都能在第一时间被解决,即 使无法快速解决,也易于发现和记录,在下一次迭代中作为优先级进行解决。对 比之前无用户参与的情况如图5.4,开发者则需要在产品发布后才能获得使用者 的反馈,开发周期长,需求变更导致的成本也更高。

image.png

图5.3用户参与的迭代开发思路

image.png

图5.4过往迭代开发思路 

3)用户参与的流程演示

增加了一名用户,参与需求分析、开发、测试、提交、上线等全流程的开发。 如图5.5所示,包括重点参与敏捷开发过程中的需求分析、计划会议、每日站立 会议、评审会议、回顾会议和需求进化等。

考虑到用户参与的效果以及实际情况中外部用户参与敏捷开发的成本费用, 本次选取的用户为提出需求的X银行业务线工作人员,此工作人员为此项政务 费用代收柜面窗口的工作人员,对缴费过程细节和可能存在的问题及应对方式较 为清楚。

image.png

图5.5基于用户参与的开发流程改进示意图

5.2项目实施

5.2.1组建用户参与的敏捷战队

1)确立用户参与在敏捷团队中的作用与意义

确立项目的功能和战略方向;了解客户 产品负责处理需求需求;对需求进行管理,确认优先级排 人   和优先级序;确定产品发布日期;团队沟通与协


引导者,

建立一致

鶯豈     做团队的倾听者、沟通桥梁,为团队创

产品经理

性分造简单的工作氛围;帮助扫清外部障产品开发引领者

[了巻吸碍;始终秉承敏捷开发的价值观念

团队核心

价值观

 


需求梳理;参与每日站立会议,代办事需求推动开发, 创造用户项梳理会议,迭代评审会议,回顾会议追求从用户价值 价值 等;对产品功能提出关键见解;对产品为出发点的开发

评审和快速反馈                          精神

用户不是敌人,相反用户应该是整个开发的核心灵魂。在传统的开发流程中, 用户通常只能在三个时间段参与到流程中,即开发的前中后三个阶段。具体表现 在项目的开始阶段,当用户和产品经理、产品负责人、Scrum Master等团队成员 谈产品细节时;项目中任何范围的变更情况,即当用户和团队成员进行变更细节
磋商时;以及项目结束时,尤其在产品没有达到用户预期时,再进一步补充和变 更的沟通谈判。这种传统的开发流程中,用户与开发团队容易被处于对立状态, 进而影响到产品本身。只有合作共赢的条件下,才能更好地交流沟通,C软件项 目在设计其开发团队时,加深开发团队对产品的认知,并灵活地做出改变,适应 不断变化的需求。

在C软件项目中,用户不仅是需求的代表,更能Scrum原始团队成员的工作 相辅相成。分别表现在以下几个方面,如上表5.1所示。

(1)      协助Scrum Master:帮助团队成员排除干扰

(2)      协助产品负责人:处理需求和优先级

(3)   协助产品经理:做团队引导者,建立一致性团队,注重建设团队核心价 值观

(4)      需求代表:创造用户价值

2)      组建用户参与的敏捷战队

表5.2组建用户参与的敏捷战队

团队Team                                                      职责                                 备注

负责整个项目,从需求到产品上线和后期运营,以及各部门间协调配合

负责设计产品方案,确认产品代办列表,是理解客户需求维持以往敏 和确认优先级的专家 捷团队成员

负责产品开发的具体实施工作                                 基本一致

排除外部干扰因素,确保开发团队独立性,确保团队运用 敏捷方法论运转 核心是帮助团队进行需求梳理。帮助团队排除外部干扰, 增强团队凝聚力,跨部门沟通协调,组织管理工作等     新增

C软件项目组建敏捷战队需要汇集各方优秀人才,每个团队成员在加入这个 团队之前都会是各个传统项目或组织的资深团队成员,如程序员的职责是完成代 码编写;测试员就是测试作为核心;用户是业务条线;大家各有所长,具备各自 的擅长领域的经验和技术。因此,在Scrum开发团队要尽力避免出现因观点不 同而争执,或因各自的角色单一而受限,要各尽其责的基础上,相互学习和充分 沟通,让产出的效益最大化,才是构建敏捷团队的意义。在用户的加入后,团队 人数控制在8人左右,是敏捷团队的最佳选择。如上表5.2组建用户参与的敏捷 战队所示。

522制定团队工作计划看板

C软件项目开发中的用户是熟悉了解银行业务的员工。这既符合对需求分解 的需要,又能作为用户提出快速的反馈。但用户除了在提出需求、快速反馈以外, 另一个核心工作还能协调进度和团队间关系。因此,让用户参与敏捷团队的工作 计划制定也是十分有助工作开展的一项方式。运用更便捷的沟通工具和团队进行 及时的信息调整,有助于软件开发的成功率。

团队工作拥有电子化平台的基础上,更应当追求返璞归真,追求人与人的沟 通,保证团队成员尽可能地缩短物理距离,确保及时有效的沟通和融洽的团队氛 围。对于每一个用户故事讲清楚,将任务上墙就是一种使团队快速理解的方式。 通过看板,也可以简单理解为项目进度板,可以知道任务被拆分到了几个状态。 这不仅可以让需求更为落地,用户、团队开发成员、产品负责人、产品经理都可 以根据自己的维度了解现状和发现问题。此外,每一个任务的落地也可以使团队 成员更有成就感,也有助于团队增强凝聚力。

每日站立会议时,团队所有成员一同到场,分别总结昨日工作内容和今天工 作计划,并一同调整更新最新进度上看板。这样的物理可视化的任务版,如下图 5.6简图,一般使用一块白色墙体,配合便签条、黑色记号笔、图钉等工具,对 于任务的分解,所有进度都可以一眼看到,可以让团队的进度更清晰化、透明化 和全局化。

5.2.3敏捷团队会议优化

敏捷会议是敏捷开发中的一个重要部分,也贯穿C软件项目的整个开发过 程,是用户参与开发流程管理的重要环节,如图5.7流程图所示。

 image.png

 5.7用户参与的敏捷开发团队会议流程 

1)确定用户参与的敏捷团队会议流程

确定敏捷小组迭代会议图,让用户与开发团队一同参与开发进程中的每一场 会议,而不是以往的仅出现于最终的迭代评审会议中。

与传统的敏捷小组一致,每个迭代周期为2周。在每次迭代前,需要确定迭 代计划会议、待办事项列表梳理会议、每日站立会议、迭代评审会议和迭代回顾 会议。具体的时间流程如图5.3所示。

表5.3用户参与的迭代会议安排

周一

周二

周三

周四

周五

迭代计划会议

每日站立会议

每日站立会议

每日站立会议

每日站立会议

待办事项列表梳 理会议




迭代评审会议





迭代回顾会议

周一

周二

周三

周四

周五

迭代计划会议

每日站立会议

每日站立会议

每日站立会议

每日站立会议 迭代评审会议 迭代回顾会议

2)  待办事项列表梳理会议Product Backlog Meeting:

用户与产品负责人对产品的内容进行分解,一般由产品负责人先行讲解,描 述故事。之后再由用户进行描述,对特定需求进行讲解,结合银行特定的监管政 策、内部风控等要求,特别对用戶事先能想到的一些可能会出现逻辑错误的BUG 进行演示。并由用户和产品负责人一同确定产品优先级,由产品负责人将记录中 变更的内容上看板上同步更改。

确认产品优先级常见的是对以下几个问题进行梳理和总结:

①    确认需求到底是什么?

②    分成哪几步来做?

③    需求的优先级是什么?

④    几个需求如何合成进行发布?

3)  迭代计划会议 Sprint Planning Meeting:

确保团队充分理解本轮迭代中所需要做的内容。由产品负责人从产品代办列 表中选出本轮迭代需完成的需求,由用户进行确认。之后产品负责人再对需求再 进行分解和演算,确认每一个小的技术任务的演示和交付时间,一般1-2工作日 为一个小周期,理论上不超过2个工作日,由用户进行确认和记录,将记录中变 更的内容在看板上同步更改。

4) 每日站立会议 Daily Standup Meeting:

每天早上的回顾会议,时间不超过15分钟,由用户进行确认和记录,将记 录中变更的内容上看板上同步更改。主要是回顾上一日的工作内容和确认今天的 工作安排,对目前遇到的问题和障碍,以及需要帮助的部分做汇报。

5) 迭代评审会议 Sprint Review Meeting:

在两周后产品迭代交付,所有Scrum团队成员一同参与,团队成员对本轮 迭代完成的功能进行演示。由用户和业务相关利益人做主要反馈,确定接受或拒 绝此轮迭代功能的发布。开发团队做记录,对于不足的部分,以及本轮迭代发生 的漏洞,依据用户的需求确认下一轮迭代的优先级。

6)  迭代回顾会议 Sprint Retrospective Meeting:

首先,迭代会议由用户组织和发起,初衷应该是赞美与总结。会议仍应当选 择物理性强的方式,最佳方式是团队人员围坐在一起,首先因由用户发起赞美, 表达对团队其他成员的感谢,从语言上有效地将用户与开发团队融合在一起。之 后团队其他成员分别发言,表达对其他成员的赞同和认可,将自己的总结的经验 和想法上墙,如下图5.8所示。

其次,总结本次迭代出现的问题,提出各自的困惑点和想法,尽可能能够让 所有人都面对面的,彼此收到有效的反馈。这不但可以收获信息,总结经验,还 能使团队彼此信任,提升士气,增强默契。

赞美、感谢

需改进、需调整

困惑点.需琵助


新思路、新想法

ms 12

团國

旷國

团國

图5.8迭代会议墙纸 

524用户故事设计

用户故事在软件开发过程中被作为描述需求的一种表达形式,一般为产品经 理对开发内容进行描述,旨在帮助开发人员尽快了解软件开发的设想。一般来说, 用户故事的表达较为自然,阐述清楚开发动作中所包含的人员、该人员从事什么 样的活动即可。在X银行C软件的实际开发过程中,不同的项目组借用不同的 软件来建立用户故事,并有效地监管整个开发的进程。例如目前在X银行中使 用的软件为teambition,通过各用户故事的描述,可以清晰地列举各开发过程的 要求,如图5.9所示。

图5.9用户故事需求图

通过用户故事的设计,产品经理也较为容易的对项目的整体开发迭代情况进 行把控,防止岀现开发超期的情形。如下图5.10所示,界面会对各个用户故事 逐一列举,同时也可实时查看开发情况,产品经理可对需求进行一些备注以确保 开发人员对用户故事中规则的理解。5.10用户故事项目经理界面

5.3实施保障

在流程改进的同时,结合银行软件开发中存在的现实问题,提出培训、人力、 技术支撑三个方面的实施保障建议,也是一项重要的内容。

5.3.1增强用户和开发人员的专业培训

想要设计好的产品,对开发者增强技能,提升综合素养,理解形势政策,相 互交流都有很高的要求。增强开发相关的基础培训,业务人员更懂软件产品的使 用,开发人员更了解业务逻辑,相互学习,取长补短。随着敏捷开发的不断迭代 更新,软件开发对银行员工和产品经理的要求不断提高,除了需要具备较高的个 人能力外,还需要具备较好的沟通表达能力、协作能力等。其中,产品经理还需 要兼顾产品的开发效率、需求的可实现性等各个方面的硬性指标,了解银行和软 件开发专业知识,应对产品的需求不断变更,及时收集内外部用户对产品的反馈 和建议意见。

然而,X银行目前有相应工作经验满五年的员工占比较低,因此X银行需 尽快提升员工的水平与能力,增大核心员工占比,不断提高对银行员工尤其是产 品经理能力的培养,健全考评制度,设立一定的激励举措提高银行员工在开发过 程中的担当使命感,从而确保产品的高效高质量开发。

5.3.2优化开发团队组织架构

过往的开发组织架构由各个板块各司其职。以产品、研发、测试、项目以及 业务部分独立工作,分别由产品总监、研发总监、测试总监、项目总监及业务总 监各自负责自己的板块,各部门间互不干涉。但这使工作职责不够清楚,相互推 诿的情况时有发生。将原来纵向的、各部门独立管理的组织架构图,转变为横向 的、敏捷团队配合用户的参与,进行横纵双向的交叉管理,能使团队更具活力, 团队成员的主人翁意识也会更强。如下图5.11所示。

image.png

图5.11优化开发团队组织架构

5.3.3注重在软件开发技术上的变革与资金投入

从敏捷工具角度来看,X银行在敏捷开发的工具使用上还比较匮乏,主要使 用的就是Scrum、看板等。但新的理论在不断出现在我们的视野,如DevOps理 论,它就让我们更多从开发的目光转移到运营的部分,这是将更进一步地突出业 务和用户,这是一种更大范围的循环和源头上避免返工。我们应当运用发展的眼 光去看问题,因为并不存在任何一种敏捷方法,是适用于所有团队的。“敏捷开 发”本身的意义就是不断地去适应新变化并做出改变,若一味追求某一固定标准, 则明显违背了 “敏捷”的初衷,要记得我们追求的是可交付的产品,每个团队都 应当独立运作,寻找适合自身的方法,并负责完善它。敏捷始终是一种文化,教 会我们去理解实践的意义。

此外,X银行软件开发的转型升级也离不开大量的资金投入作为基础。在 5G、互联网+、云计算、人工智能、大数据等高科技扶持的大环境下,为赢取更 强大和广阔的赛道,X银行需一直努力向集团总部争取更多的资金,拓展国内市 场,抢占先机。

5.4实施效果分析

通过与项目经理、开发人员及用户进行沟通和交流,并基于数据统计,以实 验中的C软件项目新模块为例,我们发现在用户参与开发流程后,一些数据得 到了明显改善,这也进一步佐证了用户参与对X银行软件项目敏捷开发流程起 到了优化作用,总结得出以下五点结论。

5.4.1开发周期缩减与成本缩减

在实际开发过程中,由于用户的参与,让开发人员能够及时与用户进行沟通 交流,对功能的实现提供了极大的指挥,对于出现理解偏差的内容,也可及时进 行修正和变更,极大提高了 C软件新增功能的开发速度,降低了开发成本。开 发周期大幅度缩减,表5.4实际数据与预估值的相关结果指标进行对比,可以看 出实际开发仅经过28天便可发布运行新增功能,对于预期的开发周期压缩了 12.5%,预计可节省成本比例超18%。此外,每一次用户参与的冲刺会议等都会 得到用户对功能实现的反馈,用户的反馈可以让开发人员增加对新增功能的需求 理解,从而降低了项目返工的数量,提升了开发效率。

表5.4实际数据与预估值对比表


实际值

预估值

实际开发时间(天)

28

32

实际进度比预计进度节省天数(天)

4

0

开发人员数量(人)

7开发人员+1用户

7开发人员

预计可节省成本比例

18%

0

5.4.2需求偏差和测试通过率明显改善

毫无疑问,用户的需求是多变的。加入用户的敏捷开发团队就是让团队快速 理解用户需求的强心剂,能够更快速地对用户变更的需求作出响应。用户参与可 以使项目的需求偏差率明显改善,测试通过率明显提高。十分容易可以理解,如 当C软件项目新模块开发实际进度低于预期进度时,用户会和开发团队进行充 分沟通,发现问题、了解问题并团队所有成员一同讨论解决方案和进行策略调整。 就不会需要一直等到传统迭代评审时,再提出问题和赶紧,不会让问题进行积压 到需要花费大量人力、物力和财力时采取解决。数据表明,无论进度的精准性预 测方面,还是进度管理的准确性都有了更明显的提升。C软件项目新模块与过往 同期相同工作量的进度的完成率分别为97.1%和72.5%O即通过查看项目的进度 完成情况,可以看出使用用户参与后进度明显优于过往。此外,如图5.12所示, 实际测试中通过率达到97%,预期为85%,并且不存在严重BUG,与过去相比 测试通过率得到了显著提升。

实际测试通过率与预期值对比

预期测试通过率■■■

c软件新模块测试通过率■■■■■■■

75%     80%     85%     90%     95%    100%

图5.12实际测试通过率与预期值对比

5.4.3埋点数据显著提升

数据埋点是对用户的数据进行采集的一种方法。是对用户的行为进行捕捉的 过程,是一种开发者角度出发的用户满意度测量。常见于点击数、停留时间、复 购率等,在了解了这些数字后有助于我们更了解用戶的参与感、用户的想法,并 能更清晰地带给我们开发的方向。分别两组之前的数据变化,即可反映出用户对 于产品的认可度。

(1)用户点击数

由于C软件刚上线交付时间不久,因此在新模块发布之前,仅有少量内部 用户(产品经理、测试人员和参与开发的业务线员工等)可进行使用。由此初期 的用户点击数字较少,因此在新功能发布的初期数据变化不大,主要由于用户初 期对于新设计的产品感受陌生,用户需要慢慢体验到便利后,才会逐步改变用户 习惯。从2021年上半年的数据看(项目新功能于2020年11月起试运营,2021 年正式启用),前期点击量都是较小的,后面再稳步提升,逐步稳定在50000 万次上下,如图5.13所示。5.13用户日点击数据图

(2)用户停留时长

从两个维度观察用户的停留时长,当然为了保证数据的有效性,需要剔除掉 无效数据,比如应页面异常退出或者超过30分钟未退出的无效停留。

一方面,关注用户停留在单一页面的时常,通过了解用户在单一页面停留的 时常确认对这个内容的关注程度,这也可以侧面的反应用户的满意度。

另一方面,关注整个应用功能中用户停留的总时长。如进入首页的时间是15:30,离开时的时间是15:34,那停留时常计算为4分钟。但若离开的时间是16:20, 即大于30分钟则属于无效处理,该数据将会被剔除,如图5.14所示。5.14页面停留时间总时常示意图

从数据统计可得,由于C软件项目由于一直有基础用户在使用,页面总停 留时长的数据一开始就有,而且缓慢平滑增长,从一开始的15秒左右逐步上升 到32秒左右。用户使用时长增加,也是用戶认可度和用户黏度提升的表现。

5.4.4用户满意度提升

在C软件正式上线后,无论从内部用户还是外部用户的反馈来看,用户满 意度明显提升,内部用户普遍表示反应速度提升,投诉降低。外部用户则觉得需 求功能增多,相比过去更满足他们的功能需求,卡顿和闪退情况明显减少。

从收集到的关于C软件存在问题的投诉上来看,与2020Q4进行相比,严重 投诉量大大降低,如图5.15所示。通过查看投诉内容,2020Q4投诉内容多针对 功能开发不满足实际流程、界面卡顿容易闪退等问题,而2021Q1的投诉内容则 多为建议C软件新增的功能、建议跳转界面增加提示内容等帮助C软件更加优 化的建议。由此可见,用户对于C软件的态度发生了极大的转变,由不满意变 为了期望功能更加完善,对C软件的认可度也不断提高。

图5.15 X银行C软件投诉条数对比图 

不难理解,原本传统的开发团队存在能力不一、分工不明确、合作欠缺等问 题,通过组建用户参与的敏捷团队,每个团队成员都具有明显的分工,例如产品 负责人、程序员、测试员、用户等,大家各司其职,在本职岗位上不断学习、锻 炼,专业技能与素质在不断提高,逐渐成为团队里的核心成员,并且不同岗位相 互交流与学习,互通有无,尽可能更多地了解本职之外的交叉学科、掌握更广泛 的专业技能,使得项目开展的每一个流程都能循序渐进,承前继后,很大程度上 能够提高整个团队的工作效率,缩短工作周期。大家的目标都是一致的,都是希 望以最低的成本,为客户提供最满意的产品与服务,用户需求一旦发生改变,整 个项目流程都要随之做出相应的变化。因此,用户加入敏捷团队之后,团队所有 成员更注重坚持合作共赢,共同创造出最大的效益。

5.5本章小结

本章对以X银行的C软件项目的新模块开发为例,对基于用户参与的新流 程进行实施方案的归纳总结。对比进度偏差率、项目成本、需求偏差、数据埋点 数据变化等得出实施效果分析。

由于用户参与了 C软件项目的新模块开发的全过程,与团队成员实现了几 乎零距离地实时沟通,任何需求变更和需求偏差上的问题,都能被快速解决,用 户和团队的满意度都有明显提升。也正是用户参与,让敏捷团队成员在专业能力、 分工职责与交流合作等方面都得到了很大提升,工作效率获得了更大提高,结合 在开发周期、开发成本、需求偏差、用户的点击数和停留时常等数据来看,用户 参与为开发迭代实现了助力。

第6章结论与展望

6.1本文结论

本文对X银行软件项目敏捷开发的流程进行了改进研究,通过用户参与改 善需求偏差问题,缩减开发周期,提升用户满意度。

首先,对X银行软件项目开发的现状和案例进行探讨,提出问题。之后, 邀请八位专家做专家访谈,对X银行在现有开发流程上的多个问题进行问题总 结。结合文献整理,做问题归纳,再通过专家打分的方式,确认最核心的问题是 用户参与不足。

其次,在X银行软件项目开发的原则基础上,设计基于用户参与的新流程, 并对迭代中关于用户参与的需求收集、开发测试、验收及用户需求进化等每个阶 段,用户参与的具体内容进行阐述分析。

最后,选择C软件项目新模块开发作为实施方案。并提出实施保障建议, 以确保实施过程中人、财、物的妥善安排。从实施项目的开发周期大幅缩减、进 度偏差率明显改善以及用户点击率增加等一些数据指标的变化,用户满意度的提 升,都可以看出用户参与对X银行的软件开发流程的改善有很大的帮助。

将用户引入银行敏捷开发的流程中,直击客户需求,是传统金融行业在电子 化领域的大胆尝试,将有助于银行占领更大市场份额。

6.2研究展璽

虽然在X银行C软件新功能开发过程中,在项目时间、成本、质量等方面 有了较明显的提升,但是研究仍然存在一定的不足之处,总结来说分为以下四点。

首先,从此前专家打分的五项问题的权重结果看,各项的差距并不是很大, 尤其是交付策略一项,更是最为接近的一项。而本文在研究内容中只考虑用户参 与这一方面,是有些以偏概全的,可以再将来的研究中逐步深化,结合其他的影 响因素,再对X银行的软件项目敏捷开发流程做进一步优化。

其次,从实际成本控制考虑,对选取的用户做了一刀切的设定,确认用户为 银行业务窗口工作人员,具有相对的单一性和片面性。因为实际的开发流程中, 用户是一个广义概念,可以涉及产品经理、银行业务人员、机构用户、政务服务 人员、产品终端客户等等。因此在未来的探究中,可以更进一步的在用户对象中 进行优化,在流程中将用户对象具象化,或细化到每一步分配不同的用户对象进 行研究探讨。

第三,由于实施内容中只是选取了一个较为简单的功能,因此可能缺乏一些 由于用户对全局开发控制等方面的考虑,在这种背景下,产品的开发往往只考虑 到功能的实现与本次更新业务的合理性,缺乏对已有功能的复用性考虑,及产品 整体构架的合理性和低冗余度的考量,尤其是面对不断更新的产品需求,以及不 断变化的人员团队,对用户、对开发团队成员、对产品经理的各自的能力要求也 需不断提高。

因此,今后X银行在对C软件项目或其他软件产品进行开发迭代时,可以 在以下两个方面展开更多地探讨与实验。一方面,可以探讨用户在更大型的软件 开发过程中可以起到的作用和效果;另一方面,可以探讨不同类型用户对敏捷开 发的影响,如产品经理也是用户,将用户的特点结合到产品经理的工作中去,研 究产品经理的把控能力、团队协作对产品的风险、进度、用户满意度等方面产生 的影响,以及在较为复杂的外部挑战影响下,如何更好的展开银行类企业的敏捷 开发工作。

最后,X银行软件的业务功能仍须不断迭代更新,随着新兴数字李生技术、 边缘计算技术、5G、区块链等新科技不断涌现,X银行在软件开发过程中不断 创新、革新的空间仍然很大,建议未来继续深化新技术应用、强化创新管理,持 续推动银行建设不断向更数字化、更智慧化升级。同时,X银行应积极利用已建 设完成的平台与软件,不断强化多平台的运营分析决策和数据资产应用能力,通 过数据挖掘等手段不断增多数据资产,从而为用户提供更多的增值服务,提升X 银行企业形象。

参考文献

[1]   章琦,章磊.TDD测试驱动开发与瀑布式软件开发流程的对比研究[J].科技 信息,2009(09): 449-450+472.

[2]   Project Management Institute. A Guide to The Project Management Body of KnowledgefM]. 2013.

⑶Phillip Kirby.流程思维企业可持续改进实践指南[M].(肖舒芸译).北京:人 民邮电岀版社,2018.

[4]   付伟江,李旭辉.国有商业银行软件开发项目分类探索[J].项目管理技术, 2017, 15(03): 113-116.

[5]   王成名,彭小娟.RPA对中小城商行的机遇与挑战卩].中国金融电脑, 2021(03): 34-37.

[6]   敖革新.银行软件开发项目管理研究[J].中国管理信息化,2017, 20(20): 159-160.

[7]      郭伟锋.G银行软件开发中心研发管理流程优化研究[D].华南理工大学,2015.

[9]   Hammer M, Champy J . Reengineering the Corporation: A manifesto for Business Revolution[J]. 1993, 36(5): 0-91.

[10]     李鹏飞,何桢.应用BPR和BPI理论改造企业流程探索[J].科技管理研究, 2006, 26(5): 3.

[11]     徐乐潇.CL公司信息系统集成项目管理流程的优化研究[D].电子科技大学,2020.

[12]     李鹏飞,何桢.应用BPR和BPI理论改造企业流程探索[J].科技管理研究, 2006, 26(5)3

[13]     魏东菊.TC软件公司软件开发项目管理流程优化研究[D].吉林大学,2020.

[14]     何兵.基于敏捷开发的软件项目管理的流程优化研究[D].北京理工大学,2016.

[15]     王蕾.广泛应用敏捷开发的分析与研究[J].硅谷,2014, 7(02): 7+5.

[16]     傅永康,郭雷华,钟晓华敏捷项目管理从入门到精通实战指南[M].北京: 人民邮电出版社.2015.

[17]     张晖.基于敏捷开发的D公司软件项目管理过程优化研究[D].山东大学,2021.

[18]    权震.Scrum方法在Y公司软件研发项目中的应用研究[D].山东大学,2020.

[19] 梁丹,张宇红.“共识”意识对于敏捷软件开发的重要性研究[J].包装工程, 2015,36(14):79-82.

[20] Meier A , Kropp M , Perellano G . Experience Report of Teaching Agile Collaboration and Values: Agile Software Development in Large Student Teams[C]// 2016 IEEE 29th International Conference on Software Engineering Education and Training (CSEET). IEEE, 2016.

[21]    李福坤.产品研发敏捷化实施成功的关键影响因素研究[D].兰州大学,2020.

[22] Tarik Z, Mirano G. LIFE AFTER SCRUM-WHERE NEXT IN FRAMEWORK DEVELOPMENT[C]//9th International Conference of the School of Economics and Business. University of Sarajevo, School of Economics and Business Trg oslobodjenja-Alija Izetbegovic 1, Sarajevo, Bosnia and Herzegovina, 2018: 395.

[23] 傅永康,郭雷华,钟晓华.敏捷项目管理从入门到精通实战指南[M].北京: 人民邮电出版社.2015.

[24] Prasetya K D , Suhaijito, Pratama D . Effectiveness Analysis of Distributed Scrum Model Compared to Waterfall approach in Third-Party Application Development[J]. Procedia Computer Science, 2021, 179(3): 103-111.

[25] 姚冬,许舟平,王立杰.敏捷无敌之DevOps时代[M].北京:清华大学出版社. 2019.

[26] Lovelock C H, Young R F. Look to consumers to increase productivity [J]. Harvard business review, 1979, 57(3): 168-178.

[27] Mills P K, Morris J H. Clients as "partial" employees of service organizations: Role development in client participation[J]. Academy of management review, 1986, 11(4): 726-735.

[28] 俞金松,高建华.基于用户分类的web日志统计测试研究[J].计算机工程与 设计,2012,33(12): 6.

[29] 崔杰生,余隋怀,周宪,面向客户的大批量定制设计方法研究[J].科学技术 与工程,2006. 104 参考文献 6(16):2561—2564.

[30] 沈波,胡云发.基于用户行为特征的虚拟品牌社区用户分类研究[J].情报探 索,2018(7):7.

[31]    Von Hippel E. kad Users: a Source of Novel Product Concepts [J]. ManagementScience, 1986, 32(7): 791-805.

[32]     Sy A,Ff B, Mm B, et al. Patterns of User Involvement in Experiment-driven Software Development]J]. Information and Software Technology, 2020, 120.

[33]     郑文清.基于领先用户的顾客创新研究[J].商业研究,2010(10):5.

[34]     郑文清.基于领先用户的顾客创新研究[J].商业研究,2010(10): 5.

[35]     王那.SCRUM敏捷开发方法和实践的研究[D].对外经济贸易大学,2012.

[36]     王新乔.基于用户参与的企业新产品开发研究[J].工业设计,2020,No. 162(01): 73-74.

[37]     Yaman S, Fagerholm F, Munezero M, Mannisto T, Mikkonen T. Patterns of User Involvement in Experiment-driven Software Development[J], Information and Software Technology, 2020, 120: 106244.

[38]     赵彦.互联网产品敏捷开发中UED团队的管理运作模式探讨[J].常州工学 院学报,2017, 30(02):34-39.

[3刃 Wallisch A , Paetzold K . METHODOLOGICAL FOUNDATIONS OF USER INVOLVEMENT RESEARCH: A CONTRIBUTION TO USER-CENTRED DESIGN THEORY[C]// DESIGN 2020 conference. 2020.

[40]     张一尘.基于用户参与的银行新型金融产品开发模型研究一一以Z银行为例 [D],浙江大学,201&

[41]     Eckhart M , Feiner J . How Scrum Tools May Change Your Agile Software Development Approach[J]. Springer International Publishing, 2016.

[42]      Tam C, da Costa Moura E J, Oliveira T, et al. The factors influencing the success of on-going agile software development projects [J]. International Journal of Project Management, 2020, 38(3): 165-176.

[43]      高亚波.优秀软件开发团队的构建讨论[J].现代经济信息,2009(12X): 1.

[44]     陈刚.传统软件开发团队敏捷转型策略研究[J].江苏科技信息,2017(26): 26-2&

[45]     杨琳.专业分工团队合作一一培训项目团队管理模式探讨[J].中国电力教育, 2009(22):216-217.

[46]     任雯.“人本理念”与“团队精神”乃企业经营之魂[J].中国集体经济,2011(20): 46-49.

[47]     刘丽丽.典型成功团队人才组合机制研究[J].领导科学,2020(2): 4.

[48]     Prasetya K D , Suhaijito, Pratama D . Effectiveness Analysis of Distributed Scrum Model Compared to Waterfall approach in Third-Party Application Development[J], Procedia Computer Science, 2021, 179(3): 103-111.

[49]     陈强.敏捷开发中的团队合作与团队绩效研究[D]・电子科技大学.2018

[50]     胡嘉欣.软件项目管理之高效团队合作卩].通讯世#,2017(18):247-248.

[51] 谢小竹,肖蕾•以团队合作精神为导向的IT人才培养模式研究与应用卩].教 育观察(上半月),2016, 5(02): 94-95.

[52] Chow T, Cao D B. A survey study of critical success factors in agile software projects卩].Journal of systems and software, 200& 81(6): 961-971.

[53] 崔启亮,李晓晴.敏捷软件本地化:特征、策略与实践[J].外语与翻译,2020, 27(01): 26-31.

[54] 崔启亮,李晓晴.敏捷软件本地化:特征、策略与实践卩].外语与翻译,2020, 27(01): 26-31.

[55] 张建斌•大型信息系统集成项目管理中的问题与策略[J].中国管理信息化, 2015, 18(08): 70.

[56] 傅永康,郭雷华,钟晓华.敏捷项目管理从入门到精通实战指南[M].北京: 人民邮电出版社.2015

[57] 夏维力,多彦彦,姜继娇.客户参与对Scrum团队信息系统开发成功率的影 响[J].科技管理研究,2017,37(017): 187-192.

[58] Tam C, da Costa Moura E J, Oliveira T, et al. The factors influencing the success of on-going agile software development projects [J], International Journal of Project Management, 2020, 38(3): 165-176.

[59] 张欣.软件项目开发过程中的需求分析[J].信息与电脑(理版),2016(18): 108-109.

[60]     支春强.软件项目需求变更与应对策略[J].科技风,2012(20): 49.

[61] 谢哲瑾.用户体验设计中的故事化思维理论与方法研究[D].北京印刷学院, 2021.

[62]     叶正卿.遗留系统架构改造的研究与实践[D].浙江大学,2012.

[63] 贾丽娜.基于用户参与的企业交互式创新项目绩效影响因素研究[D].浙江 大学,2007.

[64] 顾先华,施勇,薛质.S-SDLC影响因素分析[J].通信技术,2020, 53 (01): 225-229.

[65] 王丹.DD公司基于敏捷方法的研发项目流程优化研究[J].中国管理信息化, 2018,21(02): 55-56.

[66] 吕晶.光大银行测试能力提升探索与实践[J],中国金融电脑, 2020(07):78-81.

[67]     王新乔.基于用户参与的企业新产品开发研究[J].工业设计,2020(01):71-72.

[68] 杨帆.敏捷开发流程管理优化探讨[J].电子技术与软件工程,2015(20): 52-53.

[6刃卫东,赵东轮,石宝华•敏捷开发模式下商业银行架构管理工作的思考与实 践[J].中国金融电脑,2021(02): 66-69.

[70] 黄胜男,王艳松•软件互联网行业对敏捷开发及管理模式的应用及分析[J]. 电脑与电信,2016(09): 87-89.

[71]     彭昊.需求管理在敏捷开发中应用方式的思考[J].中国金融电脑,2021(01):76-79.

[72]     赵卫,王立杰.京东敏捷实战指南[M].北京:电子工业出版社.2020.

[73]     姜春富.SMS公司新产品开发项目管理流程优化研究[D].深圳大学,2019.

[74]     Alzoubi Y I, Gill A Q. An Empirical Investigation of Geographically Distributed Agile Development: The Agile Enterprise Architecture is a Communication Enabler[J], IEEE Access, 2020, PP(99):1-1.

[75]     Kamal T , Zhang Q , Akbar M A , et al. Identification and Prioritization of Agile Requirements Change Management Success Factors in the Domain of Global Software Development[J], IEEE Access, 2020, PP(99):1-1.

[76]     Abusamhadana G , Elias N F ,Mukhtar M , et al. Items for Measuring UserEngagement Success in Information Systems                       Development[C]//2019International Conference on Electrical Engineering and Informatics (ICEEI). 2019.

附录1

针对专业开发人员的访谈提纲

您好,非常感谢您的参与,我想就X银行软件在使用与开发过程中的一些问 题采访您一下。主要了解您对该软件的使用体验和研发情况,以及您希望今后的 改善意见和建议,以便我们对此软件现状有个大致的了解。

1.     您从事金融行业/软件开发行业多长时间了 ?

2.     您目前的职务是什么?(中级管理人员、高级管理人员、技术人员、业务人员 和其他)

3.     您负责软件开发的哪个阶段?(售前阶段、需求分析、系统设计、系统实现、 系统测试、验收测试、推广和维护等方面)

4.     在软件开发团队中,您认为哪些因素会对软件的开发结果是有正向影响的?

5.     根据您的开发经验,您倾向于使用哪些软件开发模型?

6.     您认为在软件项目开发中用户是不是会对成功率有影响?

7.     在软件投入使用后,您认为重视用户体验能否提升用户满意度?

&在收到用户的投诉建议后,您认为及时做出反馈在留住用户方面是否具有很大 作用?

9.     与其他软件相比,您认为X银行的软件最大的优势是什么?(交互性、便捷性、 流畅性、人性化等方面)

10.     您认为X银行的软件还需在哪方面进行改善?(操作界面、人工服务、使用 功能、个性设置等方面)

11.     您认为在X银行软件项目开发过程中,哪些影响因素对软件开发结果具有关 键作用?并列举重要的几项。

天天论文网
专注硕士论文服务

24小时免费热线

SERVICE ONLINE

13503820014

手机扫描二维码

收缩
  • 电话咨询

  • 13838208225