diff --git a/_posts/2024-12-01-scrum-events.md b/_posts/2024-12-01-scrum-events.md new file mode 100644 index 0000000..e716bae --- /dev/null +++ b/_posts/2024-12-01-scrum-events.md @@ -0,0 +1,68 @@ +--- +layout: post +title: scrum events +date: 2024-12-01 00:12:05 +--- + +# 创建 Scrum 事件完整指南 + +在 Scrum 框架中，几个关键事件（Scrum Events）确保了团队协作的效率、目标的明确以及产品价值的最大化。本文详细介绍了 Scrum 的五大事件：**Product Backlog Refinement**、**Sprint Planning**、**Daily Scrum**、**Sprint Review** 和 **Retrospective**，并通过表格整理了每个事件的核心信息。 + +--- + +## Scrum 事件表格 + +| **Scrum Event** | **Product Backlog Refinement** | **Sprint Planning** | **Daily Scrum** | **Sprint Review** | **Retrospective** | +|------------------------------|----------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------| +| **Goals (why)** | 让产品待办事项清晰、优先级明确，并为未来的 Sprint 做准备。 | 确定 Sprint 目标和待办事项，制定实现计划。 | 确保团队每天对进度和障碍保持同步，调整计划以达成 Sprint 目标。 | 展示团队在 Sprint 中完成的工作，收集利益相关者的反馈。 | 反思 Sprint 的执行情况，找出改进点并优化团队协作方式。 | +| **Inputs** | 产品待办事项列表（Product Backlog），团队的反馈，优先级分析。 | 精炼后的产品待办事项列表，团队能力及可用资源。 | 当前 Sprint 计划，团队任务分配及进展。 | 已完成的工作成果，Sprint 目标，利益相关者的反馈。 | Sprint 的成果，团队成员的反馈，遇到的挑战和问题。 | +| **Outputs** | 一个经过细化的、清晰的产品待办事项列表。 | Sprint 目标、Sprint 待办事项（Sprint Backlog），团队对交付的承诺。 | 调整后的任务计划，障碍清单（如有）。 | 利益相关者的反馈，调整后的产品待办事项列表。 | 下一步改进计划，团队行动项。 | +| **Who** | 产品负责人（Product Owner）、开发团队（Development Team）。 | Scrum Master、产品负责人、开发团队。 | 开发团队、Scrum Master（可选）。 | Scrum Master、开发团队、产品负责人、利益相关者。 | Scrum Master、开发团队（有时包括产品负责人）。 | +| **When** | 每个 Sprint 中，持续进行，根据需求而定。 | 每个 Sprint 的开始。 | 每天进行（通常在早晨）。 | 每个 Sprint 结束时。 | 每个 Sprint 结束时。 | +| **How long** | 每次 1-2 小时，或持续分布在整个 Sprint。 | Sprint 时间的 8 小时（1 个月的 Sprint），较短的 Sprint 相应缩短时间。 | 通常不超过 15 分钟。 | Sprint 时间的 4 小时（1 个月的 Sprint），较短的 Sprint 相应缩短时间。 | Sprint 时间的 3 小时（1 个月的 Sprint），较短的 Sprint 相应缩短时间。 | + +--- + +## 各 Scrum 事件详解 + +### 1. Product Backlog Refinement +- **目标**：确保产品待办事项（Product Backlog）清晰具体，优先级合理，为未来的 Sprint 做好准备。 +- **参与者**：产品负责人、开发团队。 +- **输入**：现有的产品待办事项列表、团队的反馈、优先级信息。 +- **输出**：经过细化和优化的产品待办事项列表。 +- **时长**：每次 1-2 小时，或分布在整个 Sprint 过程中进行。 + +### 2. Sprint Planning +- **目标**：确定 Sprint 的目标和待办事项（Sprint Backlog），制定实现计划。 +- **参与者**：Scrum Master、产品负责人、开发团队。 +- **输入**：精炼后的产品待办事项列表、团队的能力及资源。 +- **输出**：Sprint 目标、待办事项清单。 +- **时长**：8 小时（1 个月的 Sprint），较短的 Sprint 按比例缩短。 + +### 3. Daily Scrum +- **目标**：确保团队对当前的进展和障碍保持同步，调整计划以完成 Sprint 目标。 +- **参与者**：开发团队（Scrum Master 可选）。 +- **输入**：Sprint 计划、当前任务分配和进展。 +- **输出**：调整后的计划、识别的障碍清单。 +- **时长**：不超过 15 分钟。 + +### 4. Sprint Review +- **目标**：展示 Sprint 的成果，收集利益相关者的反馈。 +- **参与者**：Scrum Master、开发团队、产品负责人、利益相关者。 +- **输入**：已完成的工作成果、Sprint 目标。 +- **输出**：反馈清单、调整后的产品待办事项列表。 +- **时长**：4 小时（1 个月的 Sprint），较短的 Sprint 按比例缩短。 + +### 5. Retrospective +- **目标**：反思团队在 Sprint 中的表现，找出改进点并优化团队协作。 +- **参与者**：Scrum Master、开发团队（可能包括产品负责人）。 +- **输入**：Sprint 的成果、团队成员的反馈、遇到的问题。 +- **输出**：下一步改进计划和行动项。 +- **时长**：3 小时（1 个月的 Sprint），较短的 Sprint 按比例缩短。 + +--- + +## 总结 + +Scrum 事件为团队提供了明确的结构和节奏，帮助团队在开发过程中实现更高效的协作与价值交付。通过合理规划和执行这些事件，团队可以更好地适应变化并持续改进。如果您是 Scrum 的新手，可以从严格遵循这些事件开始，在实践中逐渐优化。 + diff --git a/_posts/2024-12-01-twelve-principles-of-agile-manifesto.md b/_posts/2024-12-01-twelve-principles-of-agile-manifesto.md deleted file mode 100644 index 589a277..0000000 --- a/_posts/2024-12-01-twelve-principles-of-agile-manifesto.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -layout: post -title: 敏捷宣言的十二条原则 -date: 2024-12-01 00:12:05 ---- - -- 我们的首要任务是通过尽早并持续交付有价值的软件，使客户满意。 -> our highest priority is to satisfy the customer through early and continuous delivery of valuable software. - -- 欢迎需求的变化，即使是在开发后期。敏捷过程利用变化来为客户创造竞争优势。 -> welcome changing requirements, even late in development. agile processes harness change for the customer’s competitive advantage. - -- 经常交付可工作的软件，周期从几周到几个月不等，倾向于较短的周期。 -> deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. - -- 业务人员和开发人员必须在整个项目过程中每天都一起工作。 -> business people and developers must work together daily throughout the project. - -- 以积极主动的个体为核心来构建项目，给予他们所需的环境和支持，并相信他们能够完成工作。 -> build projects around motivated individuals. give them the environment and support they need, and trust them to get the job done. - -- 传递信息的最有效且最具效率的方法是面对面的交流。 -> the most efficient and effective method of conveying information to and within a development team is face-to-face conversation. - -- 工作的软件是衡量进度的首要指标。 -> working software is the primary measure of progress. - -- 敏捷过程提倡可持续开发。赞助者、开发者和用户应该能够一直保持一个稳定的开发节奏。 -> agile processes promote sustainable development. the sponsors, developers, and users should be able to maintain a constant pace indefinitely. - -- 对技术卓越和良好设计的持续关注有助于增强敏捷性。 -> continuous attention to technical excellence and good design enhances agility. - -- 简洁——尽量减少不必要的工作——是根本。 -> simplicity—the art of maximizing the amount of work not done—is essential. - -- 最好的架构、需求和设计出自自组织团队。 -> the best architectures, requirements, and designs emerge from self-organizing teams. - -- 团队会定期反思如何变得更有效率，并相应地调整自己的行为以改进表现。 -> at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.