Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。 敏捷开发在其它业界的应用是否理想不得而知,但下面总结了我所在公司的敏捷开发试验,希望能够达到管中窥豹的目的。 敏捷开发的一个特点是开放式办公,充分沟通,包含測试人员也和开发者一起办公。 敏捷方法反思: 自己參与的敏捷开发项目总的来说不是非常成功,这可能也是业界遇到的通病: 1、对于全新的软件,在项目早期測试人员就參与并实现自己主动化測试脚本,但实际上软件的界面等非常不稳定,导致測试人员返工的工作量非常大 7、敏捷开发不提倡加班,但实际上无论是CMM还是Agile哪一种开发模式跟是否加班都没有必定联系。
敏捷开发流程详解 1 敏捷开发流程 ü 敏捷软件开发核心是迭代式开发,增量交付。 1.1 敏捷流程详解图-敏捷流程图 1.2 敏捷流程三种角色及其职责 角色名称 角色定义 角色职责 注意事项 Product Owner(PO)- 产品负责人 确保Team做正确的事 5-9人左右跨职能领域人员(开发人员、测试人员、设计师等)组成 l 团队车管员构成在sprint内不允许变化 l 有共同的目标、共担责任 l 团队成员严格遵守团队规则 1.3 敏捷开发流程详解 1.3.1 流程图详解步骤 1. 可以考虑安装一款支持jira的敏捷开发插件GreenHopper,完全实现电子版的看板功能和图表功能。
敏捷大数据流程 敏捷大数据流程利用了数据科学的迭代性本质和高效的工具,从数据中构建和抽取高阶的结构和价值。 数据产品团队技能多样,会产生多种可能性。 而敏捷方法就是为了更好的实现不断变化的需求,并尽快将样品转化成真正能运行的系统而发明的。 敏捷产品开发的目标是辨识出产品最根本的特性,将这个特性先实现了,然后再添加其他特性。这将敏捷带到了项目里,让项目更有可能满足产品进化过程中最真实、最根本的需求。在数据产品中,最根本的特性会给人惊喜。
这里是修真院后端小课堂,每篇分享文从 【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】 八个方面深度解析后端知识/技能,本篇分享的是: 【什么是敏捷开发流程 】 这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。 拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。 二. 然后是我理解的敏捷 主要说一下我们公司自己的开发流程,因为接触时间尚浅,所以有点地方可能说的不是很到位,希望大家多多包含。 这么一个流程走下来,特别期间各个环节的良好运行以及团队合作的情况都是确保项目能够正常实现并交付的重要因素,敏捷开发强调的是人的充分能动性,通过这种相互合作的开发模式,相信在前后端分类开发的盛行时代,公司或者团队可以在约定的时间内较好地完成用户委托的项目
CMMi 或是敏捷,都是有流程的,否则不可能经由CMMi 或敏捷而产出产品。 只是过往大家都被 CMMi 所误导,认为所谓的流程就是文档,审批,追踪,检查项,检查点…… 敏捷希望大家重新思考什么才是流程? 流程真正的核心要素为何? “敏捷在它的敏捷宣言中,给了我们答案。” 所以,既然流程的定义不同了,在敏捷开发中,对所谓的流程的思维与作法,自然就会不同。 我想,只要是做产品,该有的,还是都有的。该做的,还是都得做。不论是 CMMi 或是敏捷。 而我们只是正好在敏捷开发中找到了这个方法,而这个方法,也正好不同于以往CMMi的方法罢了。 只是,有趣的是: 过往在搞 CMMi 的时候,没有了文档,不谈流程,大家就如犯天条,惊慌失措。 而现在在搞敏捷,只要一有文档,一谈流程,大家就如犯天条,惊慌失措。 其实,这些都是误解。我想,只有回到产品(客户)的本质,这些误解才能获得澄清与理解。
Scrum流程与实践 相信通过前面一篇文章的介绍,你已经对 Scrum 有了一定的了解了。但是这玩意怎么用呢? 其实,这个 Scrum Master 就是 Scrum 教练的意思,现在它已经引申到了整个敏捷领域,也就是 敏捷教练 。不过后面我们还是以简称 SM 来说明这个角色。 SM 是项目经理吗? SM 对于 PO 来说,会帮助 PO 找到有效管理产品待开发列表的方法,帮助 PO 与开发团队进行清晰有效地沟通,与团队一起理解产品的长期规划,理解并实践敏捷。 确实,这个 敏捷教练 的角色和我们所认知的 项目经理 有很大的区别。 参考文档: 《某培训机构教材》 《用户故事与敏捷方法》 《高效通过PMI-ACP考试(第2版)》 《敏捷项目管理与PMI-ACP应试指南》
引言:敏捷绝非某一种特定的开发方法,它只是一种应对快速变化的需求的一种软件开发能力。敏捷本身只包含了《敏捷软件开发宣言》和《敏捷软件的十二条原则》两份文档。 目前很多互联网公司都在搞或者想搞敏捷开发流程,但能正常的运行起来的比较少,很多公司还是产品、开发、测试相对于独立,产品提需求,开发做功能,测试功能,这样看来不是一个Tim,而是不同的人在在做不同的工作, 敏捷开发流程是一个标准的项目管理流程,是不能适用于所有的公司,但是适用大部分的公司,公司根据标准化流程去进行优化,不管是新增还是减少,只要适用于自己的公司那就是贵公司的敏捷流程。 以下是我司的敏捷开发流程(我司的流程也是经过几次改版,这个过程可能需要几个月,因为敏捷开发的实行是在不同的流转,这就需要根据公司实际情况进行调整): 产品设计(以下就是敏捷中重要的节点): 1.产品指南评审 3.发布:产品验收后就可以进行发布了 4.回顾:回顾本次迭代或者本次项目中做的不好的、好的点进行总结,好的点要继续保持,不好的点可以要进行总结,下次迭代改进 以上就是我司的敏捷开发流程,执行下来肯定有很多困难与不适应
0、先来一张导图 1、概念 简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 敏捷最大的特色是迭代式开发。 2、优势 1、敏捷开发属于增量式开发,对于需求范围不明确,需求变更较多的项目而言,可以很大程度上响应及拥抱变化。 2、对于互联网产品而言,市场风向转变很快,需要一种及时快速的交付形式,而敏捷开发则能更好地适用于此。 3、敏捷开发可最大程度体现80/20法则的价值,通过增量迭代,每次都优先交付那能产生80%价值效益的20%功能。能最大化单位成本收益。 3、误区 4、特点 5、核心原则 6、捷开发与瀑布模型开发 瀑布模型开发 敏捷开发 某博主po的一个很有趣的“敏捷和瀑布”对比例子,给大家作为阅读参考: 6.1、敏捷开发 客人到餐馆来点菜(新项目
“敏捷”也不例外,敏捷宣言中第一句就是“个体和交互 胜过 过程和工具”,充分强调了团队合作的重要性。 所以,我的观点是,“敏捷”的前提是“团队优先”,重视团队,重视团队中的每个角色,无差别的对待每个合作成员,让每个角色、成员有动力,有激情的弥补自己的短板,让自己更敏捷,从而促进整个团队的敏捷。 所以,应该跳出旧的思维,看看到底是自身不敏捷,还是其他成员、团队、组织的不敏捷影响了整体的“敏捷”。 结合实际,流程3~6 要怎么做? 参考方案 方案1) 流程3、用Mindjet Mindmanager、XMind记录用户故事,举例如下 ? 流程4、相关人员聚在一起讨论需求细节并记录结果 ?
敏捷开发中的Scrum流程通常可以用一个简单的流程图来表示,以便更清晰地展示Scrum框架的各个阶段和活动。 以下是一个常见的Scrum流程图示例:图片这个流程图涵盖了Scrum框架的主要阶段和活动,其中包括:用户需求:从利益相关者那里获得用户需求,这些需求会被添加到产品待办清单。 这个流程图简洁地展示了Scrum框架的流程,从需求到完成工作,并强调了Scrum的迭代性质和持续改进的重要性。您可以根据需要定制和扩展这个流程图,以适应特定项目和团队的需求。
图片01 敏捷开发整体流程需求确认,产品输出用户故事,产品测试产品就需求部分达成一致开发进行接口开发,前后端按照用户故事进行接口约定,测试进行案例设计进行案例评审和接口评审,开发测试围绕业务逻辑,用户故事的数据流向达成一致后端开发进行接口开发
随着测试行业的进步,测试流程也在飞速的发展。最开始工作接触的就是瀑布模型,虽然测试工作做了很长的时间,在一家传统公司,做着传统的业务,测试流程并没有跟着行业发展而继续发展。 为了解,也为不被IT行业所淘汰掉,机缘巧合开始学习敏捷 什么是瀑布模型,瀑布模型的特点 需求固定,反对更改需求 流程固定,开发测试流程清晰,设定具体流程的时间节点,比如开发多少周,测试多少周等等 或者足够小的功能 每次功能交付以后如果发现问题,可以及时撤回修改并重新发布 迭代的问题 缺少能够将迭代划分清楚的人 迭代能够被划分也能够划分足够小,但是“小”的标准无法被定义清楚 迭代过程中没有对技能,流程 ,功能进行很好的思考与进步,只是重复做着同样的功能开发 迭代加速了产品的整个开发周期,但是对个人,产品本身没有技术沉积 敏捷是如何做的 敏捷开发历史 为什么要开展敏捷 敏捷的四个关键字VUCA 目标的设定 根据以上如果还是按照原来的计划流程来开发,也学做成的产品放在当下已经是无用的产品 根据当前的要完成目标快速调整 完成当下眼前的目标,完成一个个的小目标然后再继续完成大的目标 需要将难以完成或者暂时未完成的目标
优先级和粒度无疑问,有问题反馈给leader 方案评审 前后端快速整理出接口,哪些可复用,哪些需要合并 接口遵循RESTful风格,考虑扩展性 参数和返回值都清晰明确,遵循接口定义规范 关键业务逻辑画业务流程图
前言: 流程是轨道, 敏捷实践 (框架) 是行驶在这轨道上的火车, 团队成员便乘著这列火车, 迈向版本交付的终点◦ 本文: 企业内推行敏捷变革时, 往往将敏捷中的实践 (框架); 如: 站立会议, 回顾会议等 , 以制订流程的方式, 在团队中规范站立会议, 回顾会议的责任人, 责任人应负责的工作, 预期的结果◦ 这样的思维与作法, 使企业内的产品团队成员, 往往将敏捷中的实践 (框架) 当成是企业内制式的流程活动 , 而使敏捷在团队中流于形式◦丧失了团队可经由敏捷实践(框架), 提升团队成员的自我任务管理, 自我不断改善效率与质量的本意与功能◦ 然而在大型企业内, 假如缺乏了流程的规范, 各产品团队即使执行了种种的敏捷实践 而使流程既能兼顾 “规范”, 又不致扼杀了敏捷实践 (框架) 的本意与功能? , 责任人, 各过程的进入条件, 离开条件上的要求◦ 结论: 将企业内的流程与产品团队开发的实践隔离, 将使企业内的流程更能适配各种不同的敏捷实践 (框架), 而产品团队在执行适合自身的敏捷实践 (框架
Leangoo领歌覆盖了敏捷项目研发全流程,包括小型团队敏捷开发,Scrum of Scrums大规模敏捷。 SAFe(Scaled Agile Framework)是全球运用最广泛的大规模敏捷框架。SAFe融合了精益、敏捷和DevOps,它是一个知识库,囊括了大量已被证明的精益敏捷实践和能力。 SAFe是全球最受欢迎和接受的大规模敏捷框架。 Program Backlog 看板Program Backlog看板是未来的特性故事(Feature)的暂存区,可用于为某个敏捷发布火车(ART) 满足用户需求和交付业务收益。 Leangoo领歌也提供SAFe大规模敏捷培训,SAFe认证Leading SAFe官方认证班 大规模敏捷 SAFe ScrumMaster & Leading SAFe双认证班SAFe认证SPC官方认证班
敏捷项目管理与敏捷宣言 说到敏捷项目管理就不得不提到那十分出名的敏捷宣言。这篇文章我们就来简单地了解一下敏捷项目管理的出现和敏捷宣言说的是什么。不要有太多的压力哦,这篇文章还是非常轻松的。 到最后我们学习完了敏捷相关的知识后,大家可以自己再回过头来想一想敏捷和传统项目管理的区别和联系都有哪些,这样对大家知识的掌握才更有好处。 目前来说公认的最佳的方案,就是:敏捷。 敏捷宣言 最后,总算到了我们这篇文章最核心的内容,那就是敏捷宣言。这个东西的历史很多教材以及文章中都会介绍,所以这里我就不再多说一遍了。 个体和交互 高于 流程和工具 可交付的软件 高于 完备的文档 客户合作 高于 合同谈判 拥抱变化 高于 遵循计划 尽管右项有其价值,我们更重视左项的价值 没别的说得,这四条原则太简单了。 总结 今天这篇文章我们从传统的项目管理说起,通过 VUCA时代 这样一个时代现象来引出敏捷出现的必要性,最后介绍了敏捷的灵魂:敏捷宣言。当然,敏捷宣言很简单,就四句话,也可以概括成四个词。
摘要敏捷开发强调快速迭代和频繁交付,要求测试过程能够适应快速的开发节奏。 本文将介绍自动化测试在敏捷开发中的具体应用方案,讲解如何在 CI/CD 流水线中集成自动化测试,并提供可运行的示例代码。引言敏捷开发是当今软件开发领域的主流方法之一,其特点是短周期、高频次的迭代发布。 在本文中,我们将讨论如何在敏捷开发流程中有效应用自动化测试,并展示如何在 CI/CD 流水线中嵌入自动化测试。自动化测试的作用敏捷开发要求持续的反馈与快速的交付,而手动测试往往难以跟上开发节奏。 整个流程分为三个阶段:Build 阶段:在代码提交后,首先进行单元测试,验证代码的基本逻辑。Integration 阶段:通过集成测试,确保模块间的协作无误。 总结自动化测试是敏捷开发流程中不可或缺的环节。本文探讨了自动化测试在 CI/CD 流水线中的应用,并提供了单元测试和集成测试的设计示例。
其它敏捷框架 你们一定想知道为什么不接着讲 Scrum 呀?干嘛中间横插一脚。 好东西嘛,当然要留到最后,所以我在这里也就卖个关子,先陪着大家一起来学习一下其它好玩的敏捷框架,或许你能发现不一样的东西哦! 可视性进度报告 可视性进度报告就是包括但不限于使用各种敏捷类的图表,或者其它非敏捷的,只要能够有效地反映项目进度情况的图表。当然,更推荐的是白板、大屏这些可视性效果极佳的方式进行进度报告的展示。 其实并不新,敏捷各个框架中都强调的让团队坐在一起,没有隔离,让客户也尽量和我们坐在一起。然后呢? 参考文档: 《某培训机构教材》 《用户故事与敏捷方法》 《高效通过PMI-ACP考试(第2版)》 《敏捷项目管理与PMI-ACP应试指南》
无论你的公司是在做敏捷转型还是一开始就使用敏捷,在推进敏捷的过程中往往都碰到了很多的问题。今天和大家分享一下业界认可的正确推进敏捷的三个步骤:评估诊断、敏捷试点和大规模推广。 在敏捷转型实践中,大部分的企业都选择请外部的敏捷教练或者咨询师来帮助企业做敏捷转型,而评估诊断也通常是由他们来做。 如果没有请敏捷教练或者咨询师,那也应该从企业内部指定一个熟悉敏捷和了解业界敏捷实践的人来做评估诊断。 (2)访谈评估 对这些选中的项目组中的团队成员进行访谈,从流程、组织、人员技能、度量和技术等维度,对项目进行评估,目的是探查项目的痛点。 (3)端到端研发全流程向业务敏捷靠拢 比如,在整个产品研发流程中制定定期反馈机制,争取在每个环节都定期收集反馈,为全流程提供数据支持,便于团队回顾审视的时候识别问题和不足,能够帮助团队做到持续改进。
今天开始和你一起重新温习敏捷,先来正确理解一下敏捷吧。 相关阅读: (1)如何正确理解敏捷? (2)如何正确推进敏捷? (3)如何填好推进的坑? (5)无处不在的敏捷思想 1 敏捷的初心 2001年,一群大师聚集在美国犹他州,吃吃喝喝头脑风暴,搞出了一个敏捷宣言,阐述了5条价值观,如下图所示。 ? 所以,如果“流程和工具”、“详尽的文档”、“合同谈判”又或者“遵循计划”能够让研发工作更高效有序,那敏捷其实也是不反对也不放弃做的,这或许也是敏捷的真谛。 这十二条原则也可以帮助我们正确理解敏捷,里面的原则对于敏捷的价值观做了细致的描述,它重视各方的协作,强调持续改进和响应变化,不夸张的说,它基本涵盖了软件项目管理中比较具体的基本流程。 ? 对于方法,无论它是不是Scrum,又或者它是否打着敏捷的名头又或者冠以敏捷,本身是无所谓的,我也更是觉得并非要全盘采纳敏捷的所有方法(很多时候我发现我们都很迷信3355的流程),只要在具体实践中能够体现敏捷思想