4. 敏捷专题
4.1 什么是敏捷
敏捷（适应型生命周期）是指采用迭代或增量的方式开发项目产品，在需求不明确的情况下，主动快速的响应变化的一种开发方式
4.2 敏捷开发模型
4.3 敏捷方法VS预测生命周期
4.4 敏捷四大价值观
- 个体和交互 胜过 流程和工具
- 可工作的软件 胜过 面面俱到的文档
- 客户合作 胜过 合同谈判
- 响应变化 胜过 遵循计划
价值1：个体和交互胜于流程和工具
- 强调以人为本，强调人与人之间的沟通与协作
- 重视个体潜能的激发和团队的高效协作作
- 流程和工具重要，但是无法替代有能力的个体和高效的互动
价值2：可工作的软件胜过面面俱到的文档
- 目标导向，目标就是：可工作的软件
- 做必要的文档，以传递必要的信息
- 以小步增量的方式构建产品，做一些设计、分析然后开发、测试以验证设计
价值3：客户合作胜于合同谈判
- 客户为先，但客户不是上帝，客户更不是敌人
- 要超越谈判并尝试提升与客户的合作
- 建立以合作为基础的关系，而不是公司正式的接口
价值4：响应变化胜于遵循计划
- 拥抱变更、变更是创新的来源
- 变更创造价值、为客户或产品带来价值
- 欢迎需求变化、哪怕是在项目后期
4.4 敏捷的12条原则
原则1：我们的首要任务是通过早期和持续交付有价值的软件来满足客户
• 要点：客户满意、有价值、持续交付
原则2：欢迎变更，即使到了开发后期，利用需求变更为客户获得竞争优势
• 要点：持续拥抱变更、保持灵活性以随时适应变化
原则3：经常交付可工作的软件，几周到几个月不等，时间间隔越短越好
• 要点：经常交付、尽早交付、越快越好（1-4周）、消除“惊讶”
原则4：业务人员和开发人员必须自始至终共同完成项目的日常工作
• 要点：业务与开发全程合作、团队与客户需要彼此理解
原则5：由被激励的个体去完成项目。给予需要的支持和环境，相信他们能够完成工作
• 要点：激励、支持，个体比流程更重要
原则6：面对面地交谈是开发团队中最有效的信息交流方式
• 要点：交互式沟通、文档代替不了交谈
原则7：可工作软件是项目进展状况的主要度量
• 要点：度量标准、目标导向、可工作的软件
原则8：提倡可持续的开发。发起人、开发人员和用户应该始终保持步调稳定
• 要点：可持续开发、稳定的速度、不透支明天的精力
原则9：对卓越技术和良好设计的持续关注有助于提高项目的敏捷性
• 要点：保持设计的清晰、高效和变更的灵活性、重构以加强根基
原则10：追求极简化，尽量减少不必要的工作
• 要点：轻文档，轻流程，重产出，重目标（MVP）
原则11：最好的架构、需求和设计都源于自组织的团队
• 要点：共同的目标，共同承担责任，共同解决问题
原则12：团队定期反映如何提高工作效率，然后相应地调整其行为
• 要点：不断学习、持续改进、反思与调整、回顾会议
4.5 敏捷中的3345
3个角色：
- 产品负责人（
Product Owner） - 敏捷教练（
Scrum Master） - 团队（
Scrum Team）
3个工件：
- 产品待办项（
Product Backlog） - 迭代功能开发列表（
Sprint Backlog） - 燃尽图（
Burn-down Chart)
4个仪式：
- 迭代计划会议（
Sprint Planning Meeting） - 每日站会（
Daily Meeting） - 迭代评审会议（
Sprint Review Meeting） - 迭代回顾会议（
Sprint Retrospective Meeting）
5个价值观：
- 承诺 – 愿意对目标做出承诺，并信守承诺
- 专注 – 全身心的投入到你承诺的工作
- 开放 – SCRUM中一切信息对所有人开放，让问题无所隐藏
- 尊重 – 每个人都有独特的背景和经验，尊重他人，信任他人
- 勇气 – 有勇气做出承诺，履行承诺，敢于拒绝，并接受尊重
4.5.1 3个角色
产品负责人 (Product Owner)
Product Owner的核心工作对团队对外交付的价值负责，是PB列表的唯一责任人。
• 清晰的表述产品待办列表项、确保团队成员清晰理解
• 定义需求及需求优先级、验收标准、确保需求的价值
• 定义产品发布内容与日期
• 客户不能直接对PB进行排序，只能提供输入
• PO可以直接拒绝团队的可交付成果
• 如遇到干系人要增加需求，先由PO来判断价值，不能由团队直接决定做不做
敏捷教练(Scrum Master)
Scrum Master的核心工作是帮助团队遵循Scrum 框架，扫除障碍，提供帮助与支持 。
• 清除障碍，仆人式的领导
• 团队出现问题与冲突，先团队自组织的解决
• 团队士气低落，SM要去激励团队，此时无法靠自组织
• 保护团队免受外界打扰
• 客户、高层等对敏捷文化、原则误解，需要SM来进行宣导，告知价值的正确性
团队(Scrum Team)
Scrum team 对交付成果负责，在每个 Sprint 结束时交付潜在可发布且“完成”的产品增量。
• 自组织团队，不认可任何头衔，特征符合塔克曼团队发展阶梯模型
• 团队首先要敏捷（5-9人），没有子团队、人多建议分解
• 团队自己决定做什么、做估算，不是由PO或者SM来进行分配或估算
• 质量保证的工作是由团队来做，不是靠PO频繁的检查
• 当团队发现一个好方法的时候，SM引导，然后由团队来决定是否采纳
• 如果团队士气低下，则不能依靠自组织，需要SM的介入
• 拥有解决全部问题的所有技能，SM要培养团队跨职能技能
4.5.2 3个工件
产品待办事项 (Product Backlog)
Product Backlog即产品视角的完整需求清单。
• PO是唯一负责人，包括增删及优先级。
• 用户故事是其中一种最佳实践。
• 每项需求都需要描述其外部价值，并用用户语言加以描述。
• 遇到新需求都要放到PB表中重新排序。
Sprint 待办事项 (Sprint Backlog)
Sprint Backlog即此次迭代周期内规划要完成的内容。
• 来源于Product Backlog。
• 由团队评估和选择Product Backlog中哪些放入Sprint Backlog。
• 团队需要一起定义“完成”的标准。
• 每个团队成员都可以更改Sprint Backlog，是团队的资产。
燃尽图（ Burn-down Chart)
Burn down Chart 显示了Sprint中累积剩余的工作量，是一个反映工作量完成状况的趋势图。
• Sprint开始的时候，团队会定义当前迭代的全部任务。
• 每天结束时，剩余任务会减少。
• 最后一天结束，累积剩余工作是为0，迭代结束。
燃起图（ Burn-up Chart)
Burn up Chart展现项目时间与已完成的工作之间的关系。
• 燃起图有助于展示团队的工作成果
• 可以区分不同角色展现工作量的完成状况。
• 可以度量项目的迭代速率和工作效率。
4.5.3 4个仪式
冲刺（Sprint ）
冲刺或迭代是一个特殊的事件，或者说其一个容器事件，后续四个事件（仪式）包含在其中。
• 固定周期（2-4周），固定时间开始，固定时间结束
• 固定时间盒，如果有需求没做完的也不能延长时间交付
• 按优先级做事，每次交付的是有价值的产品
• 如果当前有一些工作无法完成，尽力按照高优先级的事项先做，等到回顾会再去梳理问的原因，在下一个迭代进行调整。
Sprint规划会 (Sprint Planning Meeting) 时间盒：2小时/周
Sprint规划会的核心议题是定义下一次冲刺要实现的目标和范围。
• 确定 Sprint的目标、工作方法、工作量。
• 对产品backlog 中 item 进行估算，以确定是否放入迭代周期。
• 对于需求不清楚的 item，请 Product Owner 说明。
• 输入是 Product backlog，输出是 Sprint backlog。
• Part1：需要做什么，产品负责人向开发团队介绍排好序的产品待办事项，由整个Scrum团队共同理解这些工作（PO\SM\TEAM）
• Part2：决定如何做，团队成员根据PB，确定产品增量，进行任务分解，并形成Sprint backlog(SM\TEAM)
每日站会 (Sprint Daily Standup) 15分钟/日
站会的目标是促进信息在团队内共享与透明。
• 从昨天的站立会到现在，我完成了什么；
• 从现在到明天的站立会，我计划完成什么；
• 有什么阻碍了我的进展。
• 阐述问题，但不讨论和解决（会后解决）；
• 关于比较深远的问题，等到回顾会处理。
• 站会不是任何人汇报进度。它是一个开发团队内部的沟通会议，来保证信息共享透明。
Sprint 评审会 (Sprint Review) 时间盒：1小时/周
Sprint 评审会在冲刺末期召开，团队和相关人员一起评审Sprint的产出。
• 团队全体参与、邀请相关干系人参与
• PO可以拒绝接收成果，并对未来做出最终的决定
• sprint 评审会议的结果是一份修订后的PB，阐明很可能进入下个 Sprint 的产品待办列表项
Sprint 回顾会 (Sprint Retrospective ) 时间盒：1小时/周
团队一起复盘本次冲刺的过程，总结经验与教训，并形成切实可行的改进清单。
• 三个目的：做的好的，不好的，改进的措施（行动项）
• 回顾一下团队在流程、人际关系以及工具方面做得如何
• 关于团队过程中的问题，在此会议上解决
4.6 精益、按需进度计划
按需进度计划：又称拉动式进度计划，用于看板体系，基于制约理论和精益生产的理念安排计划。
- 主要目的：消除在制品积压、消除瓶颈从而提升效率
- 根据团队的交付能力限制团队的工作任务
- 不以产品的功能或任务的多少安排进度计划
- 在资源可用的时候从未完项列表中提取任务开展工作
- 任务的规划或范围分解到相对类似的程度
5. 高频知识点
5.1 挣值图
5.2 可交付成果流向
5.3 变更控制流程
5.4 风险管理流程
5.5 问题解决流程
5.6 绩效数据流向
5.7 两大说明书
5.8 三大审计
5.9 五大阶段模型
5.10 十大会议
5.10 十大风险处理策略
5.11 高频关键词
- 看到“ 界限值”选什么？控制图
- 相关方出问题，选管理相关方期望
- 信息出问题，选沟通管理计划或规划沟通或沟通需求分析
- 看到变更题目，选择：最符合流程的
- 回避针对风险事件，回避改变计划；减轻针对风险概率和影响
- 开拓——分派最有能力资源，缩短时间和节约成本，开拓质量；
- 提高——增加资源，缩短时间，提高数量。
- 看到项目收尾，找：可交付成果的验收/总结经验教训
- 看到新任项目经理找：章程
- 看到计划或章程完成了，找：批准
- 看到恢复进度找：进度压缩，假设情景分析，时间提前量和滞后量
- 看到要执行风险应对措施找：变更请求
- 描述路径，选浮动时间，画网络图看不出答案，就选0（尽量别画7宫格）
- 看到风险出问题了：更新风险登记册、风险报告
- 有任何人质疑项目经理，用项目章程。
- 明确需求，定义范围，分解至工作包。工作内容和验收标准，想到范围说明书。
- 关键路径不唯一，历时最长或总时差为零的是关键路径。
- 看到资源数量有限/只在特定时间可用/资源负载太重，用资源平衡。
- 看到如果。。。就。。。，选假设情景分析
- 进度压缩：看到并行和成本是首要制约因素选快速跟进，其他都是赶工。
- 看到规格，是质量测量指标。
- 看到有人对沟通不满意，首先审查沟通管理计划。
- 看到有责任不清，选责任分配矩阵。
- 风险要走流程，就是识别、定性、定量分析和规划应对、实施应对、控制。
- 看到概率和影响相关的，优先排序的，待观察的就是定性分析。
- 看到决策、建模、敏感性分析，就是定量分析
- 看到计算平均结果的统计方法，选预期货币价值分析。
- 看到采购中甲方希望风险小，选总价合同；看到没有范围选工料合同。
- 看到完全消除风险选回避;看到风险合同，选转移；看到降低概率，选减轻
- 看到不知道变更找谁，选变更管理计划。
- 定时或随机使用、查看变更的效果，用质量审计。
- 看到项目还没有开始就有人了，这是预分配；
- 团队建设五阶段，看到信任、规则，是规范阶段。
- 冲突管理5 方法，看到有人撤选撤退；看到互相进退，选妥协；看到解决，选面对；紧要关头选强制。
- 相关方对结果不满意，选管理相关方参与，这时问依据什么，选相关方参与计)。
- 看到卖方不清楚，选投标人大会。
- 看到过程改进，选管理质量。
- 看到变更一定要根据当前的状况，选择流程中最合适的步骤。
- 看到验收，选确认范围，看到验证，选质量控制。
- 看到过程稳定、有无失控、改进效果如何，选控制图，没有就选趋势图
- 找根本原因选因果图、鱼骨图、石川图，提供解决方案选根因分析
- 找两个变量之间的关系，看有无关系，选散点图，多个变量关系选矩阵图。
- 出现的频率选直方图，排序，用帕累托图
- 新风险用风险再评估，风险是否有效用风险审计，风险应对由风险责任人
- 采购变更用谈判、解决不了ADR，避免卖方低绩效，用采购绩效审查。
