敏捷开发:所有内容

2020年12月28日17:18:36 发表评论 60 次浏览

本文概述

关于敏捷软件开发

敏捷软件开发已经存在了很长时间, 并且在其他工作领域也早已建立了敏捷方法。但是, 对于许多人来说, 该术语仍然不太清楚。你什么时候开始按照公司的敏捷方面采取行动?而实际上是错误地用流行语升级的传统作品是什么?

内容

  1. 什么是敏捷软件开发?
    1. 价值观
    2. 原则
    3. 技术技巧
  2. 敏捷软件开发的利与弊

早在1990年代, 软件开发团队就开始使用现在可以视为敏捷软件开发的方法。直到20世纪末, 各种软件开发人员和团队都为使编程更轻量而做了大量工作, 因此该方法主要以关键字"轻量级"而闻名。在这段时间内, Scrum开发了方法和看板, 这在当时还不能用"敏捷产品开发"来概括, 因为该表达尚不存在。

终于在2001年, 一个明显的突破发生了:在今天称为雪鸟会议(以开会的犹他州滑雪胜地的名称命名)的会议中, 有17位开发人员创建了敏捷宣言。将他们各自在软件开发和团队合作方面的经验汇集在一起​​, 他们找到了解决方案, 既定原则, 并总结了当今与现代工作方式同义的所有内容:敏捷软件开发。

什么是敏捷软件开发?

当他们开始对小规模的软件开发方法提出质疑, 并最终试图与敏捷宣言建立一种新型的项目工作时, 该小组的目标始终是能够更加灵活, 创造性和富有成效地行动。而不是像传统方法那样遵循经过周密计划, 线性和官僚化的过程, 例如瀑布模型–项目开始。为此, 敏捷软件开发将更多的责任分配给程序员团队。

此外, 或多或少地告别了大型项目:敏捷团队无需花费数月甚至数年的时间来生产产品, 而是在工作阶段仅花费数周的时间。结果是可以呈现给客户的成品, 更新或程序部分。为了成功实现这一目标, 敏捷宣言中已经商定了十二个原则和四个价值观。

价值观

敏捷软件开发的价值设定了团队在开发工作中应始终牢记的重点。它们被称为对立。这两个方面都很重要, 但是在敏捷开发中一个方面被另一个方面所取代:

  • 流程和工具上的个人和互动:所涉及的人员及其彼此的合作比特定过程或工具的问题更为重要。
  • 工作软件超过全面的文档:重点是功能正常的最终产品。但是, 工作记录是次要的。
  • 通过合同谈判的客户协作:敏捷产品开发更关注满足客户及其需求, 而不是进行合同谈判。
  • 响应计划变更:假定软件开发必须响应不断的变化。可能有必要推翻先前定义的计划。

这些值就像要被解释的口头禅。他们没有提供精确的指导, 但会提醒开发人员生产的关键重要方面:团队合作;专注于软件;想客户应对变化要灵活!所有其他方面虽然可能同等重要, 但也应成为这些要点的一部分。

原则

在具体指示的方向上, 更多的是《敏捷宣言》的十二项原则。这些提供了附加信息并扩展了值。但是, 即使在这里, 这也不是实际的指示–指示并非宣言所要提供的。这些原则很广泛, 可以区分敏捷方法和非敏捷方法。

客户满意度:通过尽早而连续的出版–持续交付–客户应随时满意。

  • 灵活性:敏捷团队始终将变更视为积极的方面, 即使它们出现在开发过程的后期。如果遵循《敏捷宣言》, 则对变化的要求进行调整可以使客户获得竞争优势。
  • 交货:在数周或数月的时间内直接交付功能软件。始终欢迎较短的时间范围。
  • 合作:开发人员和销售同事需要紧密合作。敏捷宣言建议每天召开会议。
  • 支持:为了使有动力的个人和富有创造力的团队能够良好地工作, 环境也必须适合他们。他们需要他人的支持, 尤其需要上级的信任。
  • 会话文化:直接通信最适合于尽可能有效地传输信息, 而不会造成误解。面对面交谈可以提出问题并避免得出错误的结论。
  • 成功:首先, 可以通过发布功能软件来衡量团队的成功。
  • 可持续发展可持续发展是有意义的。所有参与者, 而不仅仅是开发人员, 都应继续致力于发行。
  • 质量:开发人员应始终确保其产品符合最高的技术和设计标准。
  • 简单:你应该使工作尽可能简单。省略所有可以避免的内容将导致流程更精简, 从而获得更好的结果。
  • 组织:只有使团队能够组织自己, 才能取得非凡的成绩。
  • 回顾性:敏捷软件开发的一个重要方面是随时询问自己。为了不断改善团队的工作, 重要的是, 成员必须定期交换有关其工作方式的信息并相应地调整其方法。

技术技巧

在敏捷软件开发的环境中, 已经建立了一些实践, 可以用来在其团队或公司中实施敏捷方法–"敏捷开发"只是其统称。这些技术中的许多技术都可以以敏捷软件开发的形式找到, 例如Scrum, 看板, 极限编程, 功能驱动开发, 行为驱动开发或Crystal。

  • 积压:列出所有仍需完成但当前尚未完成的任务的清单的想法是敏捷方法的特征。原因是工作阶段短。你无需在大型计划中同时处理多个任务或为每个任务分配固定的时间跨度, 而是在后台拥有一个灵活的池。团队可以从该池中选择下一个任务。
  • 回顾展:这些会议不仅是敏捷方法中的抽象原则, 而且部分有具体要求。特别是Scrum以制定各种会议固定计划而闻名。只有团队定期解决挑战, 问题以及成功, 才能长期改善。
  • 用户故事:可以通过用户故事满足专注于客户或用户的需求。这里使用简单的语言来简要说明功能必须为用户执行的操作。有人在所谓的故事卡上记下了这一描述, 并将所有地图排列成一个故事地图。
  • 敏捷测试:在敏捷软件开发中, 测试被视为开发过程的组成部分。通常, 在迭代结束时(即短暂的工作阶段)对产品进行团队测试, 然后将其视为"完成"并交付给客户。只有这样, 下一次迭代才会从新任务开始。
  • 配对编程:在配对编程中, 四只眼比两只还好。两名开发人员共享一个工作站, 而两名开发人员之一编写代码, 另一名则检查输入。这会花费更多时间(审阅者可以自己编写代码), 但应减少代码中的错误数量。
  • 时间拳击:某些形式的敏捷开发有严格的时间表。同样, Scrum是一个很好的例子, 其中的sprint具有一定的长度。最后, 团队必须展示成品。这就要求你设计和选择适当的任务。

敏捷方法中可能会遇到更多技术。他们所有的共同点是希望使工作流程更有效并提高产品质量。

敏捷软件开发的利与弊

敏捷软件开发是否是所有人的正确解决方案?根据你公司的情况, 弊大于利–另一方面, 很多人对此表示反对。

优点

缺点

灵活应对不断变化的需求

对开发方法的不正确描述会导致海绵状的工作习惯

创新的可能性

开放会导致剥削并支持非生产性行为

持续改进工作流程

没有长期计划很难达到最后期限

假设先验知识

参与各方之间的密切联系-首先是与客户

额外的交流花费更多时间

避免对已经完成的项目进行后续更改

当整个团队在一个地方工作时, 效果最佳

一盏木

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: