本章将介绍所有主流敏捷实践中所遵循的大体上共通的流程模式。
2.1 敏捷通用流程框架
虽然说敏捷实践和流派的种类很多，但主流的一些敏捷实践大体上遵循同样的模式：先经过一个初始阶段（准备工作），然后进入若干个迭代开发以完成发布，最后进入发布的收尾。把这些共性流程做出抽象和总结，就得到如下面的图 2-1 所示的“敏捷通用流程框架”。
2.1.1 敏捷项目的初始阶段
如图 2-1 所示，敏捷项目的初始阶段主要是在正式进入首次迭代开发之前的准备工作。这些准备工作可以细分成三个环节。
第一个环节是论证项目的可行性。这个环节主要是要完成项目的商业论证以及创建一个项目愿景。商业论证是敏捷项目的经济可行性依据，可以用诸如投资回报率、净现值、内部回报率等经济预测指标来衡量项目值不值得做。
而项目愿景（有时也被称作产品愿景）则是用于描述敏捷项目的高层级目标，以及表明做这个项目的原因，即回答“为什么我们要做这个项目？”的问题。
第二个环节是正式启动敏捷项目。这个环节中需要制定一个项目章程。敏捷的项目章程通常比传统的项目章程更为轻量化，其主要包含的内容有以下几个方面：
创建了项目章程之后就要创建产品待办列表。产品待办列表（Product Backlog， 又称产品未完项）是项目所有需求项/工作项的价值优先级排序列表。列表中的最顶端是具有最高商业价值的需求项，而列表的最低端是具有最低商业价值的需求项。
在后续的迭代开发中，开发顺序永远是在列表中从上往下开发，体现“价值驱动交付”的理念。产品待办列表是动态的。在项目的全过程中，
客户在任一时间提出的变更或新需求都会被纳入产品待办列表中，并由产品负责人（ProductOwner，项目的需求管理人）对列表进行重新的价值优先级排序，以使产品待办列表能始终反映客户的需求和需求的优先级。
在项目工作开始之前，我们不需要为整个项目所有范围创建需求项，只需要创建第一个发布/版本所需开发的主要内容即可。
在主流的一些敏捷实践中（如 Scrum、极限编程等），产品待办列表中的需求项是以用户故事的形式来表述的。一个用户故事代表一项相对独立的需求。之所以叫做用户故事，是因为这种描述需求的形式永远是以产品的用户作为主语的。例如：“作为旅客，我需要注册成为 XX 旅店的会员，以便可以使用网上预订房间的服务。”
第三个环节是构建产品路线图和发布计划。
产品路线图（Roadmap）是产品需求的高层级概述，其勾画出产品多个版本的演变过程，是项目层面的粗粒度计划，关注的是目标，而不是细节。它可用于明确项目的中长期目标，也可用于和项目干系人的沟通。图 2-2 展现了一个以开发图书馆借书网站为例的产品路线图。
从图 2-2 可以看出，一个典型的产品路线图可以用时间轴的形式来表达。在时间轴上标出每个版本（也叫作发布）的具体发布节点，并且可以用若干个短语来描述出每个版本主要交付哪几个功能或模块。
制定完产品路线图后，接下来是制定发布计划（Release Plan， 又称为版本计划）。假设我们当前要开发第一个版本，那么我们只需要规划第一个版本的发布计划，后续版本的发布计划不需要提前规划。
发布计划虽然比产品路线图要更为详细一些，但是其仍然属于高层级的计划，该计划将规划当前发布中要包含的基本特性和功能。一个发布计划将包含若干个迭代。发布计划会规划一次发布包含多少个迭代以及每次迭代的周期有多长，因而发布周期总时长也会随之确定。
2.1.2 敏捷项目的迭代开发阶段
在迭代开发阶段，在每个迭代开始前我们需要开迭代计划会以制定一个迭代的总目标——迭代目标，并制定迭代的开发计划——迭代计划。
迭代目标和迭代计划的制定同样遵循渐进明细的理念。即在每个迭代开始之前，仅需规划当前迭代的工作内容，对后续迭代的工作内容可以不做规划。这种做法有利于我们后续拥抱需求的变更。
那么团队如何才能较为准确地预测一个迭代能完成多少工作量呢？一个比较靠谱的方法就是利用历史数值。比如，若团队之前已经完成了若干迭代，那么就可以直接利用这些迭代实际完成的工作量（通常可以从发布燃尽图获得数据）作为预测的依据，从而更为准确地规划一次迭代所能完成的需求列表。
迭代计划是整个敏捷计划中最详细的一层计划，其不仅选择产品待办列表中最高价值的用户故事作为迭代的开发内容，而且还会将用户故事分解为一系列的任务（Tasks）。这种任务列表在有些敏捷实践（例如 Scrum）中被称之为迭代待办列表。迭代计划依然需要遵循价值驱动交付的理念，即开发的工作顺序需要跟产品待办列表上的顺序保持一致。
迭代的周期需要遵循时间盒规则。时间盒指一段固定的时间。例如迭代的长度可以是 1 周、2周、3 周或 1 个月（一般不能超过 4 周），但一旦选定了一个时间，比如 2 周，那么后面每一次迭代都应该是 2 周，不能延长也不能缩短，就像一个铁盒子那样。时间盒规则的作用主要有两方面：
一是保证不同迭代的生产率（用速度来衡量）是可对比的，以一个固定的时间尺度为基准测量团队生产率，促进团队的持续改进；二是保证工作的连续性，时间盒内的工作不被打断，减少因任务切换而带来的效率浪费。
时间盒（迭代）结束时，若所规划的工作未完成，那么工作应该立即停止，并把遗留的工作项重新放回产品待办列表，以进行重新的优先级排序；若所规划的工作已全部完成且还有剩余时间，应从产品待办列表中继续领取工作项进行开发。
在迭代的中途，倘若客户或产品负责人提出了一项需求变更，而这项变更恰好涉及团队正在进行的此次迭代所需开发的内容，那么在一般情况下团队不需要放下手中的工作来实施客户所要求的变更，否则团队迭代内的工作就会被打断从而打破了时间盒规则，并且会产生半途而废的工作而浪费了团队效率。
因此，客户/产品负责人所提出的需求变更或新需求，一般都会先纳入产品待办列表进行价值优先级排序，然后在后续的迭代中进行规划和开发。而当前正在进行的迭代任务（即迭代待办列表）是不发生改变的。这样能够让团队专注于当前迭代。当然，有一些极其特殊的情况：
例如若不开发某个迭代外的新需求则迭代内的其他任务将无法开展，或者若不开发某个很紧急的合规性需求则当前迭代即使完成也无法产生商业价值，等等，这些情况可以作为例外，允许在本次迭代中插入新的任务或需求。同时可能会导致一些最低价值的任务会被挤出本次迭代，回归到产品待办列表中。
在迭代进行过程中，每天都要开会——每日站会。每日站会与迭代周期以及其他会议（迭代计划会、评审会、回顾会等）一样，都应符合时间盒规则。每日站会的时间盒是 15 分钟。每日站会上每个团队成员轮流回答下列三个问题：
虽然每日站会上团队成员可以提出所遇到的障碍或问题，但是由于站会只有短短的 15 分钟时间，因此团队不应在站会上讨论问题的具体解决方案。若要讨论解决方案，则应该在站会结束之后，另外再开一个问题解决会。
需要注意的是，每日站会并不是团队成员给敏捷教练汇报项目状态，而是团队成员之间面对面的交互沟通，促进不同项目工作间的协调，以提升团队的整体协作水平。因此，团队中的任何人都可以主持站会（虽说多数情况下是敏捷教练主持）。
基于这一原因，站会不宜有领导、管理层、产品负责人或其他相关方参与会议的讨论。如果这些相关方一定要参加站会，那他们也不能发表意见或言论，以免妨碍团队的自我组织和相互协作。一句话总结，那就是其他相关方对站会“可以出席，但不能参与。”
通常团队是站在信息发射源旁开每日站会的，在每日站会结束时，团队应更新信息发射源上的看板、燃尽图以及风险、问题列表以反映最新项目状态和信息。
在每次迭代结束时，团队都会产出迭代的功能增量，即本次迭代所开发出来的新功能。此时应该召开评审会（也称演示会、产品审查会等）。评审会上团队成员会给产品负责人或客户（产品负责人必须参加评审会，客户若能参加更好）演示产品功能。
在演示后，产品负责人将接受或拒绝功能。若拒绝功能，产品负责人应提出需求变更和反馈意见以便团队修正后续开发方向。敏捷的这种频繁获取相关方反馈的流程，可以有效防止团队朝着错误的方向前进。
在开完评审会之后，敏捷团队还应开回顾会。回顾会的目的就是让团队能总结经验教训、调整过程以实现持续改进。回顾会一般会讨论下列三个问题：
回顾会不是责备，回顾的目的是总结经验教训，让团队从以前的工作中学习并做出小的改进。因此开回顾会很重要的一点是需要培养一个开放而积极的氛围，切忌追究失败的责任。
在以上所有的事情都完成之后，接下来就会进入下一次循环：产品负责人更新产品待办列表；产品负责人、开发团队和敏捷教练一起开迭代计划会以规划下一次迭代；进行下一次迭代开发；迭代中开每日站会和待办事项列表细化会议......。不断循环，直至发布周期结束（发布期限到来）为止。
在整个发布周期结束之后，团队通常会召开一次针对整个发布开发过程的回顾总结会，以总结本次发布的经验教训，以便在后续发布进行持续改进。
一次发布结束之后，我们可能会做下一次发布的计划，进入下一个发布循环，重复前述的所有迭代开发活动和会议，直到最后一次发布我们就结束整个项目。
2.1.3 敏捷项目的多层计划
下面，我们来小结一下前面所提到的多个敏捷项目计划以及这些计划之间的层次关系。敏捷项目的多层计划及其相互间的层次关系如图 2-3 所示。
从图可以看出，敏捷中最高层级的计划是产品愿景（有时也称项目愿景），规定了项目的高层级目标。产品路线图是根据产品愿景制定出来的，描绘了产品不同版本随时间的演进，属于产品发展的粗略视图。
发布计划是根据产品路线图制定出来的，比产品路线图更细化一些，但仍属于高层次计划。发布计划描绘了当前版本大概需要开发哪些特性，并且规定当前发布周期内包含多少个迭代。
迭代计划是根据发布计划制定出来的，其属于短期的详细计划，仅在迭代开始之前对本次迭代的工作范围进行规划。迭代计划会抽取高优先级的用户故事并将其分解为任务列表，因此迭代计划在一些敏捷实践中也被称之为迭代待办列表。
敏捷项目的多层计划也称之为适应性计划，因为其在应对需求变更方面具有很高的灵活性。高层级的计划（产品路线图和发布计划）对长期的工作进行了粗略的规划，而低层级的计划（迭代计划）则对近期的工作进行了详细的规划。因此，整个多层次的敏捷计划体现出了渐进明细的特征。
