你可以理解为是当前sprint最后一个会议了,所以很多人认为是总结会,也可以这么理解。参与的人员主要是敏捷团队成员,时长不超过1.5小时。 二、Sprint Retrospective目的 目的主要是让敏捷团队成员自省同时在下个sprint的时候提升。同时总结一些事情来做整理,我们都没有去做。 SprintRetrospectiveMeetingsDosAndDonts.png 三、回顾的内容 3.1 团队成员 看看敏捷团队的成员在这个sprint过程中有没有做的好的地方或者不好的地方,那么在下一个 3.3 流程 敏捷管理不是不要流程,而是说要将流程尽量简化,改要的流程还是要的,所以在这过程中,我们也要回顾我们哪些流程用得好,继续保留,哪些流程不行,需要改进或者遗弃。 确实,在我们做敏捷管理的过程中,会用上大大小小的工具来提高效率,但是,你会发现,有一些工具在这个sprint有效,在下个sprint就不一定有效了。
Sprint Planning 有的书籍叫“冲刺计划会议”,也有的叫“迭代规划会议”,这是sprint event里面开的第一个会议,你可以理解为传统项目的项目启动会,但是和项目启动会有又很大的区别。 Sprint Backlog。 一旦Sprint Goal确定,Sprint Backlog选定,剩下的事情就是敏捷团队大显身手的时候了。 image.png 三、Sprint Planning的要点 1、新的开始 敏捷开发是增量式的交付,可能由好几个迭代周期组成,上一个迭代周期结束,新的迭代周期开始。 图片 3.png 4、确定Sprint Goal 迭代目标 敏捷团队确定这次迭代的Sprint Goal 迭代目标,这样让开发团队更聚焦、专注。
Sprint Review 有的翻译为“冲刺评审会”,有的翻译为“迭代评审会”,其实都无所谓。它是在一个sprint快结束之际召开的。 一、Sprint Review概叙 Sprint Review的核心词是“Review”,但它不是不是让你把Sprint Review开成“回顾会”,这是很多敏捷教练刚带团队的时候容易犯的错误。 开Sprint Review会的目的是演示这个Sprint中自己的工作成果,对于功能性的产品增量进行审视并调整。 成功的分享是构建敏捷团队的重要工作。 SprintReviewMeeting.png 3、庆祝团队成果 Sprint Review是庆祝团队和个人在迭代过程中所取得成就的好时机。 在Sprint review会议上,我们还要排除下一个sprint的Product Backlog,因为下一个sprint马上就要开始了,当然,你也可以乘机给你的团队成员打气助威,大家一起在一下个sprint
敏捷开发迭代管理示例:迭代规划完成后,进入迭代看板,可以看到已规划的用户故事已分别放置在独立泳道中,泳道可横向对应用户故事和拆分的任务。 敏捷迭代规划:图片用户故事任务拆分:图片迭代执行:图片免费敏捷开发工具:常见的敏捷开发项目管理软件有很多,比如Leangoo领歌、Axosoft、Trello、Asana、Monday.com、Zenkit 、Sprint.ly、Smartsheet等。 这些项目管理软件有着不同的特点和功能,可以根据不同团队的需求选择适合的软件。 比如,Leangoo领歌是国产的免费的敏捷项目管理软件,支持包括小型团队敏捷开发,规模化敏捷SAFe,Scrum of Scrums大规模敏捷等敏捷开发方法,具有产品管理和项目管理的功能;Axosoft
一、为什么敏捷团队选择“轻量化Sprint Board”? 很多团队认为“迭代管理”就是用工具记录任务,但真正高效的敏捷落地需要解决几个关键痛点:任务状态是否透明:每个需求的推进阶段、阻塞原因、负责人是否一目了然? 敏捷转型初期的团队对于刚接触敏捷的团队,复杂工具会增加学习成本,轻量化Sprint Board简单易上手,能帮助团队快速建立迭代意识和协作习惯。 匹配团队成熟度”:敏捷转型初期可选择经典轻量化工具,快速建立协作习惯;流程稳定后可切换至敏捷专用工具,提升管理精细化程度;有定制化需求的团队可考虑开源方案。 在快速变化的市场环境中,以极简的管理方式实现高效的价值交付,正是Sprint Board赋予敏捷团队的核心竞争力。
敏捷项目管理与敏捷宣言 说到敏捷项目管理就不得不提到那十分出名的敏捷宣言。这篇文章我们就来简单地了解一下敏捷项目管理的出现和敏捷宣言说的是什么。不要有太多的压力哦,这篇文章还是非常轻松的。 传统项目管理 对于传统项目管理和敏捷项目管理的不同,我们可以列一个非常大的表出来,不过,这样列出来其实挺没意思的。 到最后我们学习完了敏捷相关的知识后,大家可以自己再回过头来想一想敏捷和传统项目管理的区别和联系都有哪些,这样对大家知识的掌握才更有好处。 VCUA时代 在敏捷中,有句名言:唯一不变的就是变化。这句话非常有意思,只有变化本身是我们这个世界上唯一不会发生变化的东西。要搞明白这个事情,我们还是再看下传统项目管理和软件开发中的问题。 总结 今天这篇文章我们从传统的项目管理说起,通过 VUCA时代 这样一个时代现象来引出敏捷出现的必要性,最后介绍了敏捷的灵魂:敏捷宣言。当然,敏捷宣言很简单,就四句话,也可以概括成四个词。
基础功能免费,性价比高暂不支持超 20 人以上的大型团队权限分级管理 Jira 冲刺规划:支持多冲刺并行管理,可设置冲刺目标与验收标准;2. 数据报表丰富,便于管理层复盘 学习成本高,需专人配置;基础版收费较高,小型团队性价比低 Trello看板核心:以卡片形式管理任务,支持自定义标签(如 “ A:需支持 “多冲刺并行管理”,推荐板栗看板或 Jira:可创建独立的冲刺看板,分别管理不同冲刺的任务,且能直观查看各冲刺进度,避免任务混淆。 A:从 “核心场景” 逐步拓展:先用工具管理 “任务分配与进度跟踪”,待团队适应后,再启用 “燃尽图”“冲刺复盘数据” 等功能,避免一次性堆砌过多功能导致成员抵触。 本质上,敏捷开发任务分配工具是 “Scrum 流程的载体”—— 当工具能无缝衔接 “冲刺规划→任务拆解→资源匹配→进度跟踪→迭代优化” 全流程时,团队才能真正摆脱 “任务混乱、进度失控” 的困境,实现效率翻倍
引言:敏捷绝非某一种特定的开发方法,它只是一种应对快速变化的需求的一种软件开发能力。敏捷本身只包含了《敏捷软件开发宣言》和《敏捷软件的十二条原则》两份文档。 这样的项目管理很混乱。 敏捷开发流程是一个标准的项目管理流程,是不能适用于所有的公司,但是适用大部分的公司,公司根据标准化流程去进行优化,不管是新增还是减少,只要适用于自己的公司那就是贵公司的敏捷流程。 6.软件是你的主要目标:软件开发的主要目标是以有效的方式,制造出满足投资者需要的软件,而不是制造无关的文档,无关的用于管理的工件,甚至无关的模型。 ,但是这样利于项目管理,一个团队共同为一个目标去奋斗。
Sprint指Scrum团队完成一定数量工作所需的短暂、固定的周期。Sprint是Scrum和敏捷的核心,找到正确的Sprint周期将帮助您的敏捷团队交付更高质量的产品。 Sprint使项目更易于管理,让团队更快、更频繁地交付高质量的工作,并使团队能够更灵活地适应变化。 许多人将Scrum的Sprint与敏捷软件开发联系起来,以至于不明就里的人将Scrum和敏捷当成是同一件事。但实际上,两者根本不是一回事儿。 如果管理不当,这可能会是一个极大的挑战,并且还会破坏整个过程。 确保团队对速度有很好的理解,并且要体现休假和团队会议等事项。 用Sprint Planning会议来充实需要完成工作的具体细节。 想了解更多关于研发管理、敏捷相关的知识,可登陆【Worktile敏捷博客】查看哦~
作者:叶朝萍 [1499392921893_7114_1499392923068.png] 背景 在近几年比较火的敏捷开发大背景下,我们的项目团队的需求管理,也一直在探寻着敏捷开发的轻量化管理的原则 ,并且由于我们团队采用了Feature team 的团队运作模式,所以版本的需求都是由各个FT 自己独立管理的方式,理想状态是,各FT 自己管理需求,自己去做质量管理,自己评估把控进度和最后版本的顺利发布 下面就来谈谈,咱们浏览器项目需求管理那些事 ~ 需求管理1.0 时代 --- FT 自管理+excel 规划表 我们知道,敏捷价值观中有一个是关于文档的,认为: [1499393074848_4910 [1499393465904_7859_1499393466807.png] 项目需求管理2.0时代 --- TAPD集中管理+需求评审 1、 需求的工具化管理:变excel的人工维护,为TAPD集中管理方式 当然,敏捷项目需求管理的方法,我们仍在不断总结和迭代优化中,希望大家也一起来多探讨更好的管理模式,期待更优的需求管理4.0 时代的到来!
,那么由项目经理作为敏捷教练;如果有多个小组则有多个Scrum Master ,简称SM,项目经理对每个敏捷小组和SM统筹管理。 二、Scrum实施过程中常用的5大Scrum管理工具/软件 敏捷开发中非常强调公开、透明、直接有效的沟通,这也是“可视化的管理工具”在敏捷开发中如此重要的原因之一。 这里分享国内外的5款顶级敏捷开发管理工具。 1、国内顶级 Scrum 管理工具PingCode 这是国内最好用的敏捷开发Scrum工具之一,曾在2021年获得由36氪发布的研发项目管理榜TOP1,被广泛用于敏捷开发项目管理。 、kanban/瀑布/敏捷项目管理、测试用例管理、缺陷管理、团队知识库、效能度量,与gitlab、jinkens、飞书等外部工具集成。
对团队或企业来说,敏捷能够通过快速迭代、改进来更好地为客户或终端用户交付价值。但有些团队在引入敏捷项目管理模式之后,团队管理层看了看埋头工作的团队,“唉? 二、怎样进行价值流管理?在敏捷项目中,我们应该如何减少浪费,实现利益最大化?这个问题的关键在于“价值的流动”。价值流管理是敏捷中的一个十分重要的实践,更是团队在持续改进、优化过程中的一项基本工作。 那我们应该如何来进行价值流管理呢?1)确认需要识别价值流的阶段首先我们需要明确要改进哪一阶段。我们可以绘产品全生命周期的价值流图,也可以为单独的某一阶段(如产品测试过程)绘制一个价值流图。 所以通过价值流管理,我们可以度量实际的价值流动效率,并提出改进目标,来推动整个项目管理过程的持续改善。
敏捷项目管理架构 Release(发布,单位为月) Sprint(冲刺,单位为周) Issue(问题)类型 Epic( 史诗) Story( 用户故事) Task(任务) Bug(故障 ) Jira创建Release(发布版本) ◆Release(版本)的时间跨度通常为1-3个月 ◆版本包含多个Sprint (冲刺) ◆Release 里会清晰定义需要完成的开发任务
风险管理 在 PMP 中,风险是一个重要的章节,并且有许多的过程,比如说我们要识别风险、进行定性定量分析、应对风险等,工具方面也有决策树、敏捷性分析等,最后还有一个风险应对和机会应对(PMP认为风险和机会是对应的 同时,在项目进行的过程中,也需要不断地管理风险,并追踪风险管理的成效。 对于风险管理这一块,其实我们可以借鉴 PMP 中的一些技术,比如说 风险概率矩阵 ,它就是根据风险的 等级 和可能出现的 概率 来制作的一张表。 这个东西其实有点偏财务和管理学方面的内容,在之前 【敏捷3.1】价值与价值驱动交付https://mp.weixin.qq.com/s/Dw763UK9Dy_jH8gYthBsZw 这篇文章中有提到过一点 风险的严重程度 其实呢,在敏捷中,风险管理其实是工作进度的一个驱动因素。因为团队会将高风险的活动移到迭代的早期,并将风险的缓解这些活动放入待开发项中。
首先建立一个Spring Boot Admin Server,只需要两步,非常简单
很多人都认为敏捷管理就是将每个sprint的功能交付,给出可用的软件即可,没有数据度量。其实这种理解是不正确的,敏捷项目管理也是有度量数据的,有哪些度量数据呢? 【Kevin聊敏捷】XP极限编程之5个价值 19.【Kevin聊敏捷】XP极限编程之概述 18.【Kevin聊敏捷】敏捷项目管理之Sprint Retrospective 迭代回顾会 17. 【Kevin聊敏捷】敏捷项目管理之Sprint Review 迭代评审会 16.【Kevin聊敏捷】敏捷项目管理之Daily Scrum 每日站立会 15. 【Kevin聊敏捷】敏捷项目管理之Sprint Planning 迭代规划会 14.【Kevin聊敏捷】敏捷项目管理之Scrum Events 敏捷活动 13. 【Kevin聊敏捷】敏捷项目管理之Scrum三大支柱 08.【Kevin聊敏捷】敏捷项目管理之Scrum价值 07.【Kevin聊敏捷】敏捷项目管理之Scrum 06.
在敏捷项目管理中,我们采用“调整性行为”来说明应该采纳的一些正确做法(其中之一便有可能是纠正计划本身)。 在关于敏捷处理原则的文件中—包括敏捷宣言(Agile Manifesto, AM)和相互依赖宣言(Declaration of Interdependence, DOI)—有对怎样随机调整做出的五条主要说明 (4)当管理、客户以及技术等发生变化时,团队能否做出有效的调整和应对. 调节项目中的已知和未知 哈佛商学院教授罗布·奥斯丁(Rob Austin)和同事李德文(Lee Devin)共同执笔发表了《艺术性管理》(Artful Making)一书。 也就是说,计划或调整,不能说孰对孰错,管理者应根据项目自身的具体情况、具体条件,作出最恰当的选择。
一、敏捷的框架 对比PMP项目管理过程的五大阶段:启动、规划、执行、监控、收尾,敏捷项目管理同样可以把整个框架分为五个阶段,分别是:构想、推测、探索、适应和结束阶段。 敏捷项目管理阶段.jpeg 二、敏捷的常见问题解答 (一)、对于敏捷中文档的度,我们应该如何把握?什么样的文档是需要的,什么样的文档可裁剪? 答: 有价值的文档是需要的。什么样的文档有价值? 对于类似的文档,在敏捷中认为都是可以裁剪的,前提是确保输出的可交付成果不变形,满足预期的标准和要求。 (二)、敏捷宣言提出"客户合作胜过合同谈判",针对不断变更的需求如何签订敏捷的合同? 答: 敏捷的合同需要签订,但是签订合同的方式与传统的瀑布式合同签订方式稍有不同。根据DSDM的方法,敏捷合同的生效必须是业务人员与开发人员一起工作。 (三)、敏捷拥抱变化,是否在任何一个时间点客户端都可以提出变更 敏捷项目聚焦于客户价值,所以只要是可以给客户带来竞争优势的更变,都可以进行,所以在任何一个时间点都应该允许客户提出变更。
Scrum Events 敏捷活动包括四个活动:1、Sprint Planning(冲刺计划会) 2、Daily Scrum(每日站立会) 3、Sprint Review (冲刺评审会) 4、Sprint 一、The Sprint 迭代 一个迭代周期要小于30天,现在最流行的迭代时间是两周。主要是为了开发一个潜在可用的可发版的产品增量。 保持固定的迭代周期的好处就是,使得敏捷团队有固定的节奏感(= =#听起来是不是有点玄乎)。用专业的话术来解释就是:太长的迭代周期会增加复杂性,不容易聚焦,对干系人的反馈会拉长,甚至延期。 image.png 二、Sprint Rules 迭代规则 在敏捷管理-Scrum过程中也要遵循一定的迭代规则: 迭代过程中不要中途替换迭代目标 不应该中途降低跌倒目标价值 目标范围也许会被重新调整 最开始的一个迭代周期不仅仅有 、产品待办事宜 产品待办事项 敏捷团队、干系人 2小时 冲刺回顾会 迭代 迭代待办事项、工具等 敏捷团队 1.5小时 “IMG_8800”的副本.jpg ---- image.png
培训那些没有完全采用或者理解敏捷管理的自组织团队 可以明显的看出,对于开发团队来说,Scrum Master敏捷教练起到的不是传统项目的项目经理的作用,他更多的是作为一个教练的角色存在。 image.png 2、敏捷教练对于产品负责人来说 找到一种可以有效管理产品工作项(Product Backlog)的技术 帮助开发团队更好/更清晰地理解产品工作项(Product Backlog image.png 3、敏捷教练对于组织来说 是采用敏捷管理组织的领导和教练 在组织中推动敏捷管理计划 帮助员工和干系人理解敏捷管理 与其他敏捷教练增加敏捷管理在组织中的有效性 可以看出在组织中,敏捷教练的作用主要是推广敏捷管理,宣传敏捷管理的价值。 让组织的员工和干系人用上敏捷管理。同时优化敏捷管理在组织中的流程。 image.png ---- image.png