敏捷开发中如何做质量管理敏捷开发模式下,关于“敏捷开发中质量管理”的话题,如何进行质量管理敏捷开发并不只是一个“速度游戏”,敏捷开发中如何定义“完成”敏捷开发中如何定义“完成”是指某一项开发任务认为在完成冲刺后,如何在敏捷开发模式下进行质量管理,在敏捷开发过程中,以及项目质量多个迭代版本的质量波动数据来表示,评价在功能开发过程中的时效和质量。
什么是敏捷开发
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发可以说是在迭代开发的基础上发展形成的，它额外强调了沟通合作、以人为本的思想。敏捷开发的缺陷可能在于团队不能过大，一般少于20人，且要求成员都是精干，有互相信任的基础。
MyApps平台可以满足敏捷开发需求。
1、低耦合的开发方式：平台采用SpringBoot微服务框架支持SpringCloud模式，完善了平台的扩增基础，满足了系统快速开发、灵活拓展、无缝集成和高性能应用等综合能力。平台采用前后端分离模式，前端采购JQ和VUE架构，可满足不同技术栈的开发人员；后端采用SpringBoot。前端和后端开发人员可以分功负责不同部分。-敏捷开发
2、便捷的连接能力：提供详细的API中心，通过这些一键就可以完成API接口接入进行系统进行整合，还支持接口状态自定义，实现系统间业务数据的双向交换、业务处理流程等功能；
敏捷开发中如何定义“完成”
敏捷开发中如何定义“完成”是指某一项开发任务认为在完成冲刺后，敏捷任务即可视为完成。冲刺通常是项目过程中持续时间较短的任务，通常为一天、几天，但最长不会超过一个月。冲刺完成之后，团队开会并回顾已完成的工作、需要调整的地方和未来的行动规划。计划依然存在，但已经被调整以符合实际工作情况；-敏捷开发
完成迭代
理论上，每完成一次迭代就意味着项目的完结。但事实并非总是如此。一旦出现了必须解决的问题，项目就必须快速对这些变更做出响应。因此，我们不建议在每个冲刺（sprint）后发布产品。但需要确保在sprint阶段完成各个功能，以便追踪项目的进度。-敏捷开发
因此，完成工作意味着产品的各项功能得到充分地开发、测试、设计并得到产品负责人的认可。只有这样才可算完成。敏捷中有很多“完成”，但如果有任何存疑之处，sprint就没有真正完成，因此也不应交付。
在产品真正完成和交付之前，每个功能是否完工都需要取决于其他功能的完成情况。这就意味着需要整体的完成。但每个sprint都应该在结束是完成某个特定功能。这就意味着如有必要，该功能在sprint结束时可以单独交付。-敏捷开发
团队差异
但每个团队都有自己专属的完成定义，这从另一方面说明所有的用户故事标准已经得到认可。但无论这个定义是什么，它要能提高工作质量，并在用户故事完成时进行评估。
在软件开发方面，完成指的是某些内容按照标准进行了编码，经过了审查、实施、测试、整合和记录。在服务支持方面，指的是用户故事的每个任务都已经完成，产品所有者对其进行了审核，并确定所交付产品满足了需求。
在敏捷中，完成意味着团队知道需要交付什么，并且按要求进行了交付。完成是一种确保透明的手段，能够确保工作的质量符合产品要求和组织目的。
完成的定义是否会变化？
敏捷这种至关重要的管理方法可以在各类框架中执行，包括 Scrum、极限编程、自适应软件开发、DSDM、特性驱动开发、看板和水晶方法等。
这些流程是可在敏捷框架内工作的方法，但它们具备不同的方法和功能，可以适用于不同类型的项目并发挥最佳的成效。具体哪一种更好可能需要取决于具体项目的情况。但这并不意味着每个项目只能选择一种方法。综合运用一个或多个方法，可能更适合项目的需求。敏捷之所以广受欢迎，也恰好是因为其灵活性及过程的多样性。尽管敏捷包含不同类型的进程，它们都遵循了同样的完成定义。-敏捷开发
(图为Scrum敏捷开发流程)
完成的原则是不变的
2001年发布的《敏捷宣言》宣告了敏捷的诞生。宣言的发表是为了回应传统的软件开发管理方法，它概述了每个敏捷框架中存在的基本概念。敏捷宣言强调的四个核心价值是：
个体和互动高于流程和工具工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划敏捷软件开发还提出了12条原则。这些原则充分体现了我们对任务或项目何时真正完成的理解：
敏捷从不仅是作为IT项目管理的工具，它还可以改变其他企业的管理流程，使用敏捷思想来改变管理项目就是一个非常好的例子。
敏捷某些方面的特征，如待办事项等，可以在企业项目中使用并将成为最终交付项目的部分功能和特征。项目中的冲刺或短期项目，能充分发挥敏捷的快速和高适应性优势。敏捷的另外一种应用是跨职能团队的构建，这能大大提高沟通效率。且持续集成还将有助于提高项目不同版块之间的透明度，从而提高工作效率。此外，还有信息发射源、迭代、增量开发、Scrum会议、时间盒、用例、用户故事等等，所有这些都能够帮助公司用与传统瀑布开发不同的方法完成工作。-敏捷开发
为了获得在敏捷环境中工作所需的透明度和协作，我们需要运用正确的工具，确保每个人都知道完成的定义。
敏捷开发中如何做质量管理
敏捷开发模式下，如何进行质量管理
敏捷开发并不只是一个“速度游戏”，而是一个强调敏捷的“质量游戏”。在敏捷开发过程中，如果只满足了进度而忽视了质量，最终会影响项目的成功。越来越多的企业希望采用敏捷开发模式，但却困于没有把握，缺乏相应的质量管理方法。如何在敏捷开发模式下进行质量管理，达到质量与效率的双赢呢，不妨试试本文的方法。-敏捷开发
“产品教父”张小龙曾在微信事业群中谈到敏捷开发：
我们今天可以想一些与众不同的点子，然后我们可以很快就看到效果，因为我们可以很快把它上线了，然后可以去验证，如果不对就下线，如果还有改进余地，下个星期再去改它。这是一个能够持续实现你的想法的过程。
什么是敏捷开发
传统的开发流程采用瀑布式开发，从设计到编码，从测试到交付，每个阶段都必须全部完成，才能进入下一阶段。而在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。-敏捷开发
“敏捷开发”是互联网产品开发的典型方法论，是一种以人为核心、迭代、循序渐进的开发方法，允许有所不足，不断试错，在持续迭代中完善产品。
敏捷开发有两个点，一个“微”，一个“快”。
“微”是指从小处着眼，微创新。可能你觉得是一个不起眼的点，但是用户可能觉得很重要”。从细微的用户需求入手，贴近用户心理，在用户参与和反馈中逐步改进。
360安全卫士当年只是一个安全防护产品，后来也成了新兴的互联网巨头。
“快”是指快速迭代。“天下武功，唯快不破”。只有快速地对消费者需求做出反应，产品才更容易贴近消费者。
Zynga 游戏公司每周对游戏进行数次更新。小米MIUI系统坚持每周迭代。
敏捷开发质量判断方案
近年来，越来越多团队开始探讨如何进行敏捷规模化，提出了很多有效的框架，都是基于精益和敏捷的理念，在这个过程中通过系统思考产品开发流，让它形成一套完整有效的方法，进行整体的优化。公司有广泛而深入的精益和敏捷的理念来支撑，才能从局部优化上升到整体优化，才能走的更加长远健康。-敏捷开发
敏捷模式下的质量管理更具有挑战性。
在推动敏捷开发的同时，如何降低项目管理成本，提高研发人员工作效率，保证项目交付质量，变得日益重要。在敏捷开发中，衡量过程质量一直以来没有一个广泛的方法，在推广敏捷开发的过程中，总结归纳了项目过程中的常见问题，汇总了一套敏捷开发过程质量判断方案。这种方法用明确的数据从各个维度来说明一个迭代的质量问题，长期还可以看出一个项目多个迭代之间的质量变化趋势，如果多个项目同时进行，也可以轻松对比出各个项目的迭代质量优劣和质量发展趋势。-敏捷开发
以一个迭代为统计单元，每个迭代中的story完成情况和bug解决情况从以下6个角度，综合考虑了时效性和完成质量。
评价功能开发是否按时并达到质量基础要求完成，使用“story延期率”和“story打回率”两个指标，评价在功能开发过程中的时效和质量。
① Story 延期率：统计功能是否按时提测，以实际提测时间（story到“开发完成”状态）与story的“计划提测日期”字段中的时间对比，若晚于计划时间，那么story即标记为延期提测；
② Story 打回率：统计story开发完成提测后能否满足提测标准，以冒烟测试用例的满足情况为准，如果测试验证未满足则会将story打回开发状态，同一个story如果被多次打回，打回次数按照实际记录，也就是说打回率会急剧增加；-敏捷开发
评价在测试过程中所发现的问题是否按时解决并达到质量要求，使用“Bug打回率”、“Bug不收敛率”、“Bug引发率”和“Bug 重启率”四个维度，分别介绍如下。
③ Bug 打回率：是指开发人员解决了bug并提测到“开发完成”状态，但经测试人员验证发现并没有解决，被打回到“开发中”的状态；
④ Bug 不收敛率：测试提出的bug未按照解决时效要求修复的，例如，解决时效要求：P0:2小时内未修复视为不收敛；P1:半天未修复视为不收敛；P2：一个工作日内未修复视为不收敛；P3，P4（必修）：2个工作日内不修复视为不收敛；-敏捷开发
⑤ Bug 引发率：是指开发人员在解决一个bug时，引起了其他的bug；
⑥ Bug 重启率：已经关闭的bug在开发人员解决问题的过程中或者代码部署的误操作等导致不过重新出现。
在考虑各个指标分值占比时，从各个指标的意义、影响等方面综合考虑，6个维度指标优先级从高至低排列为：story延期率，story打回率，bug打回率，bug引发率，bug不收敛率，bug重启率。story延期率分值占比最高，因为story如果延期提测，那么后面的工作将整体受影响，并且可能会导致测试人员的工作安排冲突。-敏捷开发
以100分为总分，各个指标划分一定的分值，输入sprint结束后6个维度的质量统计数据，按照下面的积分模型，计算出这个sprint的过程质量总分。
敏捷开发的核心就是小版本迭代，快速出产品，所以项目一般会延续多个版本。所以项目过程质量可以在每个sprint结束后均有对应的质量数据输出，经过一系列迭代后，可以看出这个项目的质量趋势。如果同期有多个项目在进行，那么也可以通过质量数据的对比，对比出各个项目的质量优劣，同时辅以图表来直观分析对比。-敏捷开发
例如，同一阶段有3个项目在进行，同一个时间这3个项目的迭代质量和质量波动幅度数据如下，那么按照质量均分和波动幅度使用柱状图进行排序，各个项目的对比情况立刻见分晓。
对于多个项目的质量对比，采取项目质量平均分的方式，以及项目质量多个迭代版本的质量波动数据来表示。
质量平均分采取项目从第一个迭代至当前迭代的质量分数的平均值，代表项目截止当前的质量平均水平；
质量波动数据采取基于截止当前的迭代质量分数计算方差，数据越小，说明质量波动越小。
多个项目并行时，从质量均分和质量波动数据两个维度分别对比，同一时间将每个项目标记在一个二维象限（象限的质量均分和质量波动数据两个维度的分割值可以视具体的项目情况而定，例如采用多个项目这两个维度的平均值）中，项目质量以及波动情况即显而易见，在“质量好，波动小”到“质量差，波动大”之间一目了然。-敏捷开发
使用工具
以上介绍的质量判断方案需要有一定的工具支撑，我们使用了JIRA进行项目管理，管理需求和开发过程以及bug，story的计划提测时间和打回次数可以进行记录，在迭代结束后只要花很少的时间就可以进行快速得统计，迭代质量数据也可以呈现出来。项目经理在很短时间内就可以统计出项目的质量分数并进行后续分析。-敏捷开发
好的研发工具可以简化质量统计，质量统计方案在实施过程中，往往需要配合组织架构、流程、文化建设等多方面，才能达到有效推动改进迭代质量。
关于“敏捷开发中质量管理”的话题，我们就谈到这里，欢迎加入我的圈子——【精益管理圈】，持续的精益管理智慧传播、理念宣扬、心得分享、经验交流、培训提供，谢谢！
