敏捷的真相

　　不，敏捷宣言于2001年出版，Scrum模式语言在1998年已经开始使用，情节模式语言（ XP的前身）是在 1995开始使用，Tom Gilb的Evo方法可以追溯到1976年。

　　只要你喜欢敏捷你可以有尽可能多的文件。文档只是另一种交付，如果它给你带来价值，那么像对待其他其他任何东西一样对其进行排期和产品化。请注意：文件往往可能不会被阅读，因而无法沟通，因此它常被用作防御工具，通常作为一个大型软件项目（返工后）二次思考。

　　不是，敏捷可能意味着更多的设计。设计是与生俱来的，一路过关斩将，在每一个规划会议后不断发展。敏捷确实意味着必须在5分钟内结束前期大而全设计。

　　不是，敏捷反而意味可能有更多的规划。再次规划是分散在整个开发工作，而不是在前面，这是每个人的工作，而不是一个两个人的工作。

　　不，敏捷需要团队有更多的纪律，通常由产品经理或业务分析员扮演一个特定的角色来管理项目或业务分析。如果开发人员只做自己的事情，这些角色就没有发挥用处。

　　用户故事有没有合适的尺码，这对于每个团队是不同的。

　　如果你正在做Hard core Scrum，答案是这样。如果你是以敏捷的方式（称为Xanpan ），让故事跨越Sprint会提高流动性。你可以有故事跨越Sprint，但是不要变成经常发生的现象，需要尝试将它们分解成更小的部分。

　　没有，但背后为了吸引眼球肯定有营销成分，Xanpan是一个看板/ XP的混合，XP是肯定和Scrum不同。

　　不是，敏捷最适合有固定期限的项目环境。

　　不是，敏捷最适合在旧项目二次开发的环境。当然改造自动化单元测试是很难。

　　不是，需要你让自己处于一个稳定的状态，就像你在一个废弃项目需要改建的环境中。

一般理想的敏捷项目开始于一个旧项目改造的系统，有3至6个月的固定期限，开发已经开始，但是这时需求还不是十分清楚。