问对敏捷的幻想破灭了；你如何为1.1版之后的生活做好准备？

EN

我认为您所经历的非常类似于其他许多最初过渡到敏捷的团队。在我的上一家公司，当我们被告知要敏捷时，几乎也发生了同样的事情。这篇关于货物崇拜敏捷方法的文章可能与你在1.1之前经历过的一些事情产生共鸣。关键是，你不能简单地遵循写下的规则/指导方针，而不退一步，考虑什么对你的团队和你的具体情况来说真正重要。

关键是敏捷方法从来没有说过你不能有文档。这似乎是因为与瀑布相比，它消除了90% (如果不是更多)文档。这是一件好事，但是有些团队把“没有文档”看得太过字面意思了，而且走得太远了，消除了99.9%的文档。然后，他们把敏捷作为无文档化产品的原因。

我只是做了一个谷歌搜索，以找到本文讨论敏捷/精益文档。，并在一年前找到了另一个问题和我的答案，涉及到了同样的话题。不管我写了什么，我的底线是，我相信设计文档是重要的，但是对于组织内存来说，并且只有在足够高的水平上。当在编写代码之前编写它们时，它们几乎完全无用。

眼光和长远的方向也是如此。敏捷方法论表明，大的前期设计是不好的。他们的意思是不要试图用单词“勾勒出”应用程序的每一个螺母和螺栓，然后尝试对所有这些进行编码。那不管用。但是很多团队，包括我自己的团队，都把这一点理解得太过字面意思了，当他们开始新的项目时，他们会跳到编码中，而不需要定义总体架构，也没有想出最终产品应该是什么样子。底线是，在敏捷中，您应该拥有足够的文档，以便它能够帮助您前进，提高效率(例如，提出一个愿景，以便团队能够朝着一个共同的目标努力，而不必回去重新做工作)，但是不要仅仅为了生成大量的设计规范而创建文档，因为这样的设计规格( a)没有人会阅读和( b)甚至在软件发布之前就会完全过时。

在它的核心，敏捷是难以置信的简单。它是关于简短的迭代，消除浪费和持续改进。你应该不断地回顾是什么浪费了你的时间，降低了你的效率，并修正了它。如果团队看到他们只花了两个星期的时间制作文档，而这些文档并不是任何人所需要的，那就是浪费。但是，如果团队看到客户调用和他们自己无法理解所编写的代码而减慢了他们的速度，那么可能缺乏文档就是浪费。

你所做的不是敏捷的，让我们回顾一下你的观点：

• 轻松文档-敏捷并不是关于“没有文档”。它是关于创建不需要文档的代码，只创建必要的文档。
• 不要设计它，直到你需要它-在敏捷，这并不意味着什么。仅仅因为你以后在设计，并不意味着你根本就没有设计。
• 保持赛车到下一个冲刺-敏捷不是关于赛车到下一个冲刺。敏捷的重点是创造稳定和可持续的发展步伐。因此，无论软件有多大或多复杂，团队都可以添加新功能，并以与前几年相同的速度提高质量。
• 留下很少的文档--同样，敏捷就是让团队决定他们的工作需要哪些文档。其他方法的主要问题是由其他人来决定需要哪些文档，因此文档给出的问题往往比解决的问题多。
• 小小的远见--这是错误的。开发人员本身并不需要长远的眼光。但至少产品负责人应该着眼于未来一两年，想象一下他们想要什么样的软件。没有必要让开发人员负担这么多的“什么-如果”。
• 关于为什么进行设计决策的糟糕记录--在敏捷中，这些记录存在于代码、开发人员的内存和创建的文档团队中，因为决策非常复杂，以至于团队决定将其记录下来。

因此，要回答您的问题:当您从未执行敏捷时，您不会对敏捷感到失望。

幻灭来自于幻想:-)

我认为(戴着Scrum眼镜)在这些问题上

1. 主要原因是“做的定义”不完善。如果以后的sprint需要在当前sprint之后清理，那么对我来说，sprint没有完成它的工作。
2. 通过解散一个成功的团队做出了贡献。这是填充产品的经典方法之一。

对我来说，敏捷的一个关键特征是保持可持续的速度。这来自于了解团队的速度，他们能在每一次冲刺中取得什么。团队的重大变化意味着过去的速度作为未来的预测指标的可靠性发生了巨大的变化。这种可持续的速度包括维护，同时也意味着没有突然的切换.

当然，团队会随着人的来去和技能需求的变化而进化。但解散整个团队让我战栗。