Agile Demo

一、项目准备阶段（Scrum Master + PO）

1. 定义愿景 & 范围

• 愿景：为车企构建一个高效、安全、可扩展的采购系统，覆盖 采购申请 → 审批 → 下单 → 供应商对接 → 支付 → 报表。
• 最小可行产品 (MVP)：先上线采购申请、审批、下单。

📌 产出：在 Confluence 写下《产品愿景与范围文档》。

2. 搭建工具体系

• Jira：新建一个 Scrum Software 项目，配置好 Epic/Story/Task 模板。
• Confluence：作为文档库，存放愿景、需求规格、架构设计、会议纪要。
• GitHub/GitLab：源代码仓库，按 microservice 模块 或 单体仓库+模块目录 管理。
• GitLab CI/CD：流水线配置，负责 构建 → 测试 → 制品（Docker 镜像） → 部署到 K8s。
• K8s + Helm：部署环境，提供 测试环境 / UAT / 生产环境。

二、敏捷实践（Scrum 流程）

1. Backlog 建立（PO 负责）

在 Jira 里创建以下 Epic：

• Epic-1: 用户与权限管理
• Epic-2: 采购申请流程
• Epic-3: 审批与下单
• Epic-4: 供应商对接
• Epic-5: 支付与报表
• Epic-6: 系统运维与监控

每个 Epic 下拆分 Story（用户故事），例如：

• Story: 作为采购人员，我希望能提交采购申请，以便走审批流程。

再将 Story 拆成 Task（开发/测试/运维任务）：

• Task: 设计采购申请表结构（数据库）
• Task: 实现采购申请 API
• Task: 前端页面开发
• Task: 单元测试与集成测试

📌 最佳实践：Story 用 用户语言，Task 用 开发语言。

2. Sprint 计划（Scrum Master 主持）

• Sprint 周期：2 周
• Sprint-1 目标：实现用户注册/登录 + 提交采购申请
• Sprint-2 目标：实现审批流程 + 下单
• Sprint-3 目标：实现供应商接口对接
• Sprint-4 目标：实现支付 + 报表
• Sprint-5 目标：运维与性能优化

在 Sprint Planning 中：

• PO 提供 优先级排序后的 Backlog
• 团队估算 Story Points（工作量）
• Scrum Master 监督 可交付性

3. 日常敏捷实践

• Daily Scrum（站会）：每天 15 分钟，回答 3 个问题：

  1. 昨天完成了什么？
  2. 今天计划做什么？
  3. 有什么阻碍？
• Sprint Review（评审）：演示已完成的功能给 PO & 业务方。
• Sprint Retrospective（回顾）：团队总结改进点。

三、技术落地 Demo

1. Git 流程

采用 GitLab Flow：

• main → 稳定分支
• develop → 集成分支
• feature/* → 功能分支
• release/* → 预发布
• hotfix/* → 紧急修复

2. GitLab CI/CD Pipeline (示例 .gitlab-ci.yml)

stages:
  - build
  - test
  - docker
  - deploy

build:
  stage: build
  script:
    - mvn clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar

test:
  stage: test
  script:
    - mvn test

docker-build:
  stage: docker
  script:
    - docker build -t registry.example.com/purchase-service:$CI_COMMIT_SHA .
    - docker push registry.example.com/purchase-service:$CI_COMMIT_SHA

deploy:
  stage: deploy
  script:
    - helm upgrade --install purchase-service ./helm/purchase-service \
        --set image.tag=$CI_COMMIT_SHA
  environment:
    name: dev
    url: http://purchase.dev.company.com

3. Helm Chart (示例 values.yaml)

replicaCount: 2

image:
  repository: registry.example.com/purchase-service
  tag: "latest"

service:
  type: ClusterIP
  port: 8080

resources:
  limits:
    cpu: "500m"
    memory: "512Mi"

4. 监控与日志

• 在 K8s 部署 Prometheus + Grafana → 监控 API 延迟、错误率。
• 部署 EFK（Elasticsearch + Fluentd + Kibana） → 日志收集与可视化。

四、Scrum Master & PO 的日常角色

• 作为 PO：

  • 维护 Product Backlog
  • 确保优先级和需求清晰
  • 和业务方沟通需求

• 作为 Scrum Master：

  • 确保团队遵守敏捷原则
  • 主持 Sprint Planning / Daily / Review / Retrospective
  • 解决阻碍（技术、资源、跨部门）

五、Confluence 知识库结构（推荐）

• 产品愿景与范围
• 需求规格文档（分 Epic/Story）
• 架构设计（微服务图、数据库设计、K8s 拓扑）
• CI/CD 流程文档
• 运维手册（监控告警、日志分析）
• Sprint 回顾总结

六、敏捷落地指南：如何高效拆分 Story 和估算 Story Points

关于如何搭建 Epic, Story, Task，以及如何向组员讲清 Story Points，核心原则是“从业务价值出发，先简单后复杂”，避免为了“敏捷形式”而过度拆分。以下是具体落地指南：

一、需不需要建Epic和Story？看“需求规模”和“团队协作效率”

• 核心判断标准：如果一个需求大到“无法在1个冲刺（Sprint）内完成”，或“需要拆分给多个角色（开发/测试/设计）协作”，就需要用Epic和Story拆分；小需求（如1人1天能做完的bug修复）可直接用“Task”，无需过度拆分。 层级 适用场景 核心作用 Epic（史诗） 大型、跨多个冲刺的需求（如“用户支付模块重构”“APP登录功能升级”） 聚合相关Story，方便跟踪“大需求”的整体进度 Story（用户故事） 1个冲刺内可完成、聚焦“用户价值”的具体需求（如“用户可通过手机号验证码登录”“支付失败时显示错误提示”） 明确“做什么对用户有价值”，方便团队认领和估算 Task（任务） 拆分Story的具体执行步骤（如“编写登录接口”“设计验证码输入页”“测试支付失败场景”） 把Story拆解为“可执行的最小单元”，方便每日同步进度

二、如何建Epic和Story？按“业务价值→用户视角→可交付”三步拆

1. 建Epic：聚焦“大目标”，不纠结细节

• 创建逻辑：以“业务目标”为核心，名称体现 “要解决的问题”，而非“要做的功能”。

• 示例：

  • ❌ 错误：“开发支付模块”（只说功能，不说价值）

  • ✅ 正确：“优化支付流程，降低用户支付失败率”（明确业务目标）

• JIRA配置（极简版）：

  • 类型选“Epic”，填写“名称”和“描述”（描述清楚Epic的业务背景和最终目标）；

  • 无需加过多字段，初期只留“负责人”（通常是PO或核心业务负责人）和“优先级”。

1. 建Story：用“用户故事三要素”确保清晰

• Story 的核心是 “从用户视角描述价值”，避免写成“技术任务”。用经典的“3C原则” 搭建：

• Card（卡片）：简短描述“谁要做什么，为什么”，格式：作为[用户角色]，我想[做什么操作]，以便[获得什么价值]。

• 示例：

  • ❌ 错误：“开发验证码发送接口”（技术视角，无用户价值）

  • ✅ 正确：“作为APP新用户，我想通过手机号接收验证码，以便快速完成注册”（用户视角+价值）

• Conversation（对话）：Story卡片只写核心信息，细节通过“对话”补充（如需求评审会、Confluence文档）。

• 操作：在JIRA的Story描述中，附上Confluence需求文档链接，或直接记录“验收标准”（如“验证码有效时间5分钟”“连续3次输错需重新发送”）。

• Confirmation（确认）：明确“如何判断Story完成”，即验收标准（Acceptance Criteria），避免开发和测试理解偏差。

• 示例：Story“用户可通过手机号验证码登录”的验收标准：

  1. 输入手机号后，点击“发送验证码”，60秒内收到短信；

  2. 输入正确验证码，点击“登录”，跳转至首页；

  3. 输入错误验证码，显示“验证码错误，请重新输入”提示。

1. （可选）Story拆分为Task：拆到“1人1-2天能做完”

• 如果一个Story工作量较大（如“开发登录功能”可能需要3天），可拆分为多个Task，确保每个Task是“最小执行单元”：

• 示例：Story“用户可通过手机号验证码登录”拆分为：

  • Task1：设计验证码登录页面UI（设计师，1天）

  • Task2：编写手机号验证接口（后端开发，1天）

  • Task3：开发前端验证码输入和提交逻辑（前端开发，1天）

  • Task4：编写登录功能测试用例并执行测试（测试，1天）

三、如何给组员讲清楚Story Points（故事点）？用“共识+类比”替代“精确计算”

Story Points的核心是“团队对‘工作量相对大小’的共识”，不是“具体工时（如几小时）”，新手最容易陷入“纠结点数对应多少小时”的误区，需先明确3个核心认知，再用“三步教学法”让组员理解：

1. 先统一3个核心认知（避免误解）

• 认知1：Points是“相对值”，不是“绝对值”。比如：团队认为“登录功能”是5点，“修复一个简单bug”是1点，代表“登录功能的工作量约是这个bug的5倍”，不用纠结“5点等于几小时”。

• 认知2：Points包含“工作量+复杂度+风险”。比如：同样是“开发一个接口”，简单的查询接口可能是1点，涉及第三方支付的复杂接口可能是3点（因复杂度和风险更高）。

• 认知3：Points是“团队共识”，不是“个人判断”。即使个人觉得某个Story是2点，只要多数人认为是3点，就按3点算，避免争执。

1. 用“三步教学法”让组员快速上手

第一步：选“基准Story”，建立“点数锚点”

找1个团队都熟悉的“最小工作量需求”作为“1点基准”，让大家对“点数大小”有直观感知：

• 示例：“修复一个‘按钮文字错误’的bug（只需改1行文案，测试1分钟）”= 1点；

• 以此类推，大家可快速联想：“修复一个‘页面样式错乱’的bug（需改CSS，测试多个浏览器）”≈ 2点；“开发一个‘简单查询接口’（无需复杂逻辑，1天做完）”≈ 3点。

第二步：用“斐波那契数列”简化估算（1, 2, 3, 5, 8, 13）

不用连续数字（如1,2,3,4,5），因为数字越接近，越容易纠结“2点和3点的区别”；斐波那契数列（1,2,3,5,8）的间隔更大，强迫团队聚焦“相对大小”，而非“精确计算”。

• 操作：估算时，团队成员每人用手势比出自己认为的点数（如比“1”代表1点，比“5”代表5点），如果不一致，让点数差异大的人说说理由（如“我觉得是5点，因为要对接第三方，有不确定性”），再重新投票，直到多数人达成共识。

第三步：用“日常类比”帮新手理解（避免技术术语）

如果组员对“点数”仍陌生，用生活中的“工作量类比”举例，快速建立认知：

• 1点：像“泡一杯咖啡”（简单、无意外，5分钟搞定）；

• 2点：像“做一份简单的早餐（煎蛋+面包）”（比泡咖啡复杂一点，15分钟）；

• 3点：像“做一顿午餐（一荤一素）”（需要准备食材、烹饪，1小时）；

• 5点：像“周末大扫除（扫地、擦窗、整理衣柜）”（工作量大，半天时间）；

• 8点：像“筹备一次家庭聚餐（买菜、做饭、收拾）”（复杂且耗时，1天）。

1. 初期允许“估算不准”，通过回顾会调整

不用追求“第一次就估对”，首个冲刺结束后，在回顾会上对比“估算点数”和“实际耗时”：

• 比如：团队估3点的Story，实际用了2天；估5点的Story，实际用了1天——让大家一起分析原因（如“3点的Story没想到要对接第三方，低估了复杂度”），下次估算时更精准。

总结：落地顺序建议

1. 先从“1个Epic+3-5个Story”开始（比如下一个冲刺的需求），不用拆太多；

2. 用“用户故事三要素”写清楚每个Story，附上验收标准；

3. 选1个“1点基准”，用斐波那契数列和“生活类比”带组员做首次估算；

4. 冲刺结束后，通过回顾会优化拆分和估算方式，逐步形成团队习惯。