XP核心实践-外圈管理

计划游戏
完整团队:
客户测试
小型发布

4

XP核心实践-内圈开发

里1-结对编程:
里2-简单设计
里3-重构
里4-TDD

4

规划游戏为三个阶段:探测、计划和调整。
●第一，探测阶段:客户和开发人员一起把需求分解成很多小的、可估算的部分。
●第二，计划阶段:客户和开发人员一起制订、发布计划。

●第三，调整阶段:客户和开发人员一起，在开发过程中，根据实际情况及时调整原有的计划或制订新计划。

隐喻:隐喻这一个最佳实践是最令人费解的。在软件开发中又有什么用呢?总体来说，常用于四个方面。

• 寻求共识:也就是鼓励开发人员在寻求问题共识时，可以借用一些沟通双方都比较熟悉的事物来做类比，从而帮助大家更好地理解解决方案的关键结构,也就是更好地理解系统是什么、能做什么。
• 发明共享词汇:通过隐喻,有助于提出一个用来表示对象、对象间关系的通用名称。例如，策略模式(用来表示可以实现多种不同策略的设计模式)、工厂模式(用来表示可以按需“生产”出所需类的设计模式)等。
• 创新的武器:有的时候，可以借助其他东西来找到解决问题的新途径。例如:“我们可以将工作流看作是-一个生产线。
• 描述体系结构:体系结构是比较抽象的，引入隐喻能够大大减轻理解的复杂度。例如管道体系结构就是指两个构件之间通过一条传递消息的 “管道”进行通信。当然，如果能够找到合适的隐喻是十分有利的，但并不是每种情况都可以找到恰当的隐喻，没有必要强求。

ROI＝年利润或年均利润／投资总额×100%

注意： 是年利润，不是总利润；

假设项目能够带来400万美元的利润，投入成本是200万美元。如果公司的利润率是10%，那么，利用上面的公式可知该项目的ROI为：

[（400*0.1）/200] *100%  =20%

PV=FVl(l+R)''N  ----------现值，未来价值折现后的价值。

例子： 一个项目在第一年的投入是300000元，假设贴现率是凯在随后的4年中每年的回报是80000，那么它的净现值是多少？

内部收益率

IRR--Internal Rate of Return

内部收益率就是资金流入现值总额与资金流出现值总额相等、净现值等于0时的折现率。
一个项目第一年总投资10000 元，预计有5 年地产收益期，每年收回到3000 元，问它的内部收益率是多少？

如果这时银行利率高于15.5% ，你的投资就是不划算的，反之是赚的。

项目需求

漫画

Sutherland提出的这个结构从一个标准的固定总价合同开始， 包括额外的工作时间和材料。然后他插入“变更费用” 的选项条款。

总价合同+变更条款选项； -------

客户增加新功能的时候，消减优先级较低的功能来做变更。

CFD累积流量图，可以帮助我们了解项目的问题， 循环时间， 可能的完成时间。

A区域代表全部计划的工作，由于增加了附加的特性，所以这个数在第11周的时候从500增长到600,到第19周的时候增长到了600多。

B区域显示的是正在进行的工作;

C区域显示的是已经完成的特性。

利特尔法则

WlP和循环时间越低越好，这是我们的目标，因为它们代表了沉没成本，沉没成本是我们尚未拿到的收益。项目中如果WlP 越多、循环时间越长， 意味着当我们遇到问题的时候， 潜在的浪费越多。

用户故事

一个良好的用户故事应该遵循INVEST 原则：

●独立的( Independent )

·可协商的-Negotiable
●有价值的-Valuable ):
●可估算的--Estimable ):

小的（ Small ）：
●可测试的--Testable ):

用户故事(User Story )是从用户的角度来描述用户渴望得到的功能。

一个好的用户故事包括3个要素:

• 角色:谁要使用这个功能。
• 活动:需要完成什么样的功能。
• 商业价值:为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达:
作为-一个“角色”，我想要“活动”，以便于“商业价值”。

举例:作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便
于“我的赞助商了解我的网站会给他们带来什么收益”。
注：用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语

图4-3 故事分层-----表现底、验证层、业务层、数据层
我们可以基于不同的技术层次.对故事进行分割，从而撰写用户故事以提供全面的功能。这样做的好处是:

需求的分层： 史诗/功能特性---用户故事---任务

项目的优先级需要和干系人的优先级保持一致。

• 一种在项目中包含干系人价值的方法是让业务代表参与到待开发项的优先级排序中。业务代表会指出所执行工作的顺序，项目需要尽早地将高优先级的工作交付给业务。
• 另外一种包含干系人价值的方法是邀请干系人参与到回顾和规划会议中

包含干系人的价值

PMBOOK 4个国长城

1.识别干系人
●识别干系人，并且记录他们的重要性或影响度。
●干系人应该是越早参与越好。
●确定干系人的特殊位置，并且制定如何获得他们支持的策略。
●采购文档可以确定外部的干系人。
●干系人在项目的初始阶段有很强的影响力。
●干系人分析矩阵是干系人管理策略的一-部分。
●如果有很大数量的千系人，我们仅记录影响力比较大的干系人。
●记录的方式可以使用权利或影响方格、权利或利益方格、凸显模型等。

2.规划干系人参与
●管理策略是在整个项目的生命周期中积极地让干系人参与。
●干系人管理计划包括:目前或渴望的干系人参与级别、范围和影响力,相互之间的
关系，沟通的需求和形式，以及如何对计划进行更新。
●分发干系人的参与级别的信息是一个非常敏感的信息。
●参与级别:不知晓;抵制(抵制变化);中立;支持(支持变化);领导(积极参与以使成功)。
●干系人参与评估矩阵。

3.官理干系人参与 
●目标:通过解决问题提升干系人对项目的支持，减少干系人的抵制。
●将独立的干系人的沟通需求记录在项目沟通计划中。
●项目经理可以请求发起人的协作。
●与干系人一起工作和沟通需要满足干系人的期望和解决问题。
●构建真诚、解决冲突，项目经理要具备- -定的谈判能力和沟通技巧。
●和干系人之间也需要在适当的时间、使用合适的方式沟通不好的消息
●需要从干系人那里获得反馈以保存在组织过程资产中。
●问题日志:识别问题、定义影响、所有者和优先级。

4.控制干系人参与
监督干系人之间的关系，并能及时调整策略。

如果供应商需要以敏捷的方法参与到项目中，则对于他们的要求会写在请求建议书.
(RFP)中。在项目中会依赖于供应商的角色，其中一些供应商可能并不会使用或理解敏捷。在设置敏捷需求之前，需要让供应商熟悉敏捷,或者让供应商参加一些敏捷的培训课程。如果供应商扮演的是-个微不足道的角色,可能就不需要这么做了。做所有的决策时，需要我们考虑成本、收益。

因为敏捷项目的需求是可以改变的,范围是可以协商的,所以传统的供应商合同在敏
捷项目中是有一些问题的。在敏捷项目合同中会包含固定价工作包和分等级的固定价合同。

• 所有完成的用户故事得到产品负责人的验证。
• 所有代码得到静态分析，纠正最高级别的不符合项。
• 所有新增代码得到人工评审。
• 所有完成的用户故事都有对应的测试用例。

发布DOD，一般就有更加严格的要求，发布DoD的典型条款有:
●完成发布规划所要求的重点内容。
●通过发布的全量测试，回归测试范围是全范围，回归比率不低于50%。
●修复所有等级为1、2.3的缺陷,4级及4级以下缺陷不超过200个。

1、2级缺陷必须修复，3级缺陷经过带缺陷发布审批后可以发布。

由于发布需要达到比迭代更高的要求,所以一般很难强制规定发布测试所需要的时间
长度,也就是说敏捷中常用的时间箱方法不适宜用在发布前的测试上，因为高质量发布是第一要务,如果到了原计划测试结束的时间，仍然留有妨碍发布的缺陷的话，应当修复后才能发布。

而迭代成果一般是为了内部或者可控范围内的展示，相对发布而言，要求较低，所以可适用时间箱方法，当然迭代本身就是时间箱,迭代内的测试本来就有时间限制。采用时间箱来安排迭代内的测试可以获得时间箱安排的种种好处,在这样的安排下，回归覆盖率就应当是-一个变量，用于观察，而不应当是-一个要求指标。

最典型的是每日DoD，典型条款有:
●搭建每日构建环境，晚上自动静态代码检查、编译、部署和测试，每日修复前一-日构建和测试发现的缺陷和问题。
●下班前必须检入当夭书写的代码。
●当天的代码必须在当天或者第2天邀请同伴进行代码评审。
●搭建持续集成环境，当天上下午必须至少各检入代码- -次。(这与第1条可能冲突)
●采用TDD，凡是检入的功能代码必须要有对应的单元测试。( 严格采用TDD )

用户故事( 或者用例)的DoD，比如:
●用户故事最终的描述符合INVEST原则。
●用户故事得到测试用例的对应覆盖。
●用户故事得到对应的自动化测试用例。
●用户故事得到用户代表试用并初步认可。

有少数组织考虑到测试集过于庞大,无法在1天之内测试完成，开展每周全量回归自
动化测试，这样就有每周DoD，典型条款有:
●上上周发现的缺陷是否解决。
●上周新增功能的自动化测试是否加入到每周测试集。

敏捷模型是基于实践的一套方法论（包括了价值、原则和实践）， 它是软件开发行业基于最佳实践而衍生出来的非常有效的模型。敏捷模型通常是轻量级的（可以用手绘制），很容易改变。对于敏捷模型可以使用用例图、数据模型、界面设计等。

尽管你可以创建很多类型的模型，但是你应该记住敏捷模型的目的仍然是交付价值而不是庞大的文档。所以要保持轻量级， 并且能充分地适应变更。

时间盒被视为是帕金森定律（Parkinson’ s Law ） 的一剂良药： “如何开展工作？只要有效地填满完成前的这段时间。

无论是迭代， 还是整个项目， 时间盒的另一个价值来自人类的一个怪癖：人们往往记住的是失误的日期， 而不是失误的特征。

如果将一个项目延迟3个月， 得到100%所期望的特征集， 那么，人们会认为这是一个“失败” 的项目。假如按时交付具有75%最重要特征的产品， 人们会认为这是一个成功的项目。

制定时间盒的规则如下:
●固定时间盒的长度(一般为几天，最高为6个星期)。
●全生命周期质量是极限项目管理的十大共享价值之一。即一个时间盒应该基于40小时或1星期这个工作时间进行计划。
●在每个时间盒过程中，不要增加人员。牢记Brook的理论:在一个滞后的项目中加人只能使其更滞后。

●时间盒的结束日期不可变更。应在有效的时间里做你能做到的事情， 然后再重新
组合( re-group )。

●时间盒不是用来做绩效考核的。如果尽最大努力之后,你还没有满足时间盒的要求，你要重组并做出新的决定，决定如何做才能最好地向前推进。
●如果在时间盒期间需要追加需求，那么原来时间盒中的某些任务必须放到以后的时
间盒中。如果有重大变化发生的话，应取消时间盒，重新计划并执行新的时间盒。
●每日同步。
●拥抱改变并不意味着混沌，在持续不断的变动中，必须有一个稳定的点。因此，我
们必须遵守在迭代与渐增开发方法中的一个规则:一旦某个反复正在进行当中，外部的干系人不能改变这个反复中的工作内容。时间盒的用意在于缓冲、在于控制风险，不让整个开发过程中因为无休止的不断改变而造成混乱而失去控制，但它更不是拒绝变更或是冻结需求，而是让开发者集中心力把焦点放在最关键或最优先的问题上。换句话说，在开发过程中，时间盒可限制变动只会发生在一-定的范围中，而不让变动太过激烈而造成开发团队的崩解，或是寻求静态平衡而造成一片死寂, 它所追求的是处于混沌边缘的动态平衡，使系统富有足够的稳定与弹性。

(1)要首先确定发布的时间盒。这个时间可以是1周、2周、1个月。无论如何，要让团队有充足的时间。
(2)拿到需求的概要层级后，团队需要决定一个发布计划。因为这是概要层级，是近似的估算，不要过于详细。仅仅是一个很粗糙的开发发布计划。
(3)在每一个迭代规划会议中，坐下来和客户或产品负责人决定在这个迭代中所要做的事情。在这个阶段，你需要更详细的计划，在你现在所知道的基础之上提出更详细的计划。
(4)在迭代结束的时候，你可以基于现有的新的信息，更新概要层级信息。
(5)在每个迭代中重复3、4步。

·计划。·估算。 ·风险评估。 ·需求确认。架构设计。·验收标准。． 测试用例。

(1)通过Kickoff会议以获得愿景从而匹配客户的使命、目的和成功标准。项目开始是一个“设计产品盒子”的活动。关于“设计产品盒子”的内容可以参看《软件项目管理与敏捷方法》第44页。其主要目标是通过交流业务需要和见解来定义项目的边界和目的。

(2)通过特性工作坊将项目愿景拆分为系统潜在的特性。拆分出来的特性为了后续的迭代开发而循环使用。这个工作坊最后的输出是优先级特性列表。

(3)基于商业价值和风险对特性进行优先级的排序,然后进入循环的迭代开发过程中。

在敏捷方法中，我们不必在事前详细说明完整的需求。相反,我们在最初的时候要保证需求的“粗粒度”，然后随着过程的进展，不断地细化它们。

种方法有很多优势:
●有助于保证产品设计的平衡，所以产品不会在特定领域里进行过度的设计。
●在展现细节上推迟决定，直到最后时刻”。
这就意味着我们不会匆忙开发那些后来可能由于新信息或突发的需求变更导致需要修改的模块。

对于敏捷方法来说，我们的目的是更晚地做出决定以便拥抱变更，当我们建立不断扩大的系统时，更早地获得反馈，然后将反馈放人系统变更中，这可能看上去很不明智,但这个方法对于缓解风险、发现问题是个很有效的方法，让项目在更优化的环境下变更,使得变更成本也更少。

• 回想未来

目的：理解客户所定义的成功。
如何工作的：分发给每一个客户一些纸，让他们想象一下从现在到未来的某个时间（可以是一周， 或一个月，或一个季度）会发生的事情。让客户尽可能详细地写出来， 能够使他们高兴的确切的产品。

• 修建产品树

目的：修建你的产品以符合市场需要。
如何工作的：在白板上或者打印出一个非常大的树。粗的枝干代表系统中的主要功能。树的边缘一一一些旁支一一代表了目前发布中的可能的特性。在几个索引卡片上写下潜在的新特性，把它想象为有形状的叶子。询问你的客户在树的周围所渴望的特性，然后定义下一个阶段所要增加的新的特性。

• 帆船

目的：找出客户不喜欢你的产品或服务的地方。
如何工作的：在自板或者纸上画出一艘船。你肯定希望这般船能快速地移动。不幸的是，这艘船有一些锚阻止了它的前进。这艘船就是你的系统，客户所不喜欢的特性就是它的锚。客户写下他们所不喜欢的地方。他们还可以评估去掉多少锚这艘船可以更快地前进。当客户张贴出所有的锚后，评审每一个锚，认真地确认在系统中你需要改变的事情。这个隐喻游戏可以进行改变从而适合需要。

• 买特性

目的：对特性进行优先级划分。
如何工作的：创建一个潜在的特性列表，并为每一个特性提供一个价格。就像是一个真实的产品，这个价格是基于开发的成本、客户的价值或者其他一些事情。虽然这个价格能够负担未来特性的价格但是这并不是一个所必要的。客户可以用你给他们的钱为下一个发布购买特性。鼓励客户用他们的钱购买重要的特性。这将有助于激励一起和客户探讨哪一个特性更重要。

• ·性价比

目的：对待开发项进行优先级的排序。
如何士作的：在开会之前， 阿一幅图：Y轴代表“价值”，X轴代表“成本”， 轴上的数字都是按照斐彼拉切数字组成。用便笼纸写下待开发项， 并把它们贴在图中。让你的同事写下便笼中所没有的任务，和你的贴在一起。和团队在一起， 花一些时间讨论这些待开发项在图中所属的位置。产品经理应该更加关注任务位置的“价值”， 而开发团队更加关注X 轴的“成本” 的位置。如果团队不止一个人， 你可以从大家那里得到不同的观点。根据所贴出来的开发项， 来组织你下面的t作。

宽带德尔菲技术通常用“计划扑克” 来实施。这个技术的变化使用了一个快速的、合
作的过程，并结合了所有基本的宽带德尔菲元素。计划扑克通过卡片中的数字实现了估算。
这些数字（通常基于斐波拉契数列，在本章后面进行描述）代表了规模的单位， 如开发人日或者故事点。“

计划扑克（有时也叫Scrum 扑克）就是一个很好的典范， 它能使团队’快速地进行估算、更加的准确和有意思。

一般情况下，估算的轮数不超过三轮，如果在第三轮的时候，数值还不能收敛， 则可
能是团队成员对故事还不够清晰，需要产品负责人的进一步澄清，所以为了不耽误估算的时间， 可以将其放入下一次的估算中。每次估算会议的总体时长不超过2个小时， 否则大家会有疲惫感。

使用相对大小可以帮助我们解决两个问题：
( 1 ）人们不擅长精确地预测工作的绝对大小。
( 2 ）估算过程是困难的， 不受欢迎的。

我们在估算用户故事时，需要注意以下几点:

• 团队将自己定义故事点。在故事点大小设计时，应该由团队决定故事点的大小。
• 故事点的估算应该是将所有的时间都包括的。我们不需要为单元测试和重构单独安排时间，相反，故事点估算应该尽可能地包括所有的已知活动。
• 当分解时，不需要整体匹配。用户故事是由史诗故事分解而来的，而有的时候在估算完每一个用户故事后进行累加，其累加的总和有可能会超过史诗故事的故事点;这样是没有问题的，因为史诗故事是比较大的，在前期很难进行精确的估算。
• 规模是相对的。在进行用户故事估算时，我们使用故事点的方式，而故事点是一种相对的估算。
• 复杂性、工作量、风险都应该计算在内。完成工作的整体时间是需要考虑工作的复杂程度、工作量以及风险的。

亲和估算是一种许多团队用于快速和更容易地估算大量用户故事的技术。

所以理想时间是在没有中断的情况下，完成一件事情所需要的时间。而耗用时间指的
是将工作时间加上期间的中断时间的总和。

进行理想时间的估算时你的假设是：
·你正在估算的这个故事是你唯一需要做的工作。
·当你正式开始做时，所有的你需要的事情都已经准备好了。
．做的过程中没有任何干扰。

传统的项目章程

• 设置项目的愿景。
• 定义关键的目标和需求。
• 捕获和设置客户的期望。
• ·定义项目参与者和他们的角色。
• 定义约束条件。
• ·建立资源需求和成本目标。
• ·建立概述性的WBS 和进度表。
• ．定义最终项目的成功标准。

• 建立项目的愿景和使命。
• 建立最小的可行性产品和产品的最小市场价值。
• 建立有效的发布计划， 并且使产品待开发项与愿景和使命相匹配。
• 项目如何开展。

5.3.2 商业论证的开友

敏捷项目的商业论证开发和传统项目的是相同的。

在各个项目中，敏捷商业论证的详细程度是不一样的。对于一个小的敏捷项目，可能 没有明显的商业论证文档。相反，商业论证和商业收益的讨论可能包含在项目章程中进行陈述。

对于大型敏捷项目或者需要撰写商业论证文件的项目， 我们可能会在商业论证中看到：

( l ）项目概述：针对项目的背景和目标进行简要的描述。
( 2 ）预算：我们估算的项目成本， 包括合理的应急资金。
( 3 ）预期收益：货币形式的利益或者其他的，我们能够估算出来的项目带给我们的收益，比如新的收入、成本节约、服务提升、质量改善、合规性、工作条件的改善、员工满意度的提升等。
( 4） 商业模式和索引：组织要求的关于ROI、IRR和NPV的计算。
( 5) ROI假设和项目风险：当进行相关的数值计算时， 我们所做的假设，比如通货膨胀率和客户采用率。
( 6 ）不承担项目的风险：如果有的话，该组织如果选择不做此项目，那么需要承担的风险。
( 7) SWOT和PEST分析：SWOT和PEST分析的相关结果，SWOT是指优势、劣势、机会、威胁。PEST是指政治、经济、社会和技术。这两种分析图解工具用来审查项目不同的属性。
( 8）推荐：项目投资人针对项目的推荐，比如强制的（合规）或者关键（投资人的最高优先级）或者一个高、中、可有可无的项目。

所以，一个项目有一个或者多个发布， 一个发布包含了一个或多
个迭代， 而一个迭代往下拆分会是故事， 故事往下拆分是任务，

敏捷比传统的开发模式更加看重计划，而且做计划的频率更高。敏捷里面的计划按照规模大小排序依次是：解决方案计划、发布计划、迭代计划、每日计划。

发布计划会议需要解决的就是发布版本的计划。一般的发布计划可能会覆盖3 ～6 个月的时间，而根据迭代周期的长短，每个发布可能会包含3～12次的迭代。

还有一点需要注意的是：在规划迭代的时候，并不分配任务给具体的人。在迭代开始的时候， 谁将负责哪一块可能显而易见；但是， 项目是渐进明细的， 一开始认为的事情，在后面未必是正确的。所以在敏捷中，我们的建议是个人一开始不承诺任务，在迭代开始之后承诺l～2项任务。在完成已经承诺的任务之前， 不安排新的任务。

迭代计划会议中将本轮迭代需要完成的故事合理分配给团队中每个成员，可以采取新手或实力较弱成员先挑选任务的方式进行分配。

诊断周期时间和趋势可以在问题发生之前就发现问题，而其他工具，如逃走的缺陷和故障模式可以帮助识别已经发生的问题

步骤l ：收集数据。

• 时间表。
• 三个5游戏。
• 颜色代码圆点。
• 愤怒一悲伤一高兴。
• 定位优势。
• 满意程度直方图。
• 团队雷达图。
• 挑选同义词。

步骤2 ：激发灵感。

• 头脑风暴。
• 力场分析。
• 5个为什么。
• 鱼骨图。
• 用圆点贴进行优先级排序。
• 寻找主题。

步骤3： 决定做什么。

问题解决过程的最后一步是决定对于目前所产生的问题我们要做什么。在本阶段会使
用基于团队的技术，此技术涉及的实践是确认方法和可量化的目标，以便跟踪过程和问题
的决议。

知识共享可以出现在宏观的层面和微观的层面。

产品演示就是一个宏观的方式。一个微观的共享信息的方式是团队驻扎。

回顾也算是知识转移的一种方式。

另一种关注知识共享的敏捷方法是通过使用类似墙
上卡片的工具进行项目计划。

为了培养知识共享这种意识， 组织文化应当坚持不懈地鼓励和奖励新发现、创新以及知识传递。

典型的团队发展分为形成、震荡、规范、成熟、解散这5 个阶段。

在领导和管理公司或团队时，要随着情况和环境的改变及员工的不同， 而改变领导和管理的方式。

四种领导形态；

团队初期领着干，指导型领导方式；震荡时期当教练，即指导也支持，开始放手；规范时期放手支持干； 团队成熟期，授权型领导。

仆人式领导力隐含着一个主人（master）的概念。这个所谓的‘主人’是企业的使命。领导者要带领团队成员，企业员工完成企业的使命。

格林利夫认为，“仆人式领导”有如下十大特征:

一。倾听。

倾听。并加以定期反思。这对仆人式领导是不可或缺的。

二、说服。

仆人式领导努力寻求让别人信服

三、感同身受

四、省察。

省察可以使人高屋建瓴，从一个统一-的角度来看待问题和形势，并帮助人们理解有关道德和价值观的问题。

五。疗伤。
仆人式领导者要擅长为自己和他人疗伤。很多人都藏着-颗破碎的心灵，受过这样那样的伤害，仆人式领导需要帮助周围的人成为身，心、灵健康的人。

六、抽象化。

仆人式领导应努力培养自己“梦想宏伟”的能力，能够从抽象化的角度来透视问题，其思考必须超越日常的现实生活和短期目标。

七、预见力。

预见力是仆人式领导与生俱来的特征

八、管家。像管家一-样，把服务他人的需要作为首要的和最重要的承诺。

九、致力于员工成长。

仆人式领导应该积极帮助企业里每个人的成长，不仅是员工的职业成长，还包括其个人成长、心灵成长。

十、建设社区。

通过仆人式领导者个人对具体社区的奉献，带动大家重建社区。

一个对教练工作非常有帮助的理论就是来自“强制辅导学校” 的“收听层次” 理论（ Whitworth 等， 2007 ）。

第一层次：总是一边听一边在考虑其他事情，他的眼睛看着讲话者，心里却想着轮到自己讲话时该讲些什么，也就是说，他把自己要讲的话放在比别人讲什么更重要的位置。他们有三种典型的形式：

• 表面性的听——知道有人在和自己讲话，但只关心自己心里正在想的事。
• 半听半不听——为了等待轮到自己讲话的机会，不得不偶尔听一下。
• 安静而消极的听——听是听了，但是没反应。

第二层次：听讲者不仅听到了讲话者的声音，而且也留心了他讲什么，但听的不够深刻。在这一层次下，人们的沟通只是浮于表面，因为听话者并未注意到讲话者可能隐含在话里的真意。

这一层次的听比第一层次的听更具有危险性，因为第一层次的听讲者不专心听的神情很容易从他的脸上表现出来，而第二层次的听讲者实际上只听了一点表面上的东西，很容易使人们误以为他完全听进去了，也理解了，于是彼此之间就容易在不知不觉中发生误会。

第三层次：专心而有效的听——这一层次下的倾听者无意去批判讲话者的观点，相反，他们把自己放在讲话者的地位，试图以讲话者的观点去看待谈论的事情。

这一层次的特点包括：抓住对方所讲的主题，作出相应的反应，不让自己分心，不断章取义地理解对方的意思，不忽视对方言辞以外的意思（如非口头语言等），了解讲话者的感觉和思想，排除杂念而全心全意的去听取对方发出的信息。

PMI-ACP 的考试只需要考生能够理解如何有效地召开一个会议和工作坊。在召开一个会议时要注意以下几点：

• 目的：不开没有目的或目的不明确的会， 不开无准备的会。没有实效的会和长期议而不决的会， 不如不开。
• 原则：必须要为会议建立相关的原则。例如：在会议期间禁止打电话；按时结束会议；在会议过程中都必须严格执行这些原则， 包括管理者在内。
• 时间：要保证会议按时结束，首先不要让会议偏离主题；其次， 也可以指定会议中的某个参与者为计时员， 保证会议按时结束。

6.1.7 参与式决策模型

6.1.8 团队空间

6.1.9 信怠雷达图

6. 1. 10 谈判

敏捷的方法是使用很多工具用以提升干系人之间有效的沟通（例如：共驻点、每日站
立会议、计划工作坊、回顾等）， 很少以书写的方式作为决策工具。

1. 简单投票    一种最简单的方式就是让团队以手势的方式表示“同意” 或“反对”。

3. 决策分级
决策分级给予了参与者更多的选择：赞同、同意但持保留意见、犹豫不定、不赞成但
同意实施、否决。让所有参与者按这些顺序将他们的回答画成线时，整个团队就可以看到集体的意见。然后团队可以提出问题，了解为什么有人否决，或者了解为什么许多人犹豫不定。如图6-4所示是决策模型。

没有手指头：绝对支持。
1 个手指头：我支持这个选项。
2 个手指头：我支持但有很少的保留。
3 个手指头：我关注， 我们需要讨论。
4 个手指头：我不赞成， 需要讨论。
5 个手指头：停， 我反对这个决策。

1 . Caves and Commons
这是XP中一种经典的布局， 这样的布局有利于团队成员之间的沟通。Caves是个人的空间，Commons是公用的空间， 如图6-8所示。
’

2. 渗透式沟通
渗透式沟通指的是每天在一起紧密工作的团队成员之间谈话和提问中流动的有效信
息。

Scrum 指南中说：“自组织团队要向我抉择如何最好地完成他们的工作，而不是由其他外部团队来决定。”

我们需要授权型的领导方式，更好的激励团队。这种方法在敏捷中叫作“仆人式
管理”， 也叫向下管理模型

自指导顾名思义就是自己指导自己t作。团队成员可以共同创建相关的规范，并由自
己做出决定。但是这绝不意味着敏捷项目经理和领导就不再履行他们的职责了相反，给团队足够的权利对在一个迭代期中的任务进行估算， 如果在出现不准确的情况， 团队会在迭代结束的回顾会议中进行总结和改进， 避免类似的情况在以后再次发生。
不论是向组织还是向指导， 最终的目的是达成本迭代的目标。

团队在形成期需要的是指导，在震荡期需要的是教练，

在规范期需要的是支持，而在成熟期需要的是授权。

在不同的阶段， 敏捷PM和领导应该使用不同的领导风格， 以使团队达到最高绩效。

7.2 建立高绩效团队

在Scrum中，团队通常是5～9人，这样的小团队有助于大家的互相沟通、目标的达成， 但是也有IO ～ 20 人的团队， 我们通常会将大的团队拆分成小的团队，以便于管理，这种形式叫作“ScrumofS crum”

1. 拥有共同的目标
拥有一个共同的目标，并采取有效策略，互相聆听每个成员的思想，为实现这一共同
目标全身心地奋斗。

2. 完善的晋升机制
除了物质激励外，晋升制度也是很好的团队激励，很多优秀的团队成员在努力工作的同时，都期待主管领导给予晋升的机会。合理的制度与机制建设主要包括团队纪律、上级对下级的合理授权；团队的激励与约束；建立公平考核、健全升迁制度。

3. 高效的协作与沟通

4. 有效的团队激励

5. 良好的团队文化和团队精神

7.3 教练和指导

整个团队的指导更多地发生在迭代的边界， 因为这个时间是我们向团队收集迭代计划、迭代的评审和回顾时候。过程的改变更多地发生在迭代之间，而不是迭代的中期，因为迭代是团队专注于在一个不变环境中完成工作的阶段。

在《如何构建敏捷项目管理团队》

阐述了进行一对一指导的4 个前提

( I ）在超前半步的层次上进行指导：不要逼迫团队一开始就要获得成功，就要如何如
何。

( 2 ）置身于充满安全感的环境：而敏捷教练就要允许团队犯错误、允许他们产生抱怨， 而这些都不会受到绩效考核的影响。而且团队成员如果有一些话仅仅是对敏捷教练说的， 敏捷教练也需要对其保密。

( 3 ）与管理者们合作：敏捷团队成员的直接领导不是敏捷教练而是掌管他们绩效考核
的直属管理者，这就需要敏捷教练和管理者进行密切的合作。

( 4）创造一种积极的氛围

频繁的验证与确认被应用于敏捷项目的多个层面上， 包括代码阶段、单元测试阶段、
验收测试阶段等。

结对编程，对开发过程中的反馈与确认；

单元测试，集成测试；迭代评审和回顾；

测试驱动开发不是一种测试技术，而是一种分析技术、设计技术，更是一种组织所有开发活动的技术。

1.先写测试代码,并执行,得到失败结果。

2.写实现代码让测试通过。

3.重构代码,并保证测试通过。

4.反复实行这个步骤 测试失败

验收测试驱动开发（ATDD）这种技术使测试的焦点从代码本身转向业务需求。

通常，当我们从待开发项中抽取用户故事并与商业代表讨论其被期望的行为时，我们
会捕获那些测试。验收测试可能会被捕获至-个功能测试框架中，如“FIT(集成测试框
架)”或“FitNesse”。整个过程会经历4个阶段:讨论、提炼、开发和演示。

(1)讨论需求:在计划会议期间，我们会向PO或客户询问--些用来收集验收标准的问题。

(2)以框架友好的形式提炼测试:在这个阶段,准备好测试，并放人验收测试工具里。
这通常会涉及将测试按照表格形式进行组织的工作。

(3)开发代码并连接测试:在开发阶段,测试与代码相连，验收测试被运行。最初测试会失败，因为它们还没有找到必要的代码。一旦代码被编写,测试就会与之链接,并验证这些代码。它们可能还会失败,所以编码与测试的过程会- -直持续到代码通过所有测试。

(4)演示:团队使用自动化验收测试脚本来进行探索性的测试，并演示软件。

当我们结合定义验收标准和讨论需求这两个任务时,就被迫对软件应该展示的具体行为达成了具体的一-致协议。在某种程度.上，这种方法促使了为每个需求在非常细颗粒度上进行“完成的定义”的讨论。

风险管理指导工作时间表，将项目中的高风险工作放到迭代早期，将可以降低风险的工作放到待开发项中。

不幸的是， 我们通常所做的风险分析过于简单， 且风险管理步骤与项目任务无关， 而不是用风险管理驱动工作时间表。很多项目建立了风险管理过程和风险清单， 但是并没有将风险管理的时间包含到项目计划中。

在敏捷项目的方法中， 有很多机会让我们在项目风险变成明天的问题前，去积极地应
对。迭代开发让我们在生命周期早期解决高风险的工作。高风险的特性或故事可以在迭代的早期处理，这样能够在早期规避风险。当选择一个特性或故事时， 需要在商业价值和风险之间进行平衡。
通常用两个尺度评价风险一一风险概率（用以衡量风险发生的可能性）和风险影响（用
以衡量风险发生时对项目产生的后果）。风险概率可以用百分比表示， 风险影响用货币值表示时， 二者的乘积即为预期货币价值（EMV ），

基于风险的探针是团队试图研究一个问题而进行的简短的概念验证（PoC）。

采用简短的实验来研究项目有风险的部分的方式是基于风险的探针的关键所在。如果
概念验证的执行是成功的， 那么我们便能够排除这个风险， 并V!iX少项目的整体风险。

周期时间：实际花费在工作项上的时间总和（这个时间不包含等待的时间）， 所以当
任务进入到“工作” 栏时， 周期时间就会被度量。
前置时间：从客户发出请求开始到这项工作被完成。所以它是客户等待这项被交付的
整个过程， 如图9-2所示。

周期时间与在制品（ WIP ）密切相关。

通过S 曲
线很容易看出项目的花费是超出预算还是在预算内。如图9-3所示。但是从S 曲线中我们无法看出项目的进度表。但是甘特罔和S 曲线的局限性是相似的S 曲线缺乏进度信息， 而甘特图则缺少成本信息。

如何预测和可视化挣值管理， 减少下降趋势？双S曲线是非常好的开始。

Glen Alleman 解释了 EVM 的基础：“挣值用实际完成的百分比和计划完成的百分比的比值衡量进度。”国防军需大学（DAU）金卡提供了 EVM 如何可视化的表现当前变化作为未来调整依据的例子（注意使用的传统 EVM 术语）。

• 成本差异（cost variance）显示了实际工作的预算成本（BCWP），新术语经常被称为挣值（Earned Value，EV）和实际工作的实际成本（ACWP）的差值。这个例子中，项目当前超支。
• 进度差异（schedule variance）显示了计划工作预算成本（BCWS）和 BCWP 之间的差值，以美元为单位近似表示项目进度。这个例子中项目当前进度落后

传统的挣值管理的指标，例如， 进度绩效指数（SPI）和成本绩效指数（CPI） ，可以
很容易转化为敏捷术语。例如，我们计划在这个迭代周期内完成30个故事点，但是只完
成了25个， 用25除以30可以得到SPI，即SPI为0.83（意思是仅完成了计划的83%）。
同样的， CPI是挣值（EV， 或者是到现在为止完成的特性）除以到现在为止的实际费用
(AC）。对于前面图表的例子，ClP =$2200000/$2800000=0.79。意味着和预期相比， 我们完成了79% 。

客户发现的、开发人员发现的、内部或外部试用用户发现的、产品上市以后发现的以及应该在研发的某迭代内发现却没发现的，这些都属于溜走的缺陷的范畴。

不同的项目， 溜走的缺陷的来源不尽相同。对于这些溜走的缺陷，我们需要进行详细的分析，一个一个地找到缺陷遗漏的原因

敏捷质量标准和实践包含以下项目：

• · 通过测试和客户验收来度量产品质量。
• · 尽可能多地做自动化测试。
• ·确保测试成为每个迭代的一部分。
• ·在下一个迭代中至少修复90%的缺陷。
• ·鼓励质量控制和质量保证的人员与开发人员、业务人员一起工作，了解每个特性的
• 验收标准。

我们还需要监测和评估所使用的工具， 如缺陷的指标、方差和趋势分析， 以及根本原
因对项目过程的质量进行分析。总之，项目和质量标准指的是书面的或非书面的验收指南。

在《敏捷软件开发：合作博弈》（第2版）中讲解了人们经常失败的5种’情况：
( 1 ）犯错误。在实际工作中， 让人不犯错误是一件很难的事情。
( 2）宁可失败也要选择保守。很多人都会具有“宁可保守地失败， 也不冒险用不同的
方式追求成功” 的性格特征。
( 3 ）创新而不研究。要学会利用以前的结果。
( 4 ）不能始终如一。知道有最好的方法时都不采用， 而是采用以往稳妥的方法， 并且
无法一直持续下去。
( 5 ）使用纪律和容忍来应对。在一起工作的过程中， 要使用纪律条款来约束大家， 并
在必要时容忍个别人。

既有失败模式也有与之对应的成功模式， 成功模式包括：
l ）善于四处寻找：当遇到不正确的事情时， 人们要有观察、评审的能力。
2）有学习能力：在看到错误之后， 想办法解决它， 这样可以发展我们的技能和知识。
3 ）具有可塑’性：有能力改变和接受新的主意和方法。
4）以工作为自豪：能够在我们工作范围之外来为项目做一些事情， 比如修复或报告
问题， 因为这对于项目来说是正确的事情。

敏捷环境下团队衡量标准

一类是衡量团队的工作情况与产出的，一般的衡量指标有，每个迭代的完成的故事点数，即团队速率的变化情况，还有就是团队的质量等，比如bug的情况，以及漏网缺陷等。

ROTI:

另一类是指团队的良性运转。比如说每次仪式团队的配合程度啊，团队成员对实行敏捷的满意度啊等衡量指标。

一个比较重要的指标是针对回顾会议的“ROTI”，全称是：return on time invested，主要探讨团队成员对于这次回顾会议的时间花费是否觉得值得。其实不论是回顾会议还是其他的仪式，都可以用这个度量来获得团队成员对这场会议的感觉。