敏捷开发在软件工程中流行起来的原因

陈煜
  • 56

如题。为什么敏捷开发现在如此流行?而瀑布模型、迭代模型、增量模型等现在基本不见。

回复
阅读 2.8k
2 个回答

轻管理 可以应对变化~
让大家都是项目的一份子
充分沟通
太多了~

在当今竞争激烈的商业环境中,软件开发越来越受到客户和企业重点需求的驱动,客户和企业都需要快速响应他们的问题和关注。反馈必须立即纳入产品,工程团队必须能及时交付竞争对手所在的客户正在寻找的确切产品。

首先,敏捷开发是一种过程控制论,通俗的说,就是一种做事情的方法。

  • 它适用于软件,因为软件是软的,可以改。要是硬件,改起来就没那么方便了;

  • 它适用于客户不知道自己要啥的情况,其实,这样的客户占绝大多数。因为客户不知道要啥,所以你需要不断帮客户弄明白他到底想要啥。换句话说,你需要和客户沟通,合作,倾听反馈,持续改进;

  • 它适用于竞争激烈的市场,这样的情况下,赶在竞争对手前交付一个不完美但至少能用的产品非常重要;

  • 它适用于快速变化的市场,你在埋头造一辆汽车的时候,客户已经想开飞机满天飞了,这就需要你能一步步的把汽车改成飞机,还能按时交付;

  • 它适用于在一个地方办公的小团队,一般10个人以内。这样能使敏捷中主要的沟通方式“Face to Face” 是可行的;

其次,敏捷开发是一套工具集,里面有形形色色的工具,你可以用来提高工作效率。
再其次,敏捷开发是一种企业管理方式。比如:

一线员工可以同时是架构师,Scrum Master,开发工程师,测试工程师,发挥了他的主观能动性,有利于创新和效率;

  • 敏捷不专注于敏捷团队中个人的绩效考核,而更多的侧重于整个团队的绩效,更好的避免了KPI驱动模式;

  • 把大项目拆分成小项目去做(每个Sprint都是一个迭代,需要输出一个高质量的版本,相当于完成一个小项目),把bug的生存期控制在一个迭代以内,降低了风险,也减少了后期改bug的工作量;

  • 把数十人的大team 分成几个敏捷团队,这几个敏捷团队的Scrum Master/PO再组成一个更高一级的敏捷团队,利用站会,反思,看板等等敏捷元素,可以避免数十份邮件也不能解决一个小问题,大家互相踢皮球,沟通不畅的大企业病;

  • 老板可以是最大的PO,他给下面的高管讲idea(User Story),定期检查Demo,把控产品用户体验,负责和外界的沟通合作。

多数软件开发仍然是一个显得混乱的活动,即典型的“边写边改” (code and fix)。设计过程充斥着短期的,即时的决定,而无完整的规划。敏捷方法很好的拥抱变化和进度可视,通过短周期迭代,尽可能早的交付可用的迭代版本来拥抱和适应变化。

敏捷开发实践稳步上升,成为各地软件团队信任和首选的开发方式。使用敏捷,组织可以更快地响应市场变化,提供更高质量的软件,并获得显着的竞争优势。

敏捷思想不仅仅适用于软件行业,它的很多方法和理念都可以被其他行业所借鉴。敏捷项目管理是未来的大方向。

瀑布软件开发方法
瀑布是以顺序开发模式为基础的,因此设计步骤必须以瀑布式的风格完成。这是一个公司需要遵循的八个不同阶段的计划:

  • 想法

  • 介绍

  • 分析

  • 设计

  • 发展

  • 测试

  • 执行

  • 维护

开发人员逐一访问每一步,不能直接转到任意一个阶段。一旦完成第一步,开发人员只能移动到第二个步骤,如果在上一步中出现错误,那么开发人员不能移回去修复它。如果他这样做,那么整个项目都要被划伤,开发人员将不得不从第一步开始。在这个模型的任何阶段都没有任何错误的余地,给开发者带来很大的压力。

由于无法向后移动或在此过程中跳过,每个步骤都必须明确规划。 要进行任何类型的更改,这意味着在开始任何类型的编码之前,收集所有必需的信息,并完成设计过程。

敏捷软件开发方法
由于瀑布的缺点,敏捷模型被开发成为管理软件开发的更有效的方式。 其结果基本上是解决瀑布方法中所有问题的线性设计模型。

开发人员只需从项目的基础设计开始。设计完成后,他们移动到小模块开始开发。分为每月或甚至每周的Sprint,小模块的工作部分完成。这些冲刺用于在编码时查找错误和错误,开发人员在转到下一个Sprint之前使用客户端反馈。

在这种方法中需要大量的合作,因为规划师,开发人员,设计人员和测试人员在产品的不同迭代中一起工作。该方法更灵活,因为允许开发人员在该过程的任何步骤进行更改,并且可以在此模型的帮助下轻松满足客户端的请求。产品的质量在每次更改时保留,从而产生更好的终端产品。

你知道吗?

宣传栏