从想法到上线再到迭代——不是所有团队都需要 Scrum，但所有团队都需要纪律
从想法到上线的7个阶段——每个阶段都有明确的输入/输出和决策门
输入：用户反馈、数据洞察、竞品分析、战略需求
输出：产品需求池（Backlog）
决策门：这个想法是否值得投入？用 RICE 评分（Reach × Impact × Confidence / Effort）排优先级
输入：高优先级需求
输出：PRD（产品需求文档）
关键：用户故事格式 "作为[角色]，我希望[功能]，以便[价值]"，包含验收标准（Acceptance Criteria）
输入：PRD + 技术约束
输出：UI设计稿 + 技术方案
关键：设计评审≠审批会，而是发现问题。参会人：PM + Designer + Tech Lead
输入：确认的设计稿 + 技术方案
输出：可测试的代码
关键：每日站会（15分钟）、分支策略（trunk-based > GitFlow for 小团队）、Code Review 必须做
输入：开发完成的代码
输出：测试报告 + Bug 列表
关键：自动化测试覆盖核心路径、手动测试覆盖用户体验、性能测试别忘
输入：测试通过的版本
输出：生产环境可用的功能
关键：Feature Flag 灰度发布→5%→20%→50%→100%，回滚预案必须提前准备
输入：上线数据 + 用户反馈
输出：优化需求 → 回到第1步
关键：上线后48小时盯核心指标，7天出复盘报告，30天评估是否达到预期
一份好的PRD不需要10页纸，但必须回答5个关键问题
2周一个Sprint——小团队的黄金节奏
| 时间 | 活动 | 参与人 | 时长 | 目的 |
|---|---|---|---|---|
| Sprint第1天 | Sprint Planning | 全员 | 1小时 | 确定Sprint目标和任务 |
| 每日 | Daily Standup | 全员 | 15分钟 | 同步进度、发现阻碍 |
| Sprint中期 | Scope Check | PM + Tech Lead | 30分钟 | 评估进度、调整范围 |
| Sprint最后1天 | Demo + Retro | 全员 | 1小时 | 展示成果、回顾改进 |
1️⃣ 昨天完成了什么——对Sprint目标的贡献
2️⃣ 今天计划做什么——聚焦最重要的任务
3️⃣ 有什么阻碍——这才是站会的核心价值
⚠️ 站会不是汇报会——如果讨论超过1分钟，记下来会后单独聊。15分钟超时 = 流程有问题。
每次上线前必须过一遍——宁可多花10分钟检查，不要花10小时回滚
Feature Flag让你把"部署"和"发布"分开——代码随时可以推到生产，但功能可以按条件开启
| 类型 | 用途 | 生命周期 | 示例 |
|---|---|---|---|
| Release Flag | 灰度发布新功能 | 短期（1-2周） | new_dashboard → 5%→20%→100% |
| Ops Flag | 运维开关，紧急关闭 | 长期 | kill_switch、maintenance_mode |
| Experiment Flag | A/B测试 | 中期（2-8周） | pricing_test_variant_A |
| Permission Flag | 功能权限控制 | 长期 | enterprise_feature、beta_access |
❌ Flag爆炸：上线后不删Flag，3个月后代码里50个Flag互相纠缠。解决：每个Flag设过期时间，过期自动告警。
❌ Flag嵌套：Flag A 内嵌 Flag B，形成组合爆炸。解决：一个功能一个Flag，不要嵌套。
❌ 用Flag替代分支：if(flag) ... else ... 写死在代码里，3年后没人知道Flag是开还是关。解决：Flag评估逻辑集中在SDK，不在业务代码里。
❌ 不测Flag关闭路径：只测Flag开启的情况，关闭时Crash。解决：CI必须跑Flag全组合（或至少On/Off各一次）。
不是所有团队都需要Scrum——流程必须匹配团队规模和成熟度
| 维度 | 1-3人 | 4-10人 | 11-30人 | 30+人 |
|---|---|---|---|---|
| 流程框架 | Kanban（看板） | 轻量Scrum | Scrum | Scrum + 项目管理 |
| Sprint | 不需要 | 2周 | 2周 | 1-2周 |
| PRD | 口头+卡片 | 1页文档 | 标准模板 | 标准模板+评审会 |
| 设计 | 草图 | Figma线框图 | 完整设计稿 | 设计系统+规范 |
| Code Review | 互相看一眼 | 必须Review | 必须2人Approve | 必须2人+自动化 |
| 测试 | 手动+核心自动 | 手动+关键路径自动 | 自动为主+手动探索 | 自动+QA团队 |
| 发布 | 直接推 | Feature Flag灰度 | CI/CD + 灰度 | CI/CD + 审批 + 灰度 |
| 会议 | 每周1次对齐 | 站会+Planning | 站会+Planning+Retro | 全套+跨组同步 |
Reach × Impact × Confidence / Effort —— 用数据而非直觉排优先级
按功能分类，小团队选左边的就够了
| 功能 | 轻量选择（≤10人） | 标准选择（10-50人） | 企业选择（50+人） |
|---|---|---|---|
| 项目管理 | Linear / Notion | Jira / Shortcut | Jira + Confluence |
| 设计 | Figma | Figma + FigJam | Figma Enterprise |
| 文档 | Notion / Coda | Notion + Loom | Confluence |
| 代码托管 | GitHub | GitHub / GitLab | GitLab Enterprise |
| CI/CD | GitHub Actions | CircleCI / Buildkite | Jenkins + ArgoCD |
| Feature Flag | 自建Config | Unleash / Flagsmith | LaunchDarkly |
| 监控 | Sentry + PostHog | Datadog / Grafana | Datadog Enterprise |
| 通讯 | Slack / 飞书 | Slack + 基于频道的工作流 | Slack Enterprise |
花3个月设计再开发 → 需求已变、市场已变、预算已花。改用小批量的渐进式设计：先MVP验证，再逐步完善。
"代码不够优雅不能上线" → 用户不在乎你的代码优雅，在乎的是功能能不能用。先交付价值，再优化代码。技术债不是罪，无视它才是。
Backlog里有200个需求，每个都在"待定"状态 → 定期清理Backlog，超过3个月没人提的需求直接删。Backlog不是垃圾桶。
Sprint中间不断加需求 → Sprint目标是铁的，新需求进下个Sprint。唯一的例外：P0线上Bug。
开发一周不说话，Demo时发现方向错了 → 每天站会同步进展，每周Demo中间成果。沟通成本远低于返工成本。
跟踪50个指标，每个都不深入 → 聚焦3-5个北极星指标，深度分析比广度跟踪有价值得多。