- 综合排序
- 最热优先
- 最新优先
- 来自专栏敏捷管理
【Kevin聊敏捷】敏捷项目管理之Sprint Retrospective 迭代回顾会
你可以理解为是当前sprint最后一个会议了，所以很多人认为是总结会，也可以这么理解。参与的人员主要是敏捷团队成员，时长不超过1.5小时。 二、Sprint Retrospective目的 目的主要是让敏捷团队成员自省同时在下个sprint的时候提升。同时总结一些事情来做整理，我们都没有去做。 SprintRetrospectiveMeetingsDosAndDonts.png 三、回顾的内容 3.1 团队成员 看看敏捷团队的成员在这个sprint过程中有没有做的好的地方或者不好的地方，那么在下一个 3.3 流程 敏捷管理不是不要流程，而是说要将流程尽量简化，改要的流程还是要的，所以在这过程中，我们也要回顾我们哪些流程用得好，继续保留，哪些流程不行，需要改进或者遗弃。 确实，在我们做敏捷管理的过程中，会用上大大小小的工具来提高效率，但是，你会发现，有一些工具在这个sprint有效，在下个sprint就不一定有效了。
2.5K00发布于 2020-06-27 - 来自专栏敏捷管理
【Kevin聊敏捷】敏捷项目管理之Sprint Planning 迭代规划会
Sprint Planning 有的书籍叫“冲刺计划会议”，也有的叫“迭代规划会议”，这是sprint event里面开的第一个会议，你可以理解为传统项目的项目启动会，但是和项目启动会有又很大的区别。 Sprint Backlog。 一旦Sprint Goal确定，Sprint Backlog选定，剩下的事情就是敏捷团队大显身手的时候了。 image.png 三、Sprint Planning的要点 1、新的开始 敏捷开发是增量式的交付，可能由好几个迭代周期组成，上一个迭代周期结束，新的迭代周期开始。 图片 3.png 4、确定Sprint Goal 迭代目标 敏捷团队确定这次迭代的Sprint Goal 迭代目标，这样让开发团队更聚焦、专注。
2.9K22发布于 2019-06-07 - 来自专栏敏捷管理
【Kevin聊敏捷】敏捷项目管理之Sprint Review 迭代评审会
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
3K00发布于 2020-06-27 - 来自专栏杂七杂八杂九
如何提高敏捷迭代效率？sprint backlog
敏捷开发迭代管理示例：迭代规划完成后，进入迭代看板，可以看到已规划的用户故事已分别放置在独立泳道中，泳道可横向对应用户故事和拆分的任务。 敏捷迭代规划：图片用户故事任务拆分：图片迭代执行：图片免费敏捷开发工具：常见的敏捷开发项目管理软件有很多，比如Leangoo领歌、Axosoft、Trello、Asana、Monday.com、Zenkit 、Sprint.ly、Smartsheet等。 这些项目管理软件有着不同的特点和功能，可以根据不同团队的需求选择适合的软件。 比如，Leangoo领歌是国产的免费的敏捷项目管理软件，支持包括小型团队敏捷开发，规模化敏捷SAFe，Scrum of Scrums大规模敏捷等敏捷开发方法，具有产品管理和项目管理的功能；Axosoft
75020编辑于 2023-10-08 AI Agent 的敏捷开发：为什么你的 Loop 需要 Sprint？
本文提出 Sprint Loop Framework（SLF）——用敏捷 Sprint 的方式设计 Loop，让每个阶段有独立的验收标准、约束边界和退出策略。 它把敏捷开发的 Sprint 理念和 Loop Engineering 结合起来。 11-12: 管理后台 审核、订单管理、报表 以 Sprint 1 为例，看看实际文件是什么。 bcrypt 加密 / JWT_SECRET 从环境变量取 / SQL 参数化 规范: 统一响应 {code, data, message} / 蛇形命名 范围: 只做注册+登录，不做个人信息管理和地址管理 适合 SLF 的项目： 项目周期超过 6 个月 模块数量超过 5 个 团队希望 Agent 逐步自治，而不是一步到位 需要跨版本管理 Agent 的交付质量 不需要 SLF 的场景： 单模块、短周期项目
18400编辑于 2026-07-13- 来自专栏UniPro
敏捷基本概念之三大角色
迭代是贯穿敏捷管理的一个特有概念，Sprint是冲刺跑的意思，在敏捷里指的是一次迭代，而一次迭代的周期一般是2~4周，也就是要把一次迭代的开发内容以最快的速度完成它，这个过程我们称为迭代。 他们是自管理的，这意味着他们在团队内部决定谁做什么、何时做以及如何做。 在团队中，三种角色有不同的分工，由一名流程管理员（Scrum Master），产品负责人（Product Owner），开发团队（Dev Team）组成来完成每一次迭代，产出每一次增量，完成每一次目标。 开发团队：一般有 5-9 人，团队成员包含程序员、测试员、用户体验设计等等，由一批跨职能的人组成，他们拥有完成每个产品增量所需的全部技能。 开发团队成员需要以自组织的方式实现Sprint目标，根据Sprint的计划完成产品增量。产品负责人准备一个有序的代办事项列表。开发团队成员共同预测在一个Sprint里能完成的工作量，并决定如何实现。
1K10编辑于 2023-02-10 - 来自专栏敏捷开发
规模化敏捷LeSS（二）：LeSS团队实践指南
Scrum 能够帮助一个5-9人的小团队以迭代增量的方式开发产品，在每一迭代结束时，交付潜在的可交付的产品增量。 正是由于其灵活性，Scrum 方法现已成为团队软件交付方法的首选，近期发布的15届敏捷状态报告也显示，66%的受访者及其所在的敏捷团队最常用 Scrum 方法。 但随着敏捷在团队中得到越发广泛的实践，越来越多的人意识到全组织规模化敏捷实践在当下带来的机遇。但当人们简单地将 Scrum 套用到多团队实践中的时候，又出现了各种各样的问题。 2.团队 团队的要求在前一篇文章有也有提到过，主要是自管理的、跨职能的、专注的、长期存在的，以及共处一地的。这将会让团队中的每位成员为实现团队的共同目标，决定自己如何去做。 一名Scrum Master最多可管理3个团队。
92620发布于 2021-07-29 产品研发轻量化管理工具（Sprint Board）：敏捷落地的核心载体，让迭代效率倍增
一、为什么敏捷团队选择“轻量化Sprint Board”？ 很多团队认为“迭代管理”就是用工具记录任务，但真正高效的敏捷落地需要解决几个关键痛点：任务状态是否透明：每个需求的推进阶段、阻塞原因、负责人是否一目了然？ 敏捷转型初期的团队对于刚接触敏捷的团队，复杂工具会增加学习成本，轻量化Sprint Board简单易上手，能帮助团队快速建立迭代意识和协作习惯。 匹配团队成熟度”：敏捷转型初期可选择经典轻量化工具，快速建立协作习惯；流程稳定后可切换至敏捷专用工具，提升管理精细化程度；有定制化需求的团队可考虑开源方案。 在快速变化的市场环境中，以极简的管理方式实现高效的价值交付，正是Sprint Board赋予敏捷团队的核心竞争力。
38810编辑于 2026-01-28- 来自专栏硬核项目经理的专栏
【敏捷1.1】敏捷项目管理与敏捷宣言
敏捷项目管理与敏捷宣言 说到敏捷项目管理就不得不提到那十分出名的敏捷宣言。这篇文章我们就来简单地了解一下敏捷项目管理的出现和敏捷宣言说的是什么。不要有太多的压力哦，这篇文章还是非常轻松的。 传统项目管理 对于传统项目管理和敏捷项目管理的不同，我们可以列一个非常大的表出来，不过，这样列出来其实挺没意思的。 到最后我们学习完了敏捷相关的知识后，大家可以自己再回过头来想一想敏捷和传统项目管理的区别和联系都有哪些，这样对大家知识的掌握才更有好处。 VCUA时代 在敏捷中，有句名言：唯一不变的就是变化。这句话非常有意思，只有变化本身是我们这个世界上唯一不会发生变化的东西。要搞明白这个事情，我们还是再看下传统项目管理和软件开发中的问题。 总结 今天这篇文章我们从传统的项目管理说起，通过 VUCA时代 这样一个时代现象来引出敏捷出现的必要性，最后介绍了敏捷的灵魂：敏捷宣言。当然，敏捷宣言很简单，就四句话，也可以概括成四个词。
1.8K20发布于 2021-09-24 敏捷开发任务分配工具详解：如何让Sprint规划更高效？
基础功能免费，性价比高暂不支持超 20 人以上的大型团队权限分级管理 Jira 冲刺规划：支持多冲刺并行管理，可设置冲刺目标与验收标准；2. 数据报表丰富，便于管理层复盘 学习成本高，需专人配置；基础版收费较高，小型团队性价比低 Trello看板核心：以卡片形式管理任务，支持自定义标签（如 “ A：需支持 “多冲刺并行管理”，推荐板栗看板或 Jira：可创建独立的冲刺看板，分别管理不同冲刺的任务，且能直观查看各冲刺进度，避免任务混淆。 A：从 “核心场景” 逐步拓展：先用工具管理 “任务分配与进度跟踪”，待团队适应后，再启用 “燃尽图”“冲刺复盘数据” 等功能，避免一次性堆砌过多功能导致成员抵触。 本质上，敏捷开发任务分配工具是 “Scrum 流程的载体”—— 当工具能无缝衔接 “冲刺规划→任务拆解→资源匹配→进度跟踪→迭代优化” 全流程时，团队才能真正摆脱 “任务混乱、进度失控” 的困境，实现效率翻倍
66810编辑于 2025-08-19- 来自专栏DevOps
敏捷项目管理介绍及实施
简介 敏捷开发 Scrum Scrum就像你的丈母娘，不断支出你的问题在哪，错在哪 Scurm只是不断的暴露你的问题 团队问题: 做出来的项目无法满足客户需求-分析到底是谁在用 蜕变: 敏捷开发，倾听用户剩余 什么是敏捷开发 敏捷开发(Agile Development) 一种以人为核心，迭代，循序渐进的开发方法 7. Scrum 敏捷的核心要素 4.1 三类角色 product Owner/The Team /Scrum Master 4.2 三个工件 Product BackLog Sprint backlog 或其他相关人员 只有团队 · 注意: 只有成员可以发言，其他人可旁听 · 会议内容: - Scrum Master主持，团队成员轮流发言(昨天，今天，问题 ) - 更新任务看板，燃尽图 看板 JIRA 敏捷项目管理工具 Scrum开发团队 · 5-9人 · 项目期间，专职投入，以跨职能的方式一起工作 · 每个Sprint结束，提交可工作的软件 2.
97510编辑于 2024-03-29 - 来自专栏敏捷开发
敏捷价值流管理
对团队或企业来说，敏捷能够通过快速迭代、改进来更好地为客户或终端用户交付价值。但有些团队在引入敏捷项目管理模式之后，团队管理层看了看埋头工作的团队，“唉？ 二、怎样进行价值流管理？在敏捷项目中，我们应该如何减少浪费，实现利益最大化？这个问题的关键在于“价值的流动”。价值流管理是敏捷中的一个十分重要的实践，更是团队在持续改进、优化过程中的一项基本工作。 那我们应该如何来进行价值流管理呢？1）确认需要识别价值流的阶段首先我们需要明确要改进哪一阶段。我们可以绘产品全生命周期的价值流图，也可以为单独的某一阶段（如产品测试过程）绘制一个价值流图。 所以通过价值流管理，我们可以度量实际的价值流动效率，并提出改进目标，来推动整个项目管理过程的持续改善。
52730编辑于 2022-12-23 - 来自专栏掘金安东尼
深度解析 25 年 PMP 新考纲中的“敏捷”
敏捷核心概念 1、价值观 敏捷开发有 4 大重要的价值观： 个体互动 > 流程工具 例如：团队用每日站会替代复杂项目管理工具，通过面对面沟通快速解决技术难题。 （5）激发团队自主性 核心：信任团队能力，提供资源支持而非微观管理。 实践：自组织团队选择任务分配方式，如T型人才（全栈工程师）减少依赖。 Master 作为流程引导者，负责消除团队障碍并确保Scrum规则执行； （3）跨职能开发团队（5-9人）自组织完成冲刺目标。 流程上： （1）冲刺计划会议（Sprint Planning） 始于冲刺计划会议（Sprint Planning）选定本周期任务形成冲刺待办列表（Sprint Backlog） 3、故事点 这里有一个很重要的考点就是 所以，传统瀑布开发与敏捷开发，常常不是非此即彼，而是混合起来的：如何平衡计划驱动与灵活响应（如变更管理流程的设计）是另外一个核心考点。
38910编辑于 2026-07-24 - 来自专栏社区的朋友们
敏捷项目管理之需求管理
作者：叶朝萍 [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 时代的到来！
4.3K01发布于 2017-07-07 - 来自专栏硬核项目经理的专栏
【敏捷7.1】风险管理
风险管理 在 PMP 中，风险是一个重要的章节，并且有许多的过程，比如说我们要识别风险、进行定性定量分析、应对风险等，工具方面也有决策树、敏捷性分析等，最后还有一个风险应对和机会应对（PMP认为风险和机会是对应的 同时，在项目进行的过程中，也需要不断地管理风险，并追踪风险管理的成效。 对于风险管理这一块，其实我们可以借鉴 PMP 中的一些技术，比如说 风险概率矩阵 ，它就是根据风险的 等级 和可能出现的 概率 来制作的一张表。 这个东西其实有点偏财务和管理学方面的内容，在之前 【敏捷3.1】价值与价值驱动交付https://mp.weixin.qq.com/s/Dw763UK9Dy_jH8gYthBsZw 这篇文章中有提到过一点 风险的严重程度 其实呢，在敏捷中，风险管理其实是工作进度的一个驱动因素。因为团队会将高风险的活动移到迭代的早期，并将风险的缓解这些活动放入待开发项中。
1.3K20编辑于 2023-03-03 - 来自专栏JavaEdge
敏捷项目管理 - Jira
敏捷项目管理架构 Release(发布，单位为月) Sprint(冲刺,单位为周) Issue(问题)类型 Epic( 史诗) Story( 用户故事) Task(任务) Bug(故障 ) Jira创建Release(发布版本) ◆Release(版本)的时间跨度通常为1-3个月 ◆版本包含多个Sprint (冲刺) ◆Release 里会清晰定义需要完成的开发任务
2.7K20发布于 2021-02-23 - 来自专栏IT技术订阅
Scrum敏捷项目管理
，那么由项目经理作为敏捷教练；如果有多个小组则有多个Scrum Master ，简称SM，项目经理对每个敏捷小组和SM统筹管理。 二、Scrum实施过程中常用的5大Scrum管理工具/软件 敏捷开发中非常强调公开、透明、直接有效的沟通，这也是“可视化的管理工具”在敏捷开发中如此重要的原因之一。 这里分享国内外的5款顶级敏捷开发管理工具。 1、国内顶级 Scrum 管理工具PingCode 这是国内最好用的敏捷开发Scrum工具之一，曾在2021年获得由36氪发布的研发项目管理榜TOP1，被广泛用于敏捷开发项目管理。 、kanban/瀑布/敏捷项目管理、测试用例管理、缺陷管理、团队知识库、效能度量，与gitlab、jinkens、飞书等外部工具集成。
2.6K20编辑于 2023-02-23 - 来自专栏敏捷管理
【Kevin聊敏捷】敏捷项目管理APM-敏捷度量
很多人都认为敏捷管理就是将每个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.
2.3K00发布于 2020-12-12 - 来自专栏DotNet NB && CloudNative
.NET 云原生架构师训练营（模块二 基础巩固 Scrum 团队）--学习笔记
2.7.3 Scrum 团队 理想的环境 团队章程 如何组建 Scrum 团队 产品待办事项列表 用户故事 敏捷开发流程 理想的环境 5-9人 100% 跨职能 在一起 自组织 自组织 目标 授权 沟通 团队规范：迟到、冲突 坦诚、高效沟通 包容 相互帮助 简洁、反馈、尊重 如何组建 Scrum 团队 先确定 scrum master 人选，再由 SM 组建其他团队成员 SM 应该由熟悉 scrum 流程和敏捷原理的人担当 Small，分解到最底层的用户故事粒度尽量小，至少在一个迭代中能完成 T：Testable，可测试 拆分关键点 周期控制在 1·5 个工作日，一般在 1 个工作日 识别关键路径上的 Story，并做风险管理 ，避免影响项目进度 Story 下 Task 分解由模块负责人组织开发一起分解并做工作量评估 每个 Story 要有负责人，一般由工作量较多的人负责，可以由研发认领 敏捷开发流程 62.jpg PO 站会时团队成员应自个解释进展，而非 SM 代替解释 PO 对每轮迭代（比如：2周）交付的可工作的软件进行现场验收和反馈 Sprint 回顾会 回到第三步，开启下一轮
53300发布于 2021-01-19 - 来自专栏DotNet NB && CloudNative
.NET 云原生架构师训练营（模块二 基础巩固 Scrum 团队）--学习笔记
2.7.3 Scrum 团队 理想的环境 团队章程 如何组建 Scrum 团队 产品待办事项列表 用户故事 敏捷开发流程 理想的环境 5-9人 100% 跨职能 在一起 自组织 自组织 目标 授权 沟通 团队规范：迟到、冲突 坦诚、高效沟通 包容 相互帮助 简洁、反馈、尊重 如何组建 Scrum 团队 先确定 scrum master 人选，再由 SM 组建其他团队成员 SM 应该由熟悉 scrum 流程和敏捷原理的人担当 Small，分解到最底层的用户故事粒度尽量小，至少在一个迭代中能完成 T：Testable，可测试 拆分关键点 周期控制在 1·5 个工作日，一般在 1 个工作日 识别关键路径上的 Story，并做风险管理 ，避免影响项目进度 Story 下 Task 分解由模块负责人组织开发一起分解并做工作量评估 每个 Story 要有负责人，一般由工作量较多的人负责，可以由研发认领 敏捷开发流程 ? 站会时团队成员应自个解释进展，而非 SM 代替解释 PO 对每轮迭代（比如：2周）交付的可工作的软件进行现场验收和反馈 Sprint 回顾会 回到第三步，开启下一轮 课程链接 .NET云原生架构师训练营讲什么
45210发布于 2021-01-28
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号