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