敏捷管理方法论

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


一、敏捷的起源

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

上一篇:09-去掉盒子滚动条但是还能滚动


下一篇:Acwing第789题(数的范围)