敏捷宣言简介：
在本教程中，我们将深入探讨敏捷和敏捷宣言的细节。我们将看到宣言所说的内容以及其中所载的价值观和原则是什么。
敏捷软件开发是一种软件开发方法，通过自组织和跨职能团队及其客户 / 最终用户的协作努力，需求和解决方案得以发展。它倡导适应性规划，进化发展，早期交付和持续改进，并鼓励对变化做出快速而灵活的反应。敏捷宣言中所支持的4 个价值观和12个原则源于并支持广泛的软件开发框架，包括Scrum, XP, Lean, 和看板 (Kanban)。
宣言的措辞非常谨慎，以最小的词语捕捉敏捷的本质，内容如下 -
“我们正在通过这样做并帮助其他人来开发软件，从而发现更好的方法。通过这项工作，我们得出以下价值：
也就是说，虽然右边的项目有价值，但我们更重视左边的项目。“
正如我们所看到的，这些都是非常简洁和简单的陈述，并且非常清楚地表达了创始人想要推广的内容。通常，传统的项目计划是僵化的，它们强调程序和时间表，但敏捷宣言恰好传播相反的事物。
它更喜欢集中：
我们将探索这种新的范式，创始人希望通过深入理解敏捷的价值观和原则来提升这一范式。
这四个值以及12条原则指导敏捷软件交付。我们现在将详细讨论每个值。
个人和互动比流程和工具更受欢迎，因为它使流程更具响应性。如果个人是一致的，一旦他们相互理解，那么团队就可以解决工具或流程的任何问题。
但如果团队坚持盲目坚持这些过程，那么它可能会引起个人之间的误解，并造成意想不到的障碍，从而导致项目延误。
这就是为什么总是优先考虑团队成员之间的互动和沟通，而不是盲目地依赖于指导前进方向的流程。实现这一目标的方法之一是让一位参与的产品所有者工作，并与开发团队合作做出决策。
允许个人自己做出贡献也可以让他们自由地展示他们可以带到桌面上的东西。当这些团队互动针对解决常见问题时，结果可能非常强大。
传统的项目管理涉及全面的文件，这些文件需要滞后数月。这通常会对项目交付产生负面影响，导致延迟是不可避免的。
为这些项目创建的文档类型非常详细，因此创建了许多文档，其中许多文档在项目进度期间甚至没有被引用。这是一个不必要的邪恶，项目团队过去常常与之相处。
但这也加剧了交付方面的问题。重点是文档到这种程度，因为团队希望最终得到的成品按规格100％。这就是为什么重点是捕获详细的所有规格。
但是，最终产品过去与预期完全不同，或者会失去相关性。这就是为什么敏捷说工作软件比衡量大量文档更能衡量客户期望的原因。
这并不意味着文档不是必需的。它只是意味着工作产品在任何一天都能比几个月前创建的文档更好地指示与客户需求和期望保持一致。这也意味着团队响应并随时准备适应变化，同时在sprint结束时向客户端显示工作软件。
在短跑期间未能测试产品需要在下一个冲刺中花费大量成本和精力。部署功能后，这些变化的成本将在很大程度上进一步提高。
谈判意味着细节仍在被捕获，尚未最终确定。仍有重新谈判的余地。但是一旦谈判结束，就不可能进行讨论。敏捷所说的是，不是谈判，而是去合作。
协作意味着仍有讨论的空间，沟通正在进行中。
不是一次性的事情。它的作用是，它具有双重优势 - 虽然它可以帮助团队在早期阶段进行课程修正，但它可以帮助客户改善他们的愿景并在需要时重新定义他们的要求。项目。
另一个方面是，虽然传统的软件开发模型在开发过程中在文档和协商阶段开始涉及客户，但在项目开发过程中它们并不参与。
一旦要求被冻结，他们只有在产品准备好后才能看到产品。敏捷通过允许客户参与整个生命周期来突破这一障碍。
这有助于敏捷团队更好地满足客户需求。实现这一目标的方法之一是通过专注且相关的产品所有者，他们可以实时帮助团队澄清并使工作与客户优先级保持一致
标准的思维过程是变化是一项昂贵的事情，我们应该不惜一切代价避免变化。这就是不必要的重点是文档和精心制定的计划，坚持时间表和产品规格。
但是，正如经验也告诉我们的那样，变化大多是不可避免的，而不是从中逃避，我们应该尝试接受它并为它做好计划。
敏捷允许我们进行这种转变。敏捷认为改变不是费用，而是一个有助于改进项目的受欢迎的反馈。这是不可避免的，相反，它增加了价值。
通过敏捷提出的短期冲刺，团队可以在短时间内获得快速反馈并转移优先级。可以从迭代到迭代添加新功能。
我们为什么要做这个？因为从未使用过使用瀑布方法开发的大多数功能。这是因为瀑布模型遵循计划，而这是我们知道最少的阶段。
敏捷也计划，但它也遵循及时的方法，在需要的时候进行规划。随着冲刺的进展，计划总是乐于改变。
在宣言创建之后添加了12个敏捷原则，以帮助和指导团队过渡到敏捷，并检查他们遵循的实践是否与敏捷文化一致。
以下是敏捷联盟2001年发布的原始12条原则的文本：
＃1） 我们的首要任务是通过尽早和持续交付有价值的软件来满足客户。
＃2） 欢迎不断变化的要求，即使是在开发的后期。敏捷流程利用变化来实现客户的竞争优势。
＃3） 经常提供工作软件，从几周到几个月，优先考虑更短的时间尺度。
＃4） 商业人士和开发人员必须在整个项目中每天一起工作。
＃5） 围绕有动力的个人建立项目。为他们提供所需的环境和支持，并相信他们能够完成工作。
＃6） 向开发团队内部和内部传达信息的最有效和最有效的方法是面对面交谈。
＃7） 工作软件是进步的主要衡量标准。
＃8） 敏捷过程促进可持续发展。赞助商，开发者和用户应该能够无限期地保持稳定的步伐。
＃9） 持续关注技术卓越和良好的设计可提高灵活性。
＃10） 简单性 - 最大化未完成工作量的艺术非常重要。
＃11） 最好的架构，要求和设计来自自组织团队。
＃12） 团队定期反思如何变得更有效，然后相应地调整和调整其行为。
这些敏捷原则为开发团队提供了实用指导。
组织12条原则的另一种方法是在以下四个不同的组中考虑它们：
＃1） 我们的首要任务是通过早期和持续交付有价值的软件来满足客户 - 客户显然会很高兴看到每个sprint交付一个正在运行的软件，而不是在最后经历一个模糊的等待期只有他们才能看到产品。
在这里，客户可以被定义为项目发起人或为开发付费的人。产品的最终用户也是客户，但我们可以区分这两者，因为最终用户被称为用户。
＃2） 欢迎不断变化的要求，即使是在开发的后期。敏捷流程利用变化来实现客户的竞争优势 - 可以在整体时间表中实现变更，而不会造成太多延迟。
由于敏捷团队相信质量高于一切，他们宁愿根据客户要求整合变更和交付，而不是避免变更并交付不能满足业务需求的产品。
＃3） 经常提供工作软件，从几周到几个月，优先考虑更短的时间 - 这是由冲刺工作的团队负责。由于冲刺是时间限制的迭代，并在每个冲刺结束时提供工作软件，因此客户会定期了解进度
＃4） 业务人员和开发人员必须在整个项目中每天协同工作 - 当两者协同工作时，会更好地做出决策，并且两者之间存在持续的反馈循环，用于校正和改变敏捷性。利益相关者之间的沟通始终是敏捷的关键。
＃5） 围绕有动力的个人建立项目。为他们提供所需的环境和支持，并信任他们完成工作 - 您必须支持，信任和激励团队。一个积极进取的团队更有可能取得成功，并且会提供优质的产品，而不是那些不愿意尽力而为的不快乐的团队。
其中一种方法是让开发团队自我组织并自己做出决策。
＃6） 向开发团队内部和内部传达信息的最有效和最有效的方法是面对面交流 - 如果团队在同一地点并且可以面对面地进行讨论，那么沟通会更好，更有影响力。它有助于建立信任并在各利益相关方之间建立理解。
＃7） 工作软件是进步的主要衡量标准 - 工作软件胜过所有其他KPI，是完成工作的最佳指标。
＃8） 敏捷过程促进可持续发展。赞助商，开发者和用户应该能够无限期地保持稳定的步伐 - 强调交付的一致性。团队应该能够在项目持续期间保持他们的速度，并且在最初几次冲刺后不会烧坏。
＃9） 持续关注技术卓越和良好的设计提高敏捷性 - 团队应具备所有技能和良好的产品设计，以应对变化并生成高质量的产品，同时能够整合变更
＃10） 简单性 - 最大化未完成工作量的艺术是必不可少的，并且足以满足已完成的定义。
＃11） 最好的架构，要求和设计来自自组织团队 - 自组织团队获得授权并拥有自己的工作。这导致团队成员之间的开放式沟通和定期分享想法。
＃12） 团队定期反思如何变得更有效，然后相应地调整和调整其行为 - 自我改善导致更快的结果和更少的返工。
以客户为中心，注重沟通，使敏捷取得了今天可见的成功。它是一种经过验证的技术，不仅在软件交付领域，而且在其他行业也有影响，如今它甚至成为一个独立的行业。
warren2lynch
iThome鐵人賽
看影片追技術