敏捷开发与GeneXus哲学

译者前言

在GeneXus的重要创始人和核心成员的观念里，在做一件重大事情前往往需要进行大量的思考，尤其是所要从事事业背后的本质及相关的哲学问题进行思考，然后要研究对应的方法论。在上述问题得到明确的答案后，才开始开展工作。

这种做事方法虽然开始有些慢，但对于所从事事业的长期发展却非常有帮助。接下来，我们看看GeneXus创始人都是如何思考的。

正文

GeneXus，一种完全不同的软件开发模式

GeneXus被设计成一个颠覆性的软件开发手段：“即使用软件来生成软件、自动维护和管理计算机系统“，同时集不同用户的视野/视图作为软件开发的输入。它的开发语言基本上属于声明式的，并受各种不同的编程技术的影响不断实现自我进化。

本文的目的不是讨论GeneXus的开发语言和其特性，而是要展示“敏捷开发的方法论与GeneXus的原则最相适配”。

GeneXus：工具、平台、哲学

GeneXus一开始是作为工具出现的，在经过多年的发展它已经变成了一个完整的平台。在这个平台中，GeneXus最初的哲学理念已经得到了进一步的发展。

GeneXus的使命一直并永远是极大地降低软件开发时间并且同时保证软件开发质量。GeneXus能够创建不同的软件解决方案，利用GeneXus开发的企业核心关键应用系统从GeneXus得到的最大优势是：它们能够与时俱进和不断进化。

GeneXus哲学是基于在20世纪80年代就形成的以下”四项基本原则“：

● 生产率原则：

自20世纪80年代起，GeneXus就开始高度重视这样的问题，即业务系统软件的开发时间问题。即使当时的业务系统的规模要比现在小并且简单一个数量级。当时没有企业级应用系统，大多数作业是通过批处理来完成的，交易类的任务通常不是由实际用户来处理，而是由专门的打字员来完成任务的输入，没有外部用户。

大量的工作是在没有清晰的设计和规划就开始进行，这往往造成在应该每项工作已经完成或软件产品应该上线时，还存在一个D-Day（诺曼底登陆日，即艰苦的攻坚战）。在现在看来没有任何反馈的软件开发工作是不可想象的。实时的、或及时的原型开发已经成为在软件开发前验证解决方案的可行性的标配工作。

● 技术无关性原则：

该原则一般与多平台或多体验相关，但不仅仅是这些。因为该原则意味着可以在特定的时间里采用当时最流行的技术来实现多平台、多体验。

这是 GeneXus 的主要优势之一，它通过对业务和用户知识的建模实现多平台开发，从中可以通过将不同的人工智能技术应用于代码和用户知识管理，自动生成不同时间段的各种平台的软件及数据库。例如，同一套业务模型与用户知识，既可以生成AS/400的IBM主机应用系统，又可以生成最新的Java应用或C#应用等；既可以生成前端APP，又可以生成Web应用等。

● Future Proof（提供永不过时的技术）：

旨在以独立于技术的方式描述应用程序是 GeneXus 面向未来的原因。尽管有时客户没有意识到这一点，但客户所属组织需要他们的业务和软件知识能够在未来发生的技术变革中持续存在。这就是 GeneXus 专注于存储“纯”知识的原因：技术元素不与知识一起存储，允许在未来新技术成为主流时重复使用这些知识。

在IT技术飞快发展的今天，技术可能会改变，但随着时间的推移更加稳定的商业知识受到 GeneXus 的保护。GeneXus会利用AI技术将这些成熟的商业知识转换成可以在最新技术环境下运行的应用系统。这就意味着GeneXus给用户提供了永不过时的技术。

● 增量式开发模式：

众所周知，为了快速从用户那里获得真实的和高质量的反馈，就需要使用增量开发模式来加速软件开发速度。

在所谓的敏捷方法存在之前，传统的瀑布模型并不适合大量的软件开发项目已经是不争的事实。而从一开始，GeneXus就最适合增量和迭代方法相结合的敏捷开发模式。

GeneXus 哲学相信

● 业务知识：业务知识通过人和他们的互动获取，并存储在自动和目标导向的基础框架（我们称其为一个知识库）中，其中还包括有生成和维护应用系统所需的推理能力（即AI能力）。

● 有效的系统：也就是说应该开发出能够正常运行的软件系统。

● 合作：从一开始，GeneXus 就提供了一种共享知识的机制，而这些知识能够随着时间推移而发展。

● 进化的系统：该系统应该能够自动响应业务、用户和市场的变化（进化），而不是成为在项目早期遵循僵化的、预先制定的执行计划所产生的固化系统。

敏捷方法论：宣言和原则

敏捷开发方法是解决 50 多年来使用瀑布式软件开发方法或其派生方法一直无法解决的有关软件系统的有效性和效率问题的替代解决方案。

本文档的目的不是讨论敏捷开发是什么，而是从最广泛的意义上谈论敏捷开发，包括其原则和哲学。

XP（极限开发）、Scrum（冲刺敏捷开发）、Crystal（水晶敏捷开发）、Lean（精益开发）、DSDM（动态系统开发方法）和其他方法论有许多共同点，并在不同时期影响了敏捷开发。

对敏捷开发的批评通常涉及方法论的某些方面，但很少有反对其哲学的情况。

2001 年，创建了第一个敏捷开发宣言，其中建立了一些看似显而易见，但在其他方法中无法实现的原则。

首要任务是通过不断发布可运行的软件来满足客户的需要。

当软件由人创建时，一般会倾向于横向开发（也称水平切片开发）某些功能以实现原型，将非功能性方面放在一边或创建一些质量水平较低的功能性方面。因此，在第一个 sprint 中实现的场景最终满足了提议的功能。然而，它们也为未来的迭代留下了技术问题（也称技术债），很多时候这些问题即使在最终交付中也无法解决。

GeneXus 在这方面提供了很大的优势，因为交付的场景质量很高，并且不需要程序员的大量额外工作。

拥抱变更！

即使经过详细分析，系统的变更也是不可避免的。但是，对于程序员来说，这些更改永远不会受到欢迎，因为它们会影响系统的各个要素（数据库、程序、服务、安全性等）。

在 GeneXus 中，我们欢迎变更，而且这些变更是系统级别的更改。唯一重要且必须声明的变化是业务的变化：对已经产生的各种系统的影响及其演变是自动的。无需重新编码即可执行数据库重组以及程序、服务和用户界面的重新生成。这就是为什么，无论变化如何，系统都可以快速开发出来，使其可运行并投入生产。

工作软件是进度的衡量标准

再次强调，GeneXus的理念是始终拥有一个高质量的可工作系统。

很明显，在 GeneXus 和敏捷概念中，变化总是迫在眉睫，软件总是在工作。

GeneXus 程序员通常是那些从任何项目开始就敏锐地意识到这一原则的人。这不会转化为“没有文档、/“质量差”、“没有分析”或“没有测试”。这些元素当然存在，但它们存在于业务层面：记录业务，分析业务、设计测试等。这些是程序员处理的变量，他们可以和应该做什么来补充开发，始终关注业务而不是当时主流技术的细节。

敏捷和精益开发

对敏捷方法的批评之一是它们以开发人员为中心。这就是为什么出现了其他可以被视为替代方法的方法，即使它们的原理并没有太大的不同。我们认为精益开发为敏捷开发带来了一些新鲜元素，但它并没有改变其核心原则。

有些人错误地认为敏捷是没有任何文档的“快速而肮脏”的开发。事实并非如此，问题的出现是由于使用了一定的技术和工具，这些技术和工具为了保证足够的开发质量，明显地使敏捷开发的每个步骤中要解决的场景的构建过程复杂化。

GeneXus 提供“快速和高质量”的开发，并将结构化的业务知识集成到其项目中，并在项目本身中集成一个 Wiki，以协作和非结构化的方式对其进行记录。