敏捷宣言的背后，有一系列先驱们认为团队需要遵循的原则，一共12条，如下：

1. 最优先要做的是尽早、持续地交付有价值的软件，让客户满意。

2. 欣然面对需求变化，即使在开发后期。敏捷过程利用变化为客户维持竞争的优势。

3. 频繁地交付可工作的软件，从数周到数月，交付周期越短越好。

4. 在团队内外，面对面交谈是最有效，也是最高效的沟通方式。

5. 在整个项目过程中，业务人员必须和开发人员每天都在一起工作。

6. 以受激励的个体为核心构建项目。为他们提供所需的环境和支持，相信他们可以把工作做好。

7. 可工作的软件是衡量进度的首要标准。

8. 敏捷过程倡导可持续开发。

9. 坚持不懈的追求技术卓越和良好的设计，以此增强敏捷的能力。

10. 简单是尽最大可能减少不必要工作的艺术，是敏捷的根本。

11. 最好的架构、需求和设计来自自组织的团队。

12. 团队定期反思如何提升效率，并依此调整自己的行为。

然而在践行敏捷的途中，并不总是一帆风顺。在三番五次宣贯相关的价值观和原则后，团队或者个别成员依然我行我素的情况并不少见。这种时候无需感到沮丧，相反这是帮助团队深化对敏捷理解的很好的机会。比如说我在团队中曾经历过的以下情况。

2019年时，我所在的项目团队在前项目经理的带领下已经“敏捷化”半年，一个迭代周期是三周。然而在年初时，一项重要的功能从预期的三周，整整延迟了三个月才最终上线。中国开发团队每天加班到半夜，美国的PO每天花3~4个小时和中国团队检查跟踪测试bug清单直到美国凌晨，谈话间充斥着火药味，这种情况一直延续到了春节假期期间，整个产品团队苦不堪言，士气低落，随处可听到各式的抱怨。

在功能上线之后，PO团队以及开发团队内部分别做了一次retrospective，反思出了以下几点问题：

1. 需求太大

2. 因为语言，有限的沟通时间和方式（虚拟会议），PO和开发团队对于需求理解存在较大差异

3. 系统架构设计耦合性强，系统的迭代开发无法轻量快速完成

对比上文列出的12条，我们可以看出团队存在的问题其实是没有切实执行或者理解第一、第四、第九条原则。即：

1. 在建立user story的时候，团队就应该考虑到如何向客户尽早交付价值--PO理解了这个原则之后，最直观的结果就是US的平均颗粒度变小。

2. 面对面是最有效的沟通，在虚拟团队无法做到面对面沟通时，也需要尽量移除其他的沟通阻碍--在和领导层沟通过之后，团队在中国新增了一位PO Delegate，并且在迭代中新增了3个需求梳理会议，以保证需求能够被顺畅地理解和梳理。

3. 团队要不断地追求技术卓越和良好的设计，在累赘的设计上继续堆叠功能只会让系统走向衰亡--在和领导层以及开发团队充分沟通过后，我们做出了重构的决定，迁移整个工作流到新的平台，放弃使用过时的技术。重构的第一步在三个月后完成，其后团队在日常迭代中持续对系统进行局部优化。

今年年初时，经过一年的优化，团队稳定在了一个两周的迭代交付速率上，Grooming, Planning, Review and Retro会议都有了固定的节奏，PO团队无需再花费大量的时间跟踪团队交付的质量，而是更关注管理干系人的需求和业务架构，PO与开发同频协作，并且整个团队的Pipeline公开透明，干系人的需求能够得到及时响应和后续跟踪，满意度明显提高。