你可以理解为是当前sprint最后一个会议了,所以很多人认为是总结会,也可以这么理解。参与的人员主要是敏捷团队成员,时长不超过1.5小时。 二、Sprint Retrospective目的 目的主要是让敏捷团队成员自省同时在下个sprint的时候提升。同时总结一些事情来做整理,我们都没有去做。 3.3 流程 敏捷管理不是不要流程,而是说要将流程尽量简化,改要的流程还是要的,所以在这过程中,我们也要回顾我们哪些流程用得好,继续保留,哪些流程不行,需要改进或者遗弃。 确实,在我们做敏捷管理的过程中,会用上大大小小的工具来提高效率,但是,你会发现,有一些工具在这个sprint有效,在下个sprint就不一定有效了。 OIP (2).jpeg 4.3 产生见解 收集到了数据只是第一步,如果顺利,到此为止我们就能收集到大量的、反应真实情况的好的和需要改进的点。接下来我们需要整理了。
image.png 2、输出Sprint Goal Sprint Goal就是我们这次迭代的目标,这个非常重要,有利于开发团队的聚焦,在每日例会的时候,SM都会问开发团队这次我们的迭代目标是什么? 这个其实就是团队定义好了本次的Sprint Goal之后,根据开发团队的迭代速度和这次迭代的迭代周期(例如2周到4周),从Product Backlog 根据优先级选出可以完成的需求,这些需求的集合就叫做 一旦Sprint Goal确定,Sprint Backlog选定,剩下的事情就是敏捷团队大显身手的时候了。 image.png 三、Sprint Planning的要点 1、新的开始 敏捷开发是增量式的交付,可能由好几个迭代周期组成,上一个迭代周期结束,新的迭代周期开始。 图片 3.png 4、确定Sprint Goal 迭代目标 敏捷团队确定这次迭代的Sprint Goal 迭代目标,这样让开发团队更聚焦、专注。
一、Sprint Review概叙 Sprint Review的核心词是“Review”,但它不是不是让你把Sprint Review开成“回顾会”,这是很多敏捷教练刚带团队的时候容易犯的错误。 开Sprint Review会的目的是演示这个Sprint中自己的工作成果,对于功能性的产品增量进行审视并调整。 2、会议的氛围 我们尽量保持Sprint评审会的轻松随意氛围。团队成员们会聚集在桌子周围进行非正式的演示,讲述自己在本次迭代中完成的工作。在这期间团队成员可以相互提问、尝试新的功能并提供反馈。 成功的分享是构建敏捷团队的重要工作。 SprintReviewMeeting.png 3、庆祝团队成果 Sprint Review是庆祝团队和个人在迭代过程中所取得成就的好时机。 在Sprint review会议上,我们还要排除下一个sprint的Product Backlog,因为下一个sprint马上就要开始了,当然,你也可以乘机给你的团队成员打气助威,大家一起在一下个sprint
2、加强协作。在敏捷开发过程中,团队成员需要密切协作,及时交流,相互帮助,共同解决问题。3、简化流程。敏捷开发强调简化流程,避免繁琐的流程阻碍开发进度。4、频繁沟通。 敏捷开发迭代管理示例:迭代规划完成后,进入迭代看板,可以看到已规划的用户故事已分别放置在独立泳道中,泳道可横向对应用户故事和拆分的任务。 敏捷迭代规划:图片用户故事任务拆分:图片迭代执行:图片免费敏捷开发工具:常见的敏捷开发项目管理软件有很多,比如Leangoo领歌、Axosoft、Trello、Asana、Monday.com、Zenkit 、Sprint.ly、Smartsheet等。 比如,Leangoo领歌是国产的免费的敏捷项目管理软件,支持包括小型团队敏捷开发,规模化敏捷SAFe,Scrum of Scrums大规模敏捷等敏捷开发方法,具有产品管理和项目管理的功能;Axosoft
2、即使在项目开发的后期,仍欢迎对需求提出变更。敏捷过程通过拥抱变化,帮助客户创造竞争优势。 3、要不断交付可用的软件,周期从几周到几个月不等,且越短越好。 对于传统项目管理而言,变通通常被认为是负面的,这意味着项目范围蔓延和偏离了项目的计划,需要引发变更成本。所以传统项目中变更控制流程非常严格,只有最高优先级的更变可以被批准。 在传统项目中,项目团队大量的时间和精力都用在记录和管理变更请求上。 在软件项目或者其他类型的有高变更比率的项目而言,严格的变更管理流程会带来很多问题。 相比而言,敏捷项目管理允许变更的发生,比如极限变成(XP)提倡"拥抱变化"。敏捷使用轻便、高可视化的方法来处理待办事项的优先级排序的变更。 敏捷方法主张将团队从微观管理和甘特图中的任务式管理中脱离出来,聚焦工作技巧和团队协作从而提高生产率。 知识性项目也包含有特殊经验和技能的成员。
本文提出 Sprint Loop Framework(SLF)——用敏捷 Sprint 的方式设计 Loop,让每个阶段有独立的验收标准、约束边界和退出策略。 它把敏捷开发的 Sprint 理念和 Loop Engineering 结合起来。 原则 2:每个 Sprint 独立设计四要素 每个 Sprint 需要明确定义: Skills(Agent 需要知道什么)——新增的技术知识 + 继承自之前 Sprint 的知识 Harness(Agent 项目拆分 12 个 Sprint: Sprint 1-2: 用户模块 注册、登录、JWT、个人信息 Sprint 3-4: 商品模块 CRUD、分类、搜索、SKU Sprint 5- 11-12: 管理后台 审核、订单管理、报表 以 Sprint 1 为例,看看实际文件是什么。
一、为什么敏捷团队选择“轻量化Sprint Board”? 、符合交付标准的任务,形成迭代成果任务的精细化拆解与流转让迭代执行更有序,需规范任务管理方式:任务颗粒度控制:遵循“2-8小时”原则,将大需求拆解为可独立完成的小任务,避免任务周期过长导致进度失控任务信息标准化 匹配团队成熟度”:敏捷转型初期可选择经典轻量化工具,快速建立协作习惯;流程稳定后可切换至敏捷专用工具,提升管理精细化程度;有定制化需求的团队可考虑开源方案。 Q2:团队成员不及时更新任务状态,导致看板数据失真怎么办? 在快速变化的市场环境中,以极简的管理方式实现高效的价值交付,正是Sprint Board赋予敏捷团队的核心竞争力。
敏捷项目管理与敏捷宣言 说到敏捷项目管理就不得不提到那十分出名的敏捷宣言。这篇文章我们就来简单地了解一下敏捷项目管理的出现和敏捷宣言说的是什么。不要有太多的压力哦,这篇文章还是非常轻松的。 传统项目管理 对于传统项目管理和敏捷项目管理的不同,我们可以列一个非常大的表出来,不过,这样列出来其实挺没意思的。 到最后我们学习完了敏捷相关的知识后,大家可以自己再回过头来想一想敏捷和传统项目管理的区别和联系都有哪些,这样对大家知识的掌握才更有好处。 VCUA时代 在敏捷中,有句名言:唯一不变的就是变化。这句话非常有意思,只有变化本身是我们这个世界上唯一不会发生变化的东西。要搞明白这个事情,我们还是再看下传统项目管理和软件开发中的问题。 总结 今天这篇文章我们从传统的项目管理说起,通过 VUCA时代 这样一个时代现象来引出敏捷出现的必要性,最后介绍了敏捷的灵魂:敏捷宣言。当然,敏捷宣言很简单,就四句话,也可以概括成四个词。
所以D不对 2、在一次迭代计划会议上,团队建议进行变更,增加产品价值,但将会产生额外的工作并影响进度计划,敏捷团队领导应该怎么做? 敏捷项目管理师应该怎么做? 敏捷团队领导者有一个职责就是确保在团队运作中保持持续的愿景 17、有3个团队目标正处于一个为期2周的Sprint的第8天。团队速度为30。有20个故事点已经完成,但团队只能额外再完成6个故事点。 分析之后,团队成员确定将至少需要2周时间来解决这个问题。该名团队成员应该怎么做? 题目中说的是客户认为敏捷流程有缺陷,可能不理解敏捷,所以可以开展培训。 44、敏捷团队已经开完Sprint计划会议,目前正处于一个为期两周的Sprint会议的第六天。团队应该集中精力做什么?
基础功能免费,性价比高暂不支持超 20 人以上的大型团队权限分级管理 Jira 冲刺规划:支持多冲刺并行管理,可设置冲刺目标与验收标准;2. 并关联所有相关任务;2. Q2:团队同时推进 2 个冲刺(如版本 1.0 收尾 + 2.0 开发),工具需满足什么需求? A:需支持 “多冲刺并行管理”,推荐板栗看板或 Jira:可创建独立的冲刺看板,分别管理不同冲刺的任务,且能直观查看各冲刺进度,避免任务混淆。 本质上,敏捷开发任务分配工具是 “Scrum 流程的载体”—— 当工具能无缝衔接 “冲刺规划→任务拆解→资源匹配→进度跟踪→迭代优化” 全流程时,团队才能真正摆脱 “任务混乱、进度失控” 的困境,实现效率翻倍
这样的项目管理很混乱。 敏捷开发流程是一个标准的项目管理流程,是不能适用于所有的公司,但是适用大部分的公司,公司根据标准化流程去进行优化,不管是新增还是减少,只要适用于自己的公司那就是贵公司的敏捷流程。 2.拥抱变化:需求时刻在变,人们对于需求的理解也时刻在变。项目进行中,Project stakeholder可能变化,会有新人加入,也会有旧人离开。 敏捷迭代: 1.迭代:包含了晨会、单元测试、codereview、测试用例评审、迭代演示(项目过大的时候会分为好几个迭代) 2.交付:首先测试完成后,产品进行验收,是否符合产品的需求。 ,但是这样利于项目管理,一个团队共同为一个目标去奋斗。
对团队或企业来说,敏捷能够通过快速迭代、改进来更好地为客户或终端用户交付价值。但有些团队在引入敏捷项目管理模式之后,团队管理层看了看埋头工作的团队,“唉? 二、怎样进行价值流管理?在敏捷项目中,我们应该如何减少浪费,实现利益最大化?这个问题的关键在于“价值的流动”。价值流管理是敏捷中的一个十分重要的实践,更是团队在持续改进、优化过程中的一项基本工作。 进行广告需求分析,用时1天;设计创意方案,用时2天;等待小组评审方案,用时1天;等待创意总监评审方案,用时2天;等待方案拍摄启动,用时1天;开始广告拍摄,用时4天;进行广告剪辑,用时3天;等待小组评审广告视频 ,用时1天;等待创意总监评审方案,用时2天;等待客户反馈方案,用时3天;修改广告方案,用时2天;交付最终方案,用时0.5天。 所以通过价值流管理,我们可以度量实际的价值流动效率,并提出改进目标,来推动整个项目管理过程的持续改善。
作者:叶朝萍 [1499392921893_7114_1499392923068.png] 背景 在近几年比较火的敏捷开发大背景下,我们的项目团队的需求管理,也一直在探寻着敏捷开发的轻量化管理的原则 下面就来谈谈,咱们浏览器项目需求管理那些事 ~ 需求管理1.0 时代 --- FT 自管理+excel 规划表 我们知道,敏捷价值观中有一个是关于文档的,认为: [1499393074848_4910 2、需求评审机制:设立产品版本规划管理委员会。建立需求评审机制,由这个专门的需求决策者来对每个版本规划的需求质量和范围进行评审确认。 2、 我们将产品管理委员会对需求的评审时间,延后到合流阶段,建立了合流评审的机制。 当然,敏捷项目需求管理的方法,我们仍在不断总结和迭代优化中,希望大家也一起来多探讨更好的管理模式,期待更优的需求管理4.0 时代的到来!
敏捷项目管理架构 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 这篇文章中有提到过一点 风险的严重程度 其实呢,在敏捷中,风险管理其实是工作进度的一个驱动因素。因为团队会将高风险的活动移到迭代的早期,并将风险的缓解这些活动放入待开发项中。
第一份列出上一次Sprint开始时的产品Backlog 2. 第二份为新Sprint开始时的产品Backlog 3. 第三份是“变更报告”,详细列出前两份报告的差别 4. Sprint中发生及Sprint审核的情况 2. 项目针对Sprint审核结果所做的适应调整 3. 未来Sprint重构的原因 4. 发布日期或内容重新制定的原因 5. 2、组建敏捷小组(Scrum Team) 一个项目团队可以有多个敏捷小组,负责产品中一个功能模块的开发,比如这个组开发前端界面,这个组开发支付功能,再有一个组开发社交功能。 这里分享国内外的5款顶级敏捷开发管理工具。 1、国内顶级 Scrum 管理工具PingCode 这是国内最好用的敏捷开发Scrum工具之一,曾在2021年获得由36氪发布的研发项目管理榜TOP1,被广泛用于敏捷开发项目管理。
很多人都认为敏捷管理就是将每个sprint的功能交付,给出可用的软件即可,没有数据度量。其实这种理解是不正确的,敏捷项目管理也是有度量数据的,有哪些度量数据呢? 【Kevin聊敏捷】精益敏捷(Lean Agile)导论 25.【Kevin聊敏捷】极限编程XP2实践 24.【Kevin聊敏捷】XP极限编程之12最佳实践(四) 23. 【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.
在敏捷项目管理中,我们采用“调整性行为”来说明应该采纳的一些正确做法(其中之一便有可能是纠正计划本身)。 在关于敏捷处理原则的文件中—包括敏捷宣言(Agile Manifesto, AM)和相互依赖宣言(Declaration of Interdependence, DOI)—有对怎样随机调整做出的五条主要说明 (2)产品的质量目标—可靠性和兼容性—是否达成. (3)在可接受的限制条件下,项目进展是否令人满意. (4)当管理、客户以及技术等发生变化时,团队能否做出有效的调整和应对. 调节项目中的已知和未知 哈佛商学院教授罗布·奥斯丁(Rob Austin)和同事李德文(Lee Devin)共同执笔发表了《艺术性管理》(Artful Making)一书。 也就是说,计划或调整,不能说孰对孰错,管理者应根据项目自身的具体情况、具体条件,作出最恰当的选择。
一、敏捷的框架 对比PMP项目管理过程的五大阶段:启动、规划、执行、监控、收尾,敏捷项目管理同样可以把整个框架分为五个阶段,分别是:构想、推测、探索、适应和结束阶段。 1、构想:确定产品的构想、项目范围、项目团队以及团队共同的工作方式 2、推测:制定基于功能发布计划、里程碑和迭代计划,确保交付构想的产品 3、探索:在短期内提供经测试的功能,不断致力于减少项目风险和不确定性 敏捷项目管理阶段.jpeg 二、敏捷的常见问题解答 (一)、对于敏捷中文档的度,我们应该如何把握?什么样的文档是需要的,什么样的文档可裁剪? 答: 有价值的文档是需要的。什么样的文档有价值? 对于类似的文档,在敏捷中认为都是可以裁剪的,前提是确保输出的可交付成果不变形,满足预期的标准和要求。 (二)、敏捷宣言提出"客户合作胜过合同谈判",针对不断变更的需求如何签订敏捷的合同? 答: 敏捷的合同需要签订,但是签订合同的方式与传统的瀑布式合同签订方式稍有不同。根据DSDM的方法,敏捷合同的生效必须是业务人员与开发人员一起工作。
Scrum Events 敏捷活动包括四个活动:1、Sprint Planning(冲刺计划会) 2、Daily Scrum(每日站立会) 3、Sprint Review (冲刺评审会) 4、Sprint 一、The Sprint 迭代 一个迭代周期要小于30天,现在最流行的迭代时间是两周。主要是为了开发一个潜在可用的可发版的产品增量。 迭代周期是固定的,不能说这一次的这一次的迭代周期是3周,下次的迭代周期就是4周,再下一次的迭代周期就是2周。 保持固定的迭代周期的好处就是,使得敏捷团队有固定的节奏感(= =#听起来是不是有点玄乎)。 image.png 二、Sprint Rules 迭代规则 在敏捷管理-Scrum过程中也要遵循一定的迭代规则: 迭代过程中不要中途替换迭代目标 不应该中途降低跌倒目标价值 目标范围也许会被重新调整 最开始的一个迭代周期不仅仅有 、产品待办事宜 产品待办事项 敏捷团队、干系人 2小时 冲刺回顾会 迭代 迭代待办事项、工具等 敏捷团队 1.5小时 “IMG_8800”的副本.jpg ---- image.png