- 综合排序
- 最热优先
- 最新优先
- 来自专栏敏捷管理
【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.8K22发布于 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
2.9K00发布于 2020-06-27 - 来自专栏杂七杂八杂九
如何提高敏捷迭代效率？sprint backlog
敏捷开发迭代管理示例：迭代规划完成后，进入迭代看板，可以看到已规划的用户故事已分别放置在独立泳道中，泳道可横向对应用户故事和拆分的任务。 敏捷迭代规划：图片用户故事任务拆分：图片迭代执行：图片免费敏捷开发工具：常见的敏捷开发项目管理软件有很多，比如Leangoo领歌、Axosoft、Trello、Asana、Monday.com、Zenkit 、Sprint.ly、Smartsheet等。 这些项目管理软件有着不同的特点和功能，可以根据不同团队的需求选择适合的软件。 比如，Leangoo领歌是国产的免费的敏捷项目管理软件，支持包括小型团队敏捷开发，规模化敏捷SAFe，Scrum of Scrums大规模敏捷等敏捷开发方法，具有产品管理和项目管理的功能；Axosoft
71520编辑于 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 的场景： 单模块、短周期项目
11200编辑于 2026-07-13产品研发轻量化管理工具（Sprint Board）：敏捷落地的核心载体，让迭代效率倍增
一、为什么敏捷团队选择“轻量化Sprint Board”？ 很多团队认为“迭代管理”就是用工具记录任务，但真正高效的敏捷落地需要解决几个关键痛点：任务状态是否透明：每个需求的推进阶段、阻塞原因、负责人是否一目了然？ 敏捷转型初期的团队对于刚接触敏捷的团队，复杂工具会增加学习成本，轻量化Sprint Board简单易上手，能帮助团队快速建立迭代意识和协作习惯。 匹配团队成熟度”：敏捷转型初期可选择经典轻量化工具，快速建立协作习惯；流程稳定后可切换至敏捷专用工具，提升管理精细化程度；有定制化需求的团队可考虑开源方案。 在快速变化的市场环境中，以极简的管理方式实现高效的价值交付，正是Sprint Board赋予敏捷团队的核心竞争力。
31910编辑于 2026-01-28- 来自专栏硬核项目经理的专栏
【敏捷1.1】敏捷项目管理与敏捷宣言
敏捷项目管理与敏捷宣言 说到敏捷项目管理就不得不提到那十分出名的敏捷宣言。这篇文章我们就来简单地了解一下敏捷项目管理的出现和敏捷宣言说的是什么。不要有太多的压力哦，这篇文章还是非常轻松的。 传统项目管理 对于传统项目管理和敏捷项目管理的不同，我们可以列一个非常大的表出来，不过，这样列出来其实挺没意思的。 到最后我们学习完了敏捷相关的知识后，大家可以自己再回过头来想一想敏捷和传统项目管理的区别和联系都有哪些，这样对大家知识的掌握才更有好处。 VCUA时代 在敏捷中，有句名言：唯一不变的就是变化。这句话非常有意思，只有变化本身是我们这个世界上唯一不会发生变化的东西。要搞明白这个事情，我们还是再看下传统项目管理和软件开发中的问题。 总结 今天这篇文章我们从传统的项目管理说起，通过 VUCA时代 这样一个时代现象来引出敏捷出现的必要性，最后介绍了敏捷的灵魂：敏捷宣言。当然，敏捷宣言很简单，就四句话，也可以概括成四个词。
1.8K20发布于 2021-09-24 敏捷开发任务分配工具详解：如何让Sprint规划更高效？
基础功能免费，性价比高暂不支持超 20 人以上的大型团队权限分级管理 Jira 冲刺规划：支持多冲刺并行管理，可设置冲刺目标与验收标准；2. 数据报表丰富，便于管理层复盘 学习成本高，需专人配置；基础版收费较高，小型团队性价比低 Trello看板核心：以卡片形式管理任务，支持自定义标签（如 “ A：需支持 “多冲刺并行管理”，推荐板栗看板或 Jira：可创建独立的冲刺看板，分别管理不同冲刺的任务，且能直观查看各冲刺进度，避免任务混淆。 A：从 “核心场景” 逐步拓展：先用工具管理 “任务分配与进度跟踪”，待团队适应后，再启用 “燃尽图”“冲刺复盘数据” 等功能，避免一次性堆砌过多功能导致成员抵触。 本质上，敏捷开发任务分配工具是 “Scrum 流程的载体”—— 当工具能无缝衔接 “冲刺规划→任务拆解→资源匹配→进度跟踪→迭代优化” 全流程时，团队才能真正摆脱 “任务混乱、进度失控” 的困境，实现效率翻倍
58710编辑于 2025-08-19- 来自专栏知识碎片
Scrum vs. Kanban
区别于传统的Waterfall瀑布式开发，Agile敏捷是理想型指标和原则，Scrum和Kanban是帮助团队坚持敏捷原则并完成工作的基本框架 Scrum Kanban 节奏 固定时间长度，例如两周 Scrum工作节奏 Scrum发展很快，每2-4个星期就有一个明确的开始和结束日期。短时间框架迫使复杂的任务被分解成更小的需求，并帮助团队快速学习。 Scrum角色 Scrum有三个明确定义的角色：产品负责人为客户提供支持，管理产品 Backlog，并帮助开发团队确定所做工作的优先级；Scrum Master 帮助团队坚持 Scrum 原则；开发团队完成项目工作 那谁来管理 Scrum 团队？答案是：没有设定这个角色。Scrum 团队属于自治型，尽管职责不同，但每个人都是平等的，所有人都坚定于一个共同的目标：为客户提供有价值的产品。 看板工作节奏 看板基于一个连续的工作流结构，它能够让团队保持敏捷，随时准备适应不断变化的任务优先级。
1K00发布于 2021-02-19 - 来自专栏全栈程序员必看
Scrum 学习笔记
在 Scrum 中，使用产品 Backlog 来管理产品或项目的需求，产品 backlog 是一个依照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。 敏捷价值观之敏捷四宣言 • 个体与交互重于过程和工具 • 可用的软件重于完备的文档 • 客户协作重于合同谈判 • 响应变化重于遵循计划 敏捷价值观之敏捷十二原则 • 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户 Sprints • Scrum的项目过程有一系列的Sprint组成。 • Sprint的长度一般控制在2-4周。 • 通过固定的周期保持良好的节奏。 (有些情况例外，比方数据库管理员) • 在项目向导范围内有权利做不论什么事情已确保达到 Sprint 的目标。 • 高度的自我组织能力。 • 向 Product Owner演示产品功能。 管理 Sprint 的 backlog: • 团队成员自己挑选任务，而不是指派任务 • 对每个任务，每天要更新剩余的工作量估算 • 每一个团队成员都能够改动 Sprint backlog，添加、删除或者改动任务
63210编辑于 2022-07-14 SCRUM模型与XP模型比较
在本教程中，我们将详细介绍两个基于敏捷的框架：极限编程（XP）和Scrum。 2. 敏捷 敏捷是一种强调灵活性和协作的项目管理和产品开发方法。这是一种增量和迭代方法，用于管理项目和交付成果。 敏捷方法基于以下原则： 个人和交互对流程和工具 工作软件超过全面的文档 客户协作与合同谈判 通过坚持计划来应对变化 敏捷方法通常使用Scrum实现，Scrum是使用敏捷方法管理和完成项目的特定框架。 此外，它还定义了诸如Sprint Planning，Daily Scrum，Sprint Review和Sprint Retrospective等仪式。 虽然Scrum专注于管理和生产力，而XP专注于软件质量和工程技术。 其次，框架在Sprint方面几乎没有区别。Scrum中的冲刺通常持续更长时间，大约2-4周。而XP强调较短的冲刺，通常持续1-2周。 结论 总之，Scrum和极限编程（XP）是两种流行的IT项目管理方法，它们在规划，文档和领导角色的方法上有所不同。Scrum专注于项目管理和团队合作，而XP专注于代码质量和个人程序员的工作。
56910编辑于 2025-04-05- 来自专栏全栈程序员必看
敏捷项目管理的流程_敏捷开发项目管理方法
引言：敏捷绝非某一种特定的开发方法，它只是一种应对快速变化的需求的一种软件开发能力。敏捷本身只包含了《敏捷软件开发宣言》和《敏捷软件的十二条原则》两份文档。 这样的项目管理很混乱。 敏捷开发流程是一个标准的项目管理流程，是不能适用于所有的公司，但是适用大部分的公司，公司根据标准化流程去进行优化，不管是新增还是减少，只要适用于自己的公司那就是贵公司的敏捷流程。 6.软件是你的主要目标：软件开发的主要目标是以有效的方式，制造出满足投资者需要的软件，而不是制造无关的文档，无关的用于管理的工件，甚至无关的模型。 ，但是这样利于项目管理，一个团队共同为一个目标去奋斗。
2.2K30编辑于 2022-11-17 - 来自专栏敏捷开发
敏捷价值流管理
对团队或企业来说，敏捷能够通过快速迭代、改进来更好地为客户或终端用户交付价值。但有些团队在引入敏捷项目管理模式之后，团队管理层看了看埋头工作的团队，“唉？ 二、怎样进行价值流管理？在敏捷项目中，我们应该如何减少浪费，实现利益最大化？这个问题的关键在于“价值的流动”。价值流管理是敏捷中的一个十分重要的实践，更是团队在持续改进、优化过程中的一项基本工作。 那我们应该如何来进行价值流管理呢？1）确认需要识别价值流的阶段首先我们需要明确要改进哪一阶段。我们可以绘产品全生命周期的价值流图，也可以为单独的某一阶段（如产品测试过程）绘制一个价值流图。 所以通过价值流管理，我们可以度量实际的价值流动效率，并提出改进目标，来推动整个项目管理过程的持续改善。
49330编辑于 2022-12-23 - 来自专栏社区的朋友们
敏捷项目管理之需求管理
作者：叶朝萍 [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 - 来自专栏JavaEdge
敏捷项目管理 - Jira
敏捷项目管理架构 Release(发布，单位为月) Sprint(冲刺,单位为周) Issue(问题)类型 Epic( 史诗) Story( 用户故事) Task(任务) Bug(故障 ) Jira创建Release(发布版本) ◆Release(版本)的时间跨度通常为1-3个月 ◆版本包含多个Sprint (冲刺) ◆Release 里会清晰定义需要完成的开发任务
2.6K20发布于 2021-02-23 - 来自专栏硬核项目经理的专栏
【敏捷7.1】风险管理
风险管理 在 PMP 中，风险是一个重要的章节，并且有许多的过程，比如说我们要识别风险、进行定性定量分析、应对风险等，工具方面也有决策树、敏捷性分析等，最后还有一个风险应对和机会应对（PMP认为风险和机会是对应的 同时，在项目进行的过程中，也需要不断地管理风险，并追踪风险管理的成效。 对于风险管理这一块，其实我们可以借鉴 PMP 中的一些技术，比如说 风险概率矩阵 ，它就是根据风险的 等级 和可能出现的 概率 来制作的一张表。 这个东西其实有点偏财务和管理学方面的内容，在之前 【敏捷3.1】价值与价值驱动交付https://mp.weixin.qq.com/s/Dw763UK9Dy_jH8gYthBsZw 这篇文章中有提到过一点 风险的严重程度 其实呢，在敏捷中，风险管理其实是工作进度的一个驱动因素。因为团队会将高风险的活动移到迭代的早期，并将风险的缓解这些活动放入待开发项中。
1.2K20编辑于 2023-03-03 - 来自专栏IT技术订阅
Scrum敏捷项目管理
，那么由项目经理作为敏捷教练；如果有多个小组则有多个Scrum Master ，简称SM，项目经理对每个敏捷小组和SM统筹管理。 二、Scrum实施过程中常用的5大Scrum管理工具/软件 敏捷开发中非常强调公开、透明、直接有效的沟通，这也是“可视化的管理工具”在敏捷开发中如此重要的原因之一。 这里分享国内外的5款顶级敏捷开发管理工具。 1、国内顶级 Scrum 管理工具PingCode 这是国内最好用的敏捷开发Scrum工具之一，曾在2021年获得由36氪发布的研发项目管理榜TOP1，被广泛用于敏捷开发项目管理。 、kanban/瀑布/敏捷项目管理、测试用例管理、缺陷管理、团队知识库、效能度量，与gitlab、jinkens、飞书等外部工具集成。
2.5K20编辑于 2023-02-23 - 来自专栏Act的项目管理
DevOps学习笔记（一）
要想学习DevOps的内容，需要从以下四个方面来入手把握：敏捷管理、精益管理、持续交付、IT服务管理。 此外，还要深刻理会DevOps核心思想：从关注价值开始。 首先解释下，什么是价值。 DevOps的知识体系——敏捷开发 敏捷相较于传统的瀑布开发模式，它的开发周期更为精短，往往2-4周即为一个迭代周期，而每一个迭代周期都有一个潜在可交付的功能内容输出，不用等到完全开发完成之后用户才得以看到应用实体 它包括了三种角色， PO ( Product Order ，一般为项目经理或者产品经理)、 Scrum Master （敏捷教练，一般具有资深的敏捷项目管理经验，甚至开发技术经验）、Scrum Team Sprint 计划会议、每日站会、Sprint 评审会议、Sprint 回顾会议、产品待办事项列表梳理。 ---- 以上，篇幅关系，暂先分享‘敏捷开发’、‘精益管理’两个核心内容，‘持续交付’、‘IT服务与管理’就放到后面一篇来整理分享。
84200发布于 2021-11-07 - 来自专栏敏捷管理
【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 - 来自专栏qKnow知识平台
【千桐敏捷手记·第1篇】：为什么你的 Scrum 跑不起来？——兼谈敏捷的“神”与“形”
在这漫长的敏捷旅程中，我们见过太多团队满怀热情地引入Scrum，又在几个月后悄然放弃。问题出在哪里？本文是“千桐科技敏捷手记”系列的开篇，我们想和你聊聊Scrum背后那些比流程和工具更重要的事。 举几个千桐特有的“非标准”实践：Sprint周期定3周：教科书推荐2-4周，我们经过多次试验发现，3周对于我们的业务节奏最合适——既给了开发足够的深度工作时间，又不至于让产品负责人觉得反馈周期太长。 这些产品解决的核心问题，和Scrum要解决的管理问题如出一辙：如何让复杂系统中的各个部分高效协作？当市面上现成的Scrum工具无法满足三地协同的需求时，我们决定自己动手。 六、这篇文章想留给你的一句话如果你是那个对敏捷将信将疑的管理者，或者你正在经历“上了Scrum却更累了”的挫败感，这篇文章最想告诉你的是：别急着否定Scrum，也别急着照搬Scrum。 我们用敏捷的方式做产品，也用敏捷的方式服务客户。
18921编辑于 2026-04-16
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号