敏捷项目管理
2024-09-02 13:57:26 0 举报AI智能生成
基于敏捷项目管理
作者其他创作
大纲/内容
实施敏捷：创建敏捷的环境
敏捷思维
仆人式领导为团队服务
目的：与团队一起定义“为什么”或目的
人员：鼓励团队创建人人都能成功的团队
过程：不要计划遵循“完美”的敏捷过程，而是要注重结果
仆人领导的职责
促进作用：进者鼓励团队参与、理解，并对团队输出共同承担责；鼓励大家交互会议、非正式会议和知识共享的活动
消除障碍：改变或消除障碍，为交付团队提供支持
为他人的贡献铺路
在敏捷环境中交付
项目章程
1、 我们为什么要做这个项目？这是项目愿景。
2、谁会从中受益？如何受益？这可能是项目愿景和/或项目目标的一部分。
3、对此项目而言，达到哪些条件才意味着项目完成？这些是项目的发布标准。
4、 我们将怎样合作？这说明预期的工作流。
2、谁会从中受益？如何受益？这可能是项目愿景和/或项目目标的一部分。
3、对此项目而言，达到哪些条件才意味着项目完成？这些是项目的发布标准。
4、 我们将怎样合作？这说明预期的工作流。
团队章程
团队价值观：可持续开发的速度和核心的开发时间
工作协议：工作协议，例如“就绪”如何定义，这是团队可以接受工作的前提；“完成”如何定义，这样
团队才能一致地判断完整性；考虑时间盒；或使用工作过程限制；
团队才能一致地判断完整性；考虑时间盒；或使用工作过程限制；
基本规则
团队规范
敏捷实践
回顾：回顾是从以前的工作学习并作出改进
待办事项列表：产品路线
待办事项列表细化：
鼓励不同角色的团队成员协作
呈现故事概念并细化
每日站会（15分钟）过一下任务看板
完成了什么
计划做什么
阻碍或风险
展示，评审
规划基于迭代的敏捷
帮助团队实现价值交付：帮助团队快速交付
持续集成
在不同层面的测试
验收测试驱动开发
行动驱动开发 && 测试驱动开发
刺探：刺探对学习很有用，可以在诸如评估、验收标准定义以及通过产品
了解用户行为的流程中使用。在团队需要学习一些关键技术或功能要素时，刺探会很有帮助。
了解用户行为的流程中使用。在团队需要学习一些关键技术或功能要素时，刺探会很有帮助。
敏捷的组成
Scrum
是目前最受欢迎的敏捷框架
3355原则
3个角色
产品负责人：做正确的事情
与干系人合作定义需求，代表客户利益
和开发沟通产品目标
整理待办事项列表以及优先级，梳理PBL
定义用户故事并核实验收标准
像团队介绍产品功能，澄清和确认需求
Scrum主管：x
整理代表列表，负责这道产品的开发方向，产品负责人跟进商业价值对任务进行排序
消除障碍、服务型领导、像干系人介绍敏捷已获取支持
对应干扰的保护伞
变革的代言人
开发团队（包括，开发、测试等职能人员），T型人才
3个工件
Backlog：待办事项列表，按优先级排序（PO负责）
SBI,冲刺代办事项列表
增量的可交付物
整合：产品目标、冲刺目标、完成的定义DOD
5个事件
冲刺
规划会:规划迭代目标、讨论代办事项、确定团队SPI
梳理会：细分，优先级排序，估算；首次细分是在冲刺开始前，后续细分是团队成员和po一起进行
每日站会，列会：昨天做了什么、今天计划做什么、障碍，
评审会：团队展示完成的backlog，干系人评审讨论、对于pbl进行更新
回顾会：好的值改进的；根据重要性排序；制定改进措施
冲刺评审会：确定交付故事是否满足客户期望、确定是否需要修改、了解新需求
5个团队价值观
专注：尽可能全职，专注于目标和工作
承诺：对结果负责，团队致力主动实现其目标
开放：创造透明的环境，信息是生产力
尊重：团队成员彼此尊重，信息就是生成力
勇气：有勇气去做正确的事情并解决问题
看板
通过可视化子啊系统中消除浪费，已改进工作流和提供产量
XP（极限编程）
XP实践已获得客户的满意
敏捷团队与协作的环境
团队的结构类型
专注，尽量保证项目成员不被调走
PO，对干系人的需求负责
SM，对干系人的期望负责，确保成员专注，对项目的成果负责
教练
服务型
清道夫
变革代言人
产品规划与发布规划
愿景声明
愿景
项目目的
成功的定义
交付后如何能变好
声明
简单强有力的词句
描述可实现的最佳成果
愿景由发起人、排PM,PO,TEAM共同制定
项目章程
包括了方向以及项目目标
为什么做
谁会从中受益
达到什么样的条件意味着工作的完成，
我们需要怎么样做
团队章程
团队价值观、团队规范、工作协议
规定成员之间彼此互动的方式，团队章程的目的是创建敏捷的工作环境
用户故事的编写
元素
作为：用户角色
我想：完成的活动
以便：实现的价值
验收标准
前提条件
用户对产品实施某种动作
然后，产品的相应
3C原则
卡片 card
会谈 coversation
确认 conformation
细化梳理原则
待办事项列表
待办事项
高层的PBI遵循的原则
invest
独立（independent）
可协商（negotiable）
可估算（estimable）
小型的（small）
可测试的（testable）
独立（independent）
可协商（negotiable）
可估算（estimable）
小型的（small）
可测试的（testable）
待办事项的常见类型
特性、缺陷、技术债务、探针
PBL的deep原则
详细适合的
经过估算的
涌现的
排序的
经过估算的
涌现的
排序的
- 工具技术
优先排序的技术
模型法
MoSCOW
必须的
重要的
可有的
不会有的
单项指标法
价值
子主题
多指标法
优先级矩阵
价值成本
价值时间
价值风险
加权最短优先作业
估算技术
绝对估算
参加各种会议，实际工作时间会减少
工作中的其他事务处理
相对估算
亲和估算：将产品的待办事项组合成一组
计划扑克/估算扑克：参与者出牌，在进行讨论
决策
宽带德尔菲
举手表决
敏捷的痛点以及可能解决的思路
团队目标或任务不明确
敏捷章程中关于目标部分：愿景和使命
团队工作协议不明确
团队章程中关于一致性的部分：价值观、原则、工作协议
团队环境不明确
明捷章程中关于环境的部分：边界、承诺和前瞻性
需求不明确
帮助发起人和干系人确认愿景
路线图
分解
子主题
用户体验不佳
应该在早期就让用户经常的参与
估算不准确
分解故事
刺探进行敏捷估算
仓储，等待或不均匀的工作流程
计划需要应对的团队能力
专注任务
干系人的要求无法满足
产品经理和服务型领导一起工作
意想不到的预见或延误
子主题
0 条评论
下一页
