敏捷实践指南
2020-02-12 10:11:29 5 举报AI智能生成
ACP敏捷管理专业人士资格认证考试必读书之一 敏捷实践指南
作者其他创作
大纲/内容
第2章 敏捷概述
2.1 可确定的工作与高速不确定的工作
可确定的工作具有明确的流程，被证明行之有效
高度不确定的项目变化速度快，复杂性和风险高
2.2《敏捷宣言》及思维模式
敏捷宣言
四大价值观
个体以及互动而不是过程工具
工作的软件高于详尽的文档
客户合作而不是合同谈判
应对变更而不是遵循计划
十二大原则
1、我的的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求
2、欢迎对需求提出变更，及时在项目开发后期也不列外，敏捷过程要善于利用需求变更，帮助客户获得竞争优势
3、要经常交付可用的软件，周期从几周到几个月不等，且越短越好
4、项目实施过程中，业务人员与开发人员必须始终通力协作
5、要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务
6、无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈
7、可用的软件是平衡进度的首要平衡标准
8、敏捷过程提倡可持续的开发，项目发起人、开发人员和用户应该都能够始终保持步调稳定
9、对技术的精益求精以及对设计的不断完善将提高敏捷性
10、简介，即尽最大可能减少不必要的工作，这是一门艺术
11、最佳的架构、需求和设计将出自于组织团队
12、团队要定期反省怎样才能更有效，并相应的调整团队的行为
价值观、原则和通用实践之间的关系
价值观所界定
原则指导
实践实现
敏捷方法
囊括了各种框架和方法的涵盖性术语
敏捷是许多方法的一个总称
精益方法的子集
敏捷方法
看板方法
精益思想的具体实例
关注价值
小 批量
消除浪费
符合《敏捷宣言》价值观和原则的
方法
技术
框架
手段
实践
两种策略践行敏捷价值观和原则
1、采用正规的敏捷方法，他们为特意设计，经证明可达到期望的效果
需要花时间学习和理解敏捷方法
变更前
裁剪前
效果大打折扣，从而限制收益
不成熟的裁剪
随意的裁剪
2、以一种合适项目背景的方式对项目时间进行变更，以便在核心价值观或原则方面取得进展
使用时间盒创建功能
使用特定技术迭代优化功能
在适用于特定项目背景下，考虑将一个大项目划分为几部分发布，
实现有助于项目的变更
最终目标不是为了敏捷而敏捷
是为了向客户持续交付价值流并达成更好的商业成果
2.3精益与看板方法
将敏捷和看板方法视为精益思想的衍生物
精益思想是一个超集，与敏捷和看板方法拥有共性
交付价值
尊重人
减少浪费
透明化
适应变更
持续改善
看板方法
受到最初精益制造体系的启发，专门用于知识型工作
不如某些敏捷方法规范，破坏性较小
原地出发的方法
从精益制造构思而来，也围绕精益制造，更广泛的应用与敏捷环境中
2.4不确定性、风险和生命周期选择
团队利用较少的工作增量验证自身的工作，并且可以对接下里的工作作出相应变更
不确定性
项目在项目需求以及如何使用现有知识和技术满足这些需求方面，基友很大的不确定性
导致大量变更和项目复杂性的提高
不确定的增加
返工的风险增加
使用不同方法的需求增加
减轻这些风险影响
团队选择的生命周期要能通过较少的工作增量解决项目的大量不确定性问题
利用较少的工作增量验证自身工作，并对接下来的工作作出相应变更
当团队交付小的增量时，能够更快更准确的理解真正的客户需求
生命周期
从需求和交付手段两方面对项目进行评估后确定了项目周期的最近方法
让项目周期发生演变，以便使用迭代和增量方法
迭代和增量的方法
非常短的反馈循环
频繁调整过程
重新进行优先级排序
定期更新计划
频繁交付
效果
探讨迭代需求、更频繁的交付增量时，团队会更容易适应变更
解决问题
减少浪费
减少返工
迭代增量和敏捷方法使用场景
涉及新颖的工具技术材料或应用领域的项目
以下特点的项目
需要研究和开发
变更速度极快
具有不明确和未知的需求不确定性和风险
最终目标难以描述
构建一个小的增量对其进行测试和评估
在短时间内以成本探索不确定性
降低风险，最大程度实现商业价值的角度
不确定性可能集中于
实用性和需求
技术可行性和性能
过程和人员
迭代和增量管理方法的应用局限性
当技术和需求的不确定性都很高时，项目会极端复杂
为了使项目尽可能可靠，需要遏制其中一个变量（不确定性或分歧）
第3章 生命周期选择
四种生命周期
预测型
更为传统的方法
提前进行大量计划工作
一次性执行
执行时一个连续的过程
计划驱动型
迭代型
允许对未完成的工作及性能反馈
从而改进和修改该工作
增量型
向客户提供各个已完成的，可能立即使用的可交付成果
敏捷型
既有迭代也有增量
便于完善工作频繁交付
项目生命周期的特征
预测型
充分利用已知和已经证明的事物，不确定性和复杂性的减少，允许项目团队将工作分解为一系列可预测的小组
计划驱动工作，尽可能详细的定义需求，估算何时能够交付克交付成果，并全面开展工作
预计会从高确定行的明确的需求、稳定的团队和低风险中获益，因此项目活动通常以顺序方式执行
预测型生命周期
尽可能减少预测型项目的变更
迭代型
允许对部分完成或未完成的工作进行反馈，从而对该工作改进和修改
计划原型和验证，但输出的目的是修改一开始所创建的计划，对未完成的工作的早期评审有助于未来的项目工作
通过连续的原型或概念验证来改进产品或成果。每一个新的原型都能嗲来新的相关方新的反馈和团队见解，团队在下一周期重复一个或多个项目活动，在其中纳入新信息
迭代有利于识别和减少项目的不确定性，可能需要更长的时间，它是为学习而优化，而不是为交付速度而优化
优势
项目复杂度高
变更频繁
项目范围受到相关方对所需最终产品的不同观点支配时
迭代型生命周期
增量型
向客户提供完成的可交付成果，让客户能够立即使用
计划角度整个项目后续部分，可提前计划可交付成果的若干次连续交付或一次之计划交付一个，可交付成果为未来的项目工作提供了相关信息
为了加快交付速度，无法等待所有的事情全部完成，交付一个单一功能或交付一项完成的工作，这种少量可交付成果的频繁交付为增量型
增量型生命周期
由于可以更快的交付价值，因而团队可以管理偏差，与客户在项目结束时获得价值相比，确保客户能尽早获得价值，其变更和差异程度的重要性变得不那么重要
优势：经常交付商业价值，产品功能得到增加，吸引更多的消费者，所以说是增量交付
敏捷型
同时利用迭代属性和增量特征，使用敏捷方法时，会对产品进行迭代，创建完成的可交付成果
获得早期反馈，并提供客户可见性、信息和对产品的控制，由于团队可以提前发布产品，而团队将率先交付价值最高的工作，所以项目可以更早产生投资回报
也有计划，区别在于通过对频繁交付的可交付成果的评审，团队将能获得更多的信息，从而再次基础上进行计划和重新计划
在敏捷环境中，团队预料需求会发生变更，迭代和增量方法能够提供反馈，以便改善项目下一部分的计划，不过在敏捷项目中，增量交付会发现隐藏或误解的需求
增量交付的两种可能的方法
基于迭代
团队以迭代（相等持续时间的时间盒）形式交付完整的功能
团队集中最重要的够嫩那个，合作完成再集中进行下一个
基于流程
团队根据自身能力从待办事项中提取若干功能开始工作，而不是按照基于迭代的进度计划进行工作
完成不同功能所花费的时间可能不同
无需利用迭代定义计划和审核点，而由团队和业务相关方决定规划、产品评审与回顾的最适当的进度计划
混合生命周期
为了达到特定目标，项目经常要结合不同的生命周期要素
敏捷开发后接预测型发布
开发部分中存在不确定性、复杂性和风险时采用敏捷方法
然后一个明确可重复的发布阶段采用预测方法进行
整个生命周期结合使用敏捷方法和预测法
结合使用预测方法和敏捷方法，也许团队正逐渐向敏捷过度，使用一些方法短迭代、每日站会和回顾；
但其他方面前期评估工作分配和进度跟踪仍然遵守预测法
但其他方面前期评估工作分配和进度跟踪仍然遵守预测法
以预测为主、敏捷为辅
以敏捷处理具有不确定性、复杂性或范围蔓延机会项目的一部分，使用预测管理项目的其余部分
发部分项目是常规的可预测的，但包含了一种新的屋顶材料，先在地面进行小规模安装试验通过后增量的改进过程
敏捷为主，预测为辅
某个特定要素不可协商或敏捷不可执行时采用该法
eg 集成由不同供应商开发的不能或不会以写作或者增量方式合作的外部组件
敏捷使用性筛选器
附件X3，提供了评估模型
每个生命周期都有计划要素，生命周期的不同之处并非在于计划是否完成，而是于完成了多少计划及何时完成
3.2 混合敏捷方法
敏捷团队很少将实践局限于一种敏捷方法
敏捷框架不是针对团队定制的，为了定期交付价值，团队可能需要对实践进行裁剪
协调方法
Scrum框架
为产品待办事项列表、产品负责人、Scrum主管以及跨智能开发团队的使用提供指导
包括
冲刺计划
每日例会
冲刺评审
冲刺回顾会议
看板方法
帮助团队进一步提高效率
方法是将工作流可视化、是障碍更容易被察觉，以及通过调整在制品限制在实现流程管理
极限编程XP
故事卡
持续集成
重构
自动化测试
测试驱动开发
等进一步提高敏捷团队的效力
3.3 影响裁剪的项目因素
附件X2 影响裁剪的属性
子主题
第4章 实施敏捷：创建敏捷环境
4.1 从敏捷思维模式开始
制定实施策略
项目团队吐核以敏捷方式行动？
为了使下一交付周期受益，团队需要快速交付哪些成果并获得早期反馈？
团队如何以一种透明的方式行动？
为了专注于高优先级的项目，可以避免哪些工作？
仆人式领导对团队达成目标有何益处？
4.2 仆人式领导为团队赋权
通过对团队服务来领导团队的实践，注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效
作用：
促进团队发现和定义敏捷
实践并传播敏捷
从事项目工作的顺序
目的：
与团队一起定义“为什么”或目的
以便他们能围绕项目目标进行合作互动
整个团队在项目层面而不是在人员层面优化
人员
鼓励团队创造一个人人都能成功的环境
要求每个团队成员在项目工作中作出贡献
过程
不要计划遵循完美的敏捷过程，而是注重结果
如果跨职能团队能常常交付完成的价值并反思产品和过程，团队就是敏捷的
仆人式领导的特征
提升自我意识
倾听
为团队服务
帮助他人成长
引导与控制
促进安全、尊重与信任
促进他人精力和才智提升
4.2.1 仆人式领导的职责
4.2.1.1 促进作用
促进者帮助每个人各尽所能的思考和工作
促进者鼓励团队参与、理解并对团队输出共同承担责任
促进者帮助团队创建可接受的解决方案
促进团队内部和团队之间的合作与对话
促进者鼓励大家通过交互式会议、非正式对话和知识共享展开协作，
仆人式领导通过成为公正的搭桥者和教练来做到这一点，而不是代替他责任人来作出决策
仆人式领导通过成为公正的搭桥者和教练来做到这一点，而不是代替他责任人来作出决策
4.2.1.2 消除组织障碍
对仆人式领导而言最好的职责是
认真审视那些阻碍团队敏捷或组织敏捷的过程，并努力使其合理化
认真审视那些阻碍团队敏捷或组织敏捷的过程，并努力使其合理化
更多的时间用于提供有价值的产品而非详尽的文档
关注其他冗长的过程
与他人携手合作，共同质疑和审核可能需要处理的过程或部门的过程，为敏捷团队和领导提供支持
改变和消除这些组织障碍，为交付团队提供支持
4.2.1.3 为他人贡献铺路
为满足团队、项目和组织的需求而工作
仆式领导可以在团队工作场所与团队一起工作与管理层一起
使团队能够一次专注于一个项目
使团队能够一次专注于一个项目
与审计人员合作，改善监管环境中所需的过程
与财务部门合作，版主组织向增量预算过度
专注为团队铺路，让给你团队尽其所能
影响项目，鼓励组织以不同方式思考
人际关系技能与专业技能
团队成员还要重视自身人际关系技能与情商技能，而不仅仅是专业技能
团队每个人都要努力展示
主动性
正直
情商
诚实
合作态度
谦逊
和以不同方式沟通的意愿
4.2.1.4 职责
教育相关方，使其了解为什么要敏捷以及如何敏捷
通过指导、鼓励和帮助为团队提供支持，
倡导团队成员的培训和职业发展
培养和发展团队成员，帮助他们超越自身当前的角色
倡导团队成员的培训和职业发展
培养和发展团队成员，帮助他们超越自身当前的角色
通过技术项目管理活动，如量化风险分析来帮助团队
培训不具备某些角色或功能方面的知识或经验
培训不具备某些角色或功能方面的知识或经验
庆祝团队的成功，为团队与外部团队合作提供支持，并起到桥梁作用
创造项目欣赏的积极氛围，建立加强合作的良好意愿
创造项目欣赏的积极氛围，建立加强合作的良好意愿
4.2.2 PM在敏捷环境中的角色
PM在敏捷项目中的角色有些是未知的，因为许多敏捷框架和方法都不涉及项目经理的角色
PM
需要：务实的敏捷实践者和组织认识到在许多情况下，PM都能够创造重要价值
不需要：因为自组织团队承担了项目之前的职责
4.2.3 项目经理应用仆式领导
PM定义：为“由组织委派，领导团队实现项目目标的个人”
PM习惯：作为项目的协调中心，负责跟踪团队状态，并向组织中的其他成员反应
局限性
当项目被分解为孤立的功能时，这种方法可适用
对于高度不确定性项目，项目的复杂性是一个人无法管理的
PM从事敏捷项目时
PM角色从团队的中心转变为团队和管理人员提供服务
PM充当仆式领导，工作重点转变为引导需要帮助的人，促进团队合作，保持与相关方的需要一致
PM鼓励将责任分配给团队成员，分配给那些掌握完成任务所需知识的人
4.3 团队构成
《敏捷宣言》强调个人和交互的重要性
要善于激励项目人员，为他们提供所需的环境和支持，信任他们能够完成工作
团队考虑如何优化价值流时的好处
人员更有可能合作
团队更快的完成由价值的工作
由于不从事多任务，也不必重新建立环境，团队减少了时间浪费
4.3.1 敏捷团队
注重快速开发产品，以便获得反馈
3到9人组成，100%专职
理想情况下，集中在一个工作场所工作
鼓励自我管理团队
与仆式领导一起成长
领导支持团队的工作方法
成功敏捷团队的属性：展示团队成员如何通过合作提高工作效率、促进创造性地解决问题
4.3.2 敏捷的角色
三种常见角色
跨职能团队成员
产品负责人：
确保团队从事最高价值的工作
考虑使用影响地图查看产品如何组合在一起
团队促进者
敏捷团队角色
4.3.3 通才型专家
敏捷团队由通才型专家组成又名T型人才
团队的目的是优化已完成的工作，并获得反馈
I型人才
某个领域非常专业
有深度缺乏广度
T型人才
能够通过支持一个领域补充自身的专业知识
相关领域虽有所欠缺，但拥有良好的合作技能
有一个明确的公认的专业化的主要角色
同时具有必要时与人协作帮助他人的技能，多种才能及能力
4.3.4 团队结构
集中办公的跨职能团队
分散式或分布式团队
分布式团队可以在不同地点拥有多个跨职能团队
虽然通信成本增加，并给理想的安排但仍然是可行的
4.3.5 专职小组成员
非专职
一个人在团队中只投入25%到50%的能力，则会多任务处理和任务切换
多任务处理降低团队工作产出，并影响团队预测交付能力的一致性
任务切换工作效率损失在20%到40%之间，随着任务数量的增加，效率损失呈指数增加
专职
团队所有人负责一个项目，可作为一个团队持续协作，使每个人的工作更加有效
表A-2项目管理过程组和知识区域映射
4.3.6 团队工作场所
团队需要一个工作场所
一起工作
了解团队状态
进行协作
开例会张贴图标
独立安静的思考办公环境
不同地点工作的团队成员需要虚拟的工作空间，也要考虑让团队成员定期聚集一堂，以便建立信任学习怎样开展合作
分散式团队管理沟通的技术
鱼缸窗口
通过团队分布的各个地点之间减脂长期视频会议链接
开始工作打开，结束关闭链接
人员可以自然看到彼此进行互动，减少身处不停地点工作所固有的协作滞后问题
远程结对
使用虚拟会议工具共享屏幕包括语音和视频链接
只要考虑时区差异因素，几乎和面对面结对一样有效
4.3.7 克服孤岛组织
组件敏捷团队潜在成功因素
构建一个拥有基本信任和安全的工作环境
确保所有团队成员都有平等的话语权
他们的意见都能被听到并得到考虑
加上构建敏捷思维模式
孤岛组织的弊端
给跨职能敏捷团队组建带来重重障碍
团队成员向不同的管理人员报告
管理人员采用不同的标准衡量他们的绩效
克服孤岛组织
与团队成员的不同管理者合作
让他们为跨职能团队安排必要的专职人与那
不仅能建立团队协作，且能让组织看到怎样用人才能优化正在进行中的项目和产品
X2影响裁剪的属性
第5章 实施敏捷：在敏捷环境中交付
5.1 项目章程和团队章程
团队章程：
意义：制定章程的过程能帮助团队学习如何一起工作怎样围绕项目协作
目标：创建一个敏捷环境，在这个环境中，团队成员可以发挥他们作为团队的最大能力
项目章程意义：
了解项目重要的原因
团队的前进方向以及项目的目标
制定团队社会契约（团队章程）的基础
团队价值观：可持续的开发速度和核心工作时间
工作协议：
就绪如何定义，这是团队可以接受工作的前提
完成如何定义，这样团队才能抑制的判断完整性
考虑时间盒
使用工作过程限制
基本规则
有关一个人在会议上发言的规定
团队规范
团队如何看待会议时间
5.2 常见敏捷实践
5.2.1 回顾
是最重要的一个实践，能让团队学习、改进和调整其过程
从之前产品开发公祖及其过程中学习
《敏捷宣言》背后原则之一“团队要定期反省如何能够做到更加有效，并相应的调整团队的行为”
团队回顾不需要迭代
进行回顾的关键时刻
当团队完成一个发布或者加入一些功能时，任何发布，无论大小
自上次回顾以来，又过了几周时间
当团队出现问题时，以及团队协作完成工作不顺畅时
当团队达到任何其他里程碑时
如何实施
针对定性（人的感觉），
和定量（衡量指标）数据
利用这些数据找根源设计对策，并制定行动计划
5.2.2 待办事项列表编制
定义：已故事形式呈现给团队的所有工作的有序列表
产品负责人可能会制定一个产品路线图，显示预期的可交付成果序列，产品负责人根据团队的实际成功重新规划路线图
5.2.3 待办事项列表的细化
基于迭代的敏捷中，产品负责人在迭代中期一次或多次会议中与团队合作，为即将急性的迭代准备一些故事，通过会议细化足够的故事，让团队了解故事内容，以及相互之间的关系
细化过程连续区间时间
基于流程的敏捷的即时细化（从待办中拿一个出来讨论）
许多基于迭代的敏捷团队在两周的迭代中用1小时的时间盒讨论
基于迭代的敏捷团队的多次细化讨论，团队可以在陌生产品、产品领域问题领域使用该技巧
产品负责人处理待办事项列表的细化准备与会议
鼓励团队在开发人员、测试人员、业务分析人员和产品负责人三方面开展合作，一起讨论和撰写故事
把整个故事的概念呈现给团队，团队进行讨论，并根据需要将其细化为许多故事
与团队一起寻找各种方法团所和撰写故事，确保所有的故事都足够小，以便团队能源源不断的交付完成的工作，考虑每天至少完成一个故事
5.2.4 每日站会
团队成员利用每日站会对彼此作出小的承诺，发现问题，并确保团队工作顺利进行
基于迭代的敏捷中，每个人轮流回答以下问题
上次站会以来我饿都完成了什么？
从现在到下次站会，我计划完成什么
我的障碍风险或问题是什么
基于流程的敏捷，团队从右到左对看板进行苹果，将注意力集中在团队的产出上
我们还需要做些什么来推进这一工作
有人在做看板上所没有的事情吗
作为一个团队，我们需要完成什么
工作流程是够存在瓶颈或阻碍
站会反模式
是站会变成了传统预测环境中的状态报告会议
鼓励团队任何成员来主持而不是由项目经理或领导主持，来避免该模式
问题变得明显时，团队才开始解决问题
站会为了发现问题而不是解决，将问题添加到停车场？区创建新的会议解决
5.2.5 展示/评审
团队以用户故事的形式完成特定功能时，团队定期展示工作产品，产品负责人看过后表示接受或拒绝故事
基于迭代敏捷
迭代结束时展示所有已完成的工作项
基于流程的迭代
在需要时展示完成的工作，通过时当完成的功能累计到足以构成一个连贯组合时
团队包括产品负责人在内，都需要反馈来决定何时需要产品反馈
项目敏捷的一个基本要素时频繁的交付工作产品
5.2.6 规划基于迭代的敏捷
团队能力不同，产品负责人的典型故事大小不同，团队应考虑自身故事大小，避免提交更多的故事而超出一个迭代中所能完成工作的能力
当人员不可用时，团队能力降低，只计划相应能力能够完成的工作
估算能够完成的工作是一种能力的衡量
敏捷团队在一个工作块不会只计划一次，而会开始计划一点，交付学习然后在一个持续循环中重新规划更多的东西
5.2.7 帮助团队交付价值的执行实践
如果不重视质量，很快就会无法快速发布任何东西
来自极限编程的技术实践，帮助团队以最快速度交付
持续集成
频繁的将工作集成到整体中，在进行重新测试已确定整个产品仍然按照预期工作
在不同层面测试
端到端使用系统级测试
构建块使用单元测试
在两者之间了解是否需要进行集成测试以及在何处进行测试
敏捷团队偏爱自动化测试，他们可以借此构建和保持交付的势头
验收测试驱动开发ATDD
整个团队聚集一堂讨论工作产品的验收标准
然后创建测试，让团队能够编写足够的代码，进行自动化测试
非软件项目，要考虑怎样在团队完成大量价值时对工作进行测试
测试驱动开发TDD和行为驱动开发BDD
在编写/创建产品之前白那些自动化测试，帮助人员设计产品，防范产品错误
非软件项目，考虑如何通过测试驱动团队设计
硬件和机械类项目经常使用模拟进行设计的中间测试
刺探（时间盒研究或实验）
对学习很有用，在诸如评估、验收标准定义以及通过产品了解用户行为的流程中使用
团队学习一些关键技术或功能要素时，刺探会很有帮助
5.2.8 迭代和增量如何帮助交付工作产品
迭代帮助团队为交付和多种反馈创建一个节奏
团队为交付和反馈创建增量
交付的第一部分时一次演示
经常为反馈演示以便决定项目组合的人看到实际进展
演示和评审时敏捷项目流程的必要组成部分，为团队的交付节奏安排适当的演示
5.3 解决敏捷项目的挑战
敏捷方法
解决具有变化率 不确定性和复杂性的项目相关问题的需要
敏捷的痛点和解决痛点的可能性
5.4 敏捷项目的衡量指标
敏捷关注客户价值
状态报告的问题
团队预测完成或使用交通灯状态描述项目的能力
预测型衡量指标的问题
并不反映真真实的情况
直到发布日期前一个月项目状态一直是亮的，经常会变成红色，没有任何警告，因为直到发布日期前一个月才会得到项目的经验数据
敏捷项目的衡量指标
包含有意义的信息
敏捷项目要定期交付价值
定量指标
替代衡量指标不如经验指标更有用
敏捷帮助团队发现问题和难题，以便团队能够诊断和解决问题
定性指标
侧重于团队选择的实践，评估团队使用这些实践的情况
对交付功能的满意度
团队的士气
团队希望跟踪的任何东西
5.4.1 敏捷团队的衡量结果
敏捷基于经验和价值的衡量指标，衡量团队交付的成果，而不是团队预测交付的成果
建立稳定的速度或平均实践，能够预测项目将花费的实践
基于迭代的项目使用燃尽图查看项目随时间的进展情况
燃尽图：剩余故事的燃尽图，虚线代表计划
燃起图：已完成故事的燃起图
迭代中完成工作的能力（完成故事点）来建立成员下一个迭代的能力衡量指标
四到八次迭代达到稳定的速度
基于流程的敏捷团队使用不同的衡量指标
交付周期（交付一个新项目花费的总时间），从项目添加到看板直到项目完成
周期时间（处理一个工作项目所需的时间）
响应时间（一个工作新安股等待工作开始时间）
在一个功能燃起图/燃尽图和一个产品待办事项列表中衡量已完成的工作
第6章 关于项目敏捷性的组织考虑因素
6.1 组织变革管理
有意义变革的全面整体性方法
说明变革动态变化的模型
实现变革的框架
项目、项目集和项目组合层面的变革管理实践应用
6.1.1 变革管理驱动因素
与加速交付相关的变革
敏捷强调频繁并尽早交付项目输出，但是接收组织可能尚未做好加速纳入这些输出的充分准备
加速交付将考验组织适应该交付的能力。成功发现和交付项目功能是不够的，如果组织抗拒项目输出，则会延迟目标投资回报
客户接受并支持项目输出在敏捷环境中日益盛行
与敏捷方法相关的变革
将工作分解到迭代原型时会涉及到不利的返工
6.1.2 变革就绪情况
变革友好特征
管理层的变革意愿
组织在员工认知、审核和评估方法上最初改变的意愿
集中或分散项目、项目集和项目组合管理职能
专注于短期预算和指标而不是长期目标
人才管理成熟度和能力
成为实现组织敏捷性相关变革的障碍特征
工作被分解为部门孤岛，从而创造出阻碍加速交付的依赖关系，而不是构建在能力中心指导下的跨职能团队
采购策略基于短期定价策略，而不是长期能力
奖励领导的依据是本地效率而不是端到端项目交付流或整体优化情况
员工属于特定领域人才，实现技能多元化的工具或激励有限，不重视培养T型专家人才
分散化项目组合使员工同时分配到过多的项目，而无法专注与单个项目
加速文化兼容性可尝试的方法
积极明确的管理层支持
变革管理实践，包括沟通和引导
逐个项目应用敏捷实践
向团队增量地引入敏捷实践
通过采取适用的敏捷技术和实践示范引导
6.2组织文化
是组织的核心标识
6.2.1 创建安全环境
组织中最重要的文化规范
愿意尝试任何新方法或技术
将有利于构建安全的工作环境
6.2.2 评估文化
文化VS结构
采取何种模式或方法并不重要，关键是让领导了解其环境的驱动因素
了解组织需要满足的组织与行业需求后才能选择合适的对话、权衡尤其是技术
6.3 采购和合同
客户协作高于合同协作
设计动态特性的合同签署技术
多层结构
单个文档中正式说明整个合同关系
在不同文档中说明不同方面来提高灵活性
固定项目锁定在主协议
所有方可能会变更的其他项目列在服务明细表中
合同主要服务协议中注明这些服务参考
将合同中的更多变化因素隔离到单独的文档中，将会简化修改工作并提高灵活性
强调价值交付
许多供应商关系是由专注于中间人为因素的固定里程碑或阶段关口控制
而不是由增量业务价值的完全可交付成果控制
通常这些控制会限制利用反馈来改进产品
与之相反的是，里程碑和支付项目可以根据价值驱动可交付成果来构建，以增强项目敏捷性
总价增量
项目可以将范围分解为总价微型可交付成果
而不是将整个项目范围和预算锁定到单个协议中
于客户：可以更好的控制资金流向
于供应商：可以限制对单个功能或可交付成果的过多承诺所带来的财务风险
固定时间和材料
客户采用传统的方法时会产生不必要的风险
一种替代方法是将整体预算限制为固定数量
这就允许客户在最初末计划的项目汇总纳入新的观点和创新
累进的时间和材料
另外一种替代方法是共担财务风险法
在敏捷方法中，质量标准是已完成工作的一部分
因此，如果在合同期限之前交付，则可对供应商的高效率进行奖励
相反，如果供应商延迟交付，则将会扣除一定费用
提前取消方案
如果敏捷供应商在仅完成一般范围时便可交付足够的价值，且客户不再徐阿哟另外一半范围，则不必支付这部分费用
但合同中可以规定客户应为项目剩余部分支付一定的取消费用
因为不再需要这些服务，客户可以限制预算敞口，而供应商也可获得可观的收入
动态范围方案
于固定预算的合同，供应商可为客户提供在项目特定点改变项目范围的方案
客户可调整功能以适应该能力
客户便可利用创新机会同时限制供应商的过度承诺风险
团队扩充
大多数协作合同方法是将供应商服务直接潜入客户组织中
通过资助团队而不是特定范围，可以保留客户自行确定需要完成工作这方面策略的权利
支持全方位供应商
为了分化风险，客户可能需要采取多供应商策略
但是这样的结果是，每家供应商职能负责一项工作，这就会产所依赖关系，阻碍可行服务或产品的交付
相反，要强调提供全面价值的合约
可以创建敏捷合同，敏捷是在协作和信任的共同基础上建立的
供应商尽早频繁交付价值
客户能够提供及时反馈
6.4 商业实践
需求产生时，组织创建新能力的意愿和能力即时组织敏捷性的标志
透明和开放协作至关重要
当组织发展到更高敏捷性时，其他业务不猛将有必要更改其交互方式并履行自己的职责
应用户对组织其他领域有益的变更，以此来提高整个组织的效率
6.5 多团队协作和依赖关系（扩展）
6.5.1 框架
Scrum 和极限编程的敏捷方法
知道专注于单个小型且通常时集中办公的跨职能团队活动
需要在一个项目集或项目组合中进行多个敏捷团队协作的框架
大规模敏捷框架
大规模敏捷开发
规范敏捷
Scrum of Scrums 方法
附录A3
6.5.2 考虑事项
由多种扩展工作的方式
团队可能需要将多个敏捷项目工作扩展到单个敏捷项目中
或组织科技设计出支持整个项目组合中不同敏捷方法的结构
无论什么方法关键成功因素是健康的敏捷团队，先单个团队采用敏捷无法获得成功，勿将其扩展更大范围，要先行解决组织团队敏捷工作的组织障碍
大规模敏捷项目的目标是协调不同团队的工作以便为客户提供价值
这有多种实现方式，团队可以采用正式的框架或应用敏捷思维调整现有项目集管理实践
6.6 敏捷和项目管理办公室（PMO）
设立PMO的目的
是引导组织实现商业价值
通过实现项目目标达到目的
PMO还会提供团队教育 项目支持
针对给定项目或项目集提供相关商业价值方面的管理建议
6.6.1 敏捷PMO为价值驱动型
目标
所有项目都应在合适的为合适的受众提供合适的价值
基于敏捷的PMO方法以客户协作思维为基础，并存在于所有PMO项目集中
PMO应努力按需交付并紧跟客户需求，确保了解并适应他们的需求
这种内部创业方法专注于能为所支持的项目提供最大价值的PMO活动
6.6.2敏捷PMO为面向创新型
为了基于价值的章程下加速发展，PMO可能需要强制执行某些解决方案或方法
6.6.3 敏捷PMO为多科学型
为了支持特定项目需求，PMO需要熟悉项目管理本身以外的一些能力，因为不同项目要求不同的能力
将其PMO转换为卓越敏捷中心以提供一下服务
制定和实施标准
提供用户故事
测试案例
累计6流图等模版
提供敏捷工具并培训支持小组了解迭代开发概念
通过培训和指导发展人才
协调敏捷培训课程、教练和导师以帮助员工过度到敏捷思维模式并升级其技能
鼓励和支持员工参与本地敏捷活动
多项目管理
通过不同项目交流协调敏捷团队
考虑分享进度、问题回顾性发现和改进实验等内容
借助适当的框架，帮助管理项目层的主要客户发布和项目组合层的投资主题
促进组织学习
手机项目进度信息并获取、存储和记录回顾性发现成果
管理相关方
提供产品负责人培训
知道验收测试以及评估方法，并提供系统反馈
宣扬主题专家对项目的重要性
招聘、筛选和评估项目领导
制定敏捷实践者访谈指南
执行专业化项目任务
培训和提供回顾促进者，与敏捷项目问题解决者定力协议，并提供导师和教练
6.7 组织结构
组织结构严重影响其转向新信息或转变市场需求的能力
主要特征
地理
职能结构
项目可交付成果的大小
项目人员分配
重采购型组织
6.8 组织演变
应对单个挑战领域或实施新的混合或敏捷方法时，建议以累积方式承接工作
常用实践是将变更过程视为一个敏捷项目，团队可以根据自己的价值观或其他考虑事项引入自己的变更待办事项列表并确定其优先级
使用看板跟踪进度
显示已作为“已完成”使用的新方法
被视为“进行中”的方法
仍在等待被引入“待办事项的方法”
第7章 行动呼吁
附录 1
附录A1 项目管理过程组与知识领域
附录A2
附录 A2-1 敏捷实践指南中涵盖的敏捷宣言价值观
附录 A2-1 敏捷宣言背后原则的实践指南映射
附录 A3 敏捷和精益框架概述
A3.1 《敏捷实践指南》的选择标准
专供整体使用
适合常用环境
现代流行用例
A3.2 Scrum
用于管理产品开发的单个团队过程框架
包含
Scrum角色
事件
工件
规则
是运行在一个月或更少事件的事件盒上，其中包含持续事件一致的多个冲刺，在这些冲刺中会产生潜在可发布的产品增量
Scrum 团队
产品负责人：负责实现产品价值最大化
跨职能自组织团队：开发成员拥有所需的一切资源，可在不依赖团队外部其他资源的情况下交付工作产品
Scrum主管：负责确保Scrum过程获相应支持且Scrum团队遵循从实践和规则并指导团队消除障碍
Scrum 事件和工作
A3.3 极限编程
是一种基于频繁交付周期的软件开发方法
基于理念：将特定最佳实践提炼到最纯粹和最简单的形式，然后在整个项目周期内持续运用该实践
XP最受关注的地方在于推广旨在改建u软件项目成果的整套实践
最初包含十二种主要实践，随后逐渐演变一些推论实践
极限编程实践
A3.4 看板方法
看板在精益制造种是一种用于规划库存控制和补给的系统
看板适用于以下需要
灵活性
专注于持续交付
提高工作效率和质量
提高效率
团队成员专注力
工作负载的可变性
减少浪费
看板方法的定义原则和属性
A3.5 水晶方法
一会走功能方法论家族
旨在根据项目规模以及项目的关键性来量化并提供方法严格程度选择
认识到每个项目可能需要一系列轻量裁剪的策略、实践和过程，以匹配项目的独特特征
水晶来源自宝石，不同面代表根本的核心原则和价值观
技术
工具
标准
角色
水晶原则的核心价值观和常见属性
A3.6Scrumban
一种敏捷方法，最初设计为Scrum到看板之间的过度方法
他是通过其自身演变而成的另一种混合敏捷框架和方法，其中团队将Scrum作为框架，而将看板作为过程改进方法
A3.7 功能驱动开发
目的：满足大型软件开发项目的特定需求，小型商业价值功能重视能力
六个主要角色，每人担任一个或多个角色
项目经理
首席架构师
开发经理
首席编程人员
类负责人 和/或
领域专家
五个过程或活动
以迭代方式执行
开发整个模型
构建功能列表
依据功能规划
依据功能设计
依据功能建设
一组核心软件工程最佳实践提供支持
领域对象建模
依据功能开发
个体代码所有制
功能团队
检查
配置管理
定期构建
进度和结果可视化
A3.8 动态系统开发方法
一种敏捷项目交付框架
最初设计目的是提供20世纪90年代普及的迭代方法的严格程度
DSDM因强调制约因素驱动交付而著称
一开始便可设置成本、质量和实践
然后利用正式的范围优先级来满足这些制约因素的要求
八个指导原则
专注于业务需求
准时交付
协作
在质量上永不妥协
在坚实的基础上进行增量式构建
迭代开发
保持持续和明显的沟通
演示控制
A3.9 敏捷统一过程
是软件项目种统一过程UP的分支
与紧前统一过程相比，该过程具有加速周期和轻量级的过程
表敏捷统一过程的主要元素
A3.10 扩展框架
由两个或多个团队而不是一个大型Scrum团队所使用的一种技术，其中一个团队包含三到救命成员来协调工作
A3.11 大规模敏捷框架
专注于所有级别企业的大规模开发工作题哦功能模式知识库
专注以下原则
采用经济视角
应用系统思维
假设可变性，预留方案
以快速整合学习周期进行增量式构建
根据对工作系统的客观评估设定里程碑
直观显示并限制在制品，减少小批次规模并管理队列长度
应用节奏与跨域规划同步
解锁知识员工的内在公里
决策分散化
A3.12 大规模敏捷开发
是一种一扩展Scrum 方法为共同目标来组织多个开发团队的框架
其核心组织原则是尽可能保留传统单个团队Scrum模型的元素
表Less与Scrum比较
A3.13 企业Scrum
是一种旨在通过更整体性组织而不是单个产品开发层来应用Scrum方法的框架
该框架兼职组织领导
将所有的SCRUM 应用扩展到所有组织方面
普及Scrum技术以便在这些不同的方面轻松应用
根据需要使用补充扩展Scrum方法
A3.14 规范敏捷
是一种在综合模型中整个多个敏捷最佳实践的过程决策框架
为实现这种平衡，该方法根据以下原则缓和了多种敏捷技术
以为为先
面向学习
完全交付生命周期
目标驱动
企业意识
可扩展
附录X2 影响裁剪的属性
附录X 3 敏捷筛选工具
0 条评论
下一页
