你可以理解为是当前sprint最后一个会议了,所以很多人认为是总结会,也可以这么理解。参与的人员主要是敏捷团队成员,时长不超过1.5小时。 二、Sprint Retrospective目的 目的主要是让敏捷团队成员自省同时在下个sprint的时候提升。同时总结一些事情来做整理,我们都没有去做。 3.3 流程 敏捷管理不是不要流程,而是说要将流程尽量简化,改要的流程还是要的,所以在这过程中,我们也要回顾我们哪些流程用得好,继续保留,哪些流程不行,需要改进或者遗弃。 确实,在我们做敏捷管理的过程中,会用上大大小小的工具来提高效率,但是,你会发现,有一些工具在这个sprint有效,在下个sprint就不一定有效了。 4.4 确定改进项 选取最值得改进的几项(一般不超过3项),同时找到解决的方案,在一下个sprint过程中进行改进,当然不一定一个sprint就可以改进完。
image.png 3、输出Sprint Backlog Sprint Backlog(简称SB) 《= =# Scrum里面的简称都好奇葩,不是SB就是SM。》 一旦Sprint Goal确定,Sprint Backlog选定,剩下的事情就是敏捷团队大显身手的时候了。 image.png 三、Sprint Planning的要点 1、新的开始 敏捷开发是增量式的交付,可能由好几个迭代周期组成,上一个迭代周期结束,新的迭代周期开始。 定义优先级 Product Owner产品负责人根据产品的价值对 Product Backlog产品待办事项进行优先级排序,如图六所示,高价值的需求放在最上面,价值低的需求放在最下面, 图片 2.png 3、 图片 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
在敏捷开发过程中,团队成员需要密切协作,及时交流,相互帮助,共同解决问题。3、简化流程。敏捷开发强调简化流程,避免繁琐的流程阻碍开发进度。4、频繁沟通。 敏捷开发迭代管理示例:迭代规划完成后,进入迭代看板,可以看到已规划的用户故事已分别放置在独立泳道中,泳道可横向对应用户故事和拆分的任务。 敏捷迭代规划:图片用户故事任务拆分:图片迭代执行:图片免费敏捷开发工具:常见的敏捷开发项目管理软件有很多,比如Leangoo领歌、Axosoft、Trello、Asana、Monday.com、Zenkit 、Sprint.ly、Smartsheet等。 比如,Leangoo领歌是国产的免费的敏捷项目管理软件,支持包括小型团队敏捷开发,规模化敏捷SAFe,Scrum of Scrums大规模敏捷等敏捷开发方法,具有产品管理和项目管理的功能;Axosoft
一、敏捷的框架 对比PMP项目管理过程的五大阶段:启动、规划、执行、监控、收尾,敏捷项目管理同样可以把整个框架分为五个阶段,分别是:构想、推测、探索、适应和结束阶段。 1、构想:确定产品的构想、项目范围、项目团队以及团队共同的工作方式 2、推测:制定基于功能发布计划、里程碑和迭代计划,确保交付构想的产品 3、探索:在短期内提供经测试的功能,不断致力于减少项目风险和不确定性 敏捷项目管理阶段.jpeg 二、敏捷的常见问题解答 (一)、对于敏捷中文档的度,我们应该如何把握?什么样的文档是需要的,什么样的文档可裁剪? 答: 有价值的文档是需要的。什么样的文档有价值? 对于类似的文档,在敏捷中认为都是可以裁剪的,前提是确保输出的可交付成果不变形,满足预期的标准和要求。 (二)、敏捷宣言提出"客户合作胜过合同谈判",针对不断变更的需求如何签订敏捷的合同? 答: 敏捷的合同需要签订,但是签订合同的方式与传统的瀑布式合同签订方式稍有不同。根据DSDM的方法,敏捷合同的生效必须是业务人员与开发人员一起工作。
但面对 30 个模块、3 年周期的复杂项目,一个 Loop 跑到底会怎样?答案是:Sprint 6 之后,Loop 本身会成为瓶颈。 本文提出 Sprint Loop Framework(SLF)——用敏捷 Sprint 的方式设计 Loop,让每个阶段有独立的验收标准、约束边界和退出策略。 它把敏捷开发的 Sprint 理念和 Loop Engineering 结合起来。 11-12: 管理后台 审核、订单管理、报表 以 Sprint 1 为例,看看实际文件是什么。 bcrypt 加密 / JWT_SECRET 从环境变量取 / SQL 参数化 规范: 统一响应 {code, data, message} / 蛇形命名 范围: 只做注册+登录,不做个人信息管理和地址管理
一、为什么敏捷团队选择“轻量化Sprint Board”? 敏捷转型初期的团队对于刚接触敏捷的团队,复杂工具会增加学习成本,轻量化Sprint Board简单易上手,能帮助团队快速建立迭代意识和协作习惯。 匹配团队成熟度”:敏捷转型初期可选择经典轻量化工具,快速建立协作习惯;流程稳定后可切换至敏捷专用工具,提升管理精细化程度;有定制化需求的团队可考虑开源方案。 Q3:需求变更频繁,导致Sprint Board任务频繁调整,影响迭代节奏怎么办?A:轻量化Sprint Board的优势正是灵活适配变更。 在快速变化的市场环境中,以极简的管理方式实现高效的价值交付,正是Sprint Board赋予敏捷团队的核心竞争力。
敏捷项目管理与敏捷宣言 说到敏捷项目管理就不得不提到那十分出名的敏捷宣言。这篇文章我们就来简单地了解一下敏捷项目管理的出现和敏捷宣言说的是什么。不要有太多的压力哦,这篇文章还是非常轻松的。 传统项目管理 对于传统项目管理和敏捷项目管理的不同,我们可以列一个非常大的表出来,不过,这样列出来其实挺没意思的。 到最后我们学习完了敏捷相关的知识后,大家可以自己再回过头来想一想敏捷和传统项目管理的区别和联系都有哪些,这样对大家知识的掌握才更有好处。 VCUA时代 在敏捷中,有句名言:唯一不变的就是变化。这句话非常有意思,只有变化本身是我们这个世界上唯一不会发生变化的东西。要搞明白这个事情,我们还是再看下传统项目管理和软件开发中的问题。 总结 今天这篇文章我们从传统的项目管理说起,通过 VUCA时代 这样一个时代现象来引出敏捷出现的必要性,最后介绍了敏捷的灵魂:敏捷宣言。当然,敏捷宣言很简单,就四句话,也可以概括成四个词。
发现问题后应该分析问题,找到解决方案,而不是直接推迟日期,所以D不正确 11、团队完成了两个包含客户价值功能的的sprint。为了估算,敏捷管理专业人士需要识别用户故事未知方面的信息。 13、敏捷管理专业人士注意到产品待办事项上一个新的故事很模糊,缺少验收标准。敏捷管理专业人士应在sprint周期中的那个时间点要求产品负责人提供更多详情? 敏捷项目管理师应该怎么做? 敏捷管理专业人士应该怎么做? A 最后几个sprint中的最高速度 B 最后几个sprint中的最低速度 C 最后几个sprint中的平均速度 D 团队迄今取得的最佳速度 答案 C 本题考点是"适应性计划"中的"敏捷的估算"。
基础功能免费,性价比高暂不支持超 20 人以上的大型团队权限分级管理 Jira 冲刺规划:支持多冲刺并行管理,可设置冲刺目标与验收标准;2. 数据报表丰富,便于管理层复盘 学习成本高,需专人配置;基础版收费较高,小型团队性价比低 Trello看板核心:以卡片形式管理任务,支持自定义标签(如 “ 自动化规则减少重复操作;3. A:需支持 “多冲刺并行管理”,推荐板栗看板或 Jira:可创建独立的冲刺看板,分别管理不同冲刺的任务,且能直观查看各冲刺进度,避免任务混淆。 本质上,敏捷开发任务分配工具是 “Scrum 流程的载体”—— 当工具能无缝衔接 “冲刺规划→任务拆解→资源匹配→进度跟踪→迭代优化” 全流程时,团队才能真正摆脱 “任务混乱、进度失控” 的困境,实现效率翻倍
这样的项目管理很混乱。 敏捷开发流程是一个标准的项目管理流程,是不能适用于所有的公司,但是适用大部分的公司,公司根据标准化流程去进行优化,不管是新增还是减少,只要适用于自己的公司那就是贵公司的敏捷流程。 3.UI评审:产品只是把功能设计出来,交互与页面的展示就是要靠UI来设计。 3.发布:产品验收后就可以进行发布了 4.回顾:回顾本次迭代或者本次项目中做的不好的、好的点进行总结,好的点要继续保持,不好的点可以要进行总结,下次迭代改进 以上就是我司的敏捷开发流程,执行下来肯定有很多困难与不适应 ,但是这样利于项目管理,一个团队共同为一个目标去奋斗。
对团队或企业来说,敏捷能够通过快速迭代、改进来更好地为客户或终端用户交付价值。但有些团队在引入敏捷项目管理模式之后,团队管理层看了看埋头工作的团队,“唉? 二、怎样进行价值流管理?在敏捷项目中,我们应该如何减少浪费,实现利益最大化?这个问题的关键在于“价值的流动”。价值流管理是敏捷中的一个十分重要的实践,更是团队在持续改进、优化过程中的一项基本工作。 3)预估每一步骤耗时根据我们的实际情况对每一个步骤的耗时进行预估,并标记出来。4)区别增值活动与非增值活动什么是增值活动与非增值活动?其实简单来讲,就是这个环节对客户来说能否交付价值。 ,用时1天;等待创意总监评审方案,用时2天;等待客户反馈方案,用时3天;修改广告方案,用时2天;交付最终方案,用时0.5天。 所以通过价值流管理,我们可以度量实际的价值流动效率,并提出改进目标,来推动整个项目管理过程的持续改善。
作者:叶朝萍 [1499392921893_7114_1499392923068.png] 背景 在近几年比较火的敏捷开发大背景下,我们的项目团队的需求管理,也一直在探寻着敏捷开发的轻量化管理的原则 下面就来谈谈,咱们浏览器项目需求管理那些事 ~ 需求管理1.0 时代 --- FT 自管理+excel 规划表 我们知道,敏捷价值观中有一个是关于文档的,认为: [1499393074848_4910 [1499393465904_7859_1499393466807.png] 项目需求管理2.0时代 --- TAPD集中管理+需求评审 1、 需求的工具化管理:变excel的人工维护,为TAPD集中管理方式 2642_1499393677121.png] 经过一段时间的运作,我们来看下实际的效果: (1) 版本从延期不可控 到 逐步可控 再到基本无延期; (2)需求变更逐步改善,变更率下降了到67%; (3) 当然,敏捷项目需求管理的方法,我们仍在不断总结和迭代优化中,希望大家也一起来多探讨更好的管理模式,期待更优的需求管理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 这篇文章中有提到过一点 风险的严重程度 其实呢,在敏捷中,风险管理其实是工作进度的一个驱动因素。因为团队会将高风险的活动移到迭代的早期,并将风险的缓解这些活动放入待开发项中。
3. ScrumMaster使团队在Sprint过程中免受干预 4. 产品负责人谈论业务需求和目标,团队则讲技术。 第一份列出上一次Sprint开始时的产品Backlog 2. 第二份为新Sprint开始时的产品Backlog 3. 第三份是“变更报告”,详细列出前两份报告的差别 4. Sprint中发生及Sprint审核的情况 2. 项目针对Sprint审核结果所做的适应调整 3. 未来Sprint重构的原因 4. 发布日期或内容重新制定的原因 5. 3、确定敏捷教练(Scrum Master) 敏捷教练的作用是对成员进行敏捷培训,做好工作进度的管控,优化项目流程,解决成员遇到的阻碍,最终目的是提高整个敏捷小组的工作效率,保证顺利交付 如果团队只有一个敏捷小组 6、冲刺规划会 每个迭代周期就是一个Sprint,也就是冲刺。冲刺周期都是固定的,一般是1-3周。在冲刺规划会上,团队成员、敏捷教练和产品负责人坐在一起,规划冲刺的内容。
很多人都认为敏捷管理就是将每个sprint的功能交付,给出可用的软件即可,没有数据度量。其实这种理解是不正确的,敏捷项目管理也是有度量数据的,有哪些度量数据呢? 【Kevin聊敏捷】看板Kanban的8目标和3原则 28.【Kevin聊敏捷】看板Kanban-概述 27.【Kevin聊敏捷】精益敏捷(Lean Agile)的5个原则 26. 【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)—有对怎样随机调整做出的五条主要说明 (3)在可接受的限制条件下,项目进展是否令人满意. (4)当管理、客户以及技术等发生变化时,团队能否做出有效的调整和应对. 调节项目中的已知和未知 哈佛商学院教授罗布·奥斯丁(Rob Austin)和同事李德文(Lee Devin)共同执笔发表了《艺术性管理》(Artful Making)一书。 也就是说,计划或调整,不能说孰对孰错,管理者应根据项目自身的具体情况、具体条件,作出最恰当的选择。
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
培训那些没有完全采用或者理解敏捷管理的自组织团队 可以明显的看出,对于开发团队来说,Scrum Master敏捷教练起到的不是传统项目的项目经理的作用,他更多的是作为一个教练的角色存在。 image.png 2、敏捷教练对于产品负责人来说 找到一种可以有效管理产品工作项(Product Backlog)的技术 帮助开发团队更好/更清晰地理解产品工作项(Product Backlog image.png 3、敏捷教练对于组织来说 是采用敏捷管理组织的领导和教练 在组织中推动敏捷管理计划 帮助员工和干系人理解敏捷管理 与其他敏捷教练增加敏捷管理在组织中的有效性 可以看出在组织中,敏捷教练的作用主要是推广敏捷管理,宣传敏捷管理的价值。 让组织的员工和干系人用上敏捷管理。同时优化敏捷管理在组织中的流程。 image.png ---- image.png