来源：outsystems
作者：Thomas Huff
翻译：数字兄弟
"我们的优先任务是通过快速和持续交付有价值的软件来满足客户。"
这句话成为"敏捷宣言"中的首要诠释，根据Forrester Research的研究，低代码市场正以近40%的速度增长，通过缩短构建、测试和部署有价值的软件来帮助企业实现IT项目高效开发的目标。
此外，最近一项关于应用程序开发现状的研究表明，与不使用低代码的公司相比，采用低代码的公司的组织敏捷性高出8%.
向敏捷团队引入低代码的主要挑战
无论企业正在考虑使用低代码，还是已经使用低代码开发，IT决策者都应该密切关注使用低代码开发的三个特定方面，并确定如何定制企业的敏捷方式。
1、低代码开发确实更快
即使是高绩效、成熟的敏捷团队在第一次使用低代码开发时也不适应其带来的速度提升。对于仍然在提高敏捷度的团队，适应低代码的速度更具挑战性。
特别是，由于开发速度的提高，团队会发现没有更多需要开发的项目需求。 这可能会导致一些问题，包括：
· 撰写低价值的需求，因为只有这些是准备好的；
· 没有明确更多的开发需求，就开始启动；
· 极端情况下，甚至开发者会出现闲置。
一方面要满足企业需求，另一方面还需要保持生产力不能过程，供大于求，这可能对所有团队来说都是一个挑战，对于低代码的速度来说，这可能更具挑战性。
2、兼顾速度与质量
虽然速度是低代码的重要衡量标准，但兼顾速度和质量是最终目标。除了创建和维护业务部门的需求存量之外，对低代码不熟悉的团队可能会发现使用现有的敏捷方法从流程一开始就很难达到所需的质量。
如果没有从一开始就将质量纳入流程中，团队通常会发现测试团队很难跟上新的开发，特别是管理bug修复周期。最终结果是在每次集中开发结束后，达到实际业务需求的项目更少。
3、利益相关者的进度不同
低代码团队在大型企业或相互关联的项目组工作时，面临的另一个常见挑战是配合团队之间的开发速度的差异性。使用低代码构建企业应用程序的团队依赖于使用瀑布式或低成熟度敏捷流程的内部和外部团队，他们经常发现他们的工作由于依赖关系而变慢或受阻。
即使是曾经与敏捷团队合作过的瀑布团队，也往往无法跟上低代码团队的进度，这可能导致项目延期、昂贵的API模拟和技术负债的增长。
使低代码的力量最大化的技巧
在上述情况下，对低代码开发不熟悉的敏捷团队通常会通过对其工作流程进行小的更改来加快速度，如果没有产生有效的改善，经常会导致团队士气降低。
相比在问题上花费更多时间，敏捷团队应该在五个关键领域中寻找适应和改进敏捷流程的方法，以便挖掘出低代码平台的高效开发能力。
聚焦存量
一个强大的产品负责人是关键所在，将极大地帮助企业提升IT能力。
使用低代码开发时，首先要有一个高效的产品负责人，他要参与、授权和及时对项目进行响应。例如，如果团队习惯每周或每次集中突击需求时，则需要增加节奏。保持精心规划的IT项目达到上线标准，每天关注并快速决策需求的优先级、内容和验收标准。
对非IT利益相关者的需求也将增加，与非低代码项目相比，开发团队将交付更多功能以供审查和批准。提供构建和维护存量的需求、文档和反馈的利益相关者的响应需要比过去更加迅速。
这些利益相关者通常是应用的需求方，他们需要了解自身的责任以及向项目负责人提供信息和反馈，而负责人应提供更多培训、角色定义以及与需求方加强协作。
所有团队成员都应该了解如何以统一的格式编写项目需求，并且具有非常明确的验收标准。在开发过程中，团队成员通常需要理解、解释并提出有关如何改进需求的即时性建议。使用低代码有助于保持简洁的产品需求，因为它可以简化开发、提高吞吐量并缩短测试速度，使其与更快的开发周期保持一致。如果您正在编写长篇的故事或不使用验收标准，您需要立即解决这些问题。
增加协作
许多低代码平台使技术和非技术团队成员以及需求方轻松的实时协作并缩短开发周期。
在构建新功能时，开发人员和业务分析人员可以从开发周期初始就开始协作，尤其是复杂的项目需求。例如，使用一些低代码平台包括工作流可视化，开发人员可以用非技术语言直观地展示代码中的业务逻辑和数据。 分析师提供反馈，开发人员进行定制，并且可以实时测试更改，从而减少bug、遗漏需求和宝贵的反馈周期。
在集中开发阶段时，传统开发平台需要异步反馈循环周期，业务部门提供需求，然后开发人员编写代码、测试代码、部署代码，完成后需求方验收。使用低代码，业务发起方和开发人员可以一起查看界面并讨论更改。然后，开发人员可以根据修改发布代码，由用户和开发人员一起实时查看。这需要改变现有的流程，但能够大幅缩短周期并减少精力浪费。
采用协作的开发人员和QA测试人员可以缩短修复缺陷的周期。高绩效团队通常让开发人员和QA团队成员实时协作来修复缺陷，而不是把时间浪费在识别、记录、分类、确定优先级、修复和重新测试缺陷这一耗时的过程上。
尽早消除（或缓解）依赖关系
今天的产品基本上都对集成点、数据依赖性、安全性要求或其他问题有某种依赖性。如果使用的是低代码，而其他团队则不是，那么我们需要更改方法，以便比过去更早地识别和缓解这些依赖关系。没有一种万能的方法可以解决此问题，但是可以考虑以下因素：
· 更加注意识别潜在的依赖关系。
· 标记低风险的依赖关系并每天跟踪它们。
· 与依赖的团队协商更短的SLA（服务水平协议）。
· 通过在低代码中构建某些功能，来减少对第三方开发这些功能的依赖。
应该尽量减少调整所带来的影响，例如API模拟，这会因更改现有功能而降低速度，增加技术负担和重复测试。重要的是，我们在使用低代码进行开发时，过去有效的策略可能效果不佳。
提高仪式效率
随着对敏捷开发的熟悉，我们应该寻找简化敏捷仪式而不会失去其价值或意图的方法。 低代码开发项目是试验和实施这些变更的绝佳机会。
当使用低代码进行开发时，IT团队可能会继续编写过于详细的产品需求并创建过多的支持文档。
继续使用这种方法并跟上开发速度将是一项挑战，因此专注于小巧、简洁的需求，团队可以减少改善积压和规划集中开发的时间。
此外，在敏捷项目管理工具中将准备好标准的定义构建到需求表单中，这样的操作可以减少细化阶段因发现缺失标准而不准确的开发排期。
由于项目是通过低代码快速开发的，因此团队应该仔细研究并尽可能地减少用于估算的时间。花费更多时间来完善估算并不一定能提高准确性，而会削弱构建和部署软件的能力。
最后，使用低代码的成熟敏捷团队可以考虑缩短集中开发的持续时间，使他们能够比传统平台更快地向用户交付有价值的软件。
在所有事都趋于敏捷的情况下，我们应该进行复盘，查看哪些是有效的。
有效的复盘
采用低代码进行开发需要有持续改进的决心。如果不定期确定需要改进和实施新方法的领域，则会影响低代码的速度和价值。如实地复盘并保持有效性十分重要。
如何开始？
无论是敏捷、低代码开发的老手或是初学者，都参与了一项令人兴奋的行动。我们需要以不同的方式工作并调整当前的敏捷风格，以跟上开发的步伐。
仔细查看IT团队现有的需求排期，确保拥有强大的产品主导权，与需求方的牢固关系以及快速制定决策的文化。鼓励并要求需求的协作，尤其是在项目团队之间。
积极预测、识别和解决潜在的依赖关系，尤其是在传统开发平台上工作的团队。最后，挑战您的团队，提高敏捷仪式的效率和有效性，以便通过低代码实现最大效能。
了解qianyuthink低代码开发平台，请访问：
PC端：https://www.qianyuthink.com/?url=/product
移动端：https://www.qianyuthink.com/?url=/m/product
