敏捷开发方法的误解

  有的人对采用敏捷开发是否能真的有效提高效率并生产出成功的产品表示怀疑。他们认为，在敏捷方法中，由于没有经理的管理和约束，团队和项目必然是一团糟，仿佛越是上层越有这种想法。敏捷开发的理念是信任开发团队，信任每一个人。试想一下，如果你们这个团队对你们的项目充满激情，而老板又充分信任你们，那么你们必会将更多的时间花在如何有效地提高生产率、如何创新地完成某个功能等方面，而不是按老板的意思按部就班地工作了，这样还会节省很多时间并简化流程，例如开会、向老板报告、请示老板、等老板批准等。就像咱们刚才的那个游戏结果所揭示的那样，充分调动参与项目的人员的主动性，让他们自我组织、自我管理，由团队自身来掌握项目进度，比老板整天催促反而更有效率。
  当然，敏捷开发的团队也需要管理，但这些管理是非命令式的，很多时候是战略指导和服务性质的。在敏捷开发中，管理者对团队和项目的管理表现在挑选合适的人、为团队创造一个开放而自由的工作环境、经常性的反馈、为团队建立评估和奖励机制、当团队有方向性错误时能及早发现并纠正、容忍错误的发生等
    还有一种误解，认为敏捷开发就是完全不需要计划、文档和架构设计。这种看法也是不对的。敏捷开发也需要文档，也同样要计划。但我们要明白，计划赶不上变化，在这样一个不断变化的情况下要做出详细的计划是不可能的。因此敏捷方法认为不值得在这些因素上花费过多的资源，可工作的软件才是敏捷方法关注的重点。敏捷团队依靠变化来获取活力，他们更愿意使设计保持尽可能的干净、简单。基于以上的原因，采用敏捷方法的项目初始设计是比较粗略的，并需要使用许多测试手段作为辅助，这就保持了设计的灵活性和易于理解性。团队可以利用这种灵活性持续地改进设计，以便于每次迭代结束时的系统都具有最适合于那次迭代中需求的设计。摆脱一切对软件开发不合理的束缚就是敏捷。”
    敏捷联盟的发起人Martin Fowler 和Jim Highsmith 曾经这样解释过：敏捷开发所追求的是一种平衡——我们也建模，但不仅仅是画几个模型图存放在少人问津的项目文档库里；我们也需要文档，但从不浪费纸张去编造那些极少使用而又没有保存价值的大部头；我们也做计划，但我们同时也认识到在这纷繁复杂的环境中做计划是困难的
   但是，敏捷开发不是可以解决所有问题的银弹。在实际的项目中，受条件的限制，有些原则实施起来确实有困难，那该怎么办？要知道，敏捷并不要求你们一成不变地遵循这些条条框框，遇到困难时应该灵活地调整策略，这样才真正达到了敏捷的目的