看到一本讲敏捷开发的书，感觉里面观点和现实差距很大

[qq_33663447]

比如：
1、出现问题，解决问题比寻找责任者更重要
2、如果没有犯过错，那你就可能没有努力去工作
3、争论问题是什么导致的，通常没多大意义，与其如此，不如赶紧去修复它

我在想，are you kidding me？

以前我就做过一个项目，项目组就抱着解决问题最重要的态度，甭管是哪方面的问题，项目组都勇于承担责任，把它解决。

后来，客户觉得，只要电脑有问题，就是你的问题；领导觉得，你们的问题怎么这么多；组员也很恼火，有的问题压根就无法解决，甚至无法再现。

后来，项目组开始推卸责任，开始忽悠客户，于是日子好过多了

[gw6328]

前两点还可以赞同，第3点确实不对啊。这样问题会越来越多的。 敏捷主要是以交出能用的产品为目地，小项目还行吧。大很子必须规范，项目管理，大项目管理。建筑项目大吧，不能用敏捷，必须要求专家数量，项目管理人员数量，监里等等，当然里面有些水，但也全是水份。

[luciferisnotsatan]

书里都是理想状态。用户和开发人员紧密协作，完成任务。书里不会出现sb用户把自己电脑问题归咎给项目组的，也没有sb领导会为这个问题怪开发人员。 实际应用时，那就另当别论了。

[luciferisnotsatan]

lz的情况，如果出现在书里，那么就是： 客户发现问题，及时反馈给项目组。项目组通过排查，发现是客户自己电脑上的问题，于是领导和客户充分沟通，客户认识到是自己电脑的问题。并且，通过这一事件，客户掌握了一定的相关知识，在之后发现问题时，会先自行查，看看是否为自己电脑问题。 可喜可贺可喜可贺

[望断雁南飞]

现实是唯一的

[鸣鸣Amadues]

书里都是理想状态，实际项目里，与其说事情的做法对不对，不如看做事的人对不对。 敏捷开发的出现其实还有一部分因素是为了捞钱，出现了敏捷开发后就会有认证和培训等一系列的东西，项目里还会出现敏捷大师这种职位。 全信书不如无书，如果只能照搬书里的看法，不能理解它并且在实际项目里灵活运用，那还不如从一开始就没学过书本上的东西。

[鸣鸣Amadues]

另外还有一点是大项目和小项目是不一样的，如果没有做过那种可能有几百人的大项目，有些管理和方法之类的书本说的内容你没有实际体会，也很难理解。