问创新的软件工程方法

EN

我不确定我们是否可以将这些方法或框架归类为创新、传统或其他。

方法或框架的选择完全取决于产品和客户需求。其中任何符合产品要求并为您的团队提供效率的产品都可以在该范围内进行创新。

在当今的开发世界中，大多数软件开发过程都是在复杂环境中开发复杂产品。我完全同意敏捷方法论、极限编程、测试驱动开发和BDD与之前在复杂环境中开发复杂产品的定义非常匹配。因此，大多数敏捷方法都是对开发复杂产品的检查。

敏捷方法论

术语敏捷是软件开发专业人员使用的一个非常流行的术语。有很多敏捷方法和框架，比如scrum、看板或XP。他们提出了一些让我们变得敏捷的方法。敏捷这个术语涵盖了所有这些方法。它们大多解决了预测、适应、透明度、检验和经验过程。所有敏捷方法都试图解决软件开发过程中面临的这些问题。

Extreme Programming

极限编程专注于开发合格的软件产品，并适应不断变化的需求和环境。老实说，我真的很喜欢XP。它不仅仅建议使用开发方法。它还提供了一些关于客户管理、成本管理等方面的建议。这是非常基础的，但很难实施。我强烈建议阅读Kent Beck解释的《极限编程》一书。

另请参阅：

Extreme Programming

Extreme Programming Explained, by Kent Beck

Scrum

Scrum是另一个基于经验过程控制的软件开发框架:透明性、检查和适应性。它非常简单，并且定义了软件开发过程中的一些角色和事件。这些角色是Scrum Master、产品负责人和开发团队。这些活动包括冲刺计划、每日Scrum、冲刺回顾和冲刺回顾。我建议阅读Scrum指南以获取更多信息。

另请参阅

Scrum Guide

测试驱动开发

测试驱动开发是一个软件开发过程。我不能说它本身就是一种敏捷方法。它帮助软件开发变得敏捷。测试驱动开发支持开发人员在第一阶段进行测试。测试驱动的开发还需要一个在每次开发之前思考测试的心态。它不仅仅是编写单元测试。

另请参阅

Test-driven development

Test-driven development by Martin Fowler

Test Driven Development: By Example, Kent Beck

行为驱动开发

它是另一个软件开发过程，是从测试驱动开发中出现的。它专注于交叉团队，如开发、管理和客户共享工具和共享流程，以对需求有相同的理解。BDD建议业务人员、客户和技术团队应该对产品有相同的理解。客户需求，让sat客户语句，可以通过该工具自动测试。

另请参阅

Behavior-driven development

10 Tips for Writing Good User Stories

Cucumber.io

摘要

如果没有XP、Scrum、看板或任何其他方法或框架，敏捷本身就不存在了。如果没有TDD、BDD或持续集成，任何敏捷方法或框架都会缺失。这些项目中的任何一个都必须得到公司文化、客户或业务人员的支持。项目中的每个利益相关者都应该有产品胜过项目的心态。否则，敏捷方法可能没有帮助。

最后，我强烈建议对持续集成有更好的理解。

另请参阅

Continious Integration

Products over projects

The Clean Coder: A Code of Conduct for Professional Programmers

我认为你混淆了实践、方法论和哲学。

为了找到新的创新软件开发方法，你可以看看大型科技公司以及他们是如何做到的。

以Facebook为例，他们练习Erik Meijer's GOTO 2015 video中描述的"The hacker way“。根据Erik的说法，这不是敏捷。它的重点是编写代码，而不是像大多数敏捷框架那样过多地谈论代码。

如果你看看Spotify，你会发现他们有自己的扩展“敏捷”实现。看起来真的很有趣，看看the Spotify engineering culture video's。

但他们真的很有创意吗？或者这只是一个循环的进化？

你命名的东西根本就不再是创新。大多数都超过10岁了。它们是久经考验的概念，有些人喜欢它们，有些人讨厌它们，但创新的地狱没有。

归根结底，软件开发是一个没有一刀切的解决方案的过程。这是因为编码是一个创造性的过程，很难标准化。每个公司和产品都需要找到自己的道路。

“敏捷”是一群人在2001年创造的一个术语，他们聚集在一起研究为什么他们的项目往往会在其他项目失败(有时代价高昂)的情况下取得成功(或快速失败)。

Agile Manifesto从那次会议中走了出来。您可以看到下面的人员列表。有一群人都与被认为是“敏捷”的原则、方法和实践有关: Scrum、Crystal、XP、TDD等。

所以“敏捷”是一个总括的术语，指的是遵循主要价值观和principles的一系列东西。

“方法论”这个词有许多模糊的含义，所以我将把它追溯到它的起源。它来自于“方法”和“学”。

来自etymonline.com的词源包括：

Method:定期，系统的治疗...教书的方式或去...科学研究..。调查...追逐，追随...一种旅行的方式。做任何事情的方式。

-ology:科学知识分支

-logy: a演讲、话语、论文、教义、理论、科学……谈论或处理(某一话题)的人的性格或举止

所以“敏捷方法论”是关于如何更好地做好软件开发的一系列价值观、原则、实践和想法的总称；这些想法的教导；这些想法的遵循；以及社区中的人们。

我将快速浏览一下您提到的内容，这样您就可以看到它们都是敏捷的一部分：

• 测试驱动开发: XP的一部分，起源于Kent Beck，也被其他签名者普及，比如创建了JUnit

的Brian Marick

测试开发:起源于Dan North，基本上是测试开发，没有“

• Behaviour-Driven”这个词，只是它比听起来更深刻。当然是敏捷方法的派生。

• eXtreme Programming:还有Kent Beck，介绍了测试驱动开发，绝对是敏捷。

• 瀑布:典型的做法是尝试将所有事情都做好，而不是敏捷。

然而，有一堆来自其他学科的东西正在涌现。许多来自丰田精益制造的精益知识，特别是关于戴明的工作，开始在这个领域发挥作用。所以你会得到类似这样的东西：

• Lean Startup -通过原型和实验快速验证的想法，这些原型和实验可能在长期内不可行，但可以立即生存或盈利。精益UX -专注于与开发团队合作的持续UI改进，而不是需求捕获和analysis
• Lean Product Development -丰田设计应用于软件领域的新车的方法，包括基于集合的并行工程，平衡需求和容量的etc.
• Kanban for Software Development管理方法，也基于源自丰田的想法。

还有一大堆其他的知识和想法可能超出了你正在寻找的范围，所以我只会抛出这些术语来提高人们的意识。

• Product开发： Impact映射、故事映射、示例映射、A/B testing

• Technical flow: DevOps、持续集成、持续部署

• People与心理学：丹·平克的“驱动力”，Cynefin，神经多样性，社会资本

• Scaled敏捷方法：大规模Scrum (LeSS)，缩放敏捷框架(SAFe)，纪律敏捷交付(DAD)

• Strategy:精益画布，企业服务规划，西蒙·沃德利的战略地图。

这里的一些术语确实是新出现的，可能会发生变化；这些列表肯定不完整。我收录它们主要是为了让你了解敏捷从哪里开始的，社区有多广，以及它的发展方向。

我认为在未来，它将不再被称为敏捷，它将最终包括整个业务，而不仅仅是IT，这是一件奇妙的事情。它已经开始在全球范围内增加合作，超越业务边界，这是下一步。

如果你的演讲以这个作为笔记结束，我会很高兴的。