PMP-敏捷部分
2023-11-08 10:04:41 2 举报AI智能生成
PMP-敏捷部分
作者其他创作
大纲/内容
敏捷部分知识点梳理
敏捷主要开发方法
基于迭代的敏捷
每次迭代的周期相同，timebox一样
子主题
速度作为团队交付能力的绩效衡量指标
速度也即本次迭代中实际完成功能的故事点大小的总和。
让团队得以通过观察历史表现来更准确规划下阶段的能力
让团队得以通过观察历史表现来更准确规划下阶段的能力
用户故事
等于用户需求、功能、角色
故事点数大小是找一个基准点，在此基准点上评估
完成一半，或者只要没完成就都不算进本次迭代的速度
团队以迭代方式来交付完整功能
基于流程的敏捷
每次迭代周期不同，完成各个功能开发所需的时间各不相同
既然是基于流程的敏捷，那按照流程来完成工作，如泳道图
WIP限制内的功能数量
就是work in process。
在泳道图中时开发阶段到完成阶段这一段。
因为资源有限，所有需要限制进来的数量。
研发无法同时进行所有等待中的事项。
因为资源有限，所有需要限制进来的数量。
研发无法同时进行所有等待中的事项。
团队将根据自身能力，从待办事项列表中提取若干功能开始工作，而不是按照基于迭代的进度计划开始工作。
团队定义任务板的各项工作流，并管理各列进行中的工作。完成不同功能所花费的时间可能有所不同。团队让进行中的工作规模尽量小，
以便尽早发现问题，并在需要变更时较少返工。无需利用迭代定义计划和审核点，而由团队和业务相关方决定规划、产品评审与回顾的最适当的进度计划。
团队定义任务板的各项工作流，并管理各列进行中的工作。完成不同功能所花费的时间可能有所不同。团队让进行中的工作规模尽量小，
以便尽早发现问题，并在需要变更时较少返工。无需利用迭代定义计划和审核点，而由团队和业务相关方决定规划、产品评审与回顾的最适当的进度计划。
指标衡量
交付周期：交付一个工作项目花费的总时间，从项目添加到看到直至项目完成。
周期时间：处理一个工作项目所需要的时间。
响应时间：一个工作项目等到到工作开始的时间
周期时间：处理一个工作项目所需要的时间。
响应时间：一个工作项目等到到工作开始的时间
混合型
混合型是从预测到敏捷的一个转型
前期使用敏捷开发。
后期使用预测型进行测试发布
后期使用预测型进行测试发布
整个生命周期都使用混合
敏捷与预测结合
敏捷为主，预测未为辅的方式。
当某个特定要素不可协商，或者使用敏捷方法不可执行时，
可能会使用这种方法
当某个特定要素不可协商，或者使用敏捷方法不可执行时，
可能会使用这种方法
主要例子：这种情况的例子包括，集成由不同的供应商开发的外部组件。
这些外部组件不能或不会以协作或者增量的方式合作。在组件交付之后
需要单独集成
这些外部组件不能或不会以协作或者增量的方式合作。在组件交付之后
需要单独集成
预测为主，敏捷为辅的方法。
以敏捷方法处理具有不确定性、复杂性或范围蔓延机会项目的一部分，
而使用预测方法管理项目的其余部分。
以敏捷方法处理具有不确定性、复杂性或范围蔓延机会项目的一部分，
而使用预测方法管理项目的其余部分。
例如：工程公司正在使用一种新的组件建造一个设施，虽然大部分项目可能是常规的、
可预测的，就像组织实施的许多其他项目一样，但这个项目包含了一种的新的屋顶材料。
承包商可能计划首先在地面上进行一些小规模的安装实验，以确定最佳的实践方法，并在
有足够实践解决问题时及时尽早发现问题，随后通过实验和调整，增量的改进过程
可预测的，就像组织实施的许多其他项目一样，但这个项目包含了一种的新的屋顶材料。
承包商可能计划首先在地面上进行一些小规模的安装实验，以确定最佳的实践方法，并在
有足够实践解决问题时及时尽早发现问题，随后通过实验和调整，增量的改进过程
敏捷思维
主要是敏捷思维指导
敏捷体系
scrum
子主题
scrumBan
水晶
XP
FDD
AUP
DSDM
子主题
MVP（minimum value product）
最小可用单元、最小价值产品
价值体现
尽早交付商业价值
尽早梳理需求
尽早发现问题
尽早识别风险
MMF（minimally marketable feature）
最小可售功能，能为用户增加价值的最小单位的交付物（可供销售）
可体现为
一组已经完成的用户故事
可向用户交付推向市场的价值单元
最小可售的产品MMP
精益思想
精益概述
精益思想是一个超集，敏捷和看板方法视为精益思想的衍生物。
源自丰田汽车生产系统，借助精益思维，团队需要最大价值交付活动
和减少或消除浪费及合规性等非增值活动。
源自丰田汽车生产系统，借助精益思维，团队需要最大价值交付活动
和减少或消除浪费及合规性等非增值活动。
原则具体有
价值（Value）
用户/客户想要的和需要的
浪费（Waste）
不增加价值的活动
拉（Pull）
下游活动根据其能力进行“拉动式”工作
流（Flow）
通过缩小增值活动中的差距来交付价值
完善（Perfection）
持续检查和调整
消除浪费
生产中的浪费
等待、库存、生产过剩、运输、额外处理流程、转移/转换、缺陷、管理
软件开发中的浪费
未完成的任务、文书工作或多余的文档、额外的功能、构建错误的东西、
等待信息、缺陷、不必要的审批
等待信息、缺陷、不必要的审批
敏捷价值观
敏捷宣言
个体以及互动而不是过程和工具
个体互动
个体与互动高于流程和工具
流程和工具固然重要，但人与人之间的互动比流程和工具更重要
人与人之间互动即沟通
可用的软件（成果）而不是完成的文档
工作的软件高于详尽的文档
可用的软件比面面俱到的文档更重要，文档够用就好
客户合作而不是合同谈判
客户合作高于合同谈判
双赢的合作
客户视为团队的重要组成部分，应该是彼此协作而不是对立关系。
通过协作来达成共识而不是对立的谈判方式
通过协作来达成共识而不是对立的谈判方式
应对变更而不是遵循计划
响应变化高于遵循变化
响应变化，拥抱变化。
变更创造价值
变更创造价值
根据客户的需求响应变更，比遵循原计划更重要，这样才能为客户创造最高价值
敏捷的12条原则
主要概括敏捷的原则
我们的最好目标是，通过尽早持续交付有价值的软件来满足客户的需求
重点关注：客户满意
实践要点：满足客户需求，解决客户问题，持续交付，尽早交付
欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势
重点关注：帮助客户获得竞争优势
实践要点：拥抱变化，实现软件灵活性，良好的设计与实践
要经常交付可用的软件，周期从几周要几个月不等，且越短越好
重点关注：经常交付
实践要点：采用周期短，快速交付
项目实施过程中，业务人员和开发人员必须始终通力合作
重点关注：客户协作
实践要点：现场客户，频繁沟通
要善于激励项目成员，给予他们所需的环境和支持，并相信他们能够完成任务
重点关注：激励团队
实践要点：提供环境、提供支持、充分信任、学会放手
无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈
重点关注：面对面沟通
实践要点：尽可能面对面，分布式团队可利用在线技术
可用的软件是衡量进度的首要衡量标准
重点关注：进度度量
实践要点：可用的软件而非已完成的代码量
敏捷过程提倡可持续的开发。项目发起人、开发人员、用户应该都能够始终保持步调稳定
重点关注：可持续开发、步调稳定
实践要点：不透支精力、基于平均速率
对技术的精益求精以及对设计的不断完善将提高敏捷性
重点关注：技术精益求精、设计不断完善
实践要点：追求技术卓越，良好设计，保持代码简洁，重构
简洁，即尽最大可能减少不必要的工作，这是一门艺术
重点关注：简洁 最小化工作
实践要点：工作围绕客户需求开展，不构建华而不实的功能
最佳的架构、需求和设计将出自于自组织团队
重点关注：自组织
实践要点：团队自主、相互协作、渐进方式
团队要定期反省怎样做才更有效，并相应的调整团队的行为
重点关注：定期反省、做出调整
实践要点：定期回顾、验证与适应、持续改善
敏捷团队
敏捷团队内容
敏捷团队角色
发起人
主要内容
设定项目目标
提供项目资源
为产品负责人提供指导
参与发布与迭代评审，确定团队是否已交付增量成果
持续关注价值和成本
scrum流程及角色
主要是以scrum为例子讲解敏捷团队内容
三个角色
scrum涉及到的主要三个角色
PM/SM（项目经理/敏捷教练）团队促进者
团队促进者
所有敏捷团队都需要仆人式领导。仆人式领导是项目经理、
scrum主管、项目团队领导、团队教练或者团队促进者
scrum主管、项目团队领导、团队教练或者团队促进者
仆人式领导技能：引导、指导和消除障碍的技能
团队促进者的角色职责
组件跨职能团队，通才型专家团队
教育相关方，使其了解敏捷价值和如何敏捷
就是沟通
通过指导、鼓励、授权和帮助团队提供支持
通过技术项目管理活动帮助团队
庆祝团队成果，为团队与外部合作提供支持
为团队提供必要的环境支持
营造相互欣赏积极的氛围并促进团队内外部合作
消除组织障碍，如流程导致的瓶颈
确保敏捷仪式的开展（规划会、每日站会、演示会、回顾会等）
仆人式领导可以主持召开任何必要的会议
PO（product owner）产品负责人
澄清需求
产品负责人确保团队做正确的、有价值的事情
服务请求管理者：在连续工作流或看板环境中负责整理服务请求，旨在实现最大价值的人员，相当于产品负责人
其角色职责包括
与相关方、客户及团队合作，定义产品开发方向
根据商业价值对任务进行排序
排序，项目经理也可以进行，但是敏杰教练就不行，敏杰教练只需要管好团队就行。
产品负责人为团队创建待办事项列表，或与团队共同创建
指导产品开发方向，制定发布计划
验收产品增量，决定是否可发布以及何时发布
与团队开展日常合作，提供产品反馈，如澄清需求。为将要开发/发布的下一个功能设定方向
产品负责人需要接受关于如何组织和管理整个团队工作流的培训
维护好PBL
不恐吓、强迫团队
DEV（开发团队）跨职能团队
认领需求、分解需求（分解成任务）、估算时间
具有生产可行产品所需的各种必要技能的团队成员。
通才型专家（多种技能），跨职能工作团队无需外部支持。
包括设计人员、开发人员、测试人员以及其他所需角色。
通才型专家有利于减少瓶颈，跨职能团队是提升团队绩效的基础。
最有效的敏杰团队一般由3-9个成员组成，理想情况下是集中办公，成员100%专职
通才型专家（多种技能），跨职能工作团队无需外部支持。
包括设计人员、开发人员、测试人员以及其他所需角色。
通才型专家有利于减少瓶颈，跨职能团队是提升团队绩效的基础。
最有效的敏杰团队一般由3-9个成员组成，理想情况下是集中办公，成员100%专职
其角色职责
以自组织方式开展工作，任何人无权让团队以何种方式实现任务，即便是团队领导
频繁开发与交付
作为一个独立团队交付完成的价值
为完成任务，整合所有工作活动
为团队内部和外部（如产品负责人）提供反馈
跨职能团队成员
敏捷团队协作：在成功的敏捷团队中，团队成员在工作中以各种方式开展合作（结对、群集、群体开发）
群集（蜂拥）：指一种团队多个成员合作，重点消除特定障碍的技术（看板中遇到障碍后很常见）
跨职能团队：由掌握交付有价值产品增量所需的各种技能的实践者组成的团队
I型人才：深入掌握单一专业技能的人员他们不具备团队所需的其他技能或对其不感兴趣，也叫破梳齿人才，或者叫颜料滴洒人才
破梳齿人才：对团队所需的多种技能掌握程度深浅不一的人，或者叫颜料滴洒人才
scrum团队：在敏捷开发中，开发团队、scrum主管和产品负责人的总和
自组织团队：一种跨职能团队，为实现团队目标团队成员根据需要；轮换着发挥领导作用
如：当团队有新人进入不熟悉业务和项目情况时，项目经理不要主动去培训去介绍，
让团队主动发挥领导作用
让团队主动发挥领导作用
团队环境及协作
团队环境以及团队协作
集中办公，可实现渗透式沟通
敏捷涉及三个沟通：透明沟通（看板）、面对面沟通、渗透式沟通
分布式团队可使用追逐太阳的开发过程
安全的环境：只有在安全、诚实和透明的环境中，团队成员和领导才可以真正反思其成功，确保项目持续进不，
或者应用从失败项目中所吸取的教训，不再重蹈覆辙
或者应用从失败项目中所吸取的教训，不再重蹈覆辙
工作场所：公共区域：交流、会谈。
私人区域：发泄，哭泣、私人电话等
私人区域：发泄，哭泣、私人电话等
敏捷工作环境
工作场所内通常要有合适团队使用的敏捷工具、空间及设备，为团队提供更好的沟通环境
信息发射源：可视化的信息发射源可以让团队粘贴项目相关图示，
让团队成员一进入办公室，就能了解到项目目前的执行情况
让团队成员一进入办公室，就能了解到项目目前的执行情况
讨论环境：提供圆桌和投影仪可以让团队将要讨论的内容投影出来，
并有空间进行讨论。
并有空间进行讨论。
视频会议：如果团队成员不在同一办公室，甚至在不同的国家，视频会议室（虚拟工作区）可以让
团队免于长途跋涉之苦，达到面对面沟通效果。
团队免于长途跋涉之苦，达到面对面沟通效果。
空间安排：当个人需要安静思考时，可以由个人独立空间的安静区，其他时间在公共
空间，可以节省沟通成本，增加工作效率。在公共空间更可以达到渗透沟通的效果
空间，可以节省沟通成本，增加工作效率。在公共空间更可以达到渗透沟通的效果
分布式团队沟通技术
鱼缸窗口：长期的视频会议链接
时差不大，可以通过用这种
远程结对：利用虚拟会议工具实现语言、视频、屏幕共享
在线协作场景
追逐太阳
一般在时差比较大，通过邮件每日交接，每天都在太阳升起时工作开始
克服孤岛
客服信息孤岛，培养默契
团队绩效
敏捷团队绩效
敏捷关注过程效率而非资源利用率，团队绩效由平均速率（迭代中完成的工作量）来衡量
如果采用用户故事，不同的团队速率不具备可比性，因为用户故事可能参考的基准点不一致
可以借助燃尽图、燃起图、功能图、累积流量图等评估
三个工件
scrum涉及到主要三个工件
产品代办列表（product backlog）
记录产品需求
冲洗任务代办列表（sprint backlog）
记录任务
可工作软件，或者理解成MVP
MVP
4个主要会议
scrum涉及到主要4个会议
冲刺规划会议
定目标、定计划
每日站会
对齐工作
评审会
验收的。
注：验收时所有相关方都参与。在验收是就算有验收没有通过的，也不要在这个阶段进行修改，
放回产品代办列表。在下一个版本中由产品负责人决定是否需要在下个版本修改。因为已经在
验收评审会了，没有时间修改新增的功能和问题。
注：验收时所有相关方都参与。在验收是就算有验收没有通过的，也不要在这个阶段进行修改，
放回产品代办列表。在下一个版本中由产品负责人决定是否需要在下个版本修改。因为已经在
验收评审会了，没有时间修改新增的功能和问题。
回顾会
总结经验
总的经验记录在看板上。
敏捷中有很多看板，记录需求的、记录风险的、记录任务的、
记录问题的、记录经验的等
敏捷中有很多看板，记录需求的、记录风险的、记录任务的、
记录问题的、记录经验的等
敏捷角色
敏捷团队规模一般是3-9人，理想状态下能集中办公，并且100%专职
敏捷常见有三种角色
子主题
敏捷实践
主要关于敏捷中实践部分
项目章程
敏捷中的项目章程
项目愿景：为什么做这个项目
谁会从中受益，如何受益。项目愿景和项目目标的一部分
对于项目而言，达到哪些条件才意味着项目完成。项目的发布标准
我们将如何合作。预期的工作流
项目章程项目合法的证明文件，给项目经理的授权文件
团队章程
团队章程又叫团队社会契约，规定团队成员之间的彼此互动方式。
团队章程目标是创建一个敏捷的环境，可以发挥团队的最大能力。
团队章程目标是创建一个敏捷的环境，可以发挥团队的最大能力。
主要包含
团队价值观，例如可持续的开发速度和核心工作时间
工作协议。例如
就绪 如何定义，这是团队可以接受工作的前提
DoR（就绪定义）
团队以用户需求为中心的核对单其中包括
团队开始工作所需要的全部信息
团队以用户需求为中心的核对单其中包括
团队开始工作所需要的全部信息
用户故事已澄清
用户故事点数已估算
用户故事验收标准已明确
所需人员及设备已就位
完成 如何定义，这样团队才能一致的判断完整性
DoD（完成的定义）
团队需要满足的所有标准的核对单（检查清单、验收标准），只有可交付
成果满足该核对单才能视为准备就绪可供客户使用
团队需要满足的所有标准的核对单（检查清单、验收标准），只有可交付
成果满足该核对单才能视为准备就绪可供客户使用
DoD可以在多个层次中定义
开发完成的dod
代码以及资源都已提交到代码库
所有代码得到静态分析，不符合的已修改
所有新增代码都已评审
所有功能单元测试已通过
测试用例都已执行
迭代的DoD、发布的DoD等等
考虑时间盒
工作过程限制
基本规则，例如有关一个人在会议上发言的规定，专注于团队任务
团队规范，例如团队如何对待会议时间
敏捷规划
在敏捷项目如何规划，
scrum工件
产品待办列表
冲刺待办列表
产品增量
常见敏捷实践
这里的实践涵盖了scrum中的实践，是对敏捷实践的概括，
为了便于理解使用scrum为例来概述
为了便于理解使用scrum为例来概述
待办事项列表编制
待办事项列表编制及细化
产品待办事项列表细化目的是向产品待办事项列表添加详细信息、评估和排序
在产品待办事项列表的细化过程中，产品待办项被评审和修改
用两周不超过一小时的时间来细化
基于迭代的规划
规划会
分析和评估产品backlog
确定冲刺目标
排定优先级
确定冲刺目标
排定优先级
PO
冲刺会
决定怎么实现目标
从产品待办列表中创建冲刺待办列表，并分解成任务
估算任务的工时，能不能满足，不能满足就放一些回产品待办列表
从产品待办列表中创建冲刺待办列表，并分解成任务
估算任务的工时，能不能满足，不能满足就放一些回产品待办列表
每日站会
每日站会时间盒为15分钟，开发团队内部的会议，开发团队任何人都可以组织会议。
开发团队之外的人列席参加但不发言。
开发团队之外的人列席参加但不发言。
会议目的：增进交流，提出问题、障碍，但不在会上解决问题
站会问题多，设置优先级，同时也是防止镀金的最佳实践。
每日站会的反模式是变成状态会，所以应该由团队自己组织
站会问题多，设置优先级，同时也是防止镀金的最佳实践。
每日站会的反模式是变成状态会，所以应该由团队自己组织
会上提出问题的处理：将问题添加到停车场（看板、缺陷版），然后创建另一次会议，
可以是在站会之后立即召开，并在会上解决问题
可以是在站会之后立即召开，并在会上解决问题
待办事项列表细化
在基于迭代的敏捷中，产品负责人往往在迭代的中期的一次或多次会议中与团队合作，为即将进行的迭代准备一些故事。
这些会议的目的是细化足够的故事，让团队了解故事内容，以及故事之间的相互关系。
这些会议的目的是细化足够的故事，让团队了解故事内容，以及故事之间的相互关系。
基于流程的敏捷的即时细化
团队将下一张卡片从待办事项列表中拿出来讨论
许多基于迭代的敏捷团队在两周的迭代中用1小时的时间盒讨论。（团队选择一个迭代持续时间，为他们提供足够频繁的反馈）
基于迭代的敏捷团队的多次细化讨论。团队可以在陌生的产品、产品领域或者问题领域使用这一技巧
细化会议上，产品负责人可以向团队介绍故事的创意，让团队了解故事中潜在的挑战或者问题。
如果产品负责人不确定依赖关系，还可以请求团队对相应功能进行刺探，以了解风险。
如果团队需要每周花1小时以上时间来细化故事，那么产品负责人可能会过度准备，或者团队可能缺乏评估
和细化工作所需的一些关键技能
如果产品负责人不确定依赖关系，还可以请求团队对相应功能进行刺探，以了解风险。
如果团队需要每周花1小时以上时间来细化故事，那么产品负责人可能会过度准备，或者团队可能缺乏评估
和细化工作所需的一些关键技能
演示/评审
sprint评审会议在sprint快结束时举行，用以检视所交付的产品增量并按需调整产品待办列表。
一个月的冲刺/迭代 时间盒为4小时
一个月的冲刺/迭代 时间盒为4小时
参会者包括scrum团队和产品负责人邀请的主要利益攸关者
产品负责人说明哪些产品待办列表事项已经完成，哪些没有完成。利用DoD，完成的定义
开发团队演示完成的工作并解答关于所交付增量的问题
会议的结果是一份修订后的产品待办列表，阐明很可能进入下个冲刺/迭代的产品待办列表项
非正式会议，不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作
团队成员可以从每个迭代的展示/评审活动中得到相关方的反馈，及时确认范围，防止产品朝错误方向发展，防止相关方后期才发现问题
回顾会
回顾是帮助团队学习、改进和调整其过程。回顾会可以在必要时随时进行
冲刺回顾会是团队检视/反省自身并创建下一冲刺或迭代改进的机会。
以一个月的冲刺/迭代为例，时间盒为3小时
以一个月的冲刺/迭代为例，时间盒为3小时
其目的在于
检视前一个sprint中关于人、关系、过程和工具的具体情况如何
找出并加以排序做的好的和潜在需要改进的主要方面
同时制定改进scrum团队工作方式的计划
用户故事
三要素：角色、目标、商业价值。
作为一名<角色>，我想要<功能>，以便可以<商业价值/好处>
作为一名<角色>，我想要<功能>，以便可以<商业价值/好处>
3C原则
card：故事应该精简，可写在一张卡片上，以促进沟通交流
conversation：故事细节需要与用户写上谈论
confirmation：包含验收标准和环节
invest特性
独立的
可协商的
有价值的
可估算的
小的，拆分成小的
可测试的
用户故事的大小
交付价值的执行实践
以下实践(大多来自XP)，可帮助团队交付高质量产品
持续集成
无论产品如何，都要持续地将工作集成到整体中，然后再进行重新测试，以确定整个产品仍然按照预期工作
持续集成确保随时可以获得可用的软件
持续集成可以即使发现问题并处理
在不同层面测试
测试是保证质量的重要手段
验证构建块使用单元测试
对端到端测试使用系统级测试
将新功能添加到原系统中需要集成测试以及回顾测试
发现冒烟测试有助于测试工作产品是否良好
敏捷团队偏爱自动化测试，可以借此构建和保持交付的势头
在敏捷团队中，测试工作由团队内部完成，无需借助外部测试人员
敏捷团队非常偏爱自动化测试，因此他们可以借此构建和保持交付的势头
验收测试驱动开发（ATDD）
在ATDD中，整个团队聚集一堂讨论工作产品的验收标准。然后团队创建测试，这让团队能够编写足够的代码，进行自动化测试，满足标准要求。对于非软件项目，要考虑怎样在团队完成大量价值时对工作进行测试
测试驱动开发（TDD）和行为驱动开发（BDD）
BDD时一种系统设计和确认实践采用测试有限的原则和类似英语的脚本
结对编程
两个人共同设计和开发代码的实践
结对者是全职合作者，轮流执行键入（写）和监视
为持续的设计和代码评审提供了机会
促进知识传递
也是知识的备份，因为两个人走了一个还有一个在。
也是技术提升的最佳实践，因为两个人一起工作。
也是技术提升的最佳实践，因为两个人一起工作。
刺探（团队来做）
探针、探索，时间盒研究或实验
刺探对学习很有用，可以在诸如评估、验收标准定义以及通过产品了解用户行为的流程中使用
团队需要一些新技术、关键技术或者功能要素时，刺探会很有帮助
当产品负责人对用户故事依赖关系不确定时，也可请求团队进行刺探，了解风险
持续改进（PDCA）
持续改进在不同方面
持续过程改进
持续产品改进
持续改进可在不同层级
结对编程
每日站会
演示会议
回顾会议
风险管理
敏捷中对具体风险的应对所需活动或任务记入风险调整代办列表中。
敏捷中所有放入代办列表中的都必须排序
敏捷中所有放入代办列表中的都必须排序
问题处理
收集数据---分析原因（根本原因分析）--采取行动
技术债务
产品生命周期早期未能完成工作的递延成本
团队选择目前暂时不实施的技术决策，但是如果一直不做会成为阻碍，带来额外开销。如
开发时走捷径，不遵循设计规则
使用性能低下的架构
不及时清除静态检查告警
技术债务问题均添加进产品待办事项列表，与其他代办需求进行优先级比较
开发团队通过重构解决技术债务
信息发射源
可见的实物展示，其向组织内其他成员提供信息在不干扰团队的情况下即时实现知识共享
大型可视化的图表
发布在人员可以轻易看到的地方，而不是将信息放在日程安排或报告工具中
应该易于更新，并且经常更新
通常是 低技术和高接触的，因为他们是手工维护的，而不是电子生成的
看板概述
看板在精益生产中是一种用于规划库存控制和补给的系统，丰田精益生产中的思想是拉动式生产，
只补给已消耗的资源来达到控制资源流动的生产管理系统。
只补给已消耗的资源来达到控制资源流动的生产管理系统。
可以促进流程可视化，帮助价值流（增值/非增值）分析，限制在制品数量减少浪费
累积流量图
可以看团队效率，涉及三个周期
燃尽图
团队可能发现，可能需要4-8次迭代才能达到稳定的速度。
团队需要从每个迭代中获取反馈，了解他们的工作情况以及该如何改进。
团队需要从每个迭代中获取反馈，了解他们的工作情况以及该如何改进。
所以一般4-8个迭代看燃尽图才有意义。
燃尽图是剩余故事和时间的关系
燃尽图是剩余故事和时间的关系
燃起图
利用燃起图，团队能够查看他们已经完成的工作
燃起图是已完成的故事和时间的关系。
只有燃起图能看到范围的变更
只有燃起图能看到范围的变更
功能图
完成的功能、剩余的功能以及总的功能点数
产品代办事项列表燃起图
看大功能和时间的关系
ABC项目进度图
S曲线图
scrum板
scrumban
它是一种在团队选择scrum作为工作方式时产生的管理框架，它以看板方法作为透镜从而审视、理解并持续
改善工作。最初设计为scrum到看板之间的过渡方法。通过其自身衍生演变而成的另一种混合敏捷框架和方法，
其中团队将scrum作为框架，而将看板作为过程改进方法
改善工作。最初设计为scrum到看板之间的过渡方法。通过其自身衍生演变而成的另一种混合敏捷框架和方法，
其中团队将scrum作为框架，而将看板作为过程改进方法
scrum板
它是一种用于管理产品待办事项列表和冲刺待办列表的信息发射源，它能显示工作流及瓶颈
裁剪
分布式/分散团队
时差大也要开站会，自组织小范围的站会
即时信息、视频 会议和团队电子板都有助于确保通讯流畅。
如果在远程会议中参与者缺乏面部表情和身体语言交流；请考虑循环提问确认他们的参与程度以及对决策的认可
此外，请考虑使用基于迭代的敏捷方法。如果成员时差较大，请避免使用整个项目迭代方式，而是鼓励开展更多更频繁的私人会议（每次2-3人）
某些安全关键型产品可能需要当前敏捷过程多建议的其他文档及合规性检查
在这些环境中仍然可以使用敏捷方法，单还需要该领域要求的其他相应的合规性审查、文档和认证。在这种情况下，文档可能要随已完成的功能一起交付，只有文档完成后功能才算完成。
可以不需要整套的敏捷，使用混合的方式更优意义
信息透明，开诚布公。
成员能力不足，经验不足。早期需要一些指导和分配
缺乏管理层支持
需要有管理层的支持
敏捷术语
需要评估组织文化，统一敏捷的术语
敏捷也需要计划，也有变更管理
敏捷方法也需要计划
敏捷也有变更管理
冲刺期间原则上不可用被打扰，不鼓励在冲刺期间加入新需求和需求变更。
除非是特别紧急，特别有价值的需求，可以在冲刺期间被接纳，但通常要与团队
达成共识，必要时会替换现有的低优先级的工作。敏捷中没有CCB，也没有复杂的变更流程，变更需要团队讨论决定
除非是特别紧急，特别有价值的需求，可以在冲刺期间被接纳，但通常要与团队
达成共识，必要时会替换现有的低优先级的工作。敏捷中没有CCB，也没有复杂的变更流程，变更需要团队讨论决定
变更通常三个结果
放入PBL，下个迭代优先级来偶爱徐
直接放入SBL，然后替换一部分低优先级的工作
取消当前冲刺，直接做当前特别紧急的需求和变更
敏捷估算
轻量级估算
亲和估算，规模估算，扑克牌
理想日
敏捷采购
敏捷合同是一个多层次的合同，有一个主体合同，一般不会动。
还会有补充文件，因为有需求变更，可以放入这儿。
买方与卖方共担责任和共享利益
还会有补充文件，因为有需求变更，可以放入这儿。
买方与卖方共担责任和共享利益
0 条评论
下一页
