编程语言研究书库
精通 DevOps

计划阶段:开工之前把规矩定完

计划阶段:开工之前把规矩定完

1. 这一章讲什么

上一章给了 DevOps 的八阶段地图,这一章钻入第一个阶段:Plan。核心论点一句话:计划阶段的产出不是一份时间表,而是一套让后面七个阶段能自动转起来的规矩——编码规范、构建工具、测试策略、发布频率、部署策略、监控指标,全都要在计划阶段定好。章末还对比了三个项目管理工具(GitHub Projects、Jira、Azure DevOps)各自什么时候用。

2. 顶层全景

  计划阶段的三层:
  ① 元素层:目标(objective)、backlog、优先级、 sprint、协作、工具选型
  ② 步骤层:涉众 → 需求 → 目标 → 风险 → 组队
  ③ 预演层:替 Code/Build/Test/Release/Deploy/Operate/Monitor 七个阶段各定一份"怎么做"的规矩

主线例子(书里给的):一个电商网站团队建 backlog——市场部门要促销横幅、客户报结账流程的 bug、开发建议优化数据库——三件事估点、排序、进 sprint。

3. 核心原理

3.1 目标分两种:愿景(goal)和台阶(objective)

书里先用马拉松训练类比:目标是「完赛」,台阶是「本周跑三次、每次 5 公里」1。放到软件项目:goal 是长期方向(比如提高客户满意度),objective 是可测量的具体步骤(比如「下一个 sprint 结束前上线通过安全和性能测试的新支付网关功能」)2。写 objective 有一条现成的检验标准叫 SMART:具体、可测量、可达成、与业务相关、有截止时间3。书里给了一个成品样例:「下一财季结束前把产品 ABC 的销量提高 20%,手段是增加 10% 的线上广告预算并雇一名数字营销专员」——五个性质逐一对号入座4。

电商例子里,计划阶段的三个 objective 写得很「毕业作品级」:6 个月内线上销售提高 20%、页面加载时间压到 2 秒以内、平台可用性 99.9%5——每个数都可测,这就是 SMART 的实操样子。

3.2 backlog:一张全员可见的待办清单

backlog(待办清单) 是开发团队的「排好优先级的 to-do list」6。它存在的头号理由是透明:所有干系人随时能看到团队在做什么、做到哪了。

两个估点工具,都是相对估算(不比绝对天数,只比「A 比 B 难多少」):

  • story points(故事点):如果任务 B 值 2 点、任务 A 比 B 难一倍,A 就值 4 点7。
  • T-shirt sizing(T 恤尺码):任务按 XS/S/M/L/XL 分档,常用于计划初期快速粗估8。

主线例子的完整走法:三件事进清单后——修结账 bug(影响大,高优先级)、促销横幅(配合营销活动,中优先级)、数据库查询优化(长期改进,低优先级);估点结果:修 bug 3 点、横幅 8 点、优化 13 点9。

3.3 排优先级:六种现成框架,别自己发明

书里列了六种10,最有用的三个:

框架一句话做法书里给的例子
MoSCoW分四档:Must have(没有就失败)/ Should have / Could have / Won't have修结账 bug = Must;安全登录 = Should;头像皮肤 = Could
WSJF优先级 = (业务价值 + 时间紧迫性 + 风险降低)÷ 工作量公式照抄自原文11
RICE得分 = 触达人数 × 影响 × 信心 ÷ 投入照抄自原文12

(Eisenhower 矩阵按「紧急 × 重要」分四格、Kano 模型把功能分「基本/性能/惊喜」三类、价值-投入矩阵找「quick win」——书里各一段带过10。)

3.4 sprint:固定长度的工作节拍

sprint(冲刺) 是 1 到 4 周的固定时间段,团队在这个框里完成一批选定任务13。sprint planning 会上做三件事:定 sprint 长度、把 backlog 里的任务分配进各 sprint、按优先级和人力调整。书里给了一个小项目的三 sprint 编排:sprint 1 搭环境和数据库,sprint 2 写核心功能(认证、后端逻辑、前端组件),sprint 3 集成测试和部署准备14——节奏一目了然:基础设施 → 功能 → 收尾。

协作机制配齐三样:每 sprint 开头开计划会、每天开短站会(昨天做了什么/今天做什么/卡在哪)、sprint 末开评审会15。顺带把工具也定了:Slack/Teams 管日常沟通,Confluence/GitHub 存文档,Jira/Trello 管任务,GitHub/GitLab 管代码16。

3.5 风险:先登记,再分级

风险管理的具体物是两张表。第一张风险登记表(risk register):每条风险记描述、成因、潜在影响、负责人17。第二张风险矩阵(risk matrix):按「概率 × 影响」把风险分高中低三档,决定先处理谁18。识别风险的手段:和干系人头脑风暴、查历史数据、做 SWOT 分析(优势/劣势/机会/威胁)17。电商项目的风险清单书里点了一串:数据泄露和钓鱼攻击、宕机和扩容问题、支付欺诈、供应链中断、客服不足19——注意它不是技术风险清单,是业务风险清单,这说明 DevOps 团队的风险视野本来就包括生意本身。

组队有个容易被忽略的选择题:团队可以是横向(跨职能)的——市场部、工程、财务、客服都进组;也可以是纵向(同部门分层)的——销售总监带经理带代表。书里举了微软做例子:微软最初按 UI、数据、API 等功能划分横向团队,协调成本高;后来转向自治、自管理的纵向团队,减少依赖、聚焦交付完整功能20。

3.6 计划阶段的真正硬核:替后面七个阶段立规矩

这是本章最独特的一节(2.3):计划不是只管计划,它要给每个后续阶段定框架21。

替谁立规矩定什么书中亮点
Code语言选型(看性能、可扩性、团队熟悉度)、编码规范(如 Python 守 PEP 8)、代码评审流程(GitHub PR / Gerrit)、静态扫描(SonarQube/Checkmarx)举了一段「低效 Python」反例:手写 range(len(numbers)) 索引循环22
Build构建工具(Maven/Gradle)、多久构建一次、构建指标(时长、成功率、测试覆盖率)包管理器 npm/pip 保环境一致23
Test测什么类型(系统/验收/性能/安全)、哪些测试自动化、测试环境(dev/staging/prod)谁维护细节留到 Test 阶段再定,计划阶段只定框架24
Release发布走持续式还是排期式、什么叫「可发布」、版本号怎么打、发布说明谁写具体哪版发布什么功能,这时不定25
Deploy蓝绿还是金丝雀、上云还是本地、回滚预案、事故响应责任人扩缩容用什么编排工具(如 Kubernetes)也是这时定26
OperateSLA(服务等级协议,对可用性的承诺)、事故处理流程、runbook(运维手册)、值班表目标一句话:达到 SLA27
Monitor盯哪些指标(响应时间、错误率、资源占用)、报警阈值(超过多少就触发告警)、日志(系统逐条记下的运行记录)怎么收集监控产出回流到下一轮计划——闭环的最后一颗钉28

3.7 三个工具怎么选

  • GitHub Projects:看板形式,列(To Do / In Progress / Done)+ 卡片(issue),与 GitHub 代码库天然一体。小团队、代码已在 GitHub 上,选它29。书里展示了一个电商项目看板:登录页设计、数据库 schema 调研等待办列在三列里30。
  • Jira:Atlassian 出品,可定制 workflow、Scrum/Kanban 板、燃尽图(burndown,看还剩多少活)+ 速率图(velocity,看每个 sprint 完成多少点,用来预测下一 sprint 容量)31。大团队、复杂项目、需要重度定制的,选它32。
  • Azure DevOps(Boards):活在 Azure 生态里的团队(Visual Studio、Azure Pipelines、Application Insights)用它,功能是工作项跟踪 + 查询(如「当前 sprint 里 John Smith 的活跃 bug」)+ 分析视图33。

4. 作者的判断与证据

书里明说的取舍: Jira vs GitHub Projects 的选择标准写得很直白——需要重度定制和报告选 Jira,小团队图省事选 GitHub Projects32;Azure Boards 绑定 Azure 生态33。这是经验性建议,不是实验结论。

引用外部框架的部分:MoSCoW、WSJF、RICE、SMART 全是业界既有框架,书里没有给实证比较(哪种框架在什么团队规模下更有效),只给定义和例子。我们的读法:框架的作用是统一讨论语言,选哪个远不重要,重要的是全员用同一个。

最有分量的一句话是引艾森豪威尔的:「Plans are useless, but planning is indispensable」——计划书会过时,但做计划这个动作让人提前想过所有坑34。这句话是本章真正的论点,前面所有框架都是它的脚注。

5. 边界与局限

  • 本章是「教材式全览」,每种框架都不深:WSJF 的三个分子怎么打分、RICE 的「信心」怎么定,都没展开,要落地得另找材料。
  • 工具部分截图讲解多(Jira 的 workflow 配置、Azure Boards 的查询),知识密度低于概念部分,且工具界面随版本变得很快——书里描述的是 2024–2026 年的界面。
  • 「什么时候不该做细计划」(探索型项目、原型期)书里没讨论;它默认读者面对的是正经交付项目。

6. 可带走的

  1. objective 必须 SMART;「提高销量 20%(6 个月)」是成品,「做好用户体验」不是5。
  2. backlog 用相对估点(story points / T 恤尺码),不要估绝对天数7。
  3. 排优先级直接抄现成框架:MoSCoW 分四档、WSJF 和 RICE 用公式算,别发明轮子10。
  4. sprint 1–4 周一拍,sprint 内三件事:计划会、每日站会、期末评审1315。
  5. 风险管理落到两张表:风险登记表(谁负责)和风险矩阵(先处理谁)17。
  6. 计划阶段要替后面七个阶段各立一份规矩——发布频率、部署策略(蓝绿/金丝雀)、报警阈值,都是开工前定的,不是上线前临时抱佛脚21。
  7. 工具三选一:GitHub 上的小团队用 GitHub Projects;大团队重定制用 Jira;全家在 Azure 用 Azure Boards3233。
  8. 「计划书无用,做计划 indispensable」——文档会过期,思考过程不会34。

7. 原文地图

主题原书章原文位置
计划的定义与电商目标(20%/2s/99.9%)2 - Planningtext/07-ch02-2-planning.txt:31(搜「increase online」)
goal 与 objective 之分2 - Planningtext/07-ch02-2-planning.txt:50(搜「objectives are very specific」)
计划元素(六件)2 - Planningtext/07-ch02-2-planning.txt:95(搜「defining clear objectives of the software product」)
backlog 与估点(story points/T 恤)2 - Planningtext/07-ch02-2-planning.txt:113(搜「prioritized to-do list」) · text/07-ch02-2-planning.txt:142(搜「3 story points」)
六种优先级框架2 - Planningtext/07-ch02-2-planning.txt:151(搜「MoSCoW Method」) · text/07-ch02-2-planning.txt:162(搜「Weighted shortest job first」)
sprint 定义与三 sprint 编排2 - Planningtext/07-ch02-2-planning.txt:177(搜「fixed time period」)
每日站会/评审会2 - Planningtext/07-ch02-2-planning.txt:197(搜「daily meetings where team members」)
SMART 目标2 - Planningtext/07-ch02-2-planning.txt:315(搜「specific, measurable, achievable」)
风险登记表与风险矩阵2 - Planningtext/07-ch02-2-planning.txt:332(搜「risk register」)
横向 vs 纵向团队(微软例)2 - Planningtext/07-ch02-2-planning.txt:344(搜「Horizontal teams」)
替七个阶段立规矩(2.3 全节)2 - Planningtext/07-ch02-2-planning.txt:363(搜「impact on every other stage」)
低效 Python 反例2 - Planningtext/07-ch02-2-planning.txt:385(搜「Inefficient Python code」)
GitHub Projects / Jira / Azure DevOps2 - Planningtext/07-ch02-2-planning.txt:546(搜「Kanban-style board」) · text/07-ch02-2-planning.txt:575(搜「developed by Atlassian」) · text/07-ch02-2-planning.txt:614(搜「Azure ecosystem」)
艾森豪威尔名言2 - Planningtext/07-ch02-2-planning.txt:242(搜「Plans are useless」)

Footnotes

  1. 出处:「2 - Planning」第 10–22 段(text/07-ch02-2-planning.txt:12,搜「running a marathon」)。马拉松训练/预算/选装备是书中类比的原文。 ↩

  2. 出处:「2 - Planning」第 48–52 段(text/07-ch02-2-planning.txt:50,搜「objectives are very specific」)。 ↩

  3. 出处:「2 - Planning」第 313–315 段(text/07-ch02-2-planning.txt:315,搜「specific, measurable, achievable, relevant, and timebound」)。 ↩

  4. 出处:「2 - Planning」第 316–319 段(text/07-ch02-2-planning.txt:316,搜「Increase sales of product ABC by 20%」)。 ↩

  5. 出处:「2 - Planning」第 31–32 段(text/07-ch02-2-planning.txt:31,搜「increase online」)。 ↩ ↩2

  6. 出处:「2 - Planning」第 111–115 段(text/07-ch02-2-planning.txt:113,搜「prioritized to-do list」)。 ↩

  7. 出处:「2 - Planning」第 126–128 段(text/07-ch02-2-planning.txt:126,搜「unit of measure」)。 ↩ ↩2

  8. 出处:「2 - Planning」第 130–132 段(text/07-ch02-2-planning.txt:131,搜「XS (Extra Small)」)。 ↩

  9. 出处:「2 - Planning」第 134–143 段(text/07-ch02-2-planning.txt:135,搜「marketing team requests a new promotional banner」)。三个估点值见第 142 段。 ↩

  10. 出处:「2 - Planning」第 151–156 段(text/07-ch02-2-planning.txt:151,搜「MoSCoW Method」);Eisenhower 矩阵第 157–161 段,Kano 与价值-投入矩阵第 164–174 段。 ↩ ↩2 ↩3

  11. 出处:「2 - Planning」第 162–164 段(text/07-ch02-2-planning.txt:164,搜「Value + Time Criticality + Risk Reduction」)。 ↩

  12. 出处:「2 - Planning」第 170–171 段(text/07-ch02-2-planning.txt:170,搜「reach, impact, confidence, and effort」)。 ↩

  13. 出处:「2 - Planning」第 176–178 段(text/07-ch02-2-planning.txt:177,搜「typically ranging from 1 to 4 weeks」)。 ↩ ↩2

  14. 出处:「2 - Planning」第 183–189 段(text/07-ch02-2-planning.txt:184,搜「goal of the first sprint」)。 ↩

  15. 出处:「2 - Planning」第 196–201 段(text/07-ch02-2-planning.txt:197,搜「daily meetings where team members」)。 ↩ ↩2

  16. 出处:「2 - Planning」第 202–209 段(text/07-ch02-2-planning.txt:202,搜「Slack」)。 ↩

  17. 出处:「2 - Planning」第 325–331 段(text/07-ch02-2-planning.txt:330,搜「brainstorming sessions」)。风险登记表见第 332 段。 ↩ ↩2 ↩3

  18. 出处:「2 - Planning」第 332–334 段(text/07-ch02-2-planning.txt:333,搜「risk matrix」)。 ↩

  19. 出处:「2 - Planning」第 327–329 段(text/07-ch02-2-planning.txt:327,搜「data breaches and」)。 ↩

  20. 出处:「2 - Planning」第 344–353 段(text/07-ch02-2-planning.txt:344,搜「Horizontal teams, also known as cross-functional teams」)。微软例见同页边栏。 ↩

  21. 出处:「2 - Planning」第 360–364 段(text/07-ch02-2-planning.txt:363,搜「significant direct impact on every other stage」)。 ↩ ↩2

  22. 出处:「2 - Planning」第 385–393 段(text/07-ch02-2-planning.txt:386,搜「Example of Inefficient Python code」)。 ↩

  23. 出处:「2 - Planning」第 407–422 段(text/07-ch02-2-planning.txt:412,搜「Maven, Gradle, or Jenkins」)。 ↩

  24. 出处:「2 - Planning」第 424–438 段(text/07-ch02-2-planning.txt:429,搜「system testing, acceptance testing」)。 ↩

  25. 出处:「2 - Planning」第 446–460 段(text/07-ch02-2-planning.txt:449,搜「continuous or scheduled manner」)。 ↩

  26. 出处:「2 - Planning」第 462–488 段(text/07-ch02-2-planning.txt:467,搜「Blue-Green deployments or canary」)。 ↩

  27. 出处:「2 - Planning」第 490–511 段(text/07-ch02-2-planning.txt:496,搜「service-level agreements」)。 ↩

  28. 出处:「2 - Planning」第 513–524 段(text/07-ch02-2-planning.txt:518,搜「response time, error rates」)。 ↩

  29. 出处:「2 - Planning」第 543–547 段(text/07-ch02-2-planning.txt:544,搜「integrated directly into the GitHub platform」)。 ↩

  30. 出处:「2 - Planning」第 566–572 段(text/07-ch02-2-planning.txt:566,搜「E-commerce Project」)。 ↩

  31. 出处:「2 - Planning」第 590–592 段(text/07-ch02-2-planning.txt:590,搜「Burndown chart shows」)。 ↩

  32. 出处:「2 - Planning」第 607–611 段(text/07-ch02-2-planning.txt:607,搜「preferred solution over GitHub Project」)。 ↩ ↩2 ↩3

  33. 出处:「2 - Planning」第 613–630 段(text/07-ch02-2-planning.txt:614,搜「developed, deployed, and managed in the Azure ecosystem」)。 ↩ ↩2 ↩3

  34. 出处:「2 - Planning」第 240–247 段(text/07-ch02-2-planning.txt:242,搜「Plans are useless」)。 ↩ ↩2

为什么是 DevOps:一道没人修的墙

Previous Page

版本控制:从抄目录到 Git 的对象存储

Next Page

On this page

计划阶段:开工之前把规矩定完1. 这一章讲什么2. 顶层全景3. 核心原理3.1 目标分两种:愿景(goal)和台阶(objective)3.2 backlog:一张全员可见的待办清单3.3 排优先级:六种现成框架,别自己发明3.4 sprint:固定长度的工作节拍3.5 风险:先登记,再分级3.6 计划阶段的真正硬核:替后面七个阶段立规矩3.7 三个工具怎么选4. 作者的判断与证据5. 边界与局限6. 可带走的7. 原文地图Footnotes