首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >纯技术术语的敏捷方法

纯技术术语的敏捷方法
EN

Software Engineering用户
提问于 2018-03-30 08:15:25
回答 3查看 396关注 0票数 4

我经常听说敏捷性过程,但在我看来,它几乎总是与团队组织和交付过程联系在一起。它(几乎,再一次)从来没有到达瓶底:发展本身。

是否有任何敏捷方法专门针对技术问题,如开发方法、错误/错误处理、实践和编码时的意识形态?或者是因为我不理解敏捷在团队中编码时的意义?

EN

回答 3

Software Engineering用户

发布于 2018-03-30 08:18:14

你听到的大多是Scrum。而Scrum不处理技术实践。许多人认为Scrum的失败,因为在没有采用适当的技术实践的情况下采用Scrum会导致“松弛-Scrum”。

eXtreme编程,这是较少人所知和采用的敏捷实践,另一方面,处理大量的技术实践。自动化测试、重构、对编程和持续部署等技术实践是XP的核心。XP相信,正是这些实践允许了快速、可持续和可预测的发展。

票数 13
EN

Software Engineering用户

发布于 2018-03-30 15:53:45

短答案

敏捷宣言定义了4个值和12个原则。他们中没有一个是技术性的:这只是关于心态和团队合作。然而,每项价值和原则都有技术含义。这些都体现在最初由一种或另一种敏捷方法促进的各种实践中。

更长的答案

没有进入任何特定的方法,敏捷过程都是迭代增量

  • 迭代是关于工作的组织,不管它是如何在技术上完成的;
  • 增量是关于连续但完整的功能子集的交付。这意味着改进代码。

一般技术影响:

  • 设计必须是渐进的。因此,在前面没有详细的UML模型。
  • 代码应从一开始就针对每一个增量进行适当的设计和健壮。这不包括快速和肮脏的丢弃代码(例如原型,以验证可行性,而不打算在其代码基础上构建)。诸如清洁代码重构版本控制系统的使用等实践都支持良好的增量编码。
  • 每增加一次都应接受。这意味着需求中明确的验收标准,以及每个增量的适当测试。测试驱动开发自动测试 (例如使用jUnit之类的框架)是实现这一目的的两种有效实践。
  • 开发人员应该同步工作,以便在迭代结束时增量是有功能的(即没有未完成的内容)。我不清楚这是一个组织方面还是一个技术方面。
  • 经常的集成和构建是必需的(至少每次增加一次,但更多的是在实践中)。每日建造连续积分是这方面的两种有效实践。

当然,迭代和增量开发过程需要输入,从而能够很好地识别增量。这通常是通过用户案例或用例实现的。用户故事映射用例2.0是将需求分割成可实现块的有效实践。

您可能会反对上面提到的一些实践不一定要绑定到敏捷。您将是正确的:敏捷并不是关于技术实践的。但需要技术实践才能实现敏捷性。

票数 4
EN

Software Engineering用户

发布于 2018-03-30 11:04:14

软件开发的一个基本问题是,在一般情况下,对系统的实际需求是不明确的,更糟糕的是,它们的变化(出于各种原因)。有些情况下,这不是真的,但它们是例外,而不是规则。

人们不知道他们想要什么(虽然他们通常知道他们想解决什么问题),而且每个人通常只知道他们想要什么和他们在交付产品时要求什么之间的差距。

软件开发的“敏捷”方法的目的是通过提供很少且经常是为了能够从反馈中学习并调整需求以匹配的方式来缩短反馈循环。这一领域的许多讨论都是围绕着提供价值。

所以敏捷并不是真正的技术(“精益”制造过程也是如此,它们有很多共同之处)。尽管如此,有许多技术实践可以促进敏捷,而不管采用何种方法--那些使更改易于管理、易于以高节奏交付等等--因此,在敏捷环境中讨论技术问题是合理的。

从敏捷(或精益)的目标中产生的最后一件事是沟通和开发人员的价值--例如scrum (例如)是一种促进工程师之间的交流的手段,并且正确地揭露阻碍交付的问题。

票数 2
EN
页面原文内容由Software Engineering提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://softwareengineering.stackexchange.com/questions/368582

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档