念系统学习敏捷开发的管理方法，请各位大侠推荐一本好书

想系统学习敏捷开发的管理方法，请各位大侠推荐一本好书
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经验，在较知名、较大的项目中进行过部分产品管理工作的经验（然后把对大公司的管理思考用到小而敏捷的团队中）。

许多人随便裁剪敏捷理论，拿出里边门槛最低没有技术含量的一些手工管理方法，应用到自己的项目组。这很容易就成为想到哪里写到哪里式的鼠目寸光式的开发，而不是真正的敏捷开发。
[解决办法]

引用:

to:sp1234。感谢您这么热心的详细说明。 

你的说法和craig larman的说法有些不一样。他没有像你这样把TDD的重要性强调到这么高的程度，他最强调的东西是：迭代。我现在不清楚的是，如何具体地运作从一开始需求到最后提交整个过程。

迭代在软件工程中，有超过30年历史。最近20年的软件工程流派，没有一个不是把迭代放在首位的。你随便拿一本最近10年出版的软件工程书籍，或者随便找一个时髦的“标准化”方法文档来看，都可以看到大量地谈迭代。

说白了，迭代就等于是说“需求是变化的”。可见这个名词在现代中小型软件工程方法中肯定是家常便饭，因为客户越来越习惯于改变需求。如果你觉得迭代这个名词很雷人，可能对软件工程的历史看的不多。实际上，处理迭代的技术方法的细节差别才是关键，而不是说强调了迭代就很先进似的。实际上，敏捷方法如果不是为了跟RUP、CMMI等打嘴仗，其实都不用强调迭代这么古老的词。它自始至终自己处理需求和开发过程是本来就是“小步快跑”的。我有时说：知道该干什么不如知道该如何干。敏捷方法完完全全是再谈这个如何干的问题，所以我只说这个如何干中的更加核心的技术。
[解决办法]
实施敏捷方法的成功率其实并不高，甚至可以说是相当低的！因为敏捷宣言本来就太宽泛。

再看现在时髦的所谓培训、认证（国际的），似乎随随便便搞开发的人都可以拿到证书。原因是什么？是因为已经商业化了，大家都追求技术门槛很低的东西，来求一个敏捷开发的好名牌。

但是你想达到那个结果，而不像许多其它的所谓“标准化方法”那样走过场吗？那么就应该紧盯核心技术。敏捷不是仅强调流程，而是技术为基础的。
[解决办法]
敏捷方法如果不是为了跟RUP、CMMI等打嘴仗，其实都不用强调迭代这么古老的词。自始至终敏捷方法每一句话、每一个技术、每一个做法、每一个思想细胞都是在解决迭代中的问题，如果你不是关心“要干什么”而是关心“如何干”就会在自己看明白敏捷方法之后凭着对比其它方法而理解敏捷如何迭代。就好像当我想跟你讨论具体技术问题时，我给你说我是程序员，我没有必要给你一个劲强调我是男人，如果你听说我是男人感到很神奇，那么你就忽悠了，那根本没有那么大的技术价值，我是程序员这才应该对你有价值。

许多借着写敏捷方法的书发财的作者，把大量的20年前的软件工程教科书上的条文，或者简单的关于如何写好代码之类的各种各样的东西都塞进敏捷方法里边来。我昨天看到的一个关于敏捷开发的“技巧”的书400多页中就有一多半完全看不出跟敏捷有多大直接关系，剩下的也是拖沓、用大量的代码和屏幕拷贝来充斥版面。

我不嫉妒那些人借些敏捷开发相关的书发财，但是我要说我的实话：敏捷很容易被滥用于鼠目寸光的开发，你看书越多可能越糊涂。
[解决办法]
看Kent Beck写的书，要从《测试驱动开发》开始，之后他写的别的书。相信知道Kent Beck是谁吧！他与发明敏捷、发明模式的那些事件的关系也了解一下。


[解决办法]
TDD也不过是一种编程技术而已。所以我建议你先不要去学敏捷中的各种口号和所谓的流程，学导致敏捷地开发、可以对传统软件真正剪裁的具体技术。

有些人，简单地把传统软件工程中几十种文档给剪裁了，改成每天一小会、每周一大会，美其名曰“敏捷编程”。这种做法连小作坊都不如。在敏捷方法中，他之所以可以极端地剪裁传统软件工程的文档，靠的是技术，而不是那些毫无技术门槛的口号。
[解决办法]
如果你所谓的“正儿八经”就仅仅是读眼前的技术门槛不高的畅销书，那跟都保健品广告来学医学还有什么区别？
[解决办法]
敏捷开发理想状态是非常不错的，那不大可能很快达到，但我们可以消化吸收里面的一些思想和方法，然后结合自已公司的技术及管理流程，合理运用甚至进行改造，千万别过度崇拜和全盘照搬，适合自已的才是最好的，^_^
[解决办法]
我们公司的迭代开发流程，希望对你有所帮助，我们也没有做到完全敏捷，但迭代式开发，却达到了一些意想不到的效果，^_^
[解决办法]
给你介绍一篇文章，软件项目为什么会失败？- 浅谈需求驱动的项目管理
[解决办法]
http://download.csdn.net/source/1021391
这个不错的实践资料
[解决办法]
不错
http://download.csdn.net/source/1021391
[解决办法]
我谈点个人看法，我始终认为敏捷是需要实践的，理论确实只是一个指导性的东西；
我觉得如果能够把敏捷和软件工程的许多模型很好的结合，会达到很好的效果，比如把敏捷和CMMI无缝的链接，很多人会觉得这个是天方夜谭，似乎敏捷和cmmi本身就是死对头，在我看来，理论始终是理论，如何能把这些个复杂的理论很好的融汇贯通，只有自己有了心得才能把之发挥到极致。我坚信CMMI可以很好的=敏捷。
一点个人的浅见，见笑了
[解决办法]
各位 
尽信书不如无书。下面是关于华为敏捷项目管理的讨论。还有华为的项目经理的回复
http://vipclub.csdn.net/space.php?uid=3966&do=thread&id=60
看看他们是怎么将理论与实际结合的。

查看更多 下一篇