敏捷项目管理14个问题
2019-06-25 14:59:41 93 举报AI智能生成
登录查看完整内容
敏捷项目管理复习资料
作者其他创作
大纲/内容
Scrum的角色
项目负责人PO
负责分析项目的商业价值，决定该项目应该完成的工作，并对其进行排序，制作并维护product backlog
敏捷主管SM
激发团队活力，推动每日的工作，促进项目成员间的正常交流，并扫除敏捷过程中的障碍
开发团队
负责每日的开发生产工作，是冲刺的执行主体
项目干系人
除了以上三个角色外，还包括客户，用户，主管等
敏捷教练
传授敏捷方法的人，并不直接参与到项目执行中
Scrum的工件
Product Backlog
一个记录了产品特性的列表，并按照特性的商业价值进行排序
Sprint Backlog
当前冲刺中需要完成的任务
Product Increment
每次冲刺结束后可发布的产品
Burndown Chart
当前冲刺过程中剩余的工作时间
看板
Scrum的仪式
冲刺计划会议
PO，SM以及开发人员决定当此冲刺应该处理的任务以及冲刺结束后发布的产品
每日例会
一个简单的会议，由SM主持，开发人员汇报当前的工作情况，遇到的障碍以及之后的计划
冲刺评审
由PO向项目干系人展示当此冲刺的产品及其功能，并收集相关反馈
冲刺回顾
由PO，SM以及开发人员讨论回顾当次冲刺存在的缺陷，以及可能的解决方法
产品backlog细化
ProductBacklog的创建
要素
特性
用户故事
商业价值
工作量
优先级
完成情况
关于冲刺
定义
指一次迭代，该迭代中产生的产品还能通过验收
主要工作
每日冲刺工作(每日例会)
创建产品可交付的功能
产品负责人与开发人员需要对任务进行细化，开发和测试
SM需要做的是识别阻碍，并将其解决
PO，SM以及团队成员回顾和总结当次冲刺存在的缺陷与不足，并提出改进的意见
参与人员
SM(主持人)
PO
开发人员
可能还会有项目干系人
会议关键
活跃会议气氛，让团队成员能够积极参与进来
讨论需要时刻关注重点，不应该分散
优势
刺激和鼓舞开发人员的士气
挖掘优秀的开发经验和方法
避免犯相同的错误
改进团队气氛
敏捷的核心价值观
承诺
愿意承担任务 并承诺完成
专注
把精力集中在工作和任务中
开放
项目的一切都对项目内成员公开
勇气
有勇气做出承诺，并接受他人尊重
尊重
尊重每个人的背景和经验
敏捷管理与敏捷转型
管理
概念管理
需求分析以及高层的架构设计，会产生product backlog
计划管理
冲刺计划以及进一步的系统设计
开发过程管理
冲刺/迭代过程管理
验证管理
发布管理
生命周期管理
转型
例子
三个阶段
项目敏捷
包括部分计划，全部的开发与验证过程
版本敏捷
包括全部的计划，开发，验证以及发布
产品敏捷
在上述基础上增加了对产品概念以及产品声明周期的管理
核心
敏捷转型的成功关键是团队意识的转变以及团队技能的提升，通过三步走的方式，实现人员技能，工程能力，流程，工具等方面的积累在风险可控的情况下达到全面敏捷的转型
敏捷开发主要框架
XP
XP是一种近螺旋式的开发过程，通过将项目分解为多个小周期，积极沟通反馈，从而调整开发过程，让客户了解项目进度
ASD
ASD是迭代开发的一种，每次迭代包括推测，协作以及学习三个阶段，共同推进项目的进程
FDD
FDD是轻量级的敏捷开发方式，融合了多种行业认可的最佳实践，能够快速地向客户展现有价值的软件
TDD
AUP
AUP是简化版的RUP，包括7个方面：建模，开发，测试，发布，配置管理，项目管理，环境管理
敏捷项目管理的14个问题
敏捷宣言
个体交互高于过程工具
可运行程序高于文档
客户合作高于合同谈判
响应变化高于遵循计划
敏捷的核心思想
以人为本，拥抱变更
敏捷的12个原则
针对人的
在整个项目开发周期中，业务人员应该与开发人员一起工作
项目由有激情，可信的人合作完成
在团队中面对面沟通效率最高
每隔一段时间，团队成员应该进行自我反思和调整
针对计划的
即使在开发后期也应该接受变更
工作的软件是衡量进度的首要标准
敏捷开发过程应保持稳定的开发节奏
不做过度的设计和预测
针对产品的
应该尽早向客户交付有价值的程序
交付的频率应该越高越好
最好的架构和设计来源于自组织的团队
不断关注新的技术和设计
愿景声明与产品路线图
愿景声明
制作前提
了解企业的战略目标
考虑产品愿景与战略目标之间的关系——带来利润/扶持其它战略项目
确定项目(产品)目标
能够位企业带来何种利益
目标客户是谁，特征如何
客户所关心的/项目所能满足的需求为何
已存在的竞品
与竞品的差异/自身的竞争力
产品路线图
作用
展示产品/项目的基本特性，及其时间安排——开启和发布时间
创建过程
识别产品的需求
归纳整理产品的主题和特性
根据产品的特性，估算其优先级并排序(打分)
安排项目实施的时间规划
对某个产品需求的简单描述
类别
史诗故事
(一般)用户故事
创建
需求分析
识别项目关系人
识别客户(使用产品的人)
识别需要完成的任务
描述用户故事
谁(客户)
希望完成(功能/需求描述)
以便(商业价值描述)
评价用户故事(INVEST)
独立的(Independent)
可协商的(negotiate)
有价值的(valuable)
可估算的(estimate)
小型的(small)
可测试的(testable)
估算(优先级排序)
影响因素
客户要求
经济原因
经济回报
开发成本
新技术的试探应该高优先级
依赖关系
风险因素
风险识别，进度，成本，技术
高风险，高价值优先
高风险，低价值延后
估算方式
由PO选取商业价值高的用户故事
开发成员同时给出工作量估算
价值/工作量
SprintBacklog的创建
任务
负责人
预估工作量
意外情况的备注
由PO向项目干系人展示当次冲刺完成的产品及其功能
用户代表
PO应该毫无掩饰地向项目干系人展示产品地所有功能
会议的关注点在演示上，无需太多文档
演示的环境必须与生产环境一致
会议中需要收集干系人的反馈，作为项目变更的依据
通过演示展示当前项目的实际进展
尽早向用户反馈，从而获得更真实的需求
敏捷工程实践
结对编程
由两个人完成代码的编写，一人负责实施，一人从旁监督提醒
及早发现编码中存在的缺陷
提升代码质量
促使团队在知识层面上更容易达成共识
持续集成
开发人员经常性地构建他们的工作，每天至少集成一次
能够更直接地反应当前的项目进度
能够及时发现集成后的缺陷并可以立即修复
避免缺陷在最终集成时的堆积
关键
集成耗时因该尽可能短
需要有完备的自动化测试工具以及测试用例
修复失败的构建是开发人员最优先的任务
集成结果应该向所有成员公开
测试驱动开发
以测试作为编程的中心，要求在编写代码前必须完成测试用例，并且围绕用例进行编码TDD还要求测试必须可自动化完成
保证代码质量
提高代码可读性
测试用例需要设计完备，同时不能有依赖关系
测试用例代码与开发代码都需要简洁
敏捷度量
终端用户
功能特性
易用性
投资人
回报率
风险
企业
管理难度
团队
技术开发
敏捷实践
定义产品愿景以及产品路线图
计划发布与冲刺
全天的工作
展示工作和集成反馈
为发布做准备
0 条评论
回复 删除
下一页
