在敏捷宣言最早出现于2001年，试图改变软件的创建过程。宣言有四个关键方面，但很少有人知道12 条敏捷原则。它们对可以执行敏捷产品开发的过程提供了更具体的解释。多年后，几乎所有的公司都声称他们提供“敏捷服务”，但大多数只是口头上对敏捷宣言的思想和概念表示赞同。软件开发行业也发生了巨大的变化。值得重新审视敏捷标准以检查它们的含义以及它们是否仍然相关。
根据第一个前提，“我们的最高目标是通过及时和一致地分发有用的应用程序来取悦消费者。”
我们通常会花费其他人的时间和费用来设计应用程序，以尽可能以任何可能的方式提供帮助。如果我们花很多时间来生产商品，消费者很可能会不满意。这在现在比以往任何时候都适用。客户不仅重视流程中的早期和一致审查，而且还要求快速执行。而每一次分销都应该为客户的生活带来价值。例如，消费者并不关心您调整登录页面的想法。他很高兴现在可以通过她的社交媒体帐户登录。
管理敏捷、DevOps 和瀑布技术之间的关系可能很困难。Plutora 提供了一个共享的氛围，团队可以在其中快速工作。
用户越来越依赖应用程序来执行各种任务。他们通常习惯于定期发出警报。因此，如果他们申请更新，他们不会耐心等待几个月才能看到它们。
根据第二个原则，“我们必须接受不断变化的条件，即使是在生产后期出现的条件。” 为了客户的战略优势，敏捷系统利用过渡。”
没有人能猜出在一个以更快速度快速发展的环境中软件的规范是什么。另一方面，企业不喜欢惊喜。他们不喜欢将资金花在不再重要的商品上。如果我们拥抱进步，该平台将为消费者提供战略优势，因为它满足当前和最近的期望，而不是去年的期望。
多年来，气候正在迅速演变的说法确实是真实的。社会在发展，经济在发展，我们的公司在发展，人们也在发展。我们不应试图停止或减缓此操作，而应欢迎并利用它们来为我们和我们的客户谋取利益。
以下原则是“定期发布工作应用程序/软件，从几天到几个月不等，重点放在更短的时间范围内”。
这个理论似乎是对早期原理的复制，而且在某些方面确实如此。然而，先前的理论指出，我们必须尽快开始提供有用的应用程序。该理论更深入地探讨了持续交付所需的条件。它建议尽快发布应用程序的新更新。这意味着更少的更新和更少的发布意味着出现故障的机会更少。更多的定期发布也为客户提供了更多的机会。如果您在几个月内没有收到任何更新的输入，您将有更多的工作要做来处理评论。
随着时间的推移，这个理论变得更加进步。“几个月”的发布期不再被认为是敏捷的。定期或每周发布已成为行业规范。
另一种理论认为“在项目期间，商人和程序员应该定期合作”。
程序员经常与商人隔离。专家被安排在他们中间，以便他们可以将营销术语翻译成程序员能够理解的语言。这是鼓励公司消除这些障碍并使开发人员和公司每天保持联系的原则。这促进了更大的共享意识和欣赏。
我们希望您小时候玩过有关电话的游戏；每个人都知道，接触的每一个阶段都会导致知识的流失。与公司和开发人员密切合作可以减少（但不能消除）这种威胁。在当今群体分散的世界中，我们必须努力定期协作。尽早认识到误解并经常接受彼此的意见有助于产生良好的结果。
这一原则建议程序员“围绕受启发的个性构建程序”。“我们应该给他们所需的氛围和资源，并相信他们能够完成任务。”
一个敏捷团队经常有足够的经验来开发高质量的应用程序。这需要一定程度的信心。但是，如果你不能信任工程师，你为什么要招募他们呢？有动力的开发人员会感到有能力通过正确的指导、设置和软件正确地完成他们的工作。
如果您的项目是围绕没有动力或由于缺乏信心或鼓励而变得没有动力的人建立的，那么您的项目就不太可能奏效。
还有一种哲学说，“面对面的交流是生产中和生产中最有效和最可靠的知识媒介。” 随着技术的进步，人类互动的方式越来越多。然而，这些都没有面对面聊天那么有效。我们的大脑不仅可以从我们的声音中感知声波，还可以检测其他类型的信号。肢体语言和面部表情也很重要。使用异步联系时，误解是正常的。
自 2001 年以来，我们的工作方式有了显着改善。许多公司都有远程操作的员工，即使他们位于不同的时区。异步通信通过问题跟踪器和 Slack 等技术实现，远程面对面通信通过 Skype 和 Hangouts 等软件实现。它永远不会像个人交流那样，但是，它就足够了。世界各地的团队都表明，即使他们没有亲自见面，他们也可以具有竞争力和灵活性。
根据这个原则，“工作软件是成功的主要指标”。
软件开发需要很长时间。因此，公司监控他们的成功是有意义的。这个敏捷理论指出，工作软件是计算成功的主要手段。完整的分析、完整的模板或优雅的模型在转化为可运行的应用程序之前毫无意义。它们可能很重要，但如果您没有将其中的至少一部分投资于功能强大的产品，那么您就没有为您的客户创造价值。
今天，我们往往更进一步。如果工作软件还没有发布，它就没有完成，所以没有取得任何进展。未发布的软件是库存。库存是一种成本，而不是一笔收入或价值。
现在，我们经常超越甚至超越。工作方案没有交出来，就没有完成，也就没有成果。未发布的软件被视为库存。股票是一种费用，而不是收入或升值的来源。
第八个理论如下 - “敏捷过程鼓励长期增长。赞助商、创造者和消费者应该能够永远跟上步伐。”
它表明人们可以生活在他们可以无限期承受压力的环境中。压力表现为各种形状和类型。考虑预算、日程安排、商业政治和同事赞赏等主题。
这些项目中的任何一个都可能是繁重的工作量和压力的来源，并可能导致人们离开，或者这些项目可能存在但似乎并不打扰。这是交易。这并不是说敏捷企业中不存在任何这些问题。这确实意味着它们不能一直发生。例如，敏捷团队可以管理密集、快节奏的工作。但是，在那之后他们应该休息一下。如果组织不断地将团队推向崩溃点，那么它就无利可图，因为团队无法无限期地跟上这样的步伐。
请注意该理论中的“赞助商、开发人员和消费者”一词。因此，每个人都必须能够跟上当前的增长速度。例如，如果程序员为消费者开发功能太快，他们应该遵循它们。放慢速度是实现这一目标的一种方法。另一种选择是将更多时间用于记录和培训用户了解最新功能。
该原则的中心原则是每个相关人员都应该跟上程序的创建速度。
另一种说法是，“对工程能力和良好架构的持续承诺可以提高敏捷性。”
公司通常选择上市时间而不是成功的技术设计。而且，老实说，他们不能被追究责任。我们只是说未发布的软件很贵。最终用户不关心技术能力，它不会为公司带来收入。
然而，如果团队长时间忽视良好的工程设计，他们的步伐和上市时间将开始放缓。他们为响应不断变化的需求而修改商品的意愿将会减弱。他们正在牺牲他们的敏捷性。
这个理论至今仍在使用。根据我的经验，经理和工程师都不确定这个想法。在不考虑良好设计的情况下快速工作在小型项目中是有意义的。但是，如果项目足够大，则值得关注技术卓越。
这并不意味着我们必须在开始编码之前首先创建大型理论设计。随着软件的进步，优秀的设计将会发展。但是，开发人员必须找到时间并且足够专业才能这样做。
另一个原则是“简单性——尽量减少未完成工作量的做法——至关重要”。
优化未完成的工作量可以通过多种方式完成，包括消除过时的流程、重复任务的自动化、使用现有库而不是编写自己的库等等。这一切都节省了时间和资源，使我们能够专注于提供更多价值。
所有组织都在不断努力。但是，需要付出一些努力来确定我们何时以及如何改变。
根据最终规则之一，“最好的架构、规范和设计源自自组织团队。”
该理论是许多先前概念的综合。如果我们希望公司和程序员在一致和高效的基础上相互交流，如果我们希望通过操作应用程序而不是理论模型来评估成功，如果我们希望与受启发的人合作，我们必须有团队提供高质量的软件没有受到上面的太大影响。
团队必须学会在软件生产的所有领域进行自组织，包括通过与公司的沟通收集规范、编写高质量的软件、组织他们的工作等等。这会产生出色的应用程序，因为程序员将开始“拥有”该软件。
开发人员也被视为可以提供规范的装配线员工。然而，软件创建是一项更加困难的任务。让团队自己组织起来执行是必不可少的。
硬币的另一面是敏捷软件开发人员必须专注于这个角色。敏捷团队需要开发人员执行任务而不仅仅是编写代码。
最后，该理论指出“每隔一段时间，团队就会专注于变得更加成功，然后相应地调整和改变其行动。”
自组织团队应定期检查其流程并根据需要进行更改。没有一支球队能完美地运行。一个成熟的敏捷团队将认识到挑战，同时保持信心，然后采取措施改变运营。
这个理论仍然很重要。这就是拒绝承认现状并不断努力改变现状，从而使人员、团队和企业具有竞争力的原因。
您会发现所有敏捷标准今天仍然适用。这就是他们关注经济现实和人性的方式，所有这些都没有太大变化。任何想法，如果有的话，都比它们预期的更进步。例如，我们可以每周甚至定期部署，因为我们现在可以执行比 2001 年多得多的工作。另一方面，自 2001 年以来，某些概念有了新的含义，例如人们没有不再需要在同一个空间中进行有效沟通。