首页  思维导图  详情

敏捷项目管理

2020-08-11 14:25:49   0  举报





AI智能生成

敏捷项目管理梳理

敏捷项目管理

大纲

项目管理

敏捷开发

作者其他创作

大纲/内容

1. 敏捷革命

开篇

客户对持续创新和降低试验成本的需求，
标志着从预见性开发方式到适应性开发方式的重大转变

当试验成本减到足够低时，整个产品开发的经济学就会发生变化--
从以预测为基础的流程（定义、设计、建造）转变为适应为基础的流程（构想、探索、改进）

预见性、常规性和流程性思维的项目管理者陷入混乱

示例：Sketchbook Prod的研发过程，先构想、
不断迭代不断演进，最终打败微软的Tablet PC

清晰的产品愿景和商业计划

积极参与产品管理

有明确的时间约束和资源约束

每2周交付新特性并提交市场验证

总结

最终客户价值的交付是在销售时，而不是在计划时

任何以敏捷方法为幌子进行特殊开发的人，都是彻头彻尾的骗子

团队和个人需要保证足够的自律性

1.1敏捷商业目标

持续创新

为客户提供实际的价值

产品适应性

现在就为客户提供价值的能力

为将来创造适应性产品的能力

缩短上市时间

聚焦（产品最应该包含的特性有哪些）

简化（重点集中在那些增值活动中，减少不必要的合规性活动）

效率（发挥每个人的特长）

人员和流程适应性

成员乐于接受变革

能够自我成长

可靠的结果

满足客户目标和商业需求的可交付产品

重复的流程：按照同样的方式做同样的事情，并产生同样的结果

可靠的流程：在生产过程中无论遇到什么障碍，都能达到目标

1.2 敏捷的定义

敏捷是创造并响应变化，从而在动荡的商业环境中创造利润的能力

小型便携式DNA分析器

敏捷是平衡灵活性和稳定性的能力

担心：敏捷意味着组织架构松散，缺少稳定，容易造成混乱

创新最容易出现在“混乱的边缘”

敏捷组织避免迷失的方法：区分哪些因素需要稳定，哪些因素鼓励探索

从价值的角度出发来考虑

在高度变化的研发环境中，严格保证配置管理

1.3 敏捷领导力价值观

永恒的目的

团队为何存在，要创造什么产品，为谁而创造，如何共同工作

在高绩效的团队中，领导者管理原则，原则管理团队

两类价值观

相互依赖声明

我们通过制造所关注的价值的连续的流来增加投资回报。
我们通过使客户参与到频繁的交互和共享的所有权中的方式，来交付可靠的结果
我们预料到了不确定性，并通过迭代、预防和适应的方式来管理它
们承认个人才是价值的最终源泉，努力建立一个使他们能够体现价值的环境，以此来释放创造力和创新力
我们通过将问责按结果进行分组和按团队效率来分担职责，从而提升绩效。
我们使用根据具体情况而定的策略、过程和实践来提高效率和可靠性

敏捷宣言

个体和互动高于流程和工具

工作的软件高于详尽的文档

客户合作高于合同谈判

响应变化高于遵循计划

正确区分重要和更加重要

左边体现成员素质，需要具备一定技能的人员

右边体现约束，更加注重传统定义，成员成本较低

两种管理者

任务管理者

关注任务的完成情况，并用其度量团队是否遵循项目计划执行

团队管理者

帮助团队成员协同有效的工作，从而保证他们取得成功

交付价值胜过满足约束
领导团队胜过管理任务
适应变化胜过遵循计划

敏捷是关于思维的原则，而不是具体的实践

敏捷中是使用代码评审还是结对编程

使用站会、看板机制，是否就是敏捷团队了

对于项目管理

传统项目关注和控制3要素：范围、进度、成本

没有关注质量

没有关注价值

敏捷项目管理：关注3个核心价值观

更多的变化对管理者的要求更高，因为行为可以任意变化，没有详尽的任务列表，管理者比较痛苦，就少缺少某种东西而无所适从，他们担心放弃明确计划会导致任务流失，带来挫败感和失控感

1.4 敏捷绩效度量

泰坦尼克号

从传统项目上看，它是失败的，严重超出预算和时间

从敏捷的角度看，它是成功的，票房超10亿

摩托罗拉铱星项目

从传统项目上看，它是成功的，完全符合规格说明书

从敏捷的角度看，它是失败的，因为没产生价值

度量三角形演变

圈起来的表示不可变的

价值目标--构建可发布的产品
质量目标--构建可靠的，适应性的产品
约束目标--在可接受的约束内，实现价值和质量目标

1.5敏捷项目管理框架

构想

推演

探索

适应

约束

结束语

敏捷不是新事务

敏捷并不适用所有项目和所有人

敏捷实施依赖于与之匹配的价值观体系

2. 敏捷价值观

价值胜过约束

能够给客户带来实际利益的功能，才是有价值的功能

聚焦价值

价值确认（和产品经理一起）

价值优先级排序

价值创造（迭代开发）

价值的持续流动

今天交付，明天适应

创新价值

效率交付想象的到的产品

生产型项目

创新交付想象不到的产品

探索型项目

敏捷团队的核心在于交付创新的产品和服务，需要持续的技术变革、增加竞品优势

执行

高效、专注

精益思想

系统性的消除浪费，减少不对客户产生价值的活动

分析项目活动，以保证用在交付活动上的时间最大化

分析自己的活动：是在从事交付性的活动还是合规性活动

基于特性的交付

迭代

在一定的时间盒子内产生一个结果

基于特性

每次迭代中交付提供客户价值的产品特性

MVP

增量

不要无休止的重构

技术卓越

解决技术问题时关注项目目标

必须倡导技术卓越，因为它是适应能力和低成本迭代的关键

简洁

敏捷能够极大的提高生产力，不是因为把所有事都做的更好，而是根本就没有必要做无关的事

生成性规则

敏捷实践推动规则生成，而不是规定

从最小的实践开始，明智的随着需要增加实践

全面的规定性实践，然后试图进行精简，最后找到可用的实践

刚好足够的方法论

即是优势，也是风险

交付与合规

是否向客户提供了价值

对于必要的合规性活动尽量减少并让它远离关键路径和关键人员

约束：成本、时间、额外活动

团队胜过任务

开篇

管理任务

清晰、可具体化、可定义

管理团队

抽象模糊，不可捉摸

项目管理者关注团队

项目成员关注任务

领导团队

引导而不是控制团队成员

领导者真正的权利不是自上而下，而是自下而上赢得的

团队既需要领导者，也需要管理者，找到平稳点是敏捷领导的艺术

对不确定性保持自信，并能够承认并处理它

建立自组织团队

找到合适的人

如何高效的面试（金牌面试官学习总结）

清楚的表述产品愿景、边界

鼓励协作

协作的结果取决于信任与尊重程度、信息流动的自由度以及参与的积极性

参与式决策

偶尔需要领导者做出决策，但主要风格是包容、鼓励成员广泛的参与决策

共享空间

视觉化

原型高于文档

公共性

不能用技术构架图与交流

坚持负责

当团队承诺在里程碑结束时交付一组特性时，团队成员就接受了这个责任

信任是协作的基石，履行承诺是建产信任的核心

培养自律

对结果负责

更多的参与讨论、对话

引导而不是管制

被歪曲的自组织团队

自组织团队不等于无政府主义

不是淘汰领导，而是改变领导方式

将决策权委派给团队，同时也为合适的领导者保留适当的决策权

适应胜过遵循

开篇

传统项目经理视计划为目标，而敏捷领导者视客户价值为目标

二者都做计划

传统项目经理：修正实际活动以符合之前的计划

在敏捷中，采用“适应性”行动

我们预计到变化并做出响应，而不是遵循过期的计划

我们根据需要调整流程和实践

适应性的科学

优化流程

设计-计划-构建

适应性流程

构想-探索-适应

保持探索

伟大的探索者能够清楚的表述出激发人们灵感的目标，让人激动，从而自我激励

响应变化

例子：在某些时刻，为了交付价值，会把迭代周期延长，之后回归正常

障碍还是机会

人们感觉适应变化有障碍是因为做事效率低下，没有抓住机会简化流程并提高组织的适应能力

可靠，但不重复

可重复意味着如果流程的输入一致，就会得出一致辞的结果

接口的幂等性

适用于工业化生产

对于项目容易产生反作用力

可靠流程将重点放在输出，即使输入差距大，团队成员也能够找到方法达到预期目标

反思、回顾

3.敏捷项目管理模型

构想

代替较传统的“开始”，指出构想的重要性。确定产品构想、
项目目标和控制要素、项目目标和控制要素、项目社团以及团队如何共同工作

构想阶段为客户和项目团队创建构想，该构想包括什么、谁提供提供和如何提供。首先，我们需要构想提供什么，即产品及项目范围构想;其次，我们需要构想参与者都有谁；客户、产平经理、项目团队成员和利益相关方组成的社团；最后，项目团队成员必须构想他们打算如何共同工作

*可交付的产品：产品构想框；项目数据表——项目目标声明、企业目标、性能、性能价值
*可靠的、适应性强的产品：项目数据表——质量目标
*在可接受的约束内：项目数据表——均衡矩阵（范围、进度和成本）

产品体系结构的目标是描述项目内部沟通渠道，是一种促进探索和知道正在进行的产品开发的设计。一个早期的“骨架”产品体系结构不仅能知道技术工作，也能指导执行技术工作人员的组织工作。它旨在把较大的项目背景传达给开发团队，而不是局限于一个设计。

项目数据表是用一页概括主要商业和质量目标、产品功能和项目管理信息。这是一个简单却又重要影响力的文档

当项目启动的时候，项目计划保持在价值、质量和约束三者之间的健康平衡非常重要。当这个平衡被打破的时候，权衡矩阵就开始发挥作用

团队在某个具体项目选择和裁减做法

哪些做法是必需的？
还需要哪些辅助性做法？
需要对选择的做法哪些修改？
做法的编档、批准和更改需要什么手续和形式？

在构想阶段后，构想并没有停止。在每次迭代的开头，团队在一起思考下一次迭代时，团队成员需要重新审视该构想。重新审视的目的是为了修改这个构想，或者在紧张的日常工作之余，提醒团队他们努力的目的地在哪里

推演

收集初始的、广泛的产品要求

将工作量定义为一个产品功能清单

制订一个迭代的、基于功能的交付计划

产品经理控制哪些功能应该包含在产品中，而开发工程师控制功能的设计和实施方式。
产品经理没有全力说，“我们落后了，让我们缩短测试时间吧

如果我们想要适应性、灵活性、创新以及对客户了解到的新信息做出相应，就需要奖励团队对这些变化的响应，
而不能因为团队成员未能“实现计划”而警告他们

敏捷开发是关于焦点和平衡的：集中于项目的主要构想和目标，强迫做出困难的权衡决策，以保持产品各方面的平衡

当进度出现问题的时候，瀑布式方法所见任务，通常是减少测试，而敏捷方法减少功能，前者降低质量，后者缩小范围

把风险降低策略纳入计划

估计项目成本，并生成其他必要的行政管理和财务信息

探索

在短期内计划和提供它精测试的功能，不断致力于减少项目不确定性

通过管理工作量和使用适当的技术方法和风险降低策略，按计划交付产品功能

设定迭代长度时应该遵循3个标准：交付用具价值功能块（故事）、构建和测试故事（可工作的软件）和产品团队对的验收

工作量管理旨在让团队成员自己管理必要的日常任务，以便在每次迭代结束时交付故事。
团队成员应该尽可能地管理自己的工作量。每个人你和整个团队都对交付他们在迭代计划中承诺的结果负有责任

项目领导者主要是通过制定业绩目标（故事、质量目标、所需的做法）并监督其实施（不用微观管理）
，而不是通过制定任务进行监督管理。

当产品开发团队对卓越技术做空口承诺时，当项目和产品经理促使团队仓促而不是迅速地工作时，就会招致技术债务

重构不应该成为草率设计的借口，我们的目标不是重构，而是保证可行的、适应能力强的设计，这就要求每个步骤都有优秀的设计做法。

建立协作的、自我组织的项目社团，这是每个人的责任但需要由项目经理和迭代领导者推动

如果从根本上来讲，你不信任别人，那么在任何情况、任何时间、人们都不吭能突然值得信赖。
对于极少数真正不信赖的个人，优秀的领导者有一个解决方法，就是将他们从团队清理出去，而不是用难以负担的控制折磨整个组织

适应能力强的团队的一个信条是创新源自于不同背景的个人相互交流，每个人都有各自的想法，每个人都将信息和观点贡献给开发流程

交往规则：建立关系、确定做法和做决策。建立关系的规则是：鼓励开放、坦诚的沟通；确定做法的规则是：
迭代长度将为2个星期；做决策的标准规则是：没有偷工减料（以质量为导向的规则）

每日站会不应该是用来解决问题，而只需要确认问题，一旦确认问题，有关团队成员会在会议结束之后聚在一起对这些问题加以解决

管理团队与客户、产品经理和其他利益相关方的项目交流

适应

没有最好的做法，只有更适合具体情况的做法

客户或产品团队通过客户中心组的参与和延时实际的产品，从而进行产品的验收测试，仍然是最重要和最有益的敏捷做法之一

约束

终止项目、交流主要的学习成功并庆祝

4.敏捷项目扩展

敏捷项目扩展

大型项目存在的问题包括日益增加的官僚主义、过多的文案工作、无法管理的通信网络和缺乏灵活性

敏捷是一种理念，一种思维方式，而不是一套做法或流程

沟通设计之所以困难是因为它取决于一系列关系的基础——信任、尊重和接收文化差异和共享信息。

决策小结：
　　团队：体系结构
　　任务：开发应用数据模型
　　*受影响团队，所有功能团队和几个专业团队
　　*提供信息团队，基础团队，挑选几个功能团队
　*参与讨论：基础团队有两名体系结构团队的兼职成员，来自第N个功能团队的一名高级设计师
　　*决策者：体系结构团队
　　*决策结果传播：给所有团队负责人Email.
　　*决策审核：无

文档支持沟通和协作、促进知识传播、保留历史信息、帮助改进产品和满足法律法规的需要。他们并非不重要，仅仅是不如可行的产品版本重要

敏捷方法和以文档为中心（或以模型为中心）的方法之间的问题并不是文档过多或者没有文档的问题，而是正确组合文档和交互方式以促进理解和沟通的问题。敏捷主义者倾向于交互方式，而传统方式主义者倾向于文档

敏捷文档的指导原则
　　*根本问题是知识转移——理解而不是文档
　　*知识转移需要人与人的交互，特别在知识复杂性增加时
　　*文档应该刚刚足够，但不能不够，使用概括文档而不是详细文档
　　*文档应该进可能地非正式——白板、挂图、数码照片，维基等
　　*交互的、动态的文档对于敏捷项目非常重要
　　*可行的软件是开发目标之一，促使该软件的改进是目标侄儿，考虑用刚刚足够的文档来支持两个目标的实现
　　*文档需求因行业、公司和项目的不同而各异
　　　*用户文档应该和故事一样被确定下来，并由客户排优先级

交往规则

　　*对于影响自身工作的体系结构决策，功能团队可提出自己的意见，并且可以参与决策过程（可能要限制参与表决的团队数量）

　　*有权对任何体系结果变化所带来的影响进行评估，并相应地调整自己的估计方法和进度计划

　　*当团队对某项体系结构决策的否决权置之不理时，有权请求产品和项目经理就该决策进行审核

　　体系结构团队

　　*有权及时得到拟定的体系结构计划的各种信息和反馈

　　*在功能团队实现体系结构决策时遇到问题时，有权及时收到相关的通知

不要把项目中存在的一般问题都归因为敏捷问题，不管使用什么方法，都会产生这样的问题

治理敏捷项目

有关项目治理，主管对两件事情干兴趣——投资和风险

治理是在不确定环境中制定投资决策。主管必须制定投资决策，确定投资回报率（ROI）并且评估获取该投资回报率的概率。投资回报率有3个组成部分；产生的价值（资金流入）、消耗的成本（资金流出）和时间（流入和流出的时机）、主管必须回答两个基本问题：预测的项目价值和投资回报率是什么？获取这个回报率的概率多大？

概念阶段要实现两个首要目标，创建并确定产品构想以及识别和降低风险。构想包括产品构想、营销构想、财务构想和团队构想。风险包括市场风险(我们能卖出去吗)、技术风险（我们会构建吗？）、财务风险（我们能赚到钱吗？）。概念阶段也是为了验证概念，而不是研究项目的可行性或识别风险。

大多数公司花费太多的时间定义阶段、确定过程。如果把这些时间花费在思考决策关卡和通过这些关卡需要具备哪些信息时，将更有意义。

评估敏捷绩效

约束越严格，团队拥有的灵活性越少，团队交付最高优先级结果的可能性就越少

项目管理归根结底与两件事情有关：管理人和管理决策

评估团队的相对业绩而不是按照计划衡量团队的产出，一个明显优势是这种评估方式对于改进没有设置上限（目标）。因为一切都是相对的，所以优秀的团队会努力做得越来越好，而不是试图满足目标。

我们的绩效系统必须建立在正确的意愿之上——去指引，而不是惩罚；去学习，而不是重复；去适应，而不是拒绝改变。如果我们想要建立适应型组织，那么必须撅起固定的绩效合同，而去追寻一种符合这些新的意图的评估系统

一次自己的项目体验