结束语

相信一切，
无论你从何处读到，
无论谁说的，
即使是我所说的，
除非它符合你自己的理性
和你自己的常识。

—乔达摩·悉达多（佛陀）

最关键的成功因素

在反思各种成功因素时，归根结底都离不开沟通与持续反馈。虽然技术上的反馈可以通过测试等方式获得，但更重要的是获取团队成员以及项目个体的真实反馈。

回顾会议（Retrospectives）是实现这种交流的绝佳方式。然而，我们最能从中学习的，仍然是直接与项目成员进行对话。问题的根源往往具有多重层面，这些层面及其对应的解决方案，通常人们心里都清楚，只是表达得不够清晰（甚至根本无法表达）。要取得成功，就必须由变革推动者去挖掘出这些隐含的知识。

稳定性其实是负面的！

另一个重要观点是：稳定性比人们想象的更具负面影响。每当有人让我“稳定”某件事——比如流程或架构时，我都会怀疑：为什么偏偏要让我来帮助这件事走向终结？只要我们还有学习的空间，事物就必然会发生变化，因此它们不可能真正稳定。

变革有时需要打破规则！

有时候，当我学到新东西时，会感觉必须做出某些改变。但实现这种改变，偶尔就需要打破规则。规则绝不应成为阻碍我们向更好方向改进的障碍，尽管这意味着我们必须有勇气，走一条艰难的道路。尤其是在大公司中，很多事情安排得过于周密，许多可能性被完全排除，让人觉得突破无望。但其实，只有当我们不去尝试时，才真的不可能。

不要过度规定流程

不知为何，人们总认为大型项目必须采用更正式、更僵化、更繁琐的方式执行，而小型项目则可以灵活一些。根据我的经验，最关键的是不要过度规定流程，也不要让太多规则束缚住流程。也许是因为我常常忙于协调各个子团队，所以我通常让各子团队自行决定使用何种内部开发流程。如果我要为每个子团队都制定详细流程，那我可能需要为每个团队配备一个流程教练。因此，我更关注整体项目的敏捷性，而不是拘泥于流程本身。

关注人的因素

在小型项目中，人们往往依赖自己的常识和直觉。然而，所有软件问题本质上都是人的问题，无论发生在大型还是小型项目中。这也是敏捷方法论强调人的原因。总体而言，所有敏捷方法（无论是否规模化），本质上都是关于对变化的态度，以及对人的态度。但每个人、每个团队都不同，因此在提出具体改变要求时，必须尊重这些差异。

大型项目

在整个课程中，我分享了自己在大型项目中应用敏捷的最佳实践。但这些并非固定模板——对我和部分同事有效的方法，并不一定适合所有人。因此，如果某个实践不奏效，首先要分析其背后的初衷；然后评估这些目标对当前项目的重要性。如果这些目标依然重要，那就寻找另一种能够达成同样目标的方法。真正关键的是这些实践背后所体现的价值体系。除此之外，即便面对大型项目，最重要的依然是遵循自己的常识和直觉（哪怕需要勇气）。因此，当读者的常识和直觉与本课程所述内容相悖时，应坚持自己的判断。你会突然发现，进入大型项目变得轻松自如。