PMBOK中的敏捷
2023-03-18 21:35:10 2 举报AI智能生成
登录查看完整内容
PMBOK中的敏捷
作者其他创作
大纲/内容
敏捷
团队自行决定计划、整合方式
营造合作型的决策氛围
团队成员具备广泛技能
项目章程
项目整合管理
1、自组织团队2、仆人式领导（发现瓶颈，与团队合作解决）3、T型人才解决知识孤岛
多次迭代来交付成果，每次迭代开始时定义详细范围
确定产品未完项中，哪些应在下一次迭代中交付
发起人和客户代表应持续参与项目，提供反馈。
重复开展：确认范围和控制范围
缩短定义和协商范围时间，持续探索明确范围
有目的地构建和审查原型，通过多次发布版本来明确需求
先确定高层级愿景，再针对迭代明确详细范围
将长篇故事分解成用户故事
范围
1、小步快跑，增量交付2、Sprint计划会议3、sprint backlog4、相关方频繁参与5、Sprint评审会议6、专注于Sprint目标
1、产品增量2、Sprint评审会的两大目的
1、产品愿景（高层级）、产品路线图、发布计划（粗略）2、Sprint Backlog3、史诗Epics4、特性Features5、用户故事补充：MoSCoW排列优先级 Must or Should，Could or Want
具有未完成项的进度计划：Scrum优先级排序、再规定的时间盒内开发
按需进度计划：看板体系，基于制约理论，拉动式，消除瓶颈，再资源可用时立即提取工作开展
控制进度
进度
1、价值驱动（OKR）2、固定时间盒3、增量交付、频繁演示4、拥抱变更5、WIP在制品限制，拉动6、消除瓶颈补充：宽带德尔菲和计划扑克
1、迭代燃尽图（剩余的用户故事，了解进度）、燃起图2、看板（消除瓶颈）3、每日站会
轻量级估算，高层级预测
详细的估算适用于准时制的短期规划
成本
1、准时制短期规划
循环回顾，寻找根本原因，回顾会议
小批量工作，尽早发现质量问题
质量
1、DOD（定标准）（质量下降、返工）2、测试驱动开发TDD3、行为驱动开发BDD4、验收测试驱动开发ATDD5、持续集成6、刺探spike7、Sprint回顾会议8、强调较小的增量9、代码（成果）集体所有10、责任归属于整个团队
集中办公
协作型团队
团队价值观
工作协议
团队成员指定、参与制定，定期审查/更新，确保团队成员始终了解，新成员融入
基本规则
团队规范
团队章程
资源
1、自组织团队（团队自行领取任务）2、T型人才（一专多能）3、相互协作，共同解决问题（例对冲刺内容有分歧）4、自组织任务的分配5、交叉培训（团队成员间的知识共享）
透明的方式发布、定期邀请相关方评审
沟通
1、透明、高效2、信号扩散器（信息发射源）3、不提倡状态报告4、提倡集中办公5、鱼缸窗口6、远程结队7、多个敏捷团队（SoS：Scrum of Scrums）补充：敏捷开发实践：追逐太阳
1、整个Sprint考虑风险2、风险也是待办事项（需创建风险登记册）3、利用量化的敞口排优先级
风险
某些可交付成果采用适应型，其他部分采用更稳定的方法（混合）
主要服务协议(MSA)管辖整体，适应型工作写入附录。变更只针对适应型，不影响主体协议
采购
1、客户协作高于合同谈判2、动态特性的合同3、主协议和补充的多层结构补充：1、关注用户故事而非预算2、动态范围方案3、提前取消方案4、资助团队而非范围（包人头）
没有管理级别
将项目工件发布到公共空间
让问题尽快浮现
相关方
1、频繁参与2、高效透明的沟通3、常见的相关方管理方法
PMBOK中的敏捷
都确定，用预测方法
存在不确定性：用增量、迭代
都不确定：用敏捷方法
STACEY评估矩阵：需求的不确定性/技术程度的不确定性
可以在风险不大，具有重点程度不确定性的项目中尝试
混合型生命周期
第一张：前章
响应变化
定义
个体互动 胜过 流程和工具
可用的软件 胜过 详尽的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
敏捷宣言
敏捷的定义及敏捷宣言
1、尽早、持续不断交付有价值的软件
2、欣然面对需求变化
3、较短周期，交付可工作的软件（反馈）
4、业务与开发必须相互合作
5、提供所需的环境和支援，辅以信任
6、面对面的交谈
7、可工作的软件 是首要度量标准
8、可持续开发，维持步调稳定延续
9、追求技术卓越和良好设计
10、简洁为本
11、输出自组织团队（服务型领导）
12、定期地反思
敏捷开发十二原则
第二章：敏捷宣言和原则
想法/功能/缺陷
客户/市场/领导
用户故事：角色、功能、价值
产品是唯一责任人（提到负责）
包含特性、功能、需求、改进方法（技术负债）、缺陷
高优先级的事项，需要符合“就绪的定义DOR”Definition of Ready（团队共同定义的）
PB列表梳理会，不超过10%的时间投入，产品和开发团队共同梳理
Product Backlog产品待办事项列表
排序优先级，细化用户故事，确保开发团队对PB深刻理解
决定接受或拒绝每次冲刺的增量，确定发布
产品负责人PO（最终责任人）
2周的Sprint，一般4小时
斐波那契数列相对估算+敏捷扑克（确保成员参与）
由于不同团队选取的基准用户故事不同，因此不同Spint故事点不具可比性
每个Sprint完成的故事点越稳定越好（刚开始团队新成立不稳定，速率较慢）
决定故事点Story Point
快速实践，确认某需求在技术上是否可行，提升用户故事的有效估计（例如新法律的遵守）
刺探 / 探针 （Spike）
当前Sprint选出的用户故事
开发团队确定，
用户故事拆分成任务（有助于更准确的估算），团队成员主动领取
Sprint Backlog冲刺待办事项列表
创建风险登记册
P 冲刺计划会/迭代规划会（PO+ScrumMaster+team）
15分钟，减少团队成员孤立，增进了解
团队来自组织召开
昨天、今天、障碍（不对障碍展开讨论）
D 每日站会（ScrumMaster+team）
2小时以内，演示增量，获得反馈（适用场景：客户如果担心质量）
团队一起定义“完成的定义DOD”，产品确认DOD
无论产品是否决定发布，增量必须可用
Product Increment产品增量
结果：一份修订后产品待办事项列表
C 冲刺评审会/迭代审查会（客户+PO+ScrumMaster+team）
2小时以内，明确下个Sprint实施的改进和实践
时机（1.发布新功能；2协作不畅；3.里程碑；4.距离上次回顾几周后）
A 冲刺回顾会（ScrumMaster+team）
Sprint冲刺
找到有效管理PB的技巧
确保PO了解如何安排PB
帮助理解并实践敏捷
服务于产品负责人
指导自组织和跨职能
移除开发障碍
服务于团队
指导组织采纳Scrum
帮相关方理解并实施Scrum
提升团队生产率
增强Scrum
服务于组织
Scrum Master（服务型领导）
责任归属整个开发团队
自组织、跨职能
稳定、全职
开发团队(自组织)
勇气、承诺、专注、开放、尊重
五大价值观
外框
Scrum33553个角色3个工件5个事件5个价值观
可视化管理、消除瓶颈
看板
测试驱动开发：先写测试代码再写程序
重构：减少技术负债
结对编程
极限编程
第三章：敏捷的实践
收藏
收藏
0 条评论
回复 删除
下一页
