导图社区 《敏捷实践指南》-1 敏捷概述
- 131
- 5
- 0
- 举报
《敏捷实践指南》-1 敏捷概述
从概念上理解敏捷方法和传统瀑布项目管理，建立敏捷思维模型
编辑于2022-02-26 23:36:36- 敏捷实践…
- 相似推荐
- 大纲
《敏捷实践指南》-1 敏捷概述
引论
适应对象
敏捷实践指南为项目领导者和项目团队提供实践指导
敏捷实践在项目规划、执行过程的活动中提供帮助
作为一座桥梁，可以帮助理解从预测法转型敏捷方法的途径
敏捷不仅局限于软件领域，在制造、教育、医疗保健等向不同程度的敏捷发展
预测性项目管理
概念
项目预测法又称项目预算法，一种寻求最有效地调配资源以实现目标的系统方法
项目预测最初是在60年代由美国国防部首创的
强调的是目标和实现目标的规划，也就是要对各种可能的方案进行费用效果分析
按规划的项目或方案拨款而不是按职能部门上年的预算基数增加或减少一笔开支
目的是以最少的费用实现一个既定的目标，或是以现有的资源实现最大的效果
优势
克服了各种预算（包括企业预算）中所共有的缺点（因为预算仅考虑短期效益往往导致预的“额外追加”，或是在大量投资后全部取消计划）
摆脱了过分地受会计期（如月度、季度、年度）时间框框的限制
问题
通常缺少明确的、具体的目标
现行的会计制度也与实行项目预算的要求不相适应
人们习惯于传统的做法，不愿意改变为较长期的项目预算
缺乏一整套进行费用效果分析的目标体系和方法体系
敏捷学习
面对面的交流、有意义的学习、自组织团队以及利用想象力的增量型学习和迭代型学习都是敏捷的基本原则
敏捷原则可能改变人们的思维模式，促进教育目标的实现
敏捷第一原则是将客户满意视为最高要求，这也是交付让客户满意的产品和服务的关键
为保持竞争优势，组织不能只关注内部，而是放眼外部世界，关注客户体验
敏捷与组织变更
《敏捷指南》关注项目本身，解决项目生命周期的选择、实施敏捷方法、组织敏捷项目
帮助项目团队顺利交付商业价值，满足客户的期望和需求
范围内事项
在项目或团队层面实施敏捷方法
涵盖行业调查中最流行的敏捷方法
在选择敏捷方法和/或实践时要考虑的适应性要素
将敏捷与《PMBOK指南》的过程和知识领域对应起来
讨论将敏捷应用扩展到软件开发以外
在项目或组织中实施敏捷方法时，需要考虑的指导、技术和方法
通用术语的定义
范围外事项
在整个组织或创建敏捷项目集时实施敏捷方法
涵盖利基方法、特定公司的方法或不完整的生命周期技术
推荐或支持一个特定的方法/实践
变更或修改《PMBOK指南》的过程和/或知识领域
消除软件开发行业对敏捷方法的影响
在项目或组织中如何实施敏捷方法的规范性分步说明
新术语和/或新定义
敏捷概述
确定与不确定的工作
项目工作包括可确定的工作和高度不确定的工作
可确定工作
可确定的工作项目具有明确的流程，在以外项目中已被证明行之有效，可确定的工作日益实现自动化
传统项目管理（预测法项目管理）旨在预先确定大部分需求，通过变更请求过程来控制变更
不确定的工作
新的设计、解决问题和之前未做过的工作都具有探索性，高度不确定的工作要求携手合作创建解决方案
敏捷方法是为了在短时间内探讨可行性，根据评估和反馈实现快速调整
敏捷思维模式
敏捷4大价值观
个体以及互动，而不是过程和工具
可用的软件，而不是完整的文档
客户合作，而不是合同谈判
应对变更，而不是遵循计划
敏捷宣言
敏捷12大原则
最优先要做的是尽早、持续地交付有价值的软件，让客户满意
欣然面对需求变更，即使在项目后期。善于利用需求变更为帮助客户获得竞争优势
频繁地交付可用的软件，从数周到数月，交付周期越短越好
在整个项目过程中，业务人员必须和开发人员每天都在一起工作。
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务
在团队内外，面对面交谈是最有效，也是最高效的沟通方式
可用的软件是衡量进度的主要标准
敏捷过程倡导可持续开发。项目方、开发人员和用户应能保持稳定的进展速度
对技术的精益求精以及对设计的不断完善将提升敏捷性
简洁，是尽最大可能减少不必要工作，是敏捷的根本也是一门艺术
最佳的架构、需求和设计出自于自组织的团队
团队要定期反思如何提升效率，并依此调整整个团队的行为
艾哈迈德·西德基思维模型
敏捷思维模型
由敏捷宣言的价值观所界定，受敏捷宣言的原则指导，通过各种实践实现
敏捷是一种方法，囊括了各种框架和方法的涵盖性术语
敏捷是多种方法包括Scrum、XP、FDD、DSDM、AUP、ScrumBan等的总称
精益与看板方法
敏捷和看板方法是精益思想的衍生物
只要是对组织和团队有效的方法，都可以考虑采纳，目标始终是为了实现最佳结果
不确定、风险和生命周期选择
斯泰西复杂性矩阵
项目需求本身、以及如何使用现有的知识和技术来满足需求，始终具有很大的不确定性，不确定性的因素可能导致大量的变更和复杂度的提高
项目的不确定性，导致返工的风险和使用不同方法的需求也同步增加，包括变更、无用功、返工的可能性
减少方向的一个有效途径是能够通过较少的工作增量解决项目的大量不确定问题，较少的工作增量和交付较小的增量时，能够更准确的理解客户需求
减少浪费和返工的方法
非常短的反馈循环
频繁调整过程
重新进行优先级排序
定期更新计划
频繁交付
从传统项目演变为敏捷方法，以便使用迭代和增量交付
迭代、增量、敏捷方法适应的项目特定
需求研究和开发
变更速度极快
具有不明确或未知的需求、不确定性或风险
最终目标难以描述
敏捷的策略是构建小的增量，然后对其测试和评估，在短时间内以低成本探索不确定性，降低风险，最大程度的实现商业价值的交付
但迭代和增量方法仍然有局限性，为了项目尽可能可靠，需求尽可能的遏制其中某一个不确定性变量（适应性和需求、技术可行性和性能、过程和人员）
生命周期选择
项目生命周期的特征
始终围绕需求、交付、变更和目标的管理
预测型（瀑布）生命周期
传统方法，提前进行大量的计划性工作，然后一次执行，一次性交付
充分利用已知和已证明的事物，减少不确定性和复杂性，允许项目团队将工作分解为一系列可预测的小组
通常以顺序方式执行项目任务，在项目早期创建详尽的需求和计划，并阐明各种制约因素
强调按部门、职能有效的顺序工作，并且不会提前交付，并控制变更来降低成本、进度风险
迭代型生命周期
允许对部分完成或未完成的工作进行反馈，从而改进和修改
通过连续的原型或概念验证来改进产品或成果，识别和减少项目的不确定性
非常适合于 复杂性高、变更频繁或需求范围受相关方对成果的不同观点支配的项目
迭代型项目需要更长的项目周期，因为它是为学习而优化，而不是为交付而优化
增量型生命周期
向客户提供各个已完成的，可以立即使用的可交付成果
增量型项目可能能够经常性的优化项目发起人或客户交付价值的工作，因为能及时管理偏差
敏捷生命周期
团队预料会发生变更，既有迭代，也有增量。为了完善工作，频繁交付，强调MVP原则（最小可行性产品），及时获得反馈以便改善项目的下一部分的计划
对产品进行迭代，创建可交付的成果来获得早期的反馈，增强客户可见性、信息和对产品的控制，同时项目团队可以更早的产生投资回报
基于迭代的敏捷，强调在固定的时间盒内持续交付
基于流程的敏捷，强调团队根据自身能力，从待办事项列表中提取若干功能开始工作，完成不同功能所花费的时间不同
混合敏捷方法
采用何种方法都不重要，关键是“我们怎样做才能最成功？”
敏捷协调与裁剪
敏捷框架不是针对团队进行定制，为了定期交付价值，可能需要对实践进行裁剪
与孤立采用各种实践相比，协调不同来源的实践将产生更好的协同结果
Scrum框架
为产品待办列表、产品负责人、敏捷教练和团队提供指导，包括冲刺计划、每日例会、冲刺评审、冲刺回顾会议
看板方法
将工作流可视化，使障碍（bug）更容易被察觉，以及通过调整在制品限制实现流程管理
极限编程XP
故事卡、持续集成、重构、自动化测试和测试驱动开发