敏捷管理方法论

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

一、敏捷的起源

先不解释敏捷的基础理论，我们从一些易懂的背景展开：通过查阅资料，我并没有找到“敏捷” 的明确来源，许多出处说法不一，比较靠谱的说法是上世纪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. 在实际工作中，敏捷管理方法和其他项目管理方法结合使用效果更佳

来源：廖俊才