我的名字是 Russ Martin，我一直在使用 Mendix 在 Erie Insurance 担任高级软件工程师近三年。我们使用了 Mendix 平台完成了几个项目，取得了巨大的成功。我想分享一下我们在尝试将重点从瀑布式转移到 敏捷项目方法，以及一些如何克服这些问题的技巧。
向瀑布团队引入敏捷
你可以想象，当第一次介绍 敏捷概念，您的瀑布式开发团队最初可能会犹豫和担心。这是意料之中的，因为改变对很多人来说都很困难，尤其是在转向完全不同的事物时。我们发现最大的两个障碍是引入迭代开发和持续需求的概念。
在许多瀑布式组织中，常见的趋势是在开始开发之前设计和规划整个项目。如果您熟悉瀑布式，那么您就会知道，这需要数月的需求收集和设计会议，然后团队才能开始编写代码。这也造成了学科之间的脱节，因为它不会让整个团队参与这些会议，还需要知识传递。这个过程会产生一些沉重的开销，而且非常耗时。与瀑布式相比，敏捷过程完全是 180 度大转弯。当试图改变人们的思维方式以违背他们之前的所有培训和经验时，人们会感到担忧。这是正常的，也是意料之中的。
与瀑布式流程相比，敏捷流程完全是 180 度大转弯。对这种变化的担忧是意料之中的，甚至是正常的。
为了克服这个问题，我发现展示敏捷方法的好处有助于人们看到它的价值。从一个小的概念验证开始。拿出一小部分应用程序，或者预计需要相当长的时间才能替换的应用程序，看看你能在短短几周内完成什么。让至少一个来自不同学科的人参与进来——业务分析师、软件工程师、质量保证等。这样做的原因是你需要有不同观点的人来影响这种类型的改变。如果你能让几个人理解新方法，那么让组织中的其他人加入就容易多了。此外，利用 Mendix 团队。他们在处理这种文化转变方面经验丰富。通过让外部人员帮助解答问题，您可以提供额外的理解，从而推动采用。
这个概念验证的关键是：团队合作！你肯定会面临一场艰苦的战斗。你需要你的团队参加冲刺零练习。在这个练习中，他们将整理一些故事来决定他们想要从用户界面看到什么。通过让团队的所有成员参与进来，他们将对结果投入更多。他们会觉得自己在这个过程中有发言权。我无法强调这在长期内有多么重要。从文档繁重的流程转变为故事卡方法对许多瀑布方法实践者来说是一个陌生的概念。准备好接受团队成员的反对，这是正常的。请记住，这个概念验证更像是一个实验，一个训练练习。它不是一个将投入生产的全面项目，这有助于缓解许多怀疑论者的担忧。从开发人员的角度来看，请记住：如果这是你计划长期使用的项目，那么这是你为整个项目奠定基础的机会，并节省你未来的时间。
大多数人在开始之前就进行了过度设计。先打造一辆福特，然后再升级为奔驰。
我们用来强调我们想要做的事情的一个概念是：“我们不需要开着奔驰从 A 点到达 B 点。我们只需要到达那里。所以让我们开发福特吧。然后，一旦我们上路，我们就可以专注于我们想要的车辆升级。”这是一个有用的概念，因为大多数人都想要完整的产品。他们甚至在开始之前就想过度设计。从较小的规模开始可以让您的开发人员开发“Pinto”，这是一种可以完成工作的最小可行产品。然后展示您可以多快将您的车辆升级为“凯迪拉克”，这是一款具有更多特性和功能的成熟产品。它可以让您的用户进入 Pinto 并提供反馈，之后您可以向他们展示开发这些新功能是多么容易。
转向项目工作
假设概念验证一切顺利，并且您现在已经获得了整个项目的绿灯，那么您可以查看一些可以合并到项目中的项目，以帮助顺利过渡。
从业务分析师和质量保证的角度来看，您可以利用多种方法来进一步促进理解过程。我们发现“amigos 会议”在开始时非常有用。amigos 会议是开发人员、分析师和测试人员举行即席会议来审查分配给特定冲刺的卡片的地方。这允许所有参与者就每张卡片的开发内容达成共识，并有机会提出有关工作的具体问题。这些会议应该是非正式的，并在开发之前以临时形式举行。然后，一旦开发完成，再举行一次 amigos 会议来审查完成的编码。这允许每个人在工作完成时进行审查。同时，这让开发人员有机会展示他们能够多快适应需要更改的项目。例如，分析师在最后的 amigos 审查中指出了遗漏的要求。这将允许开发人员当场进行更改并在屏幕上显示更正后的代码，向团队成员证明代码库的适应性和对更改请求的快速响应时间。这在很大程度上帮助其他人了解您可以使用该平台做什么。我们的目的不是让这些永远持续下去。最初，应该进行朋友评论，直到每个人都对新流程感到满意。那时，您只需要在故事卡开发结束时利用这种技术。
从质量保证的角度来看，敏捷的主要好处是测试驱动开发。
从质量保证的角度来看，敏捷的主要优势是测试驱动开发 (TDD)。TDD 是 IT 社区中使用的一种众所周知的流程。通过使用 单元测试模块 可用的 Mendix App Store 中，开发人员可以创建与每个开发冲刺相关的多个单元测试。单元测试模块还允许您在每次部署时运行报告，显示单元测试是通过还是失败（并帮助您作为开发人员确保没有创建新的缺陷）。这允许 QA 团队查看代码是否稳定，并且之前测试过的代码仍然有效。当然，他们会希望做自己的测试，这是应该的。但是这种方法将提供一些信息，即代码库不会随着每个完成的冲刺而退化。这一点很重要，因为他们将按照迭代计划进行测试，而不是在项目结束时进行一次测试。您可以采取任何措施让他们知道他们的测试努力没有白费，从长远来看，这是一个巨大的胜利。
从开发人员的角度来看，我们发现代码审查对于任何项目的成功都至关重要。原因很简单：审查代码的人越多，出错的几率就越小。这也有助于为开发人员实施编码标准和流程，团队的所有成员都可以利用这些标准和流程。能够看到其他人为提高编码效率所做的工作可以缩短产品上市时间。对于那些适应敏捷速度较慢的人来说，这也大有裨益。为什么？因为他们知道您正在尽一切努力确保您的团队编写可靠的代码，并有助于减少系统中发现的缺陷数量。您发现的缺陷越少，您的团队对这种新的敏捷方法的感觉就越好。
那么管理又如何呢？
管理层不关心团队开发的具体细节，也不应该关心。他们更关心资源、速度和质量。那么，我们如何向他们提供具体的东西来表明我们正在开发一个易于维护的优秀系统呢？我强烈建议使用 Mendix 质量和安全管理工具。
我们能够在代码库内进行更改之前提供系统指标。通过这样做，我们可以轻松地表明我们想要实现的想法通过提高 AQM 分数提供了价值。
AQM 利用 McCabe 复杂度来扫描存储库中已提交的代码，以确定从 1 到 5 的评级。对于那些不熟悉 McCabe 复杂度度量的人来说，它是一种用于指示程序复杂度的软件指标。AQM 工具将您的代码库分为八个不同的类别。从开发角度来看，这些类别也非常有用。它们使您能够看到您的团队正在制作不太复杂且易于维护的项目。这在培训新开发人员时也很有用。它使团队能够了解开发人员的理解水平，并使您能够轻松指出他们可能在哪些地方编码不正确。这提供了一个机会来教他们根据组织的标准正确构建微流的方法。
那么管理层呢？我们都知道，管理层更喜欢简短、简洁、切中要点的报告，这些报告可以提供易于阅读的图表，供会议使用。AQM 工具提供了几个报告选项，可以深入了解正在开发的代码。这在我们的组织中被证明非常有用。我们能够在代码库中进行更改之前提供系统指标。通过这样做，我们可以轻松地通过提高我们的 AQM 分数来表明我们想要实现的想法提供了价值。这种方法还使我们能够通过向管理层展示前后指标来消除一些最大的违规微流。
AQM 让您看到您的团队正在制作的物品不太复杂且易于维护。
您还可以为管理团队设置用户登录名，以便他们可以访问这些指标并在整个组织的讨论中使用它们。请记住：您为人们提供的舒适度越高，他们就越容易接受。
展望未来
这是我提供的一种高级方法，可帮助改变贵组织的文化。请注意，整个过程不会一帆风顺。整个过程会有很多起伏。请记住，最终一切都是值得的。使用这些项目将有助于每个人理解和适应新流程。重复该过程的一致性对人们大有裨益。您从每个冲刺中向团队发布的越多，他们就越能看到自己的劳动成果。这些步骤极大地帮助我们的开发团队认识到敏捷方法可以取得巨大成功。