数据结构
网络
关系型数据库管理系统
操作系统
Java
MS Excel
iOS
HTML
CSS
Android
Python
C语言编程
C++
C#
MongoDB
MySQL
Javascript
PHP
物理学
化学
生物学
数学
英语
经济学
心理学
社会学
服装设计
法律研究解释敏捷软件开发流程及其原则
**敏捷宣言**首次出现于2001年。它旨在改变软件创建流程。该宣言有四个关键方面，但很少有人了解**12条敏捷原则**。它们更具体地解释了可以进行敏捷产品开发的过程。多年后，几乎所有公司都声称提供“敏捷服务”，但大多数只是对敏捷宣言的理念和概念敷衍了事。软件开发行业也发生了巨大变化。值得重新审视敏捷标准，以检查其含义以及它们是否仍然适用。
及时且持续地交付有价值的软件
根据第一条原则，“我们的首要目标是通过及时且持续地交付有用的应用来满足客户。”
我们通常在别人的时间和金钱上设计应用，以尽可能地提供帮助。如果我们花费大量时间来生产产品，客户很可能会感到不满意。这现在比以往任何时候都更加适用。客户不仅重视流程中的早期和持续反馈，而且还要求快速执行。并且每次交付都应为客户的生活带来价值。例如，客户不关心您调整登录页面的想法。他很高兴他现在可以通过她的社交媒体帐户登录。
Plutora 弥合了 DevOps 和敏捷之间的差距
管理敏捷、DevOps 和瀑布方法之间的关系可能很困难。Plutora 提供了一个共享的环境，团队可以在其中快速工作。
用户越来越依赖应用程序来执行各种任务。他们通常习惯于定期提醒。因此，如果他们申请更新，他们将没有足够的耐心等待数月才能看到它们。
接受变化
根据第二条原则，“我们必须接受不断变化的环境，即使是在生产后期出现的变化。”敏捷系统利用转型来为客户的战略优势服务。”
在快速变化的环境中，没有人能够预测软件的规格会是什么。另一方面，企业不喜欢意外。他们不喜欢在不再重要的商品上花费资金。如果我们拥抱进步，该平台将为客户提供战略优势，因为它满足当前和最近的期望，而不是去年的期望。
多年来，关于环境快速变化的说法确实属实。社会在发展，经济在发展，我们的企业在发展，人们也在发展。与其试图阻止或减缓此操作，不如拥抱并利用它们来造福我们自己和我们的客户。
更快、更统一的交付
以下原则为“定期发布可工作的应用程序/软件，从几天到几个月，重点放在较短的时间范围内。”
这个理论似乎是先前原则的重复，在某些方面确实如此。但是，先前的理论指出，我们必须尽快开始提供有用的应用程序。这个理论更深入地探讨了持续交付需要什么。它建议尽快发布应用程序的新更新。这意味着更新更少，发布更少，意味着故障潜入的机会更少。更频繁的发布也提供了更多获得客户反馈的机会。如果您在几个月内都没有获得任何更新的反馈，那么您将有更多工作要做才能处理这些评论。
随着时间的推移，这个理论变得更加进步。“几个月”的发布周期不再被认为是敏捷的。行业标准已变为定期或每周发布。
开发人员和业务人员共同协作
另一条理论说，“业务人员和程序员应在项目期间定期协作。”
程序员经常与业务人员隔离。专家被安置在他们中间，以便他们能够将营销术语翻译成程序员能够理解的语言。这就是鼓励公司消除这些障碍并使开发人员和公司能够每天联系的原则。这培养了更大的共享意识和欣赏。
我们希望您在孩提时代玩过传话游戏；每个人都知道，每一次沟通阶段都会导致知识损失。与公司和开发人员密切合作减少了（但并没有消除）这种风险。在当今分散的团队世界中，我们必须努力定期进行协作。尽早识别误解并彼此频繁获得反馈有助于产生良好的结果。
充满激情的个人
这条原则建议程序员“构建围绕充满激情的个人的程序”。我们应该为他们提供他们需要的环境和资源，并相信他们能够完成任务。”
敏捷团队通常经验丰富，能够开发出高质量的应用程序。这需要一定程度的信任。但是，如果您不信任工程师，为什么还要聘用他们呢？在正确的指导、环境和软件下，积极的开发人员会感到有权正确地完成他们的工作。
如果您的项目围绕着缺乏动力或由于缺乏信心或鼓励而变得缺乏动力的个人构建，那么您的项目不太可能成功。
面对面沟通
还有一个哲学认为，“面对面沟通是向生产以及生产内部传递知识最有效和可靠的媒介。”随着技术的进步，人类互动的方式越来越多。但是，这些都不如面对面聊天有效。我们的思想不仅可以感知来自我们声音的声波，还可以检测其他类型的信号。肢体语言和面部表情也很重要。使用异步通信时，误解是正常的。
自 2001 年以来，我们的工作方式有了很大的改进。许多公司都有远程工作的员工，即使他们身处不同的时区。问题跟踪器和 Slack 等技术支持异步通信，而 Skype 和 Hangouts 等软件支持远程面对面通信。但是，它永远不会像面对面沟通那样，但它足够了。世界各地的团队正在证明，即使他们没有面对面地见面，他们也可以具有竞争力和灵活性。
可工作的软件
根据此原则，“可工作的软件是成功的首要指标。”
软件开发需要很长时间。因此，企业有必要监控其成功情况。这条敏捷理论指出，可工作的软件是衡量成功的首要手段。在将其转换为可工作的应用程序之前，已完成的分析、完整的模板或优雅的模型毫无意义。它们可能很重要，但如果您没有将其中的一部分投入到可运行的产品中，那么您就没有为您的客户创造价值。
如今，我们通常更进一步。如果可工作的软件尚未交付，则表示它尚未完成，因此没有取得任何进展。未发布的软件是库存。库存是成本，而不是收入或价值的一部分。
现在，我们经常超越甚至超越。如果可工作的程序尚未交付，则表示它尚未完成，因此没有取得任何成就。未发布的软件被视为库存。库存是成本，而不是收入或增值来源。
长期发展
第八条理论如下：- “敏捷流程鼓励长期增长。赞助商、创建者和消费者应该能够永远保持这种速度。”
它表明人们可以生活在一个他们不断受到可以承受压力的环境中。压力以各种形状和形式表现出来。考虑预算、时间表、企业政治和同事欣赏等主题。
任何这些项目都可能成为繁重工作和压力的来源，并可能导致人们离开，或者这些项目可能存在并且似乎没有造成困扰。事情是这样的。这并不是说任何这些问题都不可能出现在敏捷企业中。这确实意味着它们不可能一直存在。例如，敏捷团队可以管理一段密集的、快节奏的工作时间。但是，此后他们应该休息一下。如果组织不断将团队推向崩溃的边缘，那将无利可图，因为团队无法无限期地保持这种速度。
请注意理论中的“赞助商、开发人员和消费者”一词。因此，每个人都必须能够跟上当前的增长速度。例如，如果程序员为消费者生产功能的速度过快，他们应该跟随他们。减速是一种实现此目的的方法。另一种选择将是投入更多时间来记录和培训用户了解最新功能。
这条原则的核心思想是，所有相关人员都应跟上程序创建的速度。
技术卓越
另一句谚语是，“持续致力于工程能力和良好的架构可以提高敏捷性。”
公司通常选择将上市时间置于成功的技术设计之上。老实说，他们无法为此负责。我们刚刚说过未发布的软件很昂贵。最终用户不关心技术能力，它也不会为公司带来收入。
但是，如果团队长时间忽视良好的工程设计，他们的速度和上市时间将开始放缓。他们根据不断变化的需求修改商品的意愿会下降。他们正在牺牲自己的敏捷性。
该理论至今仍在广泛使用。根据我的经验，管理者和工程师对这一理念都存在不确定性。在小型项目中，快速工作而不考虑良好的设计可能是合理的。但是，如果项目足够大，那么关注技术卓越性是值得的。
这并不意味着我们必须在开始编写代码之前先创建大型的理论设计。随着软件的进步，良好的设计将会发展。然而，开发人员必须抽出时间并具备足够的专业性来做到这一点。
简洁性
另一个原则是“简洁性——最大限度地减少未完成的工作量——至关重要”。
优化未完成的工作量可以通过多种方式实现，包括消除过时的流程、自动化重复性任务、使用现有库而不是自己编写等等。所有这些都能节省时间和资源，使我们能够专注于提供更多价值。
所有组织都在持续努力。但是，确定何时以及如何进行改变需要付出一些努力。
自组织团队
根据最终规则之一，“最佳的架构、规范和设计源于自组织团队”。
该理论是许多先前概念的综合。如果我们希望公司和程序员能够持续高效地相互配合，如果我们希望通过运行应用程序而不是理论模型来评估成功，如果我们希望与富有创造力的人员合作，那么我们必须拥有在没有太多来自上层干预的情况下交付高质量软件的团队。
团队必须学会在软件生产的各个方面进行自组织，包括通过与公司沟通收集规范、编写高质量软件、组织工作等等。这将带来优秀的应用程序，因为程序员将开始“拥有”软件。
开发人员也被视为可以接受规范的流水线员工。然而，软件开发是一项更加复杂的任务。允许团队自行组织执行至关重要。
另一方面，敏捷软件开发人员必须专注于这一角色。敏捷团队要求开发人员承担任务，而不仅仅是编写代码。
定期反思和调整
最后，该理论指出，“团队定期专注于如何变得更加成功，然后相应地调整和改变其行动”。
自组织团队应该定期审查其流程，并在需要时进行更改。没有一个团队能够完美运行。成熟的敏捷团队会认识到挑战，同时保持信心，然后采取措施改变运营。
该理论仍然具有重要意义。这就是使个人、团队和企业具有竞争力的原因，他们拒绝承认现状，并不断努力改变现状。
它们仍然都很重要
您会发现所有敏捷标准在今天仍然适用。这就是它们关注经济现实和人性的原因，所有这些都没有发生太大变化。如果有任何想法，它们比预期的更具进步性。例如，我们可以每周甚至定期部署，因为我们现在可以执行比 2001 年多得多的操作。另一方面，自 2001 年以来，某些概念有了新的含义，例如，人们不再需要在同一个空间才能有效地沟通。
182 次浏览
