从瀑布转型敏捷项目管理的5大注意事项

事实证明,瀑布开发管理模式并不适合所有的软件项目,但敏捷项目管理却对大多数项目有效。那么当团队选择转型敏捷的时候有哪些因素必须注意?

敏捷开发最早使用者大多是小型、独立的团队,他们通常致力于小型、独立的项目。正是他们的成功经验,让世界各地的软件团队认为敏捷开发是可行的,且对自身也有改善意义。事实证明,瀑布开发管理模式并不适合所有的软件项目,但敏捷项目管理却对大多数项目有效。

也正因此,敏捷项目管理被越来越多的团队所采用,并且从单个团队扩展到多团队,甚至是软件团队之外,包括 IT、营销、业务开发等。

一、敏捷开发与瀑布开发的区别

1、什么是敏捷项目管理

敏捷项目管理是一种迭代式的项目交付方法,它通过高频迭代的方式,将项目分解为多个尺寸较小的“小项目”,每部分能够在远比瀑布模式短得多的周期内,快速而独立地走完计划、设计、构建、测试、发布的过程。所以每次发布后都能够根据市场/客户反馈调整,从而提升了速度和适应性。

这种方法与“预设性的”瀑布式项目管理方法不同,瀑布式项目管理遵循既定的路径,对市场变化响应及适应能力有限。当下的客户和企业需要快速响应以及调整,而敏捷提供了在开发过程中进行调整和迭代的灵活性。同时,敏捷项目管理也是 DevOps 实践的基石,开发和运营团队在该方式下协同工作。

敏捷原则:

  • 敏捷项目分为几个增量步骤,并在每个增量的隔间收集反馈进行调整
  • 项目需求拆解到足够小,然后按重要性排列它们的优先级
  • 注重建立与客户之间的联系,团队之间的协作
  • 定期调整以确保满足客户的需求
  • 将计划与执行相结合,使团队能够有效地响应不断变化的需求  

敏捷项目管理的优势:

  • 更好的可见性和责任制
  • 及早发现问题
  • 更高的客户满意度
  • 更短的反馈周期
  • 更快响应市场变化
  • 持续提升团队效率
  • 价值导向的灵活优先级排序

敏捷项目管理的缺点:

  • 关键路径和项目间依赖关系不如瀑布项目中清晰
  • 组织适应敏捷需要考虑学习成本
  • 真正的敏捷执行CI/CD,实现起来存在工程和技术成本

2、什么是瀑布项目管理?

瀑布式项目管理是一种预设性的软件开发模式,它将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六项基本活动;且规定了它们自上而下、相互衔接的固定次序,项目必须严格遵循预先计划的顺序进行。开发进程只有通过上一个阶段的验收审核,才能“流动”到下一个阶段。一旦一个阶段完成了,想再去“回头”调整前一个阶段就会很困难,且成本很高。敏捷项目管理虽然也遵循类似的顺序,但会以较小的增量和定期的反馈循环进行工作。

所以,瀑布项目管理方式对那些可预测的、重复性的工作很有效,而对于那些快速变化的工作,它可能会让开发团队落后于竞争对手以及市场。

瀑布项目在进行中如果延期或发生需求变更,就会对后续版本造成巨大影响。此外,瀑布项目中通常会让团队完全专注于下一阶段的工作,直到完成之前都是在开发全新的东西,那么这就会积累非常多的技术债务、缺陷,让解决过程变得非常痛苦。

下面是一个标准瀑布项目的示意图,它具有严格的时间阶段划分,这就使开发人员、产品经理和其他相关人员患得患失的,每个人都希望在自己的时间窗口中申请更多的时间,因为将来可能没有机会迭代。通常,瀑布团队会通过“变更控制”来控制范围蔓延,即维持原计划。

image.png

瀑布模型会加剧构建产品的一些已知挑战:

  • 项目阻碍因素和依赖性的管理:传统的项目管理方式往往会有固定的流程,在彻底解决某个阻碍问题之前,项目是无法向前推进的。
  • 难以获得用户反馈,对产品进行验证:在产品完全完成之前,客户无法体验和反馈,因此,产品设计和代码中的重要问题在发布前都不会被发现。

瀑布开发模式的优点:

  • 每个阶段都有各自的角色和明确分工,所以一定程度会减少过程中的协调;
  • 明确的项目阶段有助于明确界定工作之间的依赖关系;
  • 在确定了需求后,可以对项目的成本进行估算
  • 有清晰的设计和需求文档,设计阶段更加有条不紊和结构化;

瀑布法的缺点:

  • 需求隔离:由于各阶段的人员只能接触到自己工作范围内的东西,所以对客户需求的理解程度高低不等,开发人员更像是定义为流水线上的工人。
  • 变更代价大:需求变更会带来极大的时间浪费,开发人员普遍对需求变更有很强的抵触情绪。
  • 束缚创造性:由于强调文档管理,所以管理人员会比较喜欢,但是他束缚了开发人员的创造性。
  • 周期漫长:整个开发持续的生命周期很长,需求和设计的耗时很大,有时候会占用三分之一甚至更多时间
  • 招聘需求:满足不同阶段的专业人员意味着更多招聘岗位需求,而敏捷则提倡跨职能团队。
image.png

二、转型敏捷时要考虑的因素

敏捷转型并不容易,特别是当团队或组织长期使用传统项目管理方法的情况下,因为这将涉及观念、思维方式转变、流程的更改以及不一样的团队协作方式等。

比如,在转型的过程中,团队和利益相关者必须接受两个重要概念:

  • 产品负责人的工作核心是优化团队输出的价值,而团队则是围绕产品负责人制定的工作优先级开展工作;
  • 开发团队只负责他们有能力完成的工作,通常情况下产品负责人不会强制给团队指定工作;开发团队成员从迭代待办列表中领取工作任务,因为这样他们可以尝试新的任务类型。

下面我们将简单介绍,引入敏捷项目管理在组织、运行和工作流程方面必须关注的一些要素。

1、产品路线图

产品路线图是产品需求与其完成时间的概览,宏观的展示了产品的发展方向以及开发团队何时实现目标。路线图为敏捷开发提供了重要的背景信息,能够帮助团队了解以及实现增量和整个项目的目标。

有效的路线图不仅是一个强调产品发布和功能的时间表:它是一个动态的文档,产品负责人会在项目进行过程中根据实际情况不断更新,所以在创建产品路线图的初期,对需求、工作量、优先级、完成时间的估算不要求也无法很精确,这些内容都是随着项目进行不断细化调整的。产品路线图是产品负责人推动项目发展的重要工具,它告诉我们每个阶段应该做什么。

以下是产品团队的简单路线图,方框中包含大的发布计划,红色里程碑标记表示时间表。 

image.png

2、需求

路线图中的每个大的发布计划都可以分解为一系列的需求,敏捷开发中的需求指的是“轻量级”描述,而不是与瀑布项目管理中那样多达100 页的“详尽”文档。这是因为敏捷开发中的需求会随着时间的推移,团队会根据对客户和所需产品的共同理解而不断完善。

敏捷开发同时也是符合“精益”的一种方法,它要求团队中的每个人通过持续的沟通和协作达成共识,以这种方式在最终呈现完整的细节。

3、待办事项

敏捷开发中的待办事项一定是划分了优先级的。在待办事项列表中包括所有的工作项目,比如:新功能、bug、技术需求或架构任务等。产品负责人为开发团队确定待办事项的优先次序,然后,开发团队以此作为唯一的参考,确定需要完成的工作。

4、敏捷指标

敏捷团队的持续改进离不开度量指标。比如,看板方法下的在制品限制使团队专注于交付最优先的工作。燃尽图等图表有助于团队预测他们的交付节奏,而连续流程图有助于识别瓶颈。这些指标和工件使每个人都专注于目标,同时也增强了团队交付未来工作能力的信心。 

5、敏捷以信任为基础

团队成员之间如果没有高度的信任,敏捷流程就很难运作。公开的流程和正确的产品目标、关于产品开展平等定期的对话,都有助于提升团队的积极性和信心。

小结

敏捷项目管理是一种创新方法,不仅适用于软件项目,而且适用于各种项目。通过提供在开发生命周期中响应变化的灵活性,团队能够交付满足客户需求且更高质量的产品。敏捷赋予团队权力,建立责任感,鼓励创新,同时促进持续改进。敏捷使您能够在不偏离轨道的情况下响应变化,这对任何工作都是有益的。

本文是否对你有用?

内容导航