尽管传统的“瀑布式”方法有一门学科为项目做出了贡献，然后交给下一个贡献者，敏捷呼吁协作式跨职能团队。团队成员之间的开放式沟通、协作、适应和信任是敏捷的核心。尽管项目主管或产品负责人通常会优先考虑要交付的工作，但团队会让主管决定如何完成工作，围绕精细的任务和工作进行自我组织。

敏捷不是由一系列仪式或特定的开发技巧来定义的。相反，敏捷是一组方法，表明他们致力于缩短反馈周期和持续改进。

最初的《敏捷宣言》没有规定为期两周的迭代或理想的团队规模。它只是提出了一套以人为本的核心价值观。如今，您和您的团队如何实现这些价值观——无论是照章进行 Scrum，还是混合看板和 XP 的元素——完全取决于您。

团队选择敏捷，这样他们就可以快速响应市场的变化或客户的反馈，而不会影响一年的规划。“只需足够多的”小型、频繁增量的规划和交付，就可以让您的团队收集有关每项变更的反馈，并以最低成本将其整合到未来的规划中。

但这不仅仅是一场数字游戏，首先也是最重要的是，它与人有关。正如《敏捷宣言》所描述的那样，真实的人际交互比僵化的流程更为重要。与客户和团队成员协作比预定义的安排更为重要。而且，为客户的问题提供切实可行的解决方案比提供详细的文档更为重要。

敏捷团队在共同的愿景下团结起来，然后以他们所知道的最佳方式将其变为现实。每个团队都针对质量、可用性和完整性设定了自己的标准。然后，他们对“完成的定义”说明了他们将以多快的速度完成工作。尽管起初可能令人恐惧，但公司领导者发现，当他们信任敏捷团队时，该团队会有更强的主人翁感，并逐渐达到（或超出）管理层的期望。

2001 年《敏捷宣言》的发布标志着敏捷作为一种方法的诞生。从那时起，出现了许多敏捷框架，例如 Scrum、看板、精益和极限编程 (XP)。每个框架都以自己的方式体现了频繁迭代、持续学习和高质量的核心原则。Scrum 和 XP 受到软件开发团队的青睐，而看板则是 IT 或人力资源等面向服务的团队的宠儿。

未来的敏捷团队将重视自己的效率，而不是固守教义。开放、信任和自主权正在成为想要吸引最优秀人才并充分释放人才潜力的公司的文化货币。这些公司已经证明，只要以正确的原则为指导，各个团队的实践可能会有所不同。

每个团队练习敏捷的方式都应该由需求和文化而决定。事实上，Atlassian 内部没有两个团队有相同的敏捷实践。

尽管我们许多团队采用冲刺来组织工作，根据故事点进行估算，并确定待办事项列表的优先级，但我们并不是顽固的 Scrum 实践者。或者看板。或任何其他商标方法。相反，我们赋予每个团队自主权，让他们精心挑选最有效的做法。建议您也采取类似的方法。

例如，如果您是像 IT 这样以队列为导向的团队成员，那么看板为您的敏捷实践提供了坚实的基础。但是，没有什么能阻止您进行 Scrum 实践，比如与利益相关者的演示会话或定期的回顾。

正确执行敏捷操作的关键是拥抱持续改进的心态。尝试不同的实践，并与您的团队就这些实践进行公开、诚实的讨论。保留那些行之有效的实践，抛弃无效的实践。

我们相信每个团队都必须开辟自己的敏捷之路，因此在这个网站上并没有高度规范性的信息。但是，您会发现，这是一份关于迭代工作、为客户交付价值和实现持续改进的实用指南。阅读它，与您的团队讨论，然后做出有意义的改变。

您还将找到有关将这些实践与 Jira 相结合的教程，Jira 是我们为高绩效团队提供的项目管理工具。想要设置看板？从团队的速度报告中获取洞察信息？所有内容都在教程中。

您的方向是对的，继续努力！