INFO6007 Week 02 项目管理方法论讲课总结
INFO6007 Week 02 讲课总结：项目管理方法论
课程：INFO6007 — Project Management in IT，Semester 2 2026 讲义：
Lecture - INFO6007 Week 02 - PM Methodologies.pdf（55 页）本讲三条主线：项目生命周期五阶段 → 五种方法论（Waterfall / Agile / Scrum / Kanban / DevOps） → 需求收集与项目启动。
这一讲是 Week 03 Tutorial 的直接考纲 —— 那份 tutorial 的三个部分（Agile vs Waterfall 对比、Power/Interest 网格、需求收集技术）全部出自本讲。
一、Week 1 Muddy Card 答疑：Scope vs Impact
问题：范围（scope）是不是就等于项目的影响（impact）？
| 定义 | 关键差异 | |
|---|---|---|
| Scope（范围） | 项目将交付什么 —— 哪些工作包含在内、哪些排除 | 通常在项目团队的控制之内 |
| Impact（影响） | 这些交付物产生的更广泛的变化或收益 | 往往在实施之后才显现，且可能受外部因素左右 |
讲义的学生预约系统例子：
- Scope：为三个大学诊所设计并实现一个在线预约门户
- Impact：候诊时间缩短、行政错误减少、学生满意度提升
这个区分很有用：范围是你能承诺的，影响是你希望发生的。 💡 它也解释了为什么 Week 01 讲的「项目成功」要包含 business value 和 user adoption 这些维度 —— 那些都是 impact 层面的，不在 scope 里。
二、项目生命周期五阶段
Project Lifecycle 是项目从开始到结束所经历的结构化阶段序列，提供清晰的路线图以有效管理工作、降低风险、确保成功。
这正是 Week 01 课后题第 1 题（「项目生命周期的五个阶段是什么」）的答案 —— Week 1 讲义只把 Project Lifecycle 列为框架组成之一而没展开，答案在这里。
| # | 阶段 | 目的 | 输出 |
|---|---|---|---|
| 1 | Initiation / Defining（启动/定义） | 在高层次定义项目并评估其可行性 | 项目获批并被正式启动 |
| 2 | Planning（规划） | 建立指导团队的全面计划 | 获批的项目管理计划 |
| 3 | Execution（执行） | 按计划执行实际工作 | 交付物被开发和评审 |
| 4 | Monitoring & Controlling（监控） | 跟踪绩效并按需调整 | 状态报告、更新、纠偏措施 |
| 5 | Closure（收尾） | 收尾项目、交付成果、复盘 | 最终项目报告、经验教训、客户签字 |
记忆线索：定义（做不做）→ 规划（怎么做）→ 执行（做）→ 监控（做得对不对）→ 收尾（做完了）。 注意 Closure 的输出里有「lessons learned」和「client sign-off」 —— 收尾不只是交付，还要复盘和拿到正式签字。
三、方法论总览
Project Management Methodologies 是用于规划、执行和管理项目的结构化方法或实践体系，提供可复用的框架指导团队从头到尾成功交付。
为什么重要：保证一致性与可预测性；改善团队协作；管理风险、时间和成本；使工作与业务目标对齐。
四、Waterfall（瀑布模型）
线性、顺序的方法论，每个阶段必须完成后下一个才能开始。 它是最早、最传统的方法之一，常用于工程、建筑和结构化的 IT 项目。
六个阶段
| # | 阶段 | 说明 |
|---|---|---|
| 1 | Requirements Gathering | 所有需求前期一次性收集完毕，此阶段结束后不预期再有变更 |
| 2 | Systems Design | 创建高层与详细设计 —— 架构、组件、数据模型 |
| 3 | Implementation（Coding） | 开发者根据设计文档写代码，通常按模块或组件进行 |
| 4 | Testing | 测试缺陷、bug 和性能；含单元、集成、系统测试 |
| 5 | Deployment | 交付给用户或迁入生产环境 |
| 6 | Maintenance | 部署后修复问题、更新软件、提供支持 |
优缺点
| ✅ 优点 | ⚠️ 缺点 |
|---|---|
| 简单易懂易用 | 开发一旦开始就不灵活，无法应对变更 |
| 里程碑和文档清晰 | 难以退回到前一阶段 |
| 适合范围固定、需求稳定的项目 | 测试推迟，会在后期才暴露问题 |
| 政府、建筑、合规要求高的项目的理想选择 | 不适合动态或演进中的需求 |
场景例 #1：HRMS 系统（为什么选瀑布）
背景：500 人的中型制造企业要用新的 HRMS 替换过时的纸质系统，含员工档案、薪资处理、休假管理、绩效跟踪四个模块。 高层规定严格的 8 个月工期，范围和预算前期已明确定义。选定的供应商要求在动工前拿到详细需求规格文档。公司没有敏捷经验，偏好结构化的线性交付流程。
为什么选瀑布：
- 需求已被充分理解且不太可能变
- 项目成功依赖完整的文档
- 干系人偏好每个阶段的正式审批
- 开发是外包的，需要清晰的交接
最后一条是关键判据：外包 = 需要白纸黑字的交接边界 = 偏向瀑布。 💡 这条逻辑在 Week 03 Tutorial Part A 的医疗 App 题里再次出现 —— 合规和外包都是「把需求钉死」的力量。
五、Agile（敏捷）
灵活、迭代的项目管理方法，主要用于软件开发和动态项目环境。 与瀑布这类僵化线性模型不同，敏捷把项目拆成小的、可管理的增量，称为 sprint 或 iteration。
讲义特别强调的一句： "Remember, it is not a management technique but a mindset!" （记住，它不是一种管理技术，而是一种心态！）
💡 这正是 Week 03 讲义开场答疑的内容 —— Agile 是心态，Scrum 是把它落地的框架。
六、Scrum
Scrum 是一个敏捷框架，在称为 Sprint 的时间盒定迭代（通常 1 到 4 周）中交付工作，聚焦经验性过程控制、团队协作和持续反馈。
四个关键组成
| 组成 | 说明 |
|---|---|
| Sprint | 时间盒定的开发周期，通常 1–4 周 |
| Product Backlog | 所有期望功能的清单，由 Product Owner 维护 |
| Sprint Backlog | 当前 Sprint 要完成的任务清单 |
| Increment | Sprint 结束时「潜在可发布」的产品 |
三个角色
| 角色 | 职责 |
|---|---|
| Product Owner | 定义功能、管理 backlog、排定优先级 |
| Scrum Master | 辅导团队、主持 Scrum 事件、扫除障碍 |
| Scrum Team | 跨职能成员，做实际工作 |
区分 PO 和 SM 是高频考点： PO 管「做什么」（What）—— 面向价值和优先级； SM 管「怎么顺畅地做」（How well the process runs）—— 面向流程和障碍。 SM 不是项目经理，不指派任务。
四个事件
| 事件 | 说明 |
|---|---|
| Sprint Planning | 定义本 Sprint 要做什么 |
| Daily Stand-up | 15 分钟的快速同步（讲义原文：usually over a coffee） |
| Sprint Review | 向干系人展示成果 |
| Sprint Retrospective | 复盘并改进 |
Review vs Retrospective 极易混淆： - Sprint Review = 看「产品」 —— 对外，给干系人演示做出来的东西 - Sprint Retrospective = 看「过程」 —— 对内，团队反思怎么做得更好
💡 这个「产品 vs 过程」的二分，和 Week 05 质量管理里 QC（管产品）vs QA（管过程） 是同一种思维。
场景例 #2：学生 App（为什么选 Scrum）
背景：大学 IT 部门获得资金开发一款提升学生参与度的手机 App，整合活动通知、校园地图、同伴消息、反馈问卷。用户是在校学生和教职工。 需求随各院系提出而演进。Product Owner 强调增量交付，让学生能定期测试并给反馈。App 须在 4 个月内上线，核心功能优先交付。
为什么选 Scrum：
- 需求前期未固定
- 优先级随学生反馈变化
- 需要频繁演示和干系人输入
- 团队小而跨职能
- 价值交付重于文档
💡 注意这个场景和 Week 02 Tutorial 的 UniConnect 几乎是同一个东西 —— 都是大学学生 App、都有课表/地图/通知类功能。tutorial 让你做三重约束权衡，讲义让你判断方法论选型。
七、Kanban
可视化的工作流管理方法，聚焦持续交付、限制在制品（WIP）和工作流透明度。
四个关键要素
| 要素 | 说明 |
|---|---|
| Kanban Board | 追踪任务经过各阶段的可视化看板（To Do → Doing → Done） |
| Cards / User stories | 单个任务或工作项 |
| WIP Limits | 限制每一列的条目数量，防止过载 |
| Cycle Time | 一个任务从开始到完成所花的时间 |
WIP Limit 是 Kanban 最核心也最反直觉的机制： 它通过「不许同时做太多事」来提速 —— 因为在制品越多，切换成本越高、瓶颈越隐蔽。 Cycle Time 则是 Kanban 的主要度量指标（相当于 Scrum 的 velocity）。
场景例 #3：客服工单（为什么选 Kanban）
背景：成长中的软件公司想改进客服工单处理流程。目前工单堆在 backlog 里常被延误，支持团队难以排优先级和平衡工作量。 5 名客服处理 bug 报告、功能请求和用户问题。公司想要一个可视化系统追踪工单进度、限制 WIP、持续改进效率。 解决工单没有严格截止期，但希望缩短响应时间、提升客户满意度。
为什么选 Kanban：
- 工作是持续流动的，没有固定长度的迭代
- 能随时处理新进工单的灵活性
- 可视化管理任务以识别瓶颈
- 限制 WIP 以避免客服过载
- 强调持续改进（Kaizen）
判据就在「没有严格截止期 + 工作随时到达」这两点上： Scrum 的 sprint 需要「一批工作打包做两周」，而客服工单是随机到达的 —— 硬套 sprint 反而别扭。
Scrum vs Kanban 六维对比（必背）
| 维度 | Scrum | Kanban |
|---|---|---|
| 结构 | 时间盒定的 Sprint | 持续流动（continuous flow） |
| 角色 | 有明确定义（PO、SM、Team） | 不要求特定角色 |
| 工作量 | 按 sprint 计划 | 按产能拉取（pulled as capacity allows） |
| 变更处理 | Sprint 期间受限 | 任何时候都允许变更 |
| 可视化管理 | 看板可选 | 看板是强制的 |
| 最适合 | 需要结构的团队 | 需要灵活性的团队 |
最容易考的两行是「变更处理」和「可视化管理」： Scrum 在 sprint 内冻结范围（这是它提供可预测性的代价）；Kanban 随时可变（这是它牺牲可预测性换来的）。 看板对 Scrum 是可选的，对 Kanban 是定义性的。
八、DevOps
一组把软件开发与 IT 运维整合起来的实践，以缩短开发生命周期、提高部署频率、持续交付高质量软件。
DevOps = Development + Operations
四个主要目标
- 更快的交付周期（CI/CD）
- 团队间协作改善
- 自动化的测试、部署和监控
- 基础设施即代码（IaC），实现可扩展性与可靠性
场景例 #4：电商公司（为什么选 DevOps）
背景：中型电商公司苦于发布缓慢和频繁的生产事故。传统开发与运维团队各自为政（silos）：开发写完代码就 "throw it over the wall"（扔过墙） 给运维去部署和维护。 公司希望加快发布周期、改善协作、提升系统稳定性，决定实施 DevOps 文化与实践，包括 CI/CD、IaC、自动化测试和监控。
为什么选 DevOps：
- 需要更快、更可靠的软件交付
- 希望打破孤岛、改善沟通
- 减少人为错误和部署风险
- 改善可扩展性和基础设施管理
"throw it over the wall" 这个说法值得记 —— 它精准描述了 DevOps 要解决的那个问题：开发和运维的目标是冲突的（开发要快速上新，运维要系统稳定），孤岛式组织让这个冲突无法调和。
三种方法论的形态对比（讲义 p31）
| 方法论 | 形态 |
|---|---|
| Waterfall | Design → Code → Test → Deploy（一次走完） |
| Agile | Design →（Code → Test）×N → Deploy（开发测试反复迭代，最后统一部署） |
| DevOps | （Design → Code → Test → Deploy）×N（连部署也进入循环） |
这三行揭示了演进的实质： 敏捷把「开发+测试」变成了循环，DevOps 进一步把「部署」也拉进了循环。 这就是为什么 DevOps 谈的是「部署频率」而敏捷谈的是「迭代周期」。
为什么 DevOps 对项目管理重要
收益：加速交付与创新、自动化与效率、跨职能协作改善、可靠性与一致性、更好的监控与质量控制、治理/安全/合规、支持敏捷与持续实践。
💡 DevOps 之外：现代 IT 的新兴文化
这些新文化把 DevOps 原则扩展到特定领域：
| 名称 | 关注点 |
|---|---|
| DevSecOps | 在开发早期就加入安全 |
| DataOps | 帮团队快速可靠地管理和移动数据 |
| MLOps | 更容易地构建、测试和运行 ML 模型 |
| AIOps | 用 AI 自动发现和修复 IT 问题 |
| GreenOps | 让 IT 系统更节能 |
| TestOps | 把测试纳入每一步，尽早发现 bug |
| GitOps | 用 Git 安全地自动化软件部署 |
| FinOps | 与财务团队一起追踪和控制云支出 |
💡 DevSecOps 和 FinOps 值得多留意 —— 前者呼应 Week 05 的 ISO 27001「安全是 IT 质量的核心组成」，后者呼应 Week 04 的「云成本按用量计费，不监控就不可预测」。
九、需求收集
Requirement Gathering 是识别、收集和记录干系人对新系统或产品的需求与期望的过程。
为什么重要
- 确保最终产品满足干系人需求
- 减少范围蔓延和返工
- 为设计、开发和测试奠定基础
- 促进更好的项目规划与估算
五种技术（Week 3 Tutorial 直接考）
| 技术 | 说明 |
|---|---|
| Interviews | 与干系人一对一 |
| Surveys / Questionnaires | 快速收集广泛输入 |
| Workshops | 协作式的小组会议 |
| Observation | 观察用户与现有系统的交互 |
| Document Analysis | 审阅既有的系统/流程文档 |
⚠️ 注意与 Week 03 讲义的差异： Week 3 的「收集需求」过程列的五种是：Interviews、Workshops、Surveys、Prototyping、Observation。 Week 2 这里列的是：Interviews、Surveys、Workshops、Observation、Document Analysis。
四种重合，各有一种独有：Week 2 有 Document Analysis，Week 3 有 Prototyping。 答题时把六种都写上最保险。
课堂讨论：医院预约系统
场景：医院要用数字系统替换纸质门诊预约系统。接待员管理预约、护士记录病人到达、医生申请复诊，病人也能在线查看或改约。 ⚠️ 项目团队只有三周时间收集需求。约束条件： - 五个诊所的员工流程略有不同 - 既有的流程手册已过时 - 部分员工太忙，无法参加长会 - 系统还须满足老年患者和英语能力有限患者的需求
分析框架（按约束选技术）
| 约束 | 应对的技术 |
|---|---|
| 五个诊所流程不同 | Observation —— 实地观察各诊所的真实做法，因为「他们说的」和「他们做的」往往不一致 |
| 手册已过时 | ⚠️ Document Analysis 的价值被削弱 —— 可以读，但不能当作事实来源，必须用观察去校验 |
| 员工太忙开不了长会 | Surveys 覆盖广度 + 短时定向 Interviews 深挖关键角色；避免长时间的 workshop |
| 老年患者与英语受限患者 | 这类用户很难通过问卷触达 —— 必须用 Observation 和一对一 Interview，且要考虑无障碍与多语言需求 |
| ⚠️ 只有三周 | 并行推进：问卷同时发给全部五个诊所，观察与访谈同步安排 |
这道题的核心考点是「技术选型要匹配约束，而不是全部都用一遍」： 手册过时 ⇒ 文档分析不可靠；员工忙 ⇒ 不能靠研讨会；弱势用户 ⇒ 问卷够不着。 能指出「哪种技术在这个场景下用不了、为什么」，比罗列五种技术更能得分。
十、项目启动 / 定义阶段
目的
- 明确「在做什么」和「为什么做」
- 获得干系人和领导层的支持（buy-in）
- 为规划、执行和成功衡量提供基线
九项关键活动
| 活动 |
|---|
| 识别业务需求或问题 |
| 定义项目目标 |
| 定义高层范围 |
| 识别干系人 |
| 任命 PM 和关键角色 |
| 制定项目章程（Project Charter） |
| 确定高层预算和时间线 |
| 进行初步的风险与可行性分析 |
| 与组织战略对齐 |
项目章程（Project Charter）
正式文件，用以授权项目并赋予项目经理动用组织资源的权限。
目的：
- 确立清晰的项目愿景
- 对齐干系人并获得高管支持
- 为规划提供高层路线图
- 在整个项目中充当参照点
所用工具：专家判断、商业论证（Business Case）、事业环境因素、组织过程资产。
「授权 + 赋权」是章程的本质： 它不只是说明项目要做什么，更重要的是它让 PM 有权调动资源。 没有章程，PM 的指令没有正式依据。
干系人识别与参与
干系人是任何影响项目或被项目影响的人 —— 无论正面还是负面。 例子：客户、发起人、团队成员、供应商、监管方等。
为什么重要：确保早期支持；管理期望与影响力；降低阻力、改善沟通；使项目目标与干系人利益对齐。
五项关键活动
| 活动 | 做法 |
|---|---|
| Identify（识别） | 头脑风暴、专家判断、文档 |
| Analyze（分析） | 确定权力、利益和影响力 |
| Prioritize（排序） | 用 Power/Interest Grid 等工具分类 |
| Engage & Communicate | 按干系人类型定制策略 |
| Monitor（监控） | 随干系人需求变化调整计划 |
Power/Interest Grid 的四象限策略在 Week 03 Tutorial Part B 有完整解答（含「学生利益高但权力低 ⇒ Keep Informed」这个反直觉的考点）。
定义阶段的工具与技术
专家判断、头脑风暴与研讨会、SWOT 分析、干系人分析、会议与访谈。
项目启动的七个常见挑战
「甚至在规划开始之前，项目就可能失足。」
- 目标和范围不清
- 缺乏高管支持
- 干系人参与不足
- 商业论证不完整或薄弱
- 不切实际的时间线和预算
- 角色与职责未定义
- 风险意识不足
💡 对照 Week 01 的 Aurora Tech 案例：它的四个失败原因里，「范围蔓延（无变更管理）」和「干系人参与不足」两条，根子都在启动阶段没做好。
十一、知识领域 × 生命周期阶段矩阵（讲义 p41）
讲义说这张表 "Will be revealed gradually" —— 它就是整个课程的路线图。
| 知识领域 | Defining | Planning | Execution | Monitoring & Controlling | Closure |
|---|---|---|---|---|---|
| Integration | 项目章程 | 项目管理计划 | 指导工作 | 变更控制 | 最终移交 |
| Scope | 初始范围构想 | 范围规划、创建 WBS | — | 范围确认、范围控制 | 确认交付物 |
| Time | — | 定义活动、排程、进度估算 | 管理进度 | 监控进度 | — |
| Cost | — | 预算与估算 | 支出 | 成本跟踪与控制 | 最终成本收尾 |
| Quality | — | 质量管理计划 | 质量保证（QA） | 质量控制（QC） | 质量收尾报告 |
| Resource | — | 资源管理计划 | 组建与管理团队 | 监控团队绩效 | 释放资源 |
| Communication | 识别干系人 | 沟通管理计划 | 分发信息 | 绩效报告 | 最终沟通 |
| Risk | 识别高层风险 | 风险识别、应对计划 | 实施应对 | 监控风险 | 风险收尾 |
| Procurement | — | 采购管理计划 | 实施采购 | 合同管理 | 关闭合同 |
| Stakeholder | 识别干系人 | 干系人参与计划 | 管理参与 | 监控参与 | 获得满意度 |
从这张表能读出三件事
| 观察 | 说明 |
|---|---|
| Planning 和 Monitoring & Controlling 两列没有任何空格 | 印证讲义那两句：「Planning 是知识密集度最高的阶段，几乎所有知识领域都深度参与」「Monitoring & Controlling 触及几乎每一个知识领域」 |
| Defining 列空格最多（10 个领域里有 5 个不参与） | 启动期只有 Integration、Scope、Communication、Risk、Stakeholder 五项介入 —— 时间、成本、质量、资源、采购在这一阶段还谈不上 |
| Execution 只有 Scope 是空的；Closure 只有 Time 是空的 | 执行期不「做范围」（范围在规划期定好，执行期只是照做）；收尾期没有进度工作（进度到交付就结束了） |
全表共 7 个空格（Defining 5 个 + Execution 1 个 + Closure 1 个）。
一个很实用的记忆抓手：Quality 那一行完美对应 Week 05 的三大过程 —— 规划期的质量管理计划、执行期的 QA、监控期的 QC。
十二、课后思考题与案例
讲义给的 5 道题
- 项目启动阶段的主要目的是什么？
- 列举项目章程中包含的三个关键要素。
- 为什么干系人识别在启动阶段很重要？
- 项目方法论如何影响项目启动？
- 描述 Power/Interest Grid 及其用法。
💡 第 5 题的完整答案在 Week 03 Tutorial： 高权力+高利益 → Closely Manage；低权力+高利益 → Keep Informed；高权力+低利益 → Keep Satisfied；低权力+低利益 → Monitor。
💡 第 4 题的答题方向：方法论决定了启动阶段要把需求钉多死 —— 瀑布要求前期完整的需求规格和正式审批；敏捷只要一个高层愿景和初始 backlog；两者的项目章程详细程度完全不同。
案例：电商平台项目
背景：你被任命为某中型公司新电商平台项目的 PM。 - ⚠️ CEO 要求 6 个月内完成，但详细需求尚未定义 - 市场团队急于开始 - IT 部门对平台可行性没把握 - ⚠️⚠️ 还没有正式的项目章程
① 立即要做的三步
| 步骤 | 理由 |
|---|---|
| 1. 制定项目章程 | 这是最紧迫的一步 —— 没有章程，PM 没有正式授权，也没有共同的项目定义 |
| 2. 识别并分析干系人 | CEO、市场、IT 三方的期望已经出现分歧，必须先摸清权力与利益格局 |
| 3. 进行可行性与初步风险分析 | 直接回应「IT 部门对可行性没把握」 —— 用它把「6 个月」这个数字拉回现实 |
② 干系人与 Power/Interest 定位
| 干系人 | 定位 | 策略 |
|---|---|---|
| CEO / 发起人 | 高权力 + 高利益 | Closely Manage |
| IT 部门负责人 | 高权力 + 高利益（技术可行性的把关人） | Closely Manage |
| 市场团队 | 低/中权力 + 高利益 | Keep Informed |
| 终端客户 | 低权力 + 高利益 | Keep Informed |
| 财务 | 高权力 + 低利益 | Keep Satisfied |
| 供应商 / 支付服务商 | 低权力 + 低利益（初期） | Monitor |
③ 场景中体现的启动挑战
对照讲义的七个挑战，这个案例一次命中了四个：
| 挑战 | 场景中的表现 | 应对 |
|---|---|---|
| 目标和范围不清 | 详细需求未定义 | 先做需求收集（访谈 CEO 与市场，观察现有流程） |
| 不切实际的时间线 | 6 个月是 CEO 拍的，没有依据 | 用高层估算和可行性分析验证，必要时分期交付 |
| 角色与职责未定义 | 没有章程 ⇒ 没有正式授权 | 章程里明确 PM 权限和关键角色 |
| 风险意识不足 | IT 对可行性没把握却仍在推进 | 把技术可行性列为首要风险，做原型验证 |
④ 可预见的风险
| 风险 | 评估方式 |
|---|---|
| 技术可行性风险 | 最高优先级 —— 做技术原型 / PoC 验证平台选型 |
| 范围蔓延 | 需求未定义 + 市场团队急切 = 范围蔓延的温床；用范围说明书写明 exclusions 预防 |
| 进度风险 | 6 个月的可达性 —— 用三点估算给出区间而非单点承诺 |
| 干系人冲突 | 市场（要快）vs IT（要稳） —— 需要 CEO 层面的仲裁机制 |
这道题最该答出的一句话： 「在需求未定义的情况下承诺 6 个月的期限，本身就是最大的风险。」 正确做法不是硬接，而是先做可行性和高层估算，用数据和 CEO 重新谈期限或范围 —— 这正好呼应 Week 02 Tutorial 的三重约束权衡：时间固定就必须让范围可变。
十三、考点重点
- 项目生命周期五阶段及各自的目的与输出：启动 → 规划 → 执行 → 监控 → 收尾。这是 Week 1 课后题第 1 题的答案。
- Scope vs Impact：范围在团队控制内，影响在实施后显现且受外部因素左右。
- 瀑布六阶段及优缺点；选型判据：需求稳定、需完整文档、要正式审批、外包需清晰交接。
- Agile 是心态不是技术。
- Scrum 的四组成、三角色、四事件；Sprint 1–4 周、Daily Stand-up 15 分钟。
- Sprint Review（看产品，对外）vs Sprint Retrospective（看过程，对内）。
- Kanban 四要素；WIP Limit 是核心机制，Cycle Time 是核心度量。
- Scrum vs Kanban 六维对比，尤其变更处理（sprint 内冻结 vs 随时可变）和看板（可选 vs 强制）。
- 三种方法论的形态：瀑布一次走完；敏捷「开发+测试」循环；DevOps 连部署也进循环。
- DevOps 四目标：CI/CD、协作、自动化、IaC；要解决的是「throw it over the wall」的孤岛问题。
- 八种衍生 Ops 文化，至少记住 DevSecOps、MLOps、FinOps。
- 需求收集五技术（本讲版本含 Document Analysis）；⚠️ Week 3 讲义的版本含 Prototyping —— 答题时六种都写。
- 需求收集技术选型要匹配约束，能说出「哪种在此场景下用不了、为什么」。
- 项目章程 = 授权项目 + 赋予 PM 动用资源的权限。
- 干系人管理五活动：识别 → 分析 → 排序（Power/Interest Grid） → 参与沟通 → 监控。
- 启动阶段的七个常见挑战。
- 知识领域 × 阶段矩阵：Planning 和 Monitoring & Controlling 两列全满；Defining 列只有 5 个领域参与。
十四、本讲在课程中的位置
| Week | 内容 | 与本讲的关系 |
|---|---|---|
| 1 | 导论、三重约束、三层管理 | 本讲补上了 Week 1 未展开的「生命周期五阶段」 |
| 2 | 方法论、需求收集、项目启动 | — |
| 3 | 范围管理 + 进度管理 | 「收集需求」和「WBS」是本讲启动阶段的下一步 |
| 4 | 成本管理 | 矩阵里 Cost 那一行的展开 |
| 5 | 质量管理 | 矩阵里 Quality 那一行的展开（计划 / QA / QC） |
本讲的配套练习是 Week 03 Tutorial —— 其三个部分完全对应本讲的三块内容：
Week 3 Tutorial 出自本讲 Part A 医疗 App 的 Agile vs Waterfall 对比 第四、五节的方法论对比与选型 Part B 选课系统的 Power/Interest 矩阵 第十节的干系人识别与排序 Part C 需求收集策略汇总 第九节的五种技术 这也再次印证了本课程 tutorial 恒比 lecture 慢一周的规律（由 Week 2 tutorial 答案原文 "Drawing from Week 1 lecture" 明确写明）。