敏捷实践指南

T_Mac|mumu

已于 2022-09-29 20:47:48 修改

阅读量1.2k

点赞数

分类专栏： PMP 文章标签：学习

于 2022-09-29 20:40:57 首次发布

本文链接：https://blog.csdn.net/T_Mac9334/article/details/127113674

版权

PMP 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

敏捷实践指南

敏捷概述

可确定的工作与高度不确定的工作

可确定的工作项目具有明确的流程,他们在以往类似的项目中被证明是行之有效的.
高度不确定的项目变化速度快,复杂性和风险也高
传统预测法旨在预先确定大部分需求,并通过变更请求过程控制变更
敏捷方法的出现是为了在短时间内探讨可行性,根据评估和反馈快速调整.

敏捷宣言及思维模式

敏捷宣言

个体以及互动而不是过程和工具
可用的软件而不是完整的文档
客户合作而不是合同谈判
应对变更而不是遵循计划

十二原则

我们的最高目标是,通过尽早交付有价值的软件来满足客户的需求
欢迎对需求提出变更,即便在项目开发后期也不例外.敏捷过程要善于利用需求变更,帮助客户获得竞争优势
要经常交付可用的软件,周期从几周到几个月不等,且越短越好
项目实施过程中,业务人员与开发人员必须始终通力合作.
要善于激励项目人员,给予他们所需的环境支持,并相信他们能够完成任务.
无论是对开发团队还是团队内部,信息传达最有效的方法都是面对面的交谈.
可用的软件是衡量进度的首要衡量标准
敏捷过程提倡可持续的开发.项目发起人.开发人员和用户应该都能够始终保持步调稳定
对技术的精益求精以及设计的不断完善将提高敏捷性.
简洁,即尽量最大可能减少不必要的工作,这是一门艺术
最佳的架构,需求和设计将出自于自组织团队
团队要定期反省怎么做才能更有效,并相应地调整团队行为.

敏捷方法

敏捷方法和看板方法视为精益方法的子集
敏捷方法包括:
- Scrum
- XP(极限编程)
  - 基于频繁交付周期的软件开发方法
  - 推广旨在改进软件项目成果的整套实践
- FDD(功能驱动开发)
  - 目的:满足大型软件开发项目的特定需求小型商业价值功能重视能力
- DSDM(动态系统开发方法)
  - 强调制约因素驱动交付而著称
  - 从一开始便设置成本,质量,时间然后利用正式的范围优先级来满足这些制约因素的要求
- AUP(敏捷统一过程)
  - 具有加速周期和轻量级的过程
  - 目的:在七个主要因素之间执行更多迭代的周期,并在正式交付之前纳入相关反馈
- ScrumBan
- 看板
  - 一种用于规划库存控制和补给的系统
  - 推动和实现整个系统中工作流的可视化
  - 确保工作流和价值交付的持续性
  - 灵活性:团队不受时间盒的限制,将执行待办事项列表中优先级最高的工作
  - 专注于持续交付:团队专注于完成整个系统工作流,直至在制品完成后才会开始工作
  - 提高工作效率和质量:通过限制在制品将可以提高工作效率和质量
  - 提高效率:检查每个任务,了解增值或非增值活动,然后清除非增值活动
  - 团队成员专注力:限制在制品,使团队能够专注于当前工作
  - 工作负载的可变性.如果即将开展的工作存在不可预测型,团队将无法做出可预测承诺,即使对于短期工作也不例外
  - 减少浪费:透明将会使浪费可视化,因而能够消除浪费.
- 水晶
  - 旨在根据项目规模(人员数量)以及项目的关键性来量化并提供方法严格程度的选择
- SOS
  - 由两个或多个scrum团队而不是一个大型的Scrum团队所使用的技术
  - 确保团队协调工作并清除障碍,以优化所有团队效率

不确定性,风险和生命周期选择

随着项目不确定性的增加,返工的风险和使用不同方法的需求也会增加,为了减轻风险的影响,团队选择的生命周期要能通过较少的工作增量解决项目的大量不确定性问题.
与静态书面规范相比,当团队交付小的增量时,他们能够更快更准确的理解真正的客户需求.
通过构建一个小的增量,对其进行测试和评估,团队可以在短时间内以低成本探索不确定性,降低风险,最大程度地实现商业价值的交付.

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-P5NybdO2-1664455201300)(/Users/sunhao/Library/Application Support/typora-user-images/image-20220802161419826.png)]

迭代和增量方法应用技术

非常短的反馈循环
频繁调整过程
重新进行优先级排序
定期更新计划
频繁交付

迭代,增量,敏捷方法适应的项目

需要研究和开发
变更速度极快
具有不明确或未知的需求,不确定性或风险
最终目标难以描述

生命周期的选择

预测型生命周期
- 提前进行大量的计划工作,然后一次性执行,执行是一个连续的过程
迭代型生命周期
- 允许对未完成的工作进行反馈,从而改进和修改工作
增量型生命周期
- 向客户提供各个已完成的,可能立即使用的可交付成果.
敏捷型生命周期
- 有迭代,也有增量,便于完善工作,频繁交付

项目生命周期的特征

方法	需求	活动	交付	目标
预测型	固定	整个项目仅执行一次	一次交付	管理成本
迭代型	动态	反复执行直至修正	一次交付	解决方案的正确性
增量型	动态	对给定的增量执行一次	频繁更小规模交付	速度
敏捷型	动态	反复执行直至修正	频繁小规模交付	通过频繁小规模交付和反馈实现客户价值

预测型生命周期的特征

从高确定性的明确的需求 ,稳定的团队和低风险中获益.
生命周期

迭代型生命周期的特征

通过连续的原型或概念验证来改进产品或成果
迭代有利于识别和减少项目的不确定性
生命周期

增量型生命周期特征

加快交付速度,无法等待所有事情全部完成.
生命周期

敏捷型生命周期的特征

迭代和增量方法能够提供反馈,以便改善项目下一部门的计划.
敏捷项目中,增量交付会发现隐藏或误解的需求.
客户满意度将随着有价值产品的早期交付和持续交付不断提升
功能性的,提供价值的增量可交付成果,是衡量进展的主要尺度.

混合型生命周期的特征

混合敏捷方法

敏捷团队不局限于一种敏捷方法
敏捷框架不是针对团队定制的,为了定期交付价值,团队可能需要对实践进行剪裁.
协调方法

协调使用Scrum框架,看板方法和极限编程(XP)

Scrum提供指导

看板面板提高效率,将工作流可视化,使障碍更容易被察觉,通过调整在制品限制来实现流程管理

受极限编程启发的工程实践(故事卡,持续集成,重构,自动化测试和测试驱动开发) 提高敏捷团队效力

影响剪裁的项目因素

项目因素	裁剪方案
需求模式:稳定型或偶发型	使用节奏(定期时间盒)能帮助演示,回顾和理解新任务.
团队经验水平所要求的的过程改进速度	更频繁地回顾并选择改进措施
工作流往往被各种延误或障碍打断	利用看板让工作
产品增量的质量不佳	利用各种测试驱动开发的实践.这种防错机制使缺陷难以不被发现
创建某个产品需要不止一个团队	了解敏捷项目集管理或正规扩展框架
团队成员缺乏使用敏捷方法的经验	1. 培训 2. 如果使用特定方法如Scrum或看板, 则举办研讨会

实施敏捷:创建敏捷环境

仆人式领导为团队赋权

仆人式领导是一种为团队赋权的方法,注重理解和关注团队成员的需求和发展.旨在使团队尽可能达到最高绩效
仆人式领导可以帮助他们的团队通过合作更快的交付价值
仆人式领导通过管理关系,在团队内和组织中建立沟通与协作.
仆人式领导在团队内部和团队之间帮助发现瓶颈问题,并进行沟通.然后团队将解决这些瓶颈问题
仆人式领导消除组织障碍
敏捷宣言的第一个价值观个人与过程和工具的交互
对仆人式领导而言,更好的职责是认真审视那些阻碍团队敏捷或组织敏捷的过程,并努力使其合理化
仆人式领导为他人贡献铺路
仆人式领导为满足团队,项目和组织的需求而工作.
仆人式领导领导影响项目,鼓励组织以不同方式思考.
仆人式领导的职责
教育相关方,使其了解为什么要敏捷以及如何敏捷.
通过指导,鼓励和帮助为团队提供支持.倡导团队成员的培训和职业发展.
仆人式领导的一个关键作用是,培养和发展团队成员,帮助他们超越自身当前角色,即时团队将失去他们也在所不惜.
通过技术项目管理活动,如量化风险分析来帮助团队.通过提供培训或开展活动为团队提供支持.
项目经理的价值不在于他们的岗位,而在于他们能够让每个人都变得更好
从事敏捷项目工作时,项目经理的角色就会从团队中心转变成为团队和管理人员提供服务
作为仆人式领导,项目经理要鼓励将责任分配给团队成员,分配给那些掌握完成任务所需知识的人.

团队构成

敏捷宣言的价值观和原则的一个核心宗旨是强调个人和交互的重要性.
要善于激励项目人员,为他们提供所需的环境和支持,信任他们能完成工作
敏捷优化了价值流,强调了向客户快速交付功能,而不是怎样"用"人
团队优化价值流的好处:1.人员更有可能合作 2.团队更快的完成有价值的工作 3.由于不从事多任务,也不必重新建立环境,团队减少了时间浪费.
敏捷团队
敏捷团队注重快速开发产品,以便能获得反馈.
最有效的敏捷团队往往由三到九个成员组成
理想情况下,敏捷团队应几种在一个团队工作场所工作.团队100%为专职成员.
团队越是限制在制品,团队成员就越有可能通过合作来加快整个团队的工作.
团队在给定的时间解决所有的需求,然后视图完成所有的设计,继而去完成所有的构建,就会发生迷你瀑布的情况.
敏捷的角色
跨职能团队成员:具备生产可行产品所需的各种必要技能的团队成员
产品负责人
团队促进者
通才型专家
团队成员在具备一项擅长的专业化技能的同时,还拥有多种技能的工作经验,而不是单一的专业化.
团队的目标是提高过程效率,优化整个团队的产能.
团队规模小会促进团队的合作
产品负责人的工作是确保团队从事最高价值的工作.
团队结构:跨职能团队/分布式团队/分散式团队
专职小组成员
成员只投入25%或50%的能力,带来的问题是,他们会进行多任务处理和任务切换,多任务处理会降低团队工作的产出,并影响团队预测交付能力的一致性.
多任务处理减缓了整个团队的进展,因为团队成员要浪费时间切换环境或相互等待完成其他工作.
任务切换时,人员效率的损失在20%-40%之间,随着任务数量的增加,效率损失会呈指数级增长.
当人员100%为团队专职工作是,团队最有可能最快产出.
团队工作场所
团队需要一个工作场所,可以一起工作.了解他们作为团队的状态,并进行协作.
在不同地点工作的团队成员需要虚拟的工作空间.考虑让团队成员定期聚集一堂,以便简历信任,学习怎样开展工作.
分散式团队管理沟通的技术:1.鱼缸窗口 2.远程结对
鱼缸窗口:通过在团队分布的各个地点之间建立长期视频会议链接,创建一个鱼缸窗口.
远程结对:通过使用虚拟会议工具来共享屏幕,包括语音和视频链接,简历远程结对.只要考虑了时差问题,这种方法和面对面结对是一样的.
克服组织孤岛
组件敏捷团队最好的开端是构建一个拥有基本信任和安全的工作环境,以确保所有团队成员都有平等的话语权,他们的意见都能被听到并得到考虑.
孤岛组织往往给跨职能敏捷团队的组建带来重重障碍.
为克服组织孤岛问题,就要与团队成员的不同管理者合作,让他们为跨职能团队安排必要的专职人员
作为敏捷项目的领导,首先要把重点放在如何组建跨职能团队,让所有团队成员100%投入团队工作.

实施敏捷:在敏捷环境中交付

项目章程和团队章程

项目章程能了解项目之所以重要的原因,团队的前进方向以及项目的目标
制定章程的过程能帮帮助团队学习如何一起工作,怎样围绕项目工作.
敏捷项目章程:项目愿景/项目目标/发布标准/预期的工作流
仆人式领导可以促进章程的制定过程.
只要团队知道如何一起工作,制定团队章程就不需要一个正式的过程.
团队的社会契约即团队章程.规定团队成员之间彼此互动的方式.
制定团队章程的基础
- 团队价值观,例如可持续的开发速度和核心工作时间
- 工作协议,例如就绪如何定义.这是团队可以接受工作的前提;完成如何定义.这样团队才能一致地判断完整性;考虑时间盒;使用工作过程限制;
- 基本规则,例如有关一个人在会议上发言的规定
- 团队规范,例如团队如何对待会议时间.
团队章程的目标是创建一个敏捷的环境.在这个环境中,团队成员可以发挥他们作为团队的最大能力.

常见的敏捷实践

回顾
回顾是最重要的一个实践,原因是能让团队学习,改进和调整其过程.
回顾可以帮助团队从之前的产品开发工作及其过程中学习.
敏捷宣言的原则之一:团队要定期反省如何能够做到更加有效,并相应的调整团队行为.
可以进行回顾的时刻
- 当团队完成一个发布或者加入一些功能时
- 自上次回顾以来,又过了几周时间
- 当团队出现问题时,以及团队协作完成工作不顺畅时.
- 当团队到达任何其他里程碑时
团队在完成工作时遇到困难,可以计划用充足的时间组织回顾,以此收集数据,处理数据,再决定之后要尝试的实验做法
回顾不是责备,是让团队从以前的工作学习中学习并做出小的改进.
回顾针对定性的和定量的数据,然后利用这些数据找到根源,实际对策,并制定行动计划,项目团队可以采取许多行动事项来消除障碍
考虑限制行动事项的数量,使团队在即将进行的迭代或工作期间有能力改进.
待办事项列表编制
待办事项列表是所有工作的有序列表,它以故事形式呈现给团队.工作开始之前,不需要为整个项目创建所有故事.
产品负责人可能会制作一个产品路线图,以显示预期的可交付成果序列.
产品负责人根据团队的实际成果重新规划路线图.
待办事项列表细化
基于流程敏捷的即时细化.团队将下一张卡片从待办事项列表中拿出来讨论
许多基于迭代的敏捷团队在两周的迭代中用1小时的时间盒讨论.
基于迭代的敏捷团队的多次细化讨论.团队可以在陌生的产品,产品领域或问题领域使用这一技巧.
考虑使用影响地图查看产品如何组合在一起.正常情况下,产品负责人领导者项工作.
影响地图: 一种战略规划技术被组织作为打造新产品的路线图.
细化会议上,产品负责人向团队介绍故事的创意,让团队了解故事中潜在的挑战或问题
团队通常有一个目标,每周用不超过1小时的时间来为下一批工作细化故事.
每日站会
团队成员利用每日站会对彼此做出小的承诺,发现问题,并确保团队工作顺利进行
每日站会的时间盒不超过15分钟.
团队以某种方式"过一下"看板或任务板,而团队中的任何人都可以主持站会
站会是为了发现存在问题,而不是解决它们.将问题添加到停车场区,然后创建另一次会议,它可以在站会之后立即召开,并在会上解决问题.
鼓励任何团队成员主持会议而不是由项目经理或领导主持,以确保它不会变成状态报告会议,而是作为团队进行自我组织和互相承诺的会议.
展示/评审
当团队以用户故事的形式完成特定功能时,团队会定期展示工作产品.看过展示后,产品负责人接收或拒绝故事.
团队在迭代结束时展示所有已完成的工作项.
使项目敏捷的一个基本要素是频繁地交付工作产品.一个没有展示或发布的团队,其学习的速度不会快,并且很有可能并未采用敏捷技术.
规划基于迭代的敏捷
团队应考虑自身故事大小,避免提交更多的故事,而超出在一个迭代中所能完成工作的能力
在团队能力下降的情况下,团队只会计划相应能力能够完成的工作.
帮助团队交付价值的执行实践
持续集成: 频繁地将工作集成到整体中,然后再进行重新测试,以确定整个产品扔然按照预期工作
在不同层面测试:
- 系统级测试 :端到端信息
- 单元测试 : 构建块
- 集成测试:
- 冒烟测试: 工作产品是否良好
- 回归测试 :维护产品质量的同时,良好的构建性能
- 自动化测试 :构建和保持交付势头
验收测试驱动开发(ATDD): 整个团队聚集一堂讨论工作产品的验收标准.
测试驱动开发(TDD)和行为驱动开发(BDD).
刺探(时间盒研究或实验):团队开展研究或针对方案的某个方面进行原型研究验证其可行性
迭代和增量如何帮助交付工作产品
迭代可以帮助团队为交付和多种反馈创建一个节奏
团队会为交付和反馈创建增量
演示或评审是敏捷项目流程的必要组成部分

解决敏捷项目的挑战

团队应该经常为反馈进行演示,并展示进度.鼓励PMO和其他感兴趣的人观看演示,以便决定项目组合的人能够看到实际的进度.

敏捷项目的衡量指标

敏捷倾向于使用基于经验和价值的衡量指标,
用飓风图反映估算的可变性,也可以使用发起人能够理解的其他一些可变性衡量方法
燃尽图查看项目随时间的进展情况
燃起图显示已完成的工作,可以衡量挣值
燃尽图显示了团队成员的多任务处理,过于庞大的故事或团队成员缺勤的效果
燃起图显示迭代过程中范围内的变化
速度:本次迭代中实际完成功能的故事点大小的总和
团队可能需要四到八次迭代才能达到稳定的速度
交付周期:交付一个项目花费的总时间,从项目添加到看板直至项目完成
交付周期有助于理解从第一次查看特定功能到向客户发布该功能所需的周期时间
周期时间:处理一个工作项目所需的时间
团队通过衡量周期时间发现瓶颈和延迟问题,问题不仅限于团队内部
响应时间:一个工作项目等待工作开始的时间
相对估算的缺点:无法比较各个团队或在团队之间增加速度

关于项目敏捷性的组织考虑因素

组织审查和修改这些实践的意愿程度将决定采用敏捷方法的速度和效率
采购与合同
动态特性的合同签署技术
- 多层结构:除了在单个文档中正式说明整个合同关系,项目方可以通过在不同文档中索命不同方面来提高灵活性.
- 强调价值交付:里程碑和支付项目可以根据价值驱动可交付成果来构建,以增强项目敏捷性
- 总价增量:将范围分解为总价微型可交付成果,而不是将整个项目范围和预算锁定到单个协议中.
  - 对客户而言,更好的控制资金流向
  - 对供应商而言,可以限制对单个功能或可交付成果的过多承诺所带来的的财务风险
- 固定时间和材料:将整体预算限制为固定数量
- 累进的时间和材料:共担财务风险法.在合同期限之前交付,对供应商进行奖励,相反,则扣除一定费用
- 提前取消方案:完成一半范围时可交付足够的价值,客户不需要另一半范围,则不必支付这部分费用
- 动态范围方案:具有固定预算的合同,客户可以在项目特定点改变项目范围的方案
- 团队扩充:将供应商服务直接嵌入客户组织中
- 支持全方位供应商:为了分化风险,客户可能需要采取多供应商策略

在需求产生时,组织创建新能力的意愿和能力即是组织敏捷性的标志.
大规模敏捷项目的目标是协调不同团队的工作以便为客户提供价值
设立PMO的目的是引导组织实现商业价值.
PMO提供团队教育(或安排培训)和项目支持
PMO会针对给定项目或项目集提供相关商业价值方面的管理建议
PMO应努力按需交付并紧跟客户需求,确保了解并适应他们的需求
PMO(敏捷中心)提供以下服务
- 制定和实施标准:提供用户故事,测试案例,累积流图,提供敏捷工具并培训支持小组了解迭代开发概念
- 通过培训和指导发展人才:
- 多项目管理:通过不同项目交流协调敏捷团队
- 促进组织学习:收集项目进度信息获取,存储和记录回顾性发展成果
- 管理相关方:提供产品负责人培训,指导验收测试以及评估方法,并提供系统反馈
- 招聘,筛选和评估项目领导
- 执行专业化项目任务