1.1 敏捷开发方法之极限编程 (XP)

1.1.1            XP (eXtreme Programming)

1.1.1        极限编程核心实践

*Small Releases
*Refactoring
*Testing / Test-driven Development
*Pair Programming
*Sustainable Pace / 40-hour Week
*Team Code Ownership
*Coding Standards/Conventions
*Simple Design
*Metaphor (e.g., chalkboard app)
*Planning Game

*Continuous Integration / Build
*On-site Customer
Story Cards Summarize Requirements
Prototype UIs and UI navigation
Stand-Up Meetings
Workspace Environment
Iteration Completeness
Architectural Spike

1.2     敏捷开发方法之OpenUP

* OpenUP 是一个精益的统一过程，它在结构化的生命周期中采用迭代和增加的方法。OpenUP 强调注重实效的、敏捷哲学，将关注重点放在软件开发的协作本性上面。它是一种不约束工具和拘泥于仪式的开发过程，可以被扩展到非常广泛的项目类型之中。
* OpenUP 将项目划分为迭代：有计划的、有时限的迭代操作，通常以周为单位。迭代使团队注重以一种可预见的方式向涉众发送增长式的价值。迭代计划定义了在迭代期间应当完成哪些工作，其结果是一个可以演示的构造。OpenUP 团队将自组织如何实现迭代目标以及提交结果。团队定义和“牵引”工作条目列表 中的任务。OpenuP 采用迭代生命周期（组织微增量是如何被应用的）来得到一个稳定的、复合系统需要的构造，从而逐步的向迭代的目标前进。
* OpenUP 将项目生命周期分为四个阶段：启始、精化、构建和产品化。项目生命周期为涉众和团队成员提供可见度和决策点。这将更有效的进行管理，并且允许您在适当的时间做出是否继续的决定。项目计划定义了生命周期，我们得到的最终结果是一个发布的应用程序。

1          主要的敏捷开发工程实践

1.1 敏捷开发工程实践描述模板

1.1.1        最佳实践定义和特性说明

1.1.2        如何应用最佳实践说明

1.1.3        案例说明

1.2 迭代式开发

迭代开发，也称迭代式开发，在软件开发领域，指每次按照相同的开发方式开发软件的部分，或前期开发并不详尽的软件，经过反复多次开发，逐步增加软件部分，逐步补充完善软件，最终达到最后的软件。其中每次反复开发叫做一次迭代。

需要说明的是，狭义的迭代开发和狭义的增量开发是不同的。狭义的迭代开发中，每次迭代处理的范围是不变的，这与数学中的迭代算法相同；狭义的增量开发中，每次开发是增量地扩大范围。

在目前的大量软件开发实践中，软件的规模都比较大，不可能一次迭代的范围就能覆盖软件全部，多数迭代处理的范围是需要增加的，而在业界书面材料上，有“迭代增量式开发"、“迭代化增量开发”，“迭代式增量开发”等的提法。在敏捷开发领域，为简便计，采用“敏捷迭代开发”的提法。因此在敏捷迭代开发中，每次迭代处理的范围是可以增加的，也可以保持不变，甚至可以缩减范围。

在敏捷软件开发中，敏捷迭代开发需满足3个条件：

1，迭代的时间长度，也称为迭代周期，是有短迭代周期的要求的，一般的，敏捷迭代周期不超过8周，推荐的迭代周期是2周到4周。

2，迭代的产物是可运行的软件。

3，获得迭代的反馈，并处理反馈，反馈作为迭代开发中至关重要的一个方面，必须得到足够的重视。

归纳以上，敏捷迭代开发是指每次按照相同的开发方式短期的开发软件的部分，或前期开发并不详尽的软件，每次开发结束获得可以运行的软件，以供各方干系人观测，获得反馈，根据反馈适应性的进行后续开发，经过反复多次开发，逐步增加软件部分，逐步补充完善软件，最终开发得到最后的软件。

迭代开发的优点：

　　1、降低风险，在进行大规模的投资之前就可以进行关键的风险分析

　　2、得到早期用户反馈，各次迭代为各方干系人提供了一个机会以对进行中又可运行的软件进行评论、反馈，同时能够对未来的开发趋势产生影响。每次迭代都能回顾了一个能够表明各方需求决定以及开发团队对这些需求理解的软件版本，可以决定如何修改项目方向或是划分剩余需求的优先次序。

　　3、对过程的测量是通过对实现的评定（而不仅仅是文档）来进行的，更加直观，更加体现用户价值。

　　4、能够自然的处理变更，快速的适应新情况。快速的开发周期，可以通过后续的迭代来纠正前期迭代的误解、失误，在迭代之间自然的、平滑的处理变更。

　　5、可以对局部的实现进行部署，建立团队交付能力的信心。

关于敏捷迭代开发的几个问题：

1，迭代的时间长度是否每个迭代都可以调整？

敏捷开发的迭代周期选择和项目类型、复杂度、敏捷规模化程度有关，敏捷开发讲究固定的节奏，建议按照固定的节奏开发，因此某个迭代碰到特殊情况，尽量保证迭代时间窗不变，在不得以的情况下可以调整迭代周期长度。

2，敏捷开发时，上个迭代结束后是否可以安排一段缓冲期后，再开展下个迭代吗？

敏捷开发讲究固定的节奏，强烈不建议安排缓冲期，相关任务可以安排在下个迭代中。

3，是否可以将原瀑布生命周期的阶段作为迭代？比如将需求分析阶段改称为需求迭代，迭代的目标产物就是需求规格说明书。

这种做法不符合敏捷开发方法。敏捷迭代的目标产物应当是可运行的，不能仅仅出文档。

1.3 持续集成

英文是Continuous integration

持续集成是指当代码提交后，马上启动自动编译、自动部署和自动化测试来快速验证软件，从而尽快地发现集成错误。

持续集成要素：

统一的代码库

自动编译

自动部署

自动测试

每次代码递交后都会在持续集成服务器上触发一次集成

保证快速集成，集成总时间长度不超过开发人员的一个休息间隙。

持续集成原则：

1. 所有的开发人员需要在本地机器上做本地编译，然后再提交的版本控制库中。

2. 需要有专门的集成服务器来执行集成,每天可以执行多次集成。

3. 每次集成争取都要100%通过，如果集成失败，马上修复，修复失败的集成是优先级最高的事情。

4. 每次成功的集成都可以生成可运行的软件。

1.4 多级项目规划：

多级项目规划定义：多级项目/产品规划，在软件开发领域，是指以迭代开发为基础，形成多层次的、逐步细化的项目或产品计划。这些层层相关的项目/产品规划包括：项目/产品愿景、项目/产品路线图、版本发布计划、迭代计划、每日实现（Daily Scrums）。

角色、产出物和其他说明：

1、项目/产品愿景：项目Stakeholder、项目/产品负责人将参与并组成工作组，他们负责阐述项目的重要性、给出项目成功失败的关键标准以及项目整体层面“完成”的定义。形成项目愿景的一些工具，包括愿景盒子（Vision Box）、业务收益矩阵（Business Benifits Matrix）、项目范围矩阵（Scope Matrix）、滑动器（Slider）、成本收益矩阵（Cost/Benefit Matrix）等。最后，项目愿景需要使用尽量简要的文档固定下来，并保证项目团队成员都能了解。该文档需要包括：问题、机会描述和理由（描述项目的重要性）；项目的价值；项目如何和组织的战略目标达成一致；解决方案综述；项目包含的关键功能；项目必须服从的技术和约束条件；项目范围；项目的关键时间线；项目收益分析；项目和其他项目的依赖性；项目的相关风险以及如何消除。

2、项目路线图：项目/产品路线图主要描述为了达到产品愿景而需要交付的关键功能和特性，这些特性基本处于Epic和特性层面，不包括User Story。它从时间的维度来表述对愿景的支持和实现。当项目/产品需要发布多个版本时，项目路线图就非常重要，否则，它和发布计划相同。项目/产品路线图由项目负责人和项目经理维护，并保持变化。通常，会形成路线图文档或幻灯片，使用大图标显示重要的里程碑、包含的功能和发布日期等，让所有项目/产品相关人员都清楚产品各个组件的可能发布日程。

3、版本发布计划：版本发布计划由团队成员和项目/产品负责人共同制定，并通过版本发布计划会议讨论通过。它包括了当前版本需要交付的、达成一致的关键功能，并经过优先级排序，可以包含Epic和User Story。支持版本发布计划的一些概念为故事点、迭代、团队速率和优先级排序。通常，项目/产品负责人提出本次版本发布的目标，团队成员根据目标和功能特性的重要性对故事进行排序，并依据团队速率决定本次发布需要包含的故事点。前几次版本发布使用估算值，其准确度随着项目/产品的时间持续而逐步精确。版本发布计划是具备适应性且可调整的计划，会随着项目演进而改变。

4、迭代计划：迭代计划是对版本发布计划的再次细化，同样由团队成员和项目/产品负责人共同制定，并通过迭代计划会议讨论通过。迭代会议负责2件事情：根据当前状态确定是否需要对版本计划作出更新；为当前的迭代制定迭代计划。支持迭代计划的一些概念为拆分Epic和User Story、任务、任务估算。在迭代会议上，成员首先根据当前的项目变化对发布计划进行更新，然后根据更新后的、重新排序过的故事制定当前迭代需要完成的故事，并对这些故事进行详细的任务拆分。成员在认领完任务后，会对任务的实现时间做出估算，估算值需要具体到这些估算信息可以方便任何成员追踪任务的进度。

5、每日实现：每日实现是团队成员完成任务的具体过程，它依据任务估算值并根据任务最终实现情况更新该值。在敏捷方法中，使用每日站立会议来报告进度，通过15分钟的站立形式，团队成员报告故事或者任务的完成、未完成状态，而解决层面的问题则在会议之后处理。

注：完整的多级项目规划包含如上5个层面，仅包含版本发布计划、迭代计划有时也被称为2级项目规划。

1.5 完整团队-闫建伟

敏捷开发最佳实践--完整团队

最近几年，以SCRUM为代表的敏捷开发思想在软件开发界悄然兴起，大量的实践表明，敏捷开发大大的提高了软件的开发效率和软件质量，帮助软件企业提高了效益的同时也降低了成本。据调查，在欧美的软件企业已经有近半数的企业开始使用软件开发，在国内的多家公司也悄然兴起。如果您的开发团队还在面临需求时时多变、开发周期过长、软件质量低下等难以解决的问题，那么从传统意义的开发团队向敏捷开发团队转型已是事在必行。现在比较符合敏捷开发思想的开发模式有XP极限编程、RUP、Lean和Scrum，其中最流行的当属Scrum开发方法。下面笔者将结合自己亲自参与多个Scrum开发模式团队的经验，谈一谈如何构建一只符合Scrum开发思想的完整团队。

首先对比一下Scrum团队与传统开发团队的区别。

1、 Scrum团队中不再有传统意义上的产品经理、项目经理、开发经理，而是引入了Product Owner、Scrum Master和Scrum团队等新角色，团队中通常会包含多个职责的成员，比如由需求设计、开发和测试人员共同组成的团队。

2、 传统开发团队通常是项目经理下达工作内容，而Scrum团队提倡自我管理，按照兴趣和能力挑选任务。

3、 从前的开发团队通常是接到任务后分头工作、独立完成，而现在Scrum团队需要相互配合工作，相互协作完成任务。

4、 传统开发过程中，通常是经历一个大时间段的开发过程才完成一次产品发布，而Scrum开发过程中，产品是迭代增量发布的，通常是在每个Sprint结束时交付可发布软件。

下面我来介绍一下Scrum团队完整性的一些体现。

1、Scrum团队职责完整性

在一个标准的SCRUM团队中分为3种角色，分别是Product Owner、Scrum Master和Scrum团队。他们的职责如下：

Product Owner需要确定产品的功能和完成时间，并对产品的收益负责，需要根据市场需求确定产品功能的优先级。Product Owner主要工作是根据市场需求确定产品功能，将其列入Product Backlog中，并为这些功能确定优先级。

Product Owner的角色通常由市场部门的人员来担任。

Scrum Master负责监督整个Scrum项目进程，调整项目计划，确保开发团队成员的能力能够胜任开发，促使团队中不同角色能够进行充分沟通和交流，并负责为项目进程扫清障碍，保障每日的开发进度及一些日常开发管理工作。

Scrum Master通常由开发组组长担当。

Scrum团队，一般由5-10个全职的成员组成，团队成员横跨多个职能，一般包括开发、需求、测试人员，大家在弱化分工，每个人都参与设计、开发与测试中，这也是团队职责完整性的一种体现。

2、Scrum团队素质完整性

首先，要具备很强集体协作精神。敏捷开发提倡的一个重要思想就是集体协作，即使个人能力再强，不懂得集体协作，这种人也不是敏捷开发团队所需要的。

其次，Scrum团队的成员需要具体良好的沟通能力。敏捷开发中最强调的就是沟通，最有效的沟通方式就是面对面交流，那种只会埋头工作而沟通能力不强的员工，在敏捷开发团队里也是吃不开的。

第三，Scrum团队的成员必须能积极主动的接受新的事物，要具备创新能力。敏捷开发与传统的开发模式最大的优势就是拥抱变化，面对时时变化的客户需求，那些不能及时转变思维、墨守成规的成员是不能胜任的。

最后，Scrum团队的成员要具备极强的自我管理能力和积极主动的精神。自我管理是敏捷开发团队中不可或缺的素质，那些工作时只会被别人引导而不能主动自我管理的人也是不适合的。

3、Scrum沟通完整性

Scrum团队除了日常的工作之外，有三个重要的会议也是要坚持的，这三个会议召开的好坏，直接影响到Scrum开发过程的效果。这三个会议分别是Sprint启动会、每日站立会议和Sprint回顾。

首先来介绍一下Sprint启动会,这个会议主要目的是要根据Product Owner制定的产品或项目计划在Sprint的开始时做准备工作，通常是由Product Owner根据市场的前景和商业价值制定一个排好序的客户需求列表，这个列表就是Product BackLog。当Sprint backlog确定后，ScrumMaster带领Scrum Team去分解这些功能点，细化成Sprint的一个个任务. 这些任务就是细化的来实施这些功能点的活动. Sprint Planning的这个阶段需要控制在4个小时。

其次，每日站立会议，顾名思议是每天开站会。这个会议是让团队成员能够面对面的在一起，同步目前的工作进度和状态。通常每个成员需要轮流回答“昨天我做了什么”、“今天计划做什么”和“遇到了哪些困难”三个问题。这个会议一般要严格控制在10分钟左右，不宜过长。

最后，在一个迭代周期结束的时候，要召开迭代回顾会。这个会议首先要演示本迭代完成的工作内容，需求、开发和技术人员要做相关的评审工作，由Product Owner来确定完成了哪些功能，哪些工作还没有完成。另外，整个团队还要回顾本迭代内哪些工作完成的好，继续发扬和保持下去，哪些工作完成的不好，需要进行什么样的改进。

这三个会议是Scrum开发过程中不可缺少的重要组成部分，一定要持续的将这些会议坚持下去，才能真正体会到敏捷开发带来的好处。

1.6 ATDD(验收测试驱动开发)-刘曙光

ATDD定义：Acceptance TDD是测试驱动开发核心理念的一个扩展，是指在用测试驱动开发实现某个具体功能之前，将会首先编写功能测试或验收测试，从系统功能角度驱动开发过程。ATDD是一种团队行为及过程，ATDD周期包含挑选故事，给故事写测试，实现测试以及最后实现故事这四个步骤。

1、挑选用户故事：迭代开始前的计划会议，这个会议中，客户会决定下一个迭代该做哪些故事，及给故事排优先级。一般情况下可先选择较高优先级的用户故事。

2、为故事写测试：在为故事编写测试的时候，客户是最适合写验收测试的人，而对于实际情况因为客户参与度和技能问题，可行的方式是由客户、开发人员、测试人员共同参与编写验收测试，给故事拟出一系列测试。在编写测试用例时只关注完成故事必须要做的几件事情，形成简单清单，以后在具体实现故事或者验收测试时在细化测试，添加更多细节，讨论各部分如何工作，确定客户对界面是否有特别的要求等。根据功能的类型，对应的测试可以是一组顺序操作，或者是一组输入及对应的输出。另外在故事的实现过程中还难免会发现原有测试外的新的测试，合理的做法是，在征求客户意见后，我们应该把新的验收测试加入到清单中。

3、自动化测试：在完成验收测试编写后，就需要把验收测试转化成可执行的验收测试，这时候，团队常会引入一些相对成熟的测试框架及商业化自动化测试工具。这些框架和工具一般可化分为API级别功能测试（如采用Fit和FitNesse框架）和自动化GUI测试（如可采用关键字驱动框架和商业自动化工具等），团队可以根据开发的应用及团队自身情况选择使用其中一种或组合使用。API级别功能测试，使团队能够在不牵涉UI层的情况下测试业务逻辑。而自动化GUI测试在实际应用中，团队所采用的自动化测试框架（通常需要团队自行开发）针对GUI测试的成熟度尤其重要，良好框架可通过测试用例、界面对象、数据的分离，大大减少因为频繁的界面变化而对已有自动化脚本的影响。

4、实现故事：实现新功能，让新加入的验收测试通过。ATDD本身并不会限制实现功能的 方式，不过使用ATDD的人通常倾向与在实现过程中采用TDD方式。这样在代码层面，采用TDD方法以测试驱动的方式编写代码。在软件的特性和功能层面，使用ATDD方法以测试驱动的方式构建系统，这两个不同层面上结合使用测试驱动，既能保证软件的内部质量同时能保证开发出的软件能满足正确的功能需求。

1.7 结对编程-高航

1.7.1        前言：

在敏捷软件开发的各种实践中，结对编程（Pair Programming）是特别有争议的，尤其是在国内的软件企业或团队，几乎看不到有真正实践、施行，并带来效果的。相比于其他敏捷软件开发方法的火热及它们带来的成效，结对编程可以说备受冷落。它看上去很美，但想要成功的实践，可谓障碍重重。那么实用为王，我们是不是可以秉承结对编程优秀的核心理念和思想，而将它的实践框架加以改造，让它更适合我们的工作流程和习惯，最终成功实践并提升研发效率和质量呢？于是有了下面的一种变形的、可实践的结对编程方法。

1.7.2        传统结对编程定义及特性：

两位程序员形成结对小组，肩并肩地坐在同一台电脑前合作完成同一个设计、同一个算法、同一段代码或同一组测试。

结对编程可以看作是一种敏捷化的代码检查（Code Review），其最终目标是提高软件产品的质量。代码检查工作是公认的提高软件产品质量的重要活动之一，但在实践中，成功应用的也并不多见，原因是传统的代码检查方法只能在某个功能完全开发完毕后才进行检查，效率不高。而更大的问题是，检查人对被检查人的代码所实现的业务功能并不十分清楚，所以只能检查代码的格式、语法是否规范，对实现逻辑是否满足业务需求往往无法检查。这导致了很多企业和团队的代码检查都流于形式。

结对编程就解决了这一问题，它不需要代码都写完才开始检查，而是在两个人相互协作过程中，实时的进行多次交叉检查，大大提高了效率，而且因为两人同时完成设计和代码，对业务需求也都了解，所以检查时可以验证代码是否满足了需求、是否符合业务逻辑。

但是，传统的结对编程模式也有一些显而易见的问题导致其难以实践，例如人们担心两个用一台电脑做同样一件事情，是不是浪费了人力资源？两个人的个性、习惯、水平都不同，在对等的地位上同时做一件事情会不会产生冲突和矛盾？他们之间的沟通和协作会顺畅吗？会不会感到不自在？

1.7.3        新结对编程定义及特性：

两位程序员形成结对小组，每人一台电脑，坐在临近的工位上，两人合作完成一组功能（可以是两个或多个独立的模块）的设计、代码实现。但对于某一个模块来说设计和代码是分开的，一个人负责设计，另一个人负责写代码，对于其他模块则反之。当某个功能阶段性完成后，由其设计人员对代码进行检查。

目前，很多敏捷开发的倡导者们都在积极的寻找可实践的结对编程的变形体，以打破结对编程这种看上去很美，摸上去扎手的情况。而上述这种形式的新结对编程，也是我们几经探索总结出来的一种可实践的结对编程形式，并在产品团队中成功应用。它继承了结对编程的核心理念，让代码检查更加高效、深入。也在两人合作模式上，更适应实际工作情况和工作习惯，以做到真正的可实践、可应用。下面详细介绍这种新的结对编程内容。

1、角色与参与形式：在可实践的结对编程中，参与的人是开发人员，他们两个人形成一个小组，临近而坐，在具体的某个功能或任务上，两个人所扮演的角色是有承接关系的，一个是设计者、另一个是开发者，一个是审查者、另一个是被审查者。而在在总体上，两个人的关系又是平等的，因为设计与开发、审查与被审查对于两个人来说是相互的。这样就避免了一些结对小组中的两人在协同工作中会产生的冲突与矛盾。

2、主要活动与工作流程：这里我们举例来说，两个开发人员甲和乙，形成结对编程小组，共同负责两个功能A和B。工作开始，甲进行A的设计工作，并给出设计文档(关于设计文档的说明请见“题外话”)。乙进行B的设计工作，并给出设计文档。两人的设计工作完成后，互相阅读对方设计文档并进行交流，两人要保证对对方的设计内容了解清楚，并指出对方文档中描述不当的地方让其修改，最终保证设计内容是清晰明确的，而且甲、乙两人对A、B功能的设计都熟悉明确并思想一致。接下来开始代码开发工作，甲按照乙的设计文档开发功能B，乙按照甲的设计文档开发功能A。代码开发工作进行到某个段落后，甲对乙开发的功能A代码进行审查，检查代码格式和规范以及代码实现是否符合甲设计的业务逻辑，如有问题，则请乙进行修改并复查，乙同样反之对B进行审查，最终达到代码开发完毕，A、B两个功能都进行过多次审查和修改，而且甲、乙两人都确认两个代码是合格的，并符合业务需求的。这样，功能A、B的设计和代码实现就是有甲、乙共同协作完成的，两人共同对两个功能负责，并且两人对两个功能的设计和实现都清楚，更为重要的是甲、乙两人的工作是相互并行配合的，不会产生冲突，更为容易推广施行。

3、额外的好处：按照可实践的结对编程模式完成软件开发，不仅高效的完成了代码检查，提升了软件质量，还带来了一些额外的好处：1、每个模块至少两个人熟悉，这样在有人请假的时候都有backup，不会造成严重的耽误工作进度。如果有人要离职，交接工作通常也会非常轻松，几乎没有什么需要特别交接的。2、进行结对的两个开发人员相互阅读设计文档和代码实现，实际也是一个相互学习的过程，所以结对编程也起到了一些知识传播、培训的作用。

1.7.4        题外话：

关于敏捷开发中的设计文档，说一些题外话。敏捷开发与传统瀑布型开发一个很重要的区别就是：在研发活动中各环节的流转的承接时，瀑布型开发是以文档为主，思想的交流与沟通为辅。而敏捷开发是以思想的交流与沟通为主，文档为辅。所以在瀑布型开发中，对设计文档的格式和规范等要求比较高。而敏捷开发中的设计文档，只是要描述清楚设计思想，并作为一个辅助手段，将关键内容存留作为依据即可，不需要规范的模板。可以根据设计者的习惯，以最高效的形式描述清楚设计内容，并且清晰明确即可。在结对编程的实践中，所涉及到的设计文档的书写，都是以此种方式进行的。

1.8 确定冲刺计划-袁斌、钱岭

两位专家请将这部分整理成为一个最佳实践： 敏捷规划，如何， 多谢！ - DJ

袁斌：

“确定冲刺计划”的初稿：

冲刺会议的目的：Scrum团队和产品负责人（Product Owner）共同决定在接下来的冲刺周期内的目标以及哪些功能和任务需要完成。

冲刺会议参加的最主要角色：Scrum团队，产品负责人以及Scrum Master

冲刺会议的主要输入工件：Product Backlog、团队的能力

冲刺会议的主要输出工件：Sprint Backlog

冲刺会议的主要流程说明：冲刺会议最主要的参加人员是Scrum团队，产品负责人以及Scrum Master，同时感兴趣的管理层或者客户代表也可以参加。整个冲刺会议分为两个部分：第一部分解决本次冲刺要完成哪些需求；第二部分解决这些选择的需求如何被完成。在第一部分的冲刺会议中，产品负责人向团队描述最高优先级的一些功能，团队成员详细询问功能涉及的各个细节，并决定哪些功能可以从Product Backlog放入在Sprint Backlog中完成。产品负责人和团队共同定义本次冲刺的目标，并最终在冲刺结束的评审会议中以冲刺目标是否被完成作为本次冲刺是否成功的标准。在第二部分的冲刺会议中，Scrum团队集体讨论放入本次冲刺的需求如何实现，并决定最终有多少需求可以承诺在本次冲刺内完成。

钱岭：

1 作为项目经理，我想用敏捷开发方法管理项目，以便能够快速推进项目并快速反馈

采用敏捷方法对项目进行管理并非是那种拍脑袋、不严肃的粗放式项目管理，而是需要像传统方法一样严谨的步骤，也需要包括确定工作目标、工作分解、估算、跟踪和反思等多个步骤。但是和传统方式那种大而全、重流程、重模板的工作方式有很大差别：敏捷方法更注重目标和效率；更注重发挥团队每个人的主动性。

1.1 制定敏捷研发计划

制定敏捷研发计划是敏捷开发项目的开始，通常包括三个层次的计划：

·产品计划。整个产品研发的计划，范围最大，也最不精确，定义阶段目标比定义时间计划更为重要。

·发布计划。每个交付周期的研发计划，通常根据用户需求设定子集，满足用户阶段性需求。和产品计划一样，发布计划也更重视需求，每个发布计划包括若干迭代。

·迭代计划。每个迭代是最为原子化的计划，在SCRUM方法中这被称为冲刺（Sprint）。迭代计划通常时间周期较短，一般为1~4周，这样的时间周期是一种较为可控的项目周期，具有较好的可控性和准确性。

综上，一个敏捷项目计划最终表现为多轮次迭代计划，根据项目类型的不同，迭代数量也是不一样的，通常新立项目比维护型项目的迭代数量更多；通用产品型项目比定制化项目迭代数量更多。

一般的，第一个迭代通常会完成需求分析和架构设计；第二个迭代通常会完成关键技术验证和架构修订；此后的迭代完成设计、研发和测试等工程性工作；最后一个迭代通常是项目验收和总结。

1.1.1 确定工作目标

迭代开始前，首先需要确定工作目标。工作目标源自用户需求和工程性要求。在SCRUM方法中，通常用Backlog来描述每个迭代的工作需求。

1.1.2 工作分解

对于软件产品研发来说，产品模块分解是一个必要的步骤，通常会根据用户实际需求制订的系统架构将整个产品划分为多个模块，直到易于被一个迭代覆盖，每个模块通过接口连接。传统的方法，如WBS依然是可以使用的。

根据依赖性和优先级，任务被分配给迭代。和传统模式不同，敏捷开发不需要一下子将所有任务都分配好，而是逐步分配和研发的。

1.1.3 估算

项目经理需要对每个迭代的工作量进行估算，方法很多，但是通常会给予历史数据和经验（能力强团队会采用客观而量化的估算），估算工作量最重要的部分还是团队成员的参与和讨论。集思广益和民主是成功估算的保证。

1.2 计划执行和跟踪

敏捷开发中，计划的执行和跟踪依然是项目管理中最为重要的环节，但是跟踪的粒度更细，也更靠近具体问题，而不是强调主观感受或者风险管理。

1.2.1 Kickoff

在迭代计划完成后，需要启动本轮研发。项目经理（或者相应负责人）需要当众正式宣布迭代启动，明确工作目标、分工和本轮迭代的负责人等信息。

1.2.2 每日工作状态跟踪

在敏捷开发中，由于每个迭代的时间周期已经很短，因此必须保证每个迭代的每一天都不会出现问题。SCRUM方法中，每天均会有一个15分钟的短会（Daily Scrum Standup Meeting），其中会交流当天的工作情况和遇到的问题。通常由轮值的SCRUM Master主持，这样便于让每个人均活跃地参与项目管理。

一旦出现进度滞后或者高风险事件，均需要有Master协调解决。其中不可忽视的是那些个人因素引发的问题。

1.2.3 沟通和协调

敏捷开发强调的是顺畅的沟通，一般需要同地开发，用户代表最好也在场参与需求讨论。团队的每个成员均需要自觉遵守团队文化，能够认识到个人能力的差异并互相尊重。

项目经理、迭代主管（例如Scrum Master）需尤其善于协调各种人际关系。

1.2.4 问题解决

在传统方法中，项目例会能够发现很多问题，并采用类似表格方式记录各种问题，项目经理跟踪这些问题并使其结束（Close）。在敏捷开发中，问题跟踪依然是必须的实践。但是形式可以更为灵活，比如采用小贴纸记录这些问题并粘贴在黑板上来进行跟踪。

为了确保问题被解决，必须有人来验证，一般并不建议由问题承担人验证问题，Scrum Master是一个合适的角色。在互信建立起来之后，也可以将一些重要性较低的问题交由问题承担人解决。

效率始终是敏捷开发最为关注的地方。

1.3 反思

每个迭代完成后，均需要花费一些时间来总结本次迭代。主要包括项目状态小结、测量数据收集、问题根源分析。成熟度高的敏捷开发还可以进一步进行成本收益分析、估算优化等实践工作。

项目反思不需要指名道姓地将过失落实到人，但是必须以某种方式提醒出现过失的成员。