您当前的位置:
想系统学习敏捷开发的管理方法，请各位大侠推荐一本好书
Craig larman的《UML和模式应用》已经看完了。我在我们单位带了一帮人做软件，想系统学习一下用敏捷方法开发软件，项目经理该如何去管理。在网上看了一下人家对Craig larman的《敏捷迭代开：管理者指南》的评论不是很好，大家觉得怎样，另外谁还有更好的书推荐。多谢！
------解决方案--------------------
我觉得ORelly的Headfirst Software Development《深入浅出软件开发》
还是不错的，里面采用的就是敏捷的方法，强调了迭代，如何获取需求user story，分析设计涉及的不多，可以参考Headfirst OOAD，而且也讲了配置管理的相关内容，中间讲述了Test Driven Development测试驱动开发
现在应该只有英文版，不过英文很通俗易懂，而且大部分是图片，阅读起来很轻松
项目管理的知识像PMP相关的Headfirst的书也不错
一家之言仅供参考
祝你成功～～
------解决方案--------------------
精通TDD才能真正敏捷地开发软件。其它，都是TDD衍生到有关“需求、角色分配、沟通、文档”方面的东西，可以在你非常熟练了TDD之后再结合实际管理经验。如果本末倒置，先挑出敏捷理论中最没有技术门槛的东西来学习，你会走偏。
------解决方案--------------------
我给你总结一下敏捷方法：
切忌追求空洞的理论。真正的敏捷开发不是一种标准流程，而是一种实际技术。切忌仅仅从流程的角度去看敏捷开发，要从技术角度把握。
敏捷做法，是先由需求管理人员写出可执行的自动测试程序，而不是写传统的那几十种文档。此时测试程序肯定不能通过，甚至往往连被测试对象的类型或者接口都还没有写好呢！
你完全可以酌情写任何对外使用的文档，但是只有测试代码和源代码是要长期保存的。传统开发方法的一堆系统分析员、文档管理员，可能在敏捷团队中感到了再也无法隐藏自己。
在可执行的需求文档被产生之后，然后由至少两名开发人员以协商的办法来研究如何写出代码让测试程序可以通过。
敏捷方法要求知识要共享，任何两名以上开发人员讨论之后就可以随时重构代码，而基本上无需请示汇报。因为有强大的自动化测试保证随时可以回归测试产品质量。因此，软对中不应该出现一些模块只由个人去把持的现象，也不会出现团队成员只对自己写的代码感兴趣而对别人的代码漠不关心的情况。
敏捷开发方法要拥抱需求变动。例如你的软件在开发过程中已经写了150个需求测试程序，当需求变动时，不应该轻易改变原来的需求测试，而是要补充新的配置参数、原来接口新的新的实现模块，来实现新的需求测试程序。而维系原来的测试程序不变。久而久之，OO设计习惯可以自然而然地变得非常扎实。事实上，大项目往往会有超过1000个测试。
敏捷开发方法要处理好跟客户的关系，建立一个需求讨论、评估、批准、验收测试的信息管理平台，并且往往希望在上面只是讨论今后1～3周的需求变更，使得总是能够尽快推出切实可行的内部评估产品。其实，不论对于那些在项目已开始就用合同形式固定下来基本需求的项目，还是一开始只有一个方向然后按照系统功能升级要求不断增加需求和追加开发投资的项目，敏捷方法都能支持。前提是，你要把需求及时翻译为测试代码，而不要停留在纸面上。
敏捷有许多流派。正是因为10几年前有很多流派宣称自己是敏捷开发方法，所以2001年初的时候一小撮有代表性的人物才发表了《敏捷宣言》。所以，敏捷理论的各种解释中也会充满了不实用的东西，甚至被现在国内一些培训机构故意跟其它非敏捷方法混合起来进行推销的东西。所以要注意。
------解决方案--------------------
熟练掌握TDD技术并不容易。特别是，你不深入了解开发平台，可能就无法处理 UI 界面组件查找、线程处理、定时功能处理等等测试驱动问题。许多人以为从网上下载个自动测试工具，然后对于每一个测试只要花上二十分钟就能编写一个测试了。其实那些工具的教程中只是教你最简单、没有什么交互和分支操作的功能（例如登录界面）的测试，以此来推销软件。等发现耗时大半个月也搞不清楚到底怎样测试自己的经典、稍微复杂一点的交互界面，很多人就会对自动化测试从此失去信息，鼓吹自动化测试、TDD都是不切实际的论调。所以，学习TDD，甚至自己花几天时间编写测试驱动平台（而不是简单地下载个JUnit、DUnit之类的）来了解自动化测试的那么一点点核心技术，很必要。
所以作为一个敏捷开发团队的 pm，可能需要你有超过10年的商品化软件编程经验，超过5年的pm经验，在较知名、较大的项目中进行过部分产品管理工作的经验（然后把对大公司的管理思考用到小而敏捷的团队中）。
许多人随便裁剪敏捷理论，拿出里边门槛最低没有技术含量的一些手工管理方法，应用到自己的项目组。这很容易就成为想到哪里写到哪里式的鼠目寸光式的开发，而不是真正的敏捷开发。
------解决方案--------------------
迭代在软件工程中，有超过30年历史。最近20年的软件工程流派，没有一个不是把迭代放在首位的。你随便拿一本最近10年出版的软件工程书籍，或者随便找一个时髦的“标准化”方法文档来看，都可以看到大量地谈迭代。
说白了，迭代就等于是说“需求是变化的”。可见这个名词在现代中小型软件工程方法中肯定是家常便饭，因为客户越来越习惯于改变需求。如果你觉得迭代这个名词很雷人，可能对软件工程的历史看的不多。实际上，处理迭代的技术方法的细节差别才是关键，而不是说强调了迭代就很先进似的。实际上，敏捷方法如果不是为了跟RUP、CMMI等打嘴仗，其实都不用强调迭代这么古老的词。它自始至终自己处理需求和开发过程是本来就是“小步快跑”的。我有时说：知道该干什么不如知道该如何干。敏捷方法完完全全是再谈这个如何干的问题，所以我只说这个如何干中的更加核心的技术。
------解决方案--------------------
实施敏捷方法的成功率其实并不高，甚至可以说是相当低的！因为敏捷宣言本来就太宽泛。
再看现在时髦的所谓培训、认证（国际的），似乎随随便便搞开发的人都可以拿到证书。原因是什么？是因为已经商业化了，大家都追求技术门槛很低的东西，来求一个敏捷开发的好名牌。
但是你想达到那个结果，而不像许多其它的所谓“标准化方法”那样走过场吗？那么就应该紧盯核心技术。敏捷不是仅强调流程，而是技术为基础的。
------解决方案--------------------
敏捷方法如果不是为了跟RUP、CMMI等打嘴仗，其实都不用强调迭代这么古老的词。自始至终敏捷方法每一句话、每一个技术、每一个做法、每一个思想细胞都是在解决迭代中的问题，如果你不是关心“要干什么”而是关心“如何干”就会在自己看明白敏捷方法之后凭着对比其它方法而理解敏捷如何迭代。就好像当我想跟你讨论具体技术问题时，我给你说我是程序员，我没有必要给你一个劲强调我是男人，如果你听说我是男人感到很神奇，那么你就忽悠了，那根本没有那么大的技术价值，我是程序员这才应该对你有价值。
许多借着写敏捷方法的书发财的作者，把大量的20年前的软件工程教科书上的条文，或者简单的关于如何写好代码之类的各种各样的东西都塞进敏捷方法里边来。我昨天看到的一个关于敏捷开发的“技巧”的书400多页中就有一多半完全看不出跟敏捷有多大直接关系，剩下的也是拖沓、用大量的代码和屏幕拷贝来充斥版面。