敏捷管理是软件项目应用中常见的管理方法，今天基于概念和实践讲讲敏捷管理。

---

一、敏捷的起源

先不解释敏捷的基础理论，我们从一些易懂的背景展开：通过查阅资料，我并没有找到“敏捷” 的明确来源，许多出处说法不一，比较靠谱的说法是上世纪90年代的“软件危机”的诞生，进而引发的2001年敏捷宣言的发表。发展至今，敏捷最常见的应用场景仍是软件工程。

我们来看看原因，软件开发过程中通常有3个现象：开发周期紧张；范围不可控；需求变动频繁。然而传统的瀑布式开发显然不适应目前多变的开发流程，我们需要采取更加高效的开发方法，以确保团队能发挥最大综效。以上根本原因在于软件项目的需求、技术以及人力等不可控因素对着技术日益更新也逐渐趋于复杂，所以解决“软件危机”的关键在于克服软件固有的复杂性问题。

那么对于复杂性问题我们该如何解决？最可行的就是进行经验性过程控制，对目前可见的工作进行拆解，在小范围内计划并监控。简单来说，就是通过缩短生产周期适应变化，在过程中持续改进，从而达到既定的目标。最典型的例子就是说丰田的“精益生产”（Just In Time），该思想的核心有几点：追求零库存；快速反应；企业内外环境和谐统一；以人为本。

显然，由于所处时代互联网产品的复杂性，需求往往取决于日新月异的行业及技术发展，没有任何一个人能够准确预见这种不确定性，敏捷也因此大多应用于互联网软件项目中。

需要注意的是，敏捷（Agile）是一个方法论，可以应用于多种场景，比如项目管理、开发管理、工作管理，甚至自我管理都可以。

二、 敏捷基础概念

为便于更的理解，引用一些敏捷相关的基本概念：

1. 敏捷宣言

（1） 个体与互动高于流程和工具

• 人是软件项目获得成功最为重要的因素
• 合作、沟通及交付能力比淡出的软件编程能力和工具更为重要
• 方法和工具是死的，人是活的，最重要的是协作

（2） 工作的软件高于详尽的文档

• 过多的面面俱到的文档往往比过少的文档更糟
• 软件开发的主要和中心活动是创建可工作的软件
• 直到迫切需要并且意义重大时，才进行文档编制
• 编制的内部文档应尽量短小并且主题突出

（3） 客户合作高于合同谈判

• 客户不可能做到一次性地将他们的需求完整清晰的表述在合同中
• 为开发团队和客户的系统工作方式提供指导的合同才是最好的合同

（4） 响应变化高于遵循计划

• 变化是软件开发中存在的现实
• 计划必须有足够的灵活性与可塑性
• 短期的迭代计划比长期计划更有效

2. 敏捷开发的12个原则

• 我们最优先考虑的是尽早和持续不断地交付有价值的软件，从而使客户满意
• 即使在开发后期也欢迎需求变更。敏捷过程利用变更可以为客户创造竞争优势
• 采用较短的项目周期（从几周到几个月），不断地交付可工作软件
• 业务人员和开发人员必须在整个项目期间每天一起工作
• 围绕富有进取心的个体而创建项目。为他们提供所需的环境和支持，信任他们所开展的工作
• 不论团队内外，传递信息效果最好且效率最高的方式就是面对面交谈
• 可工作软件是度量进度的首要指标
• 敏捷过程倡导可持续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐
• 坚持不懈地追求技术卓越和良好的设计，从而增强敏捷能力
• 以简洁为本，最大限度地减少工作量
• 最好的架构、需求和设计出自于自组织团队
• 团队定期地反思如何能提高成效，并相应地协调和调整自身的行为

3. 敏捷的方法

• XP（极限编程）
• SCRUM
• Crystal Methods（水晶方法）
• FDD （Feature-Driven Development，特性驱动开发）
• ASD（Adaptive Software Development，自适应软件开发）
• DSDM（动态系统开发方法）
• 轻量型RUP

4. Scrum价值观：专注、公开、承诺、勇气、尊重

5. 软件开发模式对比

（1） 传统的瀑布式开发

从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。特别是前期阶段，设计的越完美，提交后的成本损失就越少

（2） 迭代式开发

不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善

（3） 螺旋开发

很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估

（4） 敏捷开发

相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性

三、 敏捷管理理论

1. 敏捷管理与其他理论的差异和结合

上面提到软件的不同开发模式，敏捷方法最常与瀑布模型做对比。瀑布模型一般适用于需求固定且范围明确的项目，但实际项目并非如此完美；而敏捷方法能够更好的适用多变的情况，其核心思想是“以人为本，拥抱变化”。

当敏捷用于项目管理时，与传统项目管理差别同样如此，它并不是期初就对整个项目进行详尽的评估和计划，而是先粗略地估算，以周或月为短周期进行版本内的详细计划，较传统项目管理更强调发挥人的主观能动性。

另外，敏捷方法其实是能够与CMMI更好地结合去使用的，敏捷主要是为解决人之间的问题，而CMMI侧重于流程并能够解决大多数管理问题，从而更好的控制项目风险。

2. Scrum

上述提到的敏捷管理方法，我们常用的方法是Scrum，但实际中也会结合XP来使用，Scrum相对于XP来说只是提供了方法论，但XP还提供了具体的实践工具，比如测试驱动开发等。

Scrum开发的核心是增量+迭代，开发者提倡在此过程中增量迭代，对用户需求作出快速响应，以此来提升交付满意度，我们通常做法是把可见需求拆解为更小的需求作为一个迭代周期，在进入迭代前可以允许变化，迭代周期内不再允许变更。以此来做持续改善，并不断迭代新的功能。

在这里解释几个名词，每个小迭代周期称之为Sprint，项目过程中将使用Product Backlog管理需求，并以用户故事的形式分配于每个Sprint中形成Sprint Backlog，按照优先级进行任务排序。每个Sprint后，团队需按照迭代计划交付产品增量。

3. 敏捷方法的应用

（1） 测试驱动开发

（2） 增量迭代

（3） 持续集成

（4） 每日站会

（5） 用户故事

（6） 重构

（7） 结对编程

这里简单解释几个易懂的，测试驱动开发在项目中一般是指项目开始时，测试就与开发同步进行工作，通过测试用例事先指导开发，通过测试代码确保开发工作在可控范围内，但这种方法应用有一定的难度。

另外，增量迭代有在上文中提到，每个迭代周期为一个冲刺（Sprint），一般周期为一个月以内。

四、 敏捷项目管理实践

1. 团队角色

包括项目经理（Scrum Master）、产品负责人（Product Owner）、开发、测试、UI、DBA等。

• 项目经理负责整体项目把控与管理，及时协调团队资源并推动解决问题；
• 产品经理则对产品质量负责，定义Backlog并确认每个Sprint中的分配，制定用户故事及任务优先级，确认版本发布时间；
• 其他角色如开发、测试等成员，一般存在跨部门协作，需要自发组织性，在Sprint内尽量保证团队成员的稳定性

2. 应用工具

（1） Product Backlog

Product Backlog用于列示产品需求，以用户故事的形式展现。每个用户故事有对应的故事点，代表完成该故事所有工作的估算工作量；需要产品负责人在每个Sprint开始之前产出。

（2） Sprint Backlog

Sprint Backlog是每个迭代周期内的任务，一般是用户故事的细分，评估可精确到工时，需要排列每个任务的优先级；需要项目经理评估工时，产品负责人排列对应的任务优先级，在Sprint开始之前产出

（3） Burndown Chart

燃尽图，用于展示剩余工作量的工作图表。需要项目经理在Sprint复盘之前产出。

借用百度图片，横轴代表时间，纵轴代表工作量，蓝色线展示的是理想状态，黄色是实际状态，可直观的展示工作整体完成情况。

3. 会议

（1） Sprint 计划会议

Sprint开始前，由产品负责人组织，会议前需梳理完成Product Backlog，确认本次Sprint的目标，创建Sprint Backlog并做优先级及任务估算

（2） Sprint评审会议

Sprint内后期，由产品负责人组织团队并邀请干系人参加，通过现场演示展示Sprint内完成的产品功能

（3） Sprint回顾会议

Sprint结束时，项目经理组织团队及干系人参与，复盘本Sprint内团队工作的情况并进行总结，20分钟即可

（4） 每日站会

每日固定时间的例会，由项目经理组织，一般为每天早晨上班前15-20分钟，团队成员轮流说明自己昨天任务完成情况、今日计划任务、目前的阻碍。

需要注意在每日例会上，只陈述事实，不做讨论，以免浪费不别要的时间，项目经理可根据成员遇到的问题指派对接人私下讨论解决，但也仅侧重于安排。

4. 管理流程

借用百度图片

五、 应用中的误区

1. 敏捷是管理项目的最佳方法：

敏捷只是一种方法，也不是万能的，不能完全按照理论来做，需要灵活运用。比如敏捷强调人的主观能动性，每个人可以自己选择任务，但现实中该方法不可取。另外，敏捷管理往往很少有企业完全实践，主要还是该方法对环境的要求较高。

2. 敏捷不需要计划：

敏捷只需要在Sprint内制定计划，无需超前制定详尽的计划，因为多变的需求往往会偏离实际计划，该种计划也毫无意义

3. 敏捷不需要文档：

敏捷只是管理上的敏捷，并非降低质量的敏捷，需要根据需要产出对应文档，包括用户故事、PRD、验收报告、操作手册、测试用例、测试报告、部署手册、软件版本说明等

4. 敏捷一定要面对面：

不一定是传统意义上的面对面，比如视频、即时通讯都可以，强调的是沟通上的即时性

5. 敏捷的需求可以随意变更：

在Sprint内不允许做变更，可为下一个Sprint制定对应的计划

6. 敏捷可以使项目做到“快”与“省”：

敏捷管理不一定可以缩短整体开发周期，更不一定省钱，其中往往存在重复的开发、测试、部署等工作。

六、 其他注意事项

1. 敏捷最难的仍然是对人的管理，需要团队中每个人都有主观的自我管理意识，每个人都要保持积极进行协作沟通，显然该方法很适合互联网研发项目

2. 对于人员流动率大的公司，该方法很难发挥真正的成效，至少要保证每个Sprint内成员不能有变化

3. 每个小迭代周期不一定要时间一致，可以适当做调整，敏捷方法重在实践

4. 在实际工作中，敏捷管理方法和其他项目管理方法结合使用效果更佳