前言: 本文主要探讨在精益敏捷的开发下, 该如何看待与处理所谓的 “带病迭代”? (而不在探讨如何定义带病迭代◦) 本文: 精益敏捷开发采用迭代的方式进行开发◦许多的团队在这方面往往犯了以下的其中一个错误, 而使得精益敏捷开发最终以失败收场! 2) 认为迭代是 “带病” 了, 便认为应停止开发下一轮迭代的所有需求, 先将这轮迭代搞 “健康” 了再说◦ 如此的思维, 作法是以 CMMi 的方式在执行精益敏捷开发;标准的借尸还魂◦最终, 结论: 在精益敏捷的开发下, 看待与处理所谓的 “带病迭代”, 是期望项目经理需根据: 1) 外部客户, 使用者的变化 2) 产品质量的变化 有智慧的做出正确的 “决策”, “计画 ” 与 “执行’◦ 能拥抱变化, 才是真正的精益敏捷开发!
扯得有点远了,赶紧收回来——敏捷迭代是个好东西,能让产品更快速、更精确地应对用户需求的变化。 如若不然,产品就会走上颠簸之路或者伪敏捷之路,前者的体现是敏捷反而会导致版本稳定性下降,后者的表现是在快速版本周期内只能做小打小闹式修改,并不能真正使产品核心功能完成迭代式演进、不断提升产品品质。 迭代模型说明 当然,除了角色能力这一关键因素,合适的敏捷运作流程也是甚为关键,两者是相得益彰的,为讲清楚这一点,笔者特意将所在产品团队的敏捷迭代模型规划图贴出来,以便做针对性讲解。 三周敏捷迭代模型规划图 图中要素说明: 1、绿色字样的是整个团队的核心里程碑交付节点; 2、蓝色字样是各角色各阶段工作需完成里程碑节点; 3、此迭代模型迭代周期为三周,故仅适用于后台开发工作量在两周以内的需求 综上所述,敏捷迭代运作必然是多角色工作递延启动、并行运作,而且环环相扣的,对每一个角色的要求都很高,任意一个角色拖后腿都会影响整个团队进度,迭代运作初期团队人员可能会比较累(特别是产品跟设计,差不多要同时准备两个版本的需求与设计稿
1.概要 在公司我们经常会听到敏捷迭代这个词汇,可能也在敏捷迭代的工作流中工作过 。但是却没有对敏捷迭代有更全面的了解,希望这篇文章能简单的让大家有个全面一点的了解。 本文需要讲到的内容是Scrum敏捷框架,当然还有其他的敏捷框架这里就不多讲了。 1.1 什么是Scrum? Scrum 将 敏捷 原则作为一组具体的项目、做法和角色来实现。 2.详细内容 2.1 Scrum生命周期 下图详细介绍了迭代 Scrum 生命周期。整个生命周期在称为 冲刺的固定时间段内完成。 当我们用Scrum来实施敏捷开发时就大不相同了,整个项目会被分解成不同的小部分。 Plan: 围绕最小化可行性产品的特性进行产品规划。 Build: 把最小可行化产品开发出来。 做详细的规划来完成下一个增量式发布,经过几轮迭代得到了几个增量式版本,成为Sprint。一个Sprint通常需要一个到三个星期,就这样一直重复Sprint直到你的产品功能齐全。
敏捷开发的核心就是小步快跑,快速迭代。过去,企业开发的需求是完整的、清晰的、固定的,产品定义也是稳定的,因此企业在项目开发中经常采用自上而下、相互衔接且固定次序的瀑布开发模式。 敏捷开发提倡以迭代式开发的方式开发产品,即一次完整地经过所有工作流程的过程:需求、分析设计、实施和测试工作流程,所有的阶段都可以细分为迭代,并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。 在迭代计划会上,需要明确这个迭代的目标是什么,任务是什么,每个任务的目标又是什么。2、加强协作。在敏捷开发过程中,团队成员需要密切协作,及时交流,相互帮助,共同解决问题。3、简化流程。 敏捷开发迭代管理示例:迭代规划完成后,进入迭代看板,可以看到已规划的用户故事已分别放置在独立泳道中,泳道可横向对应用户故事和拆分的任务。 敏捷迭代规划:图片用户故事任务拆分:图片迭代执行:图片免费敏捷开发工具:常见的敏捷开发项目管理软件有很多,比如Leangoo领歌、Axosoft、Trello、Asana、Monday.com、Zenkit
Sprint Retrospective 迭代回顾会 是非常重要的一个会议,很多时候,团队成员都会忽视,或者流于表面,今天和大家好好聊一聊这一块 一、Sprint Retrospective的概叙 迭代回顾会是在 参与的人员主要是敏捷团队成员,时长不超过1.5小时。 二、Sprint Retrospective目的 目的主要是让敏捷团队成员自省同时在下个sprint的时候提升。 3.2 团队关系 这里的关系不仅指的是敏捷团队成员之间的关系,也包括和干系人之间的关系,这也是我们要关注的。 确实,在我们做敏捷管理的过程中,会用上大大小小的工具来提高效率,但是,你会发现,有一些工具在这个sprint有效,在下个sprint就不一定有效了。 我们还要设定一个安全的会议环境,鼓励与会的敏捷团队成员多发言。
迭代计划会议是团队级敏捷的三个基础会议形式的一个,按软件开发的时序,这个是第一个会议,我之所以放到最后讲,是因为这个会议很重要,非常容易陷入误区。 Backlog:一个经过产品经理和开发Leader预沟通的备选迭代Backlog,初步的需求优先级排序 2.迭代的目标:目标包括很多类型,是这个迭代的“教堂”,比如这个迭代要交付的重大特性,重大的市场发布等 11.会议结束,开始为这个迭代的目标而冲刺。 迭代会中的一些雷和坑 1.迭代会议预先准备是非常关键的。 关于为什么比较流行使用斐波那契数列我写了一个短文:https://bbs.huaweicloud.com/forum/thread-13153-1-1.html 3.业界在各种敏捷,DevOps培训中, 整个迭代会议,建议使用专业的敏捷协同管理工具,大家看到内容一致,大家刷新调整后的内容也一致并即刻生成,会议结束的同事,一份本迭代的UserStory/Task列表就生成了,也不用会后再去整理。
一、Sprint Planning 迭代规划会 迭代规划会从大的方面来说其实就是做两件事情: 1、决定迭代阶段需要做哪些事情? 开发团队回答:“实现微信支付”,那么在接下来的迭代周期内,开发团队就是围绕着这个迭代目标奋斗,其他和此迭代目标无关的至少在这个迭代周期内不管。 一旦Sprint Goal确定,Sprint Backlog选定,剩下的事情就是敏捷团队大显身手的时候了。 image.png 三、Sprint Planning的要点 1、新的开始 敏捷开发是增量式的交付,可能由好几个迭代周期组成,上一个迭代周期结束,新的迭代周期开始。 图片 3.png 4、确定Sprint Goal 迭代目标 敏捷团队确定这次迭代的Sprint Goal 迭代目标,这样让开发团队更聚焦、专注。
---- CODING 承载了最先进的敏捷研发理论,能够帮助您和您的团队快速入门敏捷研发,并通过标准化的流程和完整的信息统计成为企业实践敏捷研发的好工具。 在上一篇中我们通过视频教程展示了 CODING 完整的敏捷研发工作流,接下来的视频系列将会更加细致地展示敏捷研发模块中各个场景的使用方式。 如何使用 CODING 敏捷研发 进行迭代管理 接下来通过视频跟随 CODING 了解如何轻松搞定迭代管理: 更多敏捷模块功能使用指南,可查看近期 CODING 公众号发布的系列视频: 基于 CODING 轻松搞定敏捷开发
Sprint Review 有的翻译为“冲刺评审会”,有的翻译为“迭代评审会”,其实都无所谓。它是在一个sprint快结束之际召开的。 一、Sprint Review概叙 Sprint Review的核心词是“Review”,但它不是不是让你把Sprint Review开成“回顾会”,这是很多敏捷教练刚带团队的时候容易犯的错误。 团队成员们会聚集在桌子周围进行非正式的演示,讲述自己在本次迭代中完成的工作。在这期间团队成员可以相互提问、尝试新的功能并提供反馈。成功的分享是构建敏捷团队的重要工作。 SprintReviewMeeting.png 3、庆祝团队成果 Sprint Review是庆祝团队和个人在迭代过程中所取得成就的好时机。 在迭代过程中更改了优先级,而开发团队则因范围的变更陷入困境; 这就需要我们团队成员花点时间来探讨原因,并在下一个sprint有选择性的解决这些问题。
本文将从得物技术部的敏捷迭代在落地过程中的实践出发,对比敏捷行业敏捷实践的共性及差异性,以大规模团队的实践做为切入点,以点带面带大家了解千人规模的敏捷迭代在得物的落地实践。 二、千人敏捷迭代的挑战与解题思路 电商业务本身属于长流程业务,从产品上架到用户下单再到履约,涉及到商品管理、订单处理、支付结算、物流配送等多个方面。 得物敏捷迭代在推广落地过程中并没有死搬硬套行业内的一些敏捷框架,诸如团队级的敏捷框架Scrum甚至是组织级的大规模敏捷框架SAFE等,而是结合自身业务和团队的特点,借鉴和落地好的敏捷实践,形成了自己特色的解决方案 小步快跑 需求在没有上线之前只是假设(假设这样做可以解决用户的问题),敏捷开发中,通过需求拆分,高优先级需求识别及迭代交付机制,尽快将一个需求从提出推进到上线,能够尽早收集用户反馈,验证需求价值,并及时响应变化 这里强调一下迭代周期和发布能力是要区分开的,对于APP的迭代周期来说是以两周作为维度,但是发布是可以根据实际情况单周进行甚至任意时间点进行的动作。
这种不可预测性使项目管理复杂化,因为传统的开发方法可能无法满足AI必不可少的迭代学习过程的需求。 敏捷原则强调灵活性和协作以及渐进式进展,为应对这些挑战提供了一个有前景的框架。 通过结合迭代周期、持续反馈和自适应规划,敏捷方法允许团队快速适应变化,改进其模型,并有效地整合新数据。 这种AI和敏捷之间的结合促进了更具弹性的方法,使团队能够在交付有价值和功能的AI解决方案的同时管理不确定性。 将敏捷适应AI开发 在AI开发中,迭代周期对于解决数据质量变化和模型更新至关重要。 随着数据集的发展,定期迭代允许团队根据新的见解和挑战改进其算法,确保AI模型保持相关性和准确性。这种方法使团队能够快速转向,适应不断变化的数据环境的复杂性。 协作对于在敏捷框架内发展项目范围至关重要。 结论 将敏捷方法与AI产品管理相结合,创建了一种应对迭代开发复杂性的动态方法。敏捷强调灵活性和快速反馈,与AI技术的不可预测性完美契合,使团队能够快速适应新兴挑战和利益相关者期望。
01 从0到1 在敏捷测试中找到最优解 背靠义乌商品市场,靖然优品有着天然的产品供应链优势,几乎所有的小商品品类,都能直接在当地接触到,因此在产品选择方面有足够的尝试空间。 靖然优品表示,正是在巨量千川的帮助下,靖然优品已经走出了自己的巨量千川经验之道,如何做敏捷测试,什么时候控制成本,什么时候追投,怎样在策略上做整改,靖然优品都已经掌握了规律。
敏捷开发 极限编程的思想体现了适应客户需求的快速变化,激发开发者的热情,也是目前敏捷开发思维的重要支持者。 敏捷软件开发是一个开发软件的管理新模式,用来替代以文件驱动开发的瀑布开发模式。 敏捷开发集成了新型开发模式的共同特点,它重点强调: 1.敏捷就是“快”。快才可以适应目前社会的快节奏,要快就要发挥个人的个性思维多一些。 2.客户参与。 迭代开发,敏捷开发,区别一种生命周期模型,项目管理方法集合 迭代开发是一种软件开发的生命周期模型,与其对应的还有瀑布模型、螺旋模型等等 敏捷开发是多种软件开发项目管理方法的集合 简单来说,迭代模型是敏捷开发普遍使用的软件生命周期模型,敏捷开发所包含的内容比迭代模型宽泛的多. 敏捷开发中,XP与SCRUM的区别 区别之一: 迭代长度的不同 XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.
当风险识别完成并有确定的风险消除方案以后,就继续采用瀑布模型完成一次迭代开发。在多次迭代以后,达成所期望的戏疼。敏捷开发:如果只是从开发的核心阶段来看,敏捷开发就是迭代开发。 敏捷开发敏捷开发(agile development)是非常流行的软件开发方法。据统计,2018年90%的软件开发采用敏捷开发。敏捷开发的核心是迭代开发(iterative development)。 敏捷一定是采用迭代开发的方式。敏捷开发是总体概念,而迭代式开发是实践敏捷开发概念的一个手段。 敏捷开发除迭代式开发外,还包含了其他许多管理与工程技术实践,如演进式架构设计、敏捷建模、重构、自动回归测试(ART)。综上,敏捷开发与迭代开发是整体与局部的关系,前者是家族,而后者是家族成员。 增量开发加上迭代开发,才算真正的敏捷开发。敏捷开发是以用户的需求为核心,采用迭代、循序渐进的方式开发软件。敏捷开发的优势早期交付敏捷开发的第一个好处,就是早期交付,从而大大降低成本。
ABB 3BSE006096R1 利用敏捷和迭代协作原则图片行业中的领跑者正在开启一个以精益经验为基础的时代,但不仅仅是简单的自动化,而是利用敏捷和迭代协作原则,如果这仅意味着精益 + 数字“领先”,则远远超过数字精益
,第二周再进行细节完善 4.敏捷 敏捷开发有很多种方式,其中scrum是比较流行的一种 scrum: 轻文档,轻流程,重目标,重产出 轻量级:迭代周期短,参与人员少 组成结构: product 4 演示会议:迭代结束之后,召开演示会议,相关人员都受邀参加,团队负责向大家展示本次迭代取得的成果。 5 回顾会议:项目团队对本期迭代进行总结,发现不足,制定改进计划,下一次迭代继续改进,已达到持续改 进的效果。 敏捷中的测试: 挑战1:轻文档 挑战2:快速迭代 1、测试工作的核心内客是没有变的,就是不断地找Bug,只是要调整好自己的心态,一切以敏捷的原则为主。 2、测试人员不能依赖文档,测试用例作用减弱,更多的采用思维导图、探索性测试(强调自由度,设计和执行同时执行,根据测试结果不断调整测试计划)、自动化测试 3、敏捷讲求合作,在敏捷项目组中,测试人员应该更主动点
迭代型生命周期通过连续的原型或者概念来验证产品或者成果,它允许对未完成或者部分完成的需求进行反馈和调整,从而对该工作进行修改。 迭代型生命周期 首先会设立一个时间盒(固定的迭代周期,一般都是几周),在这个迭代周期里面可以根据干系人的反馈或者团队的反馈进行需求调整,这样越来越接近用户的价值和主张,才能使得用户要的产品有价值。 图片 1.jpg 迭代型生命周期适用于需求高度不确定的项目,所以迭代型生命周期的时间较长(需要不断反馈和调整),但是它是为了产品价值优化,而不是为了交付速度优化。迭代型生命周期是一次交付。 个人认为迭代型生命周期适用于软件类项目,不适用于硬件类项目,因为需要不断地调整和修改,所以导致时间长。硬件类项目这样不断调整的话,一是时间长,二是费用代价大。 举一个通俗的例子: 你要去未来丈母娘家。
敏捷项目管理与敏捷宣言 说到敏捷项目管理就不得不提到那十分出名的敏捷宣言。这篇文章我们就来简单地了解一下敏捷项目管理的出现和敏捷宣言说的是什么。不要有太多的压力哦,这篇文章还是非常轻松的。 到最后我们学习完了敏捷相关的知识后,大家可以自己再回过头来想一想敏捷和传统项目管理的区别和联系都有哪些,这样对大家知识的掌握才更有好处。 目前来说公认的最佳的方案,就是:敏捷。 敏捷宣言 最后,总算到了我们这篇文章最核心的内容,那就是敏捷宣言。这个东西的历史很多教材以及文章中都会介绍,所以这里我就不再多说一遍了。 当然,你可以向客户阐明你的敏捷观点,进行详尽的沟通,但是,一切都是以交付客户价值为基础。 所以,敏捷将这四条视为原则,而不是准则、规则。 总结 今天这篇文章我们从传统的项目管理说起,通过 VUCA时代 这样一个时代现象来引出敏捷出现的必要性,最后介绍了敏捷的灵魂:敏捷宣言。当然,敏捷宣言很简单,就四句话,也可以概括成四个词。
其它敏捷框架 你们一定想知道为什么不接着讲 Scrum 呀?干嘛中间横插一脚。 可视性进度报告 可视性进度报告就是包括但不限于使用各种敏捷类的图表,或者其它非敏捷的,只要能够有效地反映项目进度情况的图表。当然,更推荐的是白板、大屏这些可视性效果极佳的方式进行进度报告的展示。 而 DSDM 之所以说快速地用 20% 的时间去完成那些功能,是因为 DSDM 认为任何事情都不可能一次圆满完成的,但我们可以在一个短时间内快速地实现大部分的功能,不用过多关注它们的质量,而在后面的迭代中再继续去优化完善 其实并不新,敏捷各个框架中都强调的让团队坐在一起,没有隔离,让客户也尽量和我们坐在一起。然后呢? 参考文档: 《某培训机构教材》 《用户故事与敏捷方法》 《高效通过PMI-ACP考试(第2版)》 《敏捷项目管理与PMI-ACP应试指南》
无论你的公司是在做敏捷转型还是一开始就使用敏捷,在推进敏捷的过程中往往都碰到了很多的问题。今天和大家分享一下业界认可的正确推进敏捷的三个步骤:评估诊断、敏捷试点和大规模推广。 如果没有请敏捷教练或者咨询师,那也应该从企业内部指定一个熟悉敏捷和了解业界敏捷实践的人来做评估诊断。 在敏捷中,计划的指定通常来说都是渐进的,近期的计划可以落实到细节,但远期的只能是粗略的,这也和我们强调短迭代快反馈的思想一致。 试点前的准备 “凡事预则立,不预则废”,只有做好准备,才能在敏捷试点时有备无患。很多人还给这个试点前的准备工作起了个外号“迭代0 (Iteration 0)”。 ? 在推进试点进行中,定期开展“回顾会议”,引导团队成员自发思考每个迭代的不足和改进方法,使得团队能够做到持续改进,也锻炼团队的自组织能力。