敏捷开发指南

敏捷是一种迭代式的项目管理和软件开发方法，它可帮助团队减少开发中的障碍，更快的向客户交付价值。敏捷团队不会把所有的需求都集中在一个”大版本“发布，而是通过少量多次的方式交付增量，并根据市场反馈调整开发方向。正是这种持续评估需求、计划和结果的方式，帮助敏捷团队建立起快速响应变化的机制。

敏捷相关文章

敏捷宣言是否依然适用？

当下的我们正处在一个持续创新的世界，面对技术变革洪流，有时候我们可能会产生思考：敏捷宣言是否仍然应该成为我们的指南？

Scrum 框架概述

Scrum 是符合敏捷开发原则的一种典型且在全球使用最为广泛的框架，它用于复杂产品的开发。

什么是看板（Kanban）管理方法

为了帮助更多企业更好的了解敏捷，本章节将给大家系统的分享看板管理方法系列知识。

敏捷项目管理的概念，以及与传统项目管理的区别

较之瀑布等传统项目管理模式，敏捷是“适应性的”，而非“预设性的”。

什么是产品管理，产品管理者需要具备哪些能力？

敏捷开发为产品管理提供了一种灵活、迭代、实验和学习的方式，而产品管理为敏捷开发提供了一种清晰、有价值、可测试和可交付的目标。

什么是规模化敏捷

多年来，软件研发团队已经证明，使用 Scrum 和看板等敏捷框架可以更快地向客户交付解决方案，并且能更好的预测、更快地响应变化。

敏捷调研报告

敏捷实践调研报告提供了一个窗口，让我们可以看到敏捷在这个动荡时期所扮演的角色，并反思敏捷实践如何能够帮助企业适应市场变化和脱颖而出。

敏捷的优势有哪些

尽管出现超过十五年，但敏捷实践仍一如既往的重要。从瀑布转型成敏捷有诸多好处，任何一个有经验的开发人员都会这样告诉你，但对于开发组织之

打造一流的敏捷开发团队

团队合作对于交付出色软件来说非常关键，而在优秀的敏捷团队普遍都是站在集体的角度去思考和工作，而不是以个体的形式。

使用 PingCode 软件学习敏捷

现在您已经学习了一些敏捷概念，是时候将这些知识付诸实践了。我们的教程重点介绍如何使用 PingCode 这一 标准化敏捷项目管理软件

传统的“瀑布式”方法把软件项目的开发分隔成各个开发阶段，只有当上一阶段所有需求都按标准完成之后，才会交付给下一环节的团队，两个团队之间几乎是割裂的。而敏捷则是由跨职能团队一同协作完成所有工作。开放式的沟通、协作、自组织、以及相互信任是敏捷的核心，尽管有时候产品负责人是工作优先级的决定者，但要以何种方式完成这些工作是敏捷团队自己决定的，他们会自组织的对任务进行拆解、分配、完成。

敏捷并不是由一组仪式或特定的开发技术定义的。相反，敏捷是基于敏捷宣言定义的价值观和原则等一系列方法和实践的总称，它展示了对紧密反馈周期和持续改进的承诺。

《敏捷宣言》并没有规定两周的迭代周期或理想的敏捷团队规模，它只是制定了一套以人为本的核心价值观。你和你的团队可以自由选择践行这些价值观的方式——无论是 Scrum、看板，还是混合一起使用，这都没有问题，完全取决于你。

为什么选择敏捷

团队选择敏捷的好处在于，可以快速的响应市场变化以及客户反馈，而不用频繁的调整年度计划。敏捷方法中“恰到好处”的规划，以及少量多次的的增量交付方式，让团队收集到每次发布的反馈，并以最低的成本将其加入到未来的计划中。

但这并不是形式主义——它的核心以人为本。正如《敏捷宣言》所描述的，真实的人际沟通比僵化的流程更重要、与客户和队友的协作比自己提前的规划内容更重要、为客户的问题提供有效的解决方案比超详细的文档更重要。

敏捷团队因为一个共同的项目目标而建立、相互团结，然后以他们认为的最好的方式将这个目标变为现实。每个团队都为质量、可用性和完整性设定了清晰的标准。然后，他们通过“完成定义”预估自己将以多快的速度完成工作。在刚开始组建敏捷团队时会遇到很多困难，但当公司领导者信任敏捷团队时，会发现该团队会展现出主人翁意识，并达到（或超过）管理层的期望。

敏捷的过去和未来

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

如今，许多敏捷团队将来自几个不同框架的实践结合起来，并结合团队独有的特色进行工作。比如，一些团队采用一些敏捷仪式（如站立会议、迭代回顾、迭代待办列表等）进行开发工作，而另一些团队则创造了一种新的敏捷实践（如将敏捷宣言应用于营销活动）。

未来的敏捷团队一定是更重视效率，而不是僵化的坚持原则。开放、信任和自组织正在成为那些希望吸引最优秀人才并充分利用他们的公司的文化优势。这些公司已经证明，只要他们遵循正确的原则，不同团队的做法可能有所不同，但并不影响什么。

PingCode 谈敏捷

每个团队实践敏捷的方式应该根据他们的需求和文化而决定。事实上，PingCode 内部都不存在敏捷实践一模一样完的团队。

尽管我们许多团队在迭代中组织他们的工作，估算故事点，并确定迭代待办事项中工作项的优先级，但我们也算不上Scrum、Kanban以及其他敏捷方法的铁杆实践者。相反，我们会赋予每个团队自主权，以挑选最适合自己、最有效的实践。我们也建议大家采取类似的方法。

例如，如果你在像 IT 这样流水线形式的团队中，看板天生就为你的敏捷实践提供了极大的便利。但这并不代表你不能尝试加入一些有益的 Scrum 实践，比如与利益相关者组织的迭代评审会或迭代回顾。

正确实践敏捷的关键是具备持续改进的心态，去尝试不同的实践，并与团队进行公开、透明的讨论，保留那些有效的，扔掉那些不起作用的。

如何游览”敏捷大学“

我们相信每个团队都将走上，或正走在自己的敏捷之路上。可能你不会在这个网站上找到100%标准的方法指导，相信你也明白这需要经过一次次迭代。这份指南旨在为客户提供价值，我们会根据大家的反馈持续改进。希望你在阅读之后，与你的团队讨论，并做出对你有意义的改进。

除此之外，你还可以找到有关将这些实践与 PingCode 工具相匹配的教程，PingCode 是我们面向敏捷开发团队打造的项目管理工具。想要体验看板？Scrum？从团队效能度量报告中获取有效信息？这一切都可以通过“敏捷大学”来了解。