一、项目
项目的概念
- 独特性
- 临时性
项目是为创造独特的产品、服务或成果而进行的临时性工作
- 独特的产品、服务或成果:一个或多个可交付成果
- 临时性工作:有明确的起点和终点
- 项目驱动变更:从当前状态到未来状态
- 项目创造商业价值:有形效益和无形效益
项目经理的道德与专业行为规范与价值观
- 责任
- 尊重
- 公正
- 诚信
项目启动背景的原因因素四类
- 法规
- 满足相关方
- 执行、变更业务或技术战略
- 创造、改进或修复
批准项目启动的战略考虑
- 新技术
- 竞争力、材料问题
- 政治变革、市场需求
- 经济变革、客户需求
- 相关方需求、法律需求
- 业务过程改进
- 战略机会、业务需求
- 社会需要
- 环境考虑
项目管理是组织的战略能力
项目是组织创造价值和效益的主要方式。广泛的利用项目管理,来持续创造商业价值。
二、项目、项目集、项目组合
项目集管理
项目集是一组相互关联且被协调管理的项目、子项目集和项目集活动,以便获得分别管理所无法获得的利益。
项目集注重:
- 组成部分的项目与项目集之间的依赖关系,以确定管理这些项目的最佳方法
- 项目集并非大型项目。
- 项目集和项目管理的重点在于以“正确”的方式开展项目集和项目
项目组合管理
项目组合是指为实现战略目标而组合在一起管理的项目、项目集、子项目组合和运营工作。
项目组合管理是指为了实现战略目标,对一个或多个项目组合进行的集中管理,项目组合中的项目或项目集不一定彼此依赖或直接相关。
项目组合管理注意:
- 开展“正确”的项目集和项目
- 项目组合价值的最大化
- 项目的筛选和排序
项目、项目集、项目组合
项目 | 项目集 | 项目组合 | |
---|---|---|---|
范围 | 渐进明细 | 项目集组件的范围,为组织带来效益 | 因组织战略目标的变化而变化 |
变更 | 项目经理变更管理和控制 | 在必要时接受和适应变更,优化效益实现 | 持续监督更广泛内外部环境的变更 |
规划 | 项目经理渐进明细将其转化为详细的计划 | 利用高层次计划,跟踪项目集组件,在组件层指导规划 | 维护与总体项目组合有关的必要过程和沟通 |
管理 | 项目经理管理项目团队 | 协调项目集组件 | 项目组合经理管理或协调项目组合管理人员,或有责任的项目集和项目人员 |
成功 | 质、进、成和客户满意度的平衡 | 交付项目集预期效益、交付效益的效率和效果 | 总体投资效果和实现的效益 |
监督 | 项目经理对创造预定产品、服务或成果的工作进行监控 | 项目集经理监督项目集组件,确保整体目标、进度计划、预算和项目集效益的实现 | 项目组合经理监督战略变更以及总体资源分配、绩效成果和项目组合风险 |
项目管理绝对不可以“镀金”:项目组自主、自发地更高范围、更高质量的来提升客户满意度的行为
运营管理
注重:
- 产品持续生产和服务的持续运作
- 使用最优资源满足客户要求,来保证业务运作的持续高效
- 把各种输入转变为输出
项目和运营在产品生命周期的不同时点交叉,在每个交叉点时转移:
- 可交付成果
- 知识
- 项目资源或运营资源
项目、项目集、项目组合、运营的关系
所有项目符合组织战略
组织级项目管理(OPM)
为实现战略目标而整合项目组合、项目集和项目管理与组织驱动因素的框架。
OPM旨在确保组织开展正确的项目并合适地分配关键资源。
三、项目生命周期
关键组成部分
项目生命周期与阶段
- 项目生命周期指项目从开始到完成所经历的一系列阶段。
- 项目阶段是一组具有逻辑关系的项目活动的集合,通常以一个或多个可交付成果的完成为结束。
过程要素
风险既是威胁也是机遇
项目和开发生命周期
项目生命周期类型:
- 预测型
- 适应型
项目开发生命周期:
- 预测型
- 迭代型
- 增量型
- 适应型
- 混合型
类型 | 定义 | 特征 |
---|---|---|
预测型 (瀑布型) | 早期确定范围、时间、成本,对任何范围的变更都仔细管理 | 文档管理成本高、变更成本高 开始就明确需求、详细规划 |
迭代型 | 范围早期确定,时间和成本定期修改 | 循环 |
增量型 | 预定时间内渐进增加产品功能,只有最后一次迭代后,可交付成果具有必要和足够能力,才能被视为完整的 | 增加范围 |
适应型 (敏捷型、变更驱动型) | 详细范围在迭代之前得到定义和批准 | 迭代+增量 短期迭代规划,需求渐进明细 |
混合型 | 针对不同要素选择不同的开发生命周期 | 预测+适应 |
四、项目信息
工作绩效
定义 | 特征 | |
---|---|---|
工作绩效数据 | 从每个正在执行的活动中收集到的原始观察结果和测量值 | 没有办法直接点评好与坏 |
工作绩效信息 | 从各控制过程中收集并结合相关背景和跨领域关系,进行整合分析而得到的绩效数据 | 数据和基准对比之后的绩效信息,不能评价全局 |
工作绩效报告 | 汇编工作绩效信息所形成的实物或电子项目文件 | 评价全局 |
项目管理商业文件
项目发起人负责项目商业文件的制定和维护,而项目经理需要确保项目管理方法紧扣商业文件的意图。
商业论证(业务论证)
文档化的经济可行性研究报告,用来对尚缺乏充分定义的所选方案的收益进行有效性论证,是启动后续项目管理活动的依据,他列出了项目启动的目标和理由。
包括不限于:
- 业务需求
- 形势分析
- 推荐
- 评估
BA编写商务分析,不做决策
PO产品经理做决策
财务测量指标
指标项 | 含义 | 对项目含义 |
---|---|---|
项目优先级 | 项目重要程度代表获得资源的能力 | 越高越好 |
NPV(净现值) | 按一定的折现率将每年现金流折现到同一时点的现值累积值。未来报酬 | 越大越好 |
IRR(内部回报率) | 就是资金流入现值总额与资金流出现值总额相等、净值等于零时的折现率 | 越大越好 |
PBP(回收期) | Payback period 分动态、静态两种,收回成本本所需时间 | 越短越好 |
BCR(效益成本比) | Benefit(Payback)/Cost Ratio,每投资一美元所获得的收益 | 越大越好 |
ROI(投资回报率) | Return on investment,利润除以投资 | 越大越好 |
项目效益管理计划
描述了项目实现效益的方式和时间,以及应制定的效益衡量机制。效益的关键要素,可能包括(但不于)以下内容:
- 目标效益
- 战略一致性
- 实现效益的时限
- 效益责任人
- 测量指标
- 假设
- 风险
制定和维护效益管理计划是迭代的活动,需要使用商业论证和需求评估的数据和信息,它是商业论证、项目章程和项目管理计划的补充。
项目成功标准
关于项目成功的定义和看法,项目相关方可能有不同的观点。项目经理和相关方应就项目成功达成共识并记录下来。
明确记录项目目标并选择可测量的目标是项目成功的关键。这些目标除范围、进度、质量、成本等以外还可能包括:
- 完成项目范围
- 达成商业论证中的已商定的战略目标
- 组织的利益方向和种阶段目标
项目阶段与项目关口
项目可以分解成不同的阶段或子组件,有助于更好地掌控项目管理,同时还提供了评估项目绩效并在后续阶段采取必要的纠正或预防措施的机会。
阶段关口在项目阶段结束时进行,将项目的绩效和进度与项目和业务文件比较,并作出决定:
- 进入下个阶段;
- 整改后进入下个阶段
- 结束项目
- 停留在当前阶段
- 重复阶段或某个要素
- 每个阶段都包括活动+可交付成果
- 阶段关口包括评审+决策
项目管理过程组
过程组在项目或阶段中的相互作用
过程组与知识领域的关系
项目的边界
项目管理的趋势:敏捷项目管理
五、敏捷开发
敏捷宣言
- 加强客户参与
- 尽可能多的产品展现
- 尽可能客户现场合作
- 响应变化
敏捷十二项原则
- 我们的最高目标是,通过尽早持续交付有价值的软件来满足客户的需求。
- 欢迎对需求提出变更,即使在项目开发后期也不例外。敏捷过程要善于利用需求变更,帮助客户获得竞争优势。
- 要经常交付可用的软件,周期从几周到几个月不等,且越短越好
- 项目实施过程中,业务人员与开发人员必须始终通力协作
- 要善于激励项目人员,给予他们所需的环境和支持,并相信他们能够完成任务。
- 无论是对开发团队还是团队内部,信息传达最有效的方法都是面对面的交谈。
- 可用的软件是衡量进度的首要衡量标准。
- 敏捷过程提倡可持续的开发。项目发起人,开发人员和用户应该都能够始终保
特步调稳定。 - 对技术的精益求精以及对设计的不断完善将提高敏捷性。
- 简洁,即尽最大可能减少不必要的工作,这是一门艺术。
- 最佳的架构,需求和设计将出自于自组织团队。(通才)
- 团队要定期反省怎样做才能更有效,并相应地调整团队的行为。(复盘会)
敏捷三角形
MVP
- 最基本可行产品(Minimum Viable Product):满足最基本的功能需求
- 最小可售特性(Minimum Marketable Feature):符合快速试错的原则
SCRUM三大角色
- 产品负责人 Product Owner
- 管理产品清单(还没有被排入迭代的产品需求,产品待办清单)
- 排列工作优先级
- 决定版本发布内容和时间
- 面向业务相关方代表团队
- 面向团队代表业务相关方
- 接受和退回工作成果
- 澄清需求
- 敏捷教练 Scrum Master
- 帮团队隔开杂务
- 移开妨碍团队的障碍
- 带领每日站立会议
- 帮助团队成长
- 负责scrum价值观、原则和规则被采纳和彰显
- 开发团队 Development Team
- 自我组织
- 只有一个角色,复合平衡技能
- 集中办公
- 整体团队共同负责
- 团队人数:5-9人
冲刺 Spring
长度:2-4周
包含:
- 冲刺计划 Spring Planning
- 每日站立会议 Daily Stand-ups
- 冲刺评审会议 Spring Review (验收会)
- 冲刺回顾会议 Spring Retrospective
- 产品清单生成会议 backlog grooming(可选) 用户故事澄清会
冲刺计划
冲刺计划会议
- Spring开始时召开,4-8小时
- 参加人员:产品负责人(PO)、Scrum Master、Scrum团队和其他感兴趣的人
- 第一阶段PO从产品backlog中挑选高优先级的故事并讲解
- 与团队决定这个Spring中需要完成多少backlog,确定优先级、承诺完成
- 第二阶段团队成员详细讨论如何完成
- 分解并估计完成任务所需时间,并认领任务
- 将故事和任务放入任务板
- 制作燃尽图
用户故事 User story
从用户的角度来描述用户渴望得到的功能
三个要素:
- 角色:谁要这个功能
- 活动:需要完成什么样的功能或目标
- 商业价值:为什么需要这个功能,这个功能带来什么样的价值
作为一个<角色>,我想要<活动>,以便于<商业价值>
故事点 Story Point 估算
- 历史经验教训
- 资源FTE数量
- 迭代中开发日数量
- Meeting Day、验收日除外
计划扑克 Planning Poker
作用:减少估算偏离
时间盒 Time Box
冲刺中不允许变更 Forbidden Change in a Spring
- 禁止变更交付件和交付日期
- 一旦团队作出承诺,就不允许变更交付件
- 如果发生重大变化,PO可以中止当次迭代
- 在迭代中会出现“分解”和“澄清”,但不允许添加
- 如果存在争议,那么将其认定为变更,放到PBI中,下次迭代再考虑
每日站会
- 时间:15分钟之内
- 每天同一时间同一地点举行
- 都可以参加,只有团队成员发言,其他人只能旁听
- 都站立
- 确定更新燃尽图
- 每个团队成员需要问3个问题:
- 我昨天完成
- 我今天将做
- 我遇到障碍
- SM带领会议,并阻止各种影响会议的行为
冲刺评审会议
- 非正式:no PowerPoints
- 展示会议 Demo meeting
- 上限4小时
- 引导出反馈
- 培养协同合作
- 故事的旅程
冲刺回顾会议
- 2小时
- 反省冲刺
- 为往后的冲刺做改善
工具
看板墙
燃尽图
极限编程体系 Extreme Programming
- XP聚焦软件开发的最佳实践,最短为一周
- 使用用户故事描述用户需求,由客户定义用户故事,和Acceptance criteria(验收标准)
- 客户全程参与项目
- 每个用户故事代码开发由编程员两两结对一起工作,并定期互换,以撰写符合测试案例的代码
测试驱动开发 Test-driven development
TDD是XP方法论的关键实践
步骤:
- 编写测试代码
- 运行和确认测试(红)
- 编写代码并通过测试(绿)
- 重构
Scrum of Scrums
大规模敏捷框架SAFe
专注于在项目组合、项目集和团队成员层
5-6周冲刺,包括IP冲刺(Innovation and Planning)