产品开发方法学习笔记(4)——敏捷开发法

2023-04-16  本文已影响0人  Leung_ManWah

一、简介

敏捷开发(Agile Development)是一种以人为核心,通过迭代完善、循序渐进快速交付的开发方法。敏捷开发从1990年代开始逐渐引起广泛关注,相对于“非敏捷”,更强调开发团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重人在软件开发中的作用。

敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

敏捷开发借助互联网浪潮开始流行起来,相比瀑布模式,敏捷无疑更加贴近互联网时代背景下快速发展变化的市场环境以及业务需求。

1.1 敏捷的定义

《敏捷宣言》创始人之一的Jim Highsmith曾经这样描述“敏捷”:

敏捷是制造并响应变化,从而在动荡的商业环境中创造利润的能力。

敏捷是平衡灵活性和稳定性的能力。

从Jim Highsmith对敏捷的描述中可以看出,变化孕育着创新,而创新则需要一定的灵活性来保证。但敏捷绝不意味着要牺牲质量和秩序来换取速度,敏捷≠仓促,它是追求既快又好的一种思维和方法。

1.2 敏捷开发模型

敏捷开发模型是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。

1.3 敏捷宣言四大价值观

2001年2月,Martin Fowler,Jim Highsmith等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪胜地,举行了一次敏捷方法发起者和实践者的聚会。在这次会议上,他们正式提出了敏捷(Agile)这个概念,并共同签署了敏捷宣言,包含四大价值观

敏捷宣言价值观

  • 个体和互动胜过流程和工具
  • 工作的软件胜过详尽的文档
  • 客户合作胜过合同谈判
  • 响应变化胜过遵循计划

也就是说,尽管右项有一定的价值,我们更重视左项的价值。 右项的状态和瀑布模型的理念相一致,而敏捷就是为了改变这些理念而提出了全新的敏捷思想。

1.4 敏捷的十二条原则

十二条基本原则按照三个思想层次记忆:

价值驱动

以人为本

协作迭代

1.5 敏捷实践方法

在《敏捷宣言》和原则的思维模式和价值观下,随着各行各业的快速发展,敏捷开发方法也随之发生了演变,直到现在,我们所熟知的敏捷开发方法可以粗略的统计出九个流派,每个流派都在不同的行业领域发挥着不可替代的作用,它们是:Srcum、XP、水晶、DSDM、FDD、AUP、精益、看板以及OpenUP。下图是项目管理协会(PMI)《敏捷实践指南》中罗列的部分常见方法,我们平时最常用的是 Scrum 管理方法:

二、敏捷的特点和逻辑

2.1 敏捷的特点

敏捷方法的整体性

敏捷方法从诞生之日起,就已经通过《敏捷宣言》和原则等高度精炼的文字阐释了其精髓,在这里,我们尝试用过程模型将提炼后的12项原则组合为一个整体:

可以看出敏捷方法充分考虑了开发过程中的各种要素,但聚焦于通过迭代交付的方式解决需求变化的业务场景,并强调了客户参与这一要点。

自组织团队和以人为本

自组织团队和以人为本是敏捷方法的另一大特点,也是敏捷项目管理的核心。敏捷原则5和原则11描述的就是这两方面。

自组织的团队不是没有领导的团队,而是一种团队的领导方式。

自组织团队具有自主权,要自我选择如何最好地完成工作。自组织团队结合了自由与责任,面对不确定与各种矛盾,要始终坚持实现交付目标。

在自组织团队中,团队成员需要具有自律性,个人负责管理自己的工作量,对于如何“交付结果”,团队成员保有较大的灵活性,但他们要对结果负责,并在制定的灵活框架内工作。

根本上讲,敏捷方法关注人以及人和人之间的相互交流,通过营造一种环境,让个人能力充分释放,从而创造出优秀的产品。要注意到,最终创造优秀产品的是人,而不是流程或方法。

  1. 更快交付价值
  2. 更低的风险
  3. 拥抱变化
  4. 更好的质量
  5. 持续改进
  6. 更高的客户满意度
  7. 更高的团队满意度
  1. 很难进行准确的资源规划
  2. 很难准确的定义“轻量的“或必要的文档
  3. 很难把握整体产品的一致性
  4. 很难预测有限的终点
  5. 很难有效地进行度量

对于时间期限紧张,高难度、高度新颖性(独特性)的项目,建议可以采用敏捷管理的方式。

新的产品、问题和之前未做过的工作都具有探索性,它要求不同领域的专家协作来解决问题。这类不确定的问题变化速度快,复杂性和风险也高,并不适合用传统的计划型方法来应对。在这种场景下,可以考虑应用敏捷的方法。

敏捷方法始于软件行业,但敏捷思想的应用并不需要局限于此。凡是需求不明确或频繁变化、需要客户更多参与的场景,都是敏捷方法的用武之地。

《敏捷实践指南》中提供了一种敏捷适用性筛选工具,可以帮助大家来评估自己的业务是否适合采用敏捷方法。

2.2 敏捷背后的逻辑

在敏捷方法的认识过程中,我们可以体会到两种思维方式:

不同的思维方式会产生不同的行为,小到一个产品,大到世界观,思维方式对人类的影响是非常深刻的。

但我们在此只是在探讨产品开发的方法,搞清楚什么场景下采用哪种思维方式,进而创造或选用适合的方法,开发出客户所期待的产品,才是我们所追求的目标。罗伯特·G.库珀在2016年提出了敏捷门径混合(Agile-Stage-Gate Hybrid)模型,这种将两种产品开发思维方式结合的尝试,给我们很好的启示。

三、Scrum方法(迭代式增量软件开发过程)

3.1 Scrum的由来

Scrum一词来自于橄榄球运动中的“带球过人”。在橄榄球比赛中,攻守双方每次在各自的冲刺前,都会制定一个明确的攻守计划,这个计划仅适用于每一次的冲刺,而每次的冲刺都非常简短,可能是一次传球、可能是一冲撞,还有可能是一次冲刺或得分,因此在制定计划时,团队只明确本次冲刺的目标是什么,具体的技战术细节则有每位运动员自行决定,这也依赖于运动员本身的经验和基本素质。

3.2 Scrum的生命周期

Scrum相比瀑布模型,与之不同的是,Scrum并不是将开发过程划分为需求、设计、编码、测试、运维等线性阶段,而是采用了一种迭代式的、增量的开发过程。Scrum开发过程包含很多关键元素,每次迭代都包含跨不同阶段的跨职能团队:

3.2.1 迭代式开发生命周期

听说过敏捷的同学一定都听说过迭代这个东西。有的人说我们要迭代一个版本,有的人说我们要在这个迭代周期内完成什么,不管它指的是具体的软件版本,还是一段时间,这两字的含义其实都是一样的,那就是在整个项目开发过程中,切分出来的一个一个的小时间段。这一个时间段就是一次迭代。通过一次次的迭代,让整个项目更加清晰。最出名的针对迭代的概念的图示就是这个图。

迭代就是不断丰富细节的过程。每一次的迭代,我们都应该让这个项目更加的清晰明了,细节也一步步地完善。

3.2.2 增量式开发生命周期

迭代和增量是所有敏捷教程都会说的东西,因为这两个东西很多人容易搞混。增量实际上是不断的添加待开始项目的产品的模块功能。就像搭积木一样地将不同的模板拼成一个完整的产品。同样地,也有一张图是专门针对增量这个概念的。

迭代的时候,有轮廓,不断完善细节。而增量,没有整体轮廓,上来就是细节完整的一个部分,不断地一部分一部分地完成,最终形成一个完整的产品。

3.2.3 混合式开发生命周期

将上面的迭代和增量合起来,也就是在一次迭代中同时包含着增量,这样的形式就是混合式的生命周期 。这种情况下可以很好地运用这两种开发形式的优点。其实,我们目前大部分公司中的迭代冲刺都是这种混合式的生命周期的开发形式。在每次迭代中,我们添加的新功能模块其实就是在整个项目的轮廓中不断添加完善细节。

此外,在混合的时候,每次迭代也可以看做是一次传统的开发过程,总之,混合就是各种混合,吸收各家优势。

3.3 Scrum的核心要素

3.3.1 三个工件及作用

3.3.2 五个相关事件及具体内容

3.3.3 三个相关角色及角色职责


• 由 Leung 写于 2023 年 4 月 17 日

• 参考:NPDP学习心得系列三十四:新产品开发流程——敏捷中的Scrum方法(二)
    常见开发模型-敏捷开发与瀑布开发模型详解
    产品攻略系列:敏捷开发方法解读
    《敏捷项目管理-创造创新产品》

上一篇下一篇

猜你喜欢

热点阅读