目录
最近阅读了《敏捷软件开发实践——估算与计划》这本书，总的来说，是一本非常好的书籍。先前只是采用敏捷研发的流程，对于敏捷研发的关键环节理论理解不深，通过阅读本书，解开了很多疑惑。以下整理了第一部分的内容。
在介绍敏捷估算和计划方式之前，首先需要理解计划的目的。
一、计划的目的
1、为什么要进行估算和计划
- 减少风险——计划通过提供对项目风险的认识而提高了项目成功的可能性
- 降低不确定性
- 提供更好的决策支持
- 建立信任——频繁地、可靠地支付承诺的功能可以在产品开发人员和产品的客户之间建立信任；可靠的估算使得可靠地交付成为可能；客户需要估算来做出关键的优先级和折中决策
- 传递信息——计划可以传递针对项目的期待，并且描述完成项目的可能路径之一
2、优秀的计划是什么
- 是项目利益相关者认为足够可靠、可以作为决策基础的计划；
- 公司的其他人可以使用这个计划来做决策：可以准备市场推广材料、计划广告宣传攻势、分配资源以帮助关键客户进行升级等
3、敏捷计划是什么
- 敏捷计划将重点从作为结果的计划转向了计划的过程；
- 敏捷计划平衡计划所需要的精力和投资；
- 敏捷计划回一个我们不仅愿意、而且渴望修改的计划
4、小结
估算和计划是关键的，但也是困难和容易出错的。我们不能仅仅由于它们很困难就不去做这些事情。项目早期给出的估算没有项目晚期给出的估算准确。不确定性锥形显示了这一逐渐细化的过程。
计划的目的在于找到一个最佳答案，用于回答“要构建什么”这一产品开发的总体问题。这一答案综合了功能、资源和进度安排。一个可以减少风险、降低不确定性、为可靠地决策提供支持、建立信任和传递信息的计划流程为解答这个问题提供了支持。
优秀的计划应该足够可靠，可以作为对该产品和项目进行决策的基础。敏捷计划更关注计划的过程而不只是创建一个计划它鼓励修改、产生易于修改的计划，并且延续到整个项目周期。
二、计划失败的原因
计划的目的是以迭代方式为“我们应该开发什么”这一新产品开发的终极问题找出最佳答案。也就是说，产品应该具有哪些特性、在什么时间完成、需要哪些资源以及需要多少资源。
传统的项目计划方法往往会让我们失望。要回答一个新产品的范围/进度/资源的组合问题，传统的计划过程不一定会产生令人非常满意的答案和最终产品。本章介绍了导致计划失败的5个原因。
1、基于活动而不是基于特性进行计划
基于活动的计划的第一个问题在于客户并不能从活动的完成中获得价值。特性才是客户价值的计量单位。因此，计划也应该是从特性的层面，而不是活动的层面进行。
基于活动的计划常导致项目的实际开发时间超出计划表，这引起更多的问题。当面临超出计划表的情况时，有些团队会试图通过不恰当地降低质量来节省时间。也有一些团队会制定变更控制策略来限制产品的变更，即便对高价值的变更也是如此。基于活动的计划导致超期的原因如下：
1.1、活动不会提前完成
工作总是要拖到最后一刻才完成；
人的本性就是用多余的时间做一些对我们自己有价值，但对别人不一定有价值的事。
1.2、延误沿着计划表向下传递
提前启动要求很好地完成多件事；而只有一件事出错就会导致延迟启动。
1.3、活动不是互相独立的
2、多任务处理导致更多的延迟
多任务处理，也就是同时处理多个任务。多任务处理会对生产效率产生可怕的影响。Clark和Wheelwright研究了多任务处理的效果，发现当一个人同时处理3个甚至更多的任务时，用于增值任务的时间会迅速减少。
3、不按优先级开发特性
传统计划方法无法带来高价值产品的第三个原因是，制订的计划没有按照对用户和客户的价值大小来排列工作的优先级。
4、忽视了不确定性
传统计划方法的第四个缺点是无法意识到不确定性的存在。
应对不确定性的最佳方法是迭代。要降低关于产品应该是什么的不确定性，使用短的迭代周期开发，每过几周就向用户展示可用的软件。通过迭代也可以同样降低关于如何开发产品的不确定性。例如，可将遗漏的任务加入到计划中，或者纠正错误的估算等。按照这样的方法，关注点就从计划本身转到计划过程。
5、把估算当作承诺
每个估算都包含了一定的可能性，它表示该特定工作在估算的时间长度内完成的可能性。
如果项目团队或者利益干系人把估算当做了承诺，传统的计划方法就会出现问题。估算是一个可能性，而对一个可能性做出承诺是不可能的。承诺都是针对于日期。通常，团队为他们被要求（或被告知）的承诺日期所给出的可能性是低于100%的。在做出这样的承诺之前，团队需要对大量的商业因素和风险进行评估。重要的是让他们拥有评估的机会，并且不要把所有的估算都当成是隐性的承诺。
6、小结
基于活动的计划分散了我们对特性的专注，而特性才是衡量客户价值的单元。如果遵循从基于活动的计划所得到的的计划安排表，很多问题都可能导致交付的延迟。项目团队的成员本来是满怀好意的把多任务处理当作一个可能解决延迟的办法，但由于多任务处理背后隐藏的代价，实际上它会导致更长的延迟。当项目计划表上剩余的时间不够时，放弃一些特性就是无法避免的，由于是按照开发人员认为最有效的顺序来开发特性，因此被放弃的特性对用户来说不一定是价值最低的。
忽视关于用户最终需要什么的不确定性，会导致虽然按时完成了项目，却丢失了在制订计划以后所发现的那些重要功能。而忽视关于如何开发产品的不确定性，则会导致在项目计划中遗漏掉一些活动，反过来增大了项目被延迟，最终放弃部分功能，或者不适当的降低质量的可能性。
很多公司混淆了估算和承诺，只要团队做出了一个估算，他们就被迫承诺完成。
三、敏捷方法
敏捷宣言作者们的价值观是：
- 个体与交互胜于流程与工具
- 可工作的软件胜于面面俱到的文档
- 客户协作胜于合同谈判
- 响应变化胜于遵循计划
客户协作的价值胜于合同谈判，原因在于敏捷团队希望与项目相关的所有团队都在朝共同的目标努力。
1、项目的敏捷开发方法
敏捷开发的4个价值观会导致高度迭代式的、增量式的软件开发过程，并在每次迭代结果的时候交付完成编码与测试的软件。敏捷团队的主要工作方式如下：
1.1、敏捷团队作为一个整体工作
项目取得成功的关键在于，所有的项目参与者都把自己视为朝着一个共同目标前进的团队的一员
1.2、敏捷团队按短迭代周期工作
在敏捷开发项目中，开发过程没有分成什么重要的阶段——没有什么先是先期需求阶段，然后是分析阶段，然后是架构设计阶段，等等。根据你的实际选择或者定义的敏捷开发过程，你可以在项目的最开始设置一个很短的设计、建模或其他阶段。但只要项目真正开始，每次迭代都会同时进行所有的工作（分析、设计、编码、测试等）。
1.3、敏捷团队每次迭代交付一些成果
1.4、敏捷团队关注业务优先级
敏捷团队通过下面两种方式保障了业务优先级。
（1）按照产品负责人所定义的顺序交付特性，而产品所有人一般会按照使得组织在项目上的投资回报最大化的方式来确定特性的优先级，并按照发布来组织特性。为此，制定发布计划需要基于团队的能力以及按优先级排好的新特性列表
（2）敏捷团队关注完成和交付具有用户价值的特性，而不是完成孤立的一个个任务（这些任务最终组合成具有用户价值的特性）。达到这个目的的最佳方式之一就是使用用户故事，这是一种表达软件需求的轻量级技术。
用户故事（User Story）是从系统用户或者客户的视角对功能的简要描述。用户故事的形式很自由，没有强制性的语法，然而，用户故事通常会采取这样的形式——“作为<一类用户或一类角色>，我希望<能力>，这样<业务价值>”。
1.5、敏捷团队进行检查和调整
任何项目刚开始的时候所建立的计划都不能保证将来会发生什么事情。
在每次新迭代开始的时候，敏捷团队都会结合从上一次迭代中获得的所有新知识，作出相应的调整。
计划的价值可能会由于产品负责人获得了期望用户或者可能用户的知识而发生改变。
2、敏捷计划方法
作为一个新项目的开发进行估算和计划是一件令人望而生畏的工作，而我们对项目的误解更增加了他们的难度。应该把项目看成是快速、可靠地产生一系列可用的新功能和新知识的过程。新功能在产品中交付，新知识则被用于让这个产品做到尽可能的最好结果。
把对项目的传统观点比作10公里长跑。你知道终点到底有多远，而你的目标就是尽快达到终点。而在敏捷项目中，我们不确切知道终点线在哪里，但我们尝尝知道我们需要在某个特定的期限内去达到或者尽可能接近这个终点。敏捷项目更像是计时赛而不是10公里比赛；在60分钟里跑得越远越好。
2.1、计划的不同层次
在设定和修正目标的时候，重要的是记住我们无法看到地平线以外的东西，而且当我们试图计划的距离超出视线范围越远，计划的准确性降低得就越迅速。
如果对一个项目的计划远远超出了计划人员的可见地平线范围，而且没有包括给计划人员抬头瞭望新的地平线并做出调整的时间。那么项目时很危险的。渐进的明确计划是非常必要的。敏捷团队通过对3个不同层次的地平线进行计划来达到这一目的。这3个地平线分别是发布、迭代和当日。下图展示了这3个（以及其他）规划地平线之间的关系。
大多数敏捷团队只关注规划洋葱最里面的3个层次。
（1）发布计划要考虑在产品或系统的新发布中需求开发的用户故事或者主题（theme）。发布计划的目标是为项目的范围、进度安排以及资源问题确定适当的答案。发布计划在项目开始的时候进行，但并不是孤立的工作。
一个好的发布计划会在项目的整个过程中保持更新（通常是在每次迭代开始的时候），以使它总是反映团队当前对于发布中应该包含什么内容的期望。
（2）迭代计划，它在每次迭代开始的时候进行。根据团队在刚结束的迭代里面所完成的工作，产品负责人确定团队在新的迭代中应该处理的高优先级工作。
由于现在看的是比发布计划更接近的地平线，迭代计划的组成部分可以更小。在迭代计划中，我们谈论的是把特性需求转变成完成测试的可工作软件所需执行的任务。
（3）每日计划，大多数敏捷团队采用某种形式的每日站会来协调和同步每天的工作。在每日展会上，开发小组把他们的计划地平线限制在不长于接下来的一天之内，知道第二天的站会。他们关注于对任务的计划，以及协调个人的活动来完成任务。
通过这3层次（发布、迭代和每日）的计划，敏捷团队聚焦于对他们正在制定的计划可见而且重要的内容。
在大多数独立敏捷团队的考虑范围之外，是产品计划、资产计划和战略计划。产品计划要求产品负责人的视野超越本次计划，为已发布的产品或系统的演化进行计划。资产计划则是选择最合适的产品，以最好地达成公司的战略计划所确立的远景。
2.2、满意条件
每个项目最初都有一组目标。这些目标可以被视为客户或者产品负责人的满意条件（condition of satisfaction）——也就是用来衡量项目是否成功的标准。
在发布计划开始的时候，团队和产品负责人会共同研究产品负责人的满意条件。这往往包括了常见的事项，如范围、进度、预算和质量，不过敏姐团队通常倾向把质量看成不可协商的。团队和产品负责人寻找可以满足所有满意条件的各种方法。
但是，有时无法满足产品负责人全部的满意条件。当无法找到可行解决方案的时候，就必须对满意条件进行修改。因此，发布计划和对产品负责人的满意条件进行探索是高度迭代式的，如下图所示：
上图显示了反馈闭环包括了从生成的产品增量回到发布计划和迭代计划之前满意条件框的反馈回路。基于在迭代里面开发产品增量时的经验，团队可能会获得新的知识或者经验，进而在一个或更多层次上影响到计划。与之类似，向现有用户或可能用户展示产品也可能产生导致计划发生改变的新知识。敏捷团队会把这些变化结合到他们的计划中，知道获得具体更高价值的产品。
3、小结
敏捷团队作为一个整体一起工作，但包含了由特定人员担任的不同角色。首先是产品负责人，负责确定产品愿景和团队将要实现特性的优先级。然后是客户，就是为项目提供资金或在软件完成后购买它的人。敏捷开发项目中的其他角色还包括用户、开发人员和项目经理。
敏捷团队按照短的、时间限制的迭代周期进行工作，在每次迭代结束的时候交付可工作的产品。在这些迭代中开发的特性是根据他们对产品的业务重要性选择出来的。这保证了最重要的特性首先开发。用户故事是敏捷团队用于表达用户需求的一种常见方式。敏捷团队认识到计划可能很快就会过时。因此，他们会根据需要调整计划。
项目应该被看成是快速、可靠地产生一些列有用的新功能和新知识的过程，而不只是对一系列步骤的执行。项目会产生两类新知识：关于产品的知识和关于项目本身的知识。每一类知识都有有益于使计划更精细，从而为组织实现更多价值。
敏捷团队试用3个层次上的计划：发布计划、迭代计划和每日计划。发布计划展望一次发布的整个事件范围——通常是3~6个月。迭代计划只考虑一次迭代的时间范围——通常是2~4周。每日计划则通常由小组成员在每日站会上向其他人做出的承诺组成。
115
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
