出版社: 机械工业出版社
原作名: The Art of Agile Development
译者: 王江平
出版年: 2009-8
页数: 448
定价: 78.00元
装帧: 平装
丛书: O’Reilly精品图书系列
ISBN: 9787111268048
内容简介 · · · · · ·
本书为那些正在考虑应用敏捷开发来构建有价值软件的人们提供了实用的指导。现在已经有大量的书籍描述敏捷开发是什么或者为什么它能帮助软件项目成功,但很少有哪一本书能把针对开发者、管理者、测试者和客户的信息合并成一个整体,从而使其能够直接应用。
本书为敏捷的计划、开发、交付和管理提供了严谨的建议,这些建议来自于作者多年的极限编程(Extreme Programming,XP)经验。你将看到敏捷开发过程的全景图,包括为非技术类读者准备的全面指导,以及为开发者和测试人员准备的实用技术实践。
本书为以下问题提供了明确的答案:
怎样才能采用敏捷开发?
我们真的需要结对编程吗?
汇报应该详细到什么程度?
如果无法让客户参与进来该怎么办?
我们应该编写多少文档?
何时进行设计和架构?
作为一名非开发人员,我应如何同敏捷团队一起工作?
产品的路线在哪里?
QA应该如何参与...
本书为那些正在考虑应用敏捷开发来构建有价值软件的人们提供了实用的指导。现在已经有大量的书籍描述敏捷开发是什么或者为什么它能帮助软件项目成功,但很少有哪一本书能把针对开发者、管理者、测试者和客户的信息合并成一个整体,从而使其能够直接应用。
本书为敏捷的计划、开发、交付和管理提供了严谨的建议,这些建议来自于作者多年的极限编程(Extreme Programming,XP)经验。你将看到敏捷开发过程的全景图,包括为非技术类读者准备的全面指导,以及为开发者和测试人员准备的实用技术实践。
本书为以下问题提供了明确的答案:
怎样才能采用敏捷开发?
我们真的需要结对编程吗?
汇报应该详细到什么程度?
如果无法让客户参与进来该怎么办?
我们应该编写多少文档?
何时进行设计和架构?
作为一名非开发人员,我应如何同敏捷团队一起工作?
产品的路线在哪里?
QA应该如何参与进来?
本书教你如何采用XP实践,详细描述了每一种实践,然后讨论了一些原则,使你可以更改XP并创建自己的敏捷方法。尤其是,本书为敏捷开发中一些较为困难的方面(合作的需要和团队成员之间的信任)提供了解决办法。
不管你目前已经是敏捷团队的一部分,还是只对敏捷开发感兴趣,本书都为你提供了开始实践敏捷开发所需的实用技巧。随着你的经验的增长,内容也随之深入。本书教你首先理解敏捷开发的规则,然后打破这些规则,最后当你掌握了敏捷开发的艺术之后,再完全撇开这些规则。
原文摘录 · · · · · · ( 全部 )
-
In an XP team, on-site customers are responsible for choosing and prioritizing features. The value of the project is in their hands. (查看原文) —— 引自第120页 -
The larger your project becomes, the harder it is to plan everything in advance. The more chaotic your environment, the more likely it is that your plans will be thrown off by some unexpected event. Yet in this chaos lies opportunity. (查看原文) —— 引自第199页
> 全部原文摘录
丛书信息
喜欢读"敏捷开发的艺术"的人也喜欢的电子书 · · · · · ·
喜欢读"敏捷开发的艺术"的人也喜欢 · · · · · ·
敏捷开发的艺术的书评 · · · · · · ( 全部 3 条 )
> 更多书评 3篇
-
chimney (来~来~大家来读书~~~)
三种类型的成功都很重要。没有个人的成功,你将很难为自己及其他员工提供激励。没有技术上的成功,你的代码最终将被它自身的重量压垮。没有组织的成功,你的团队可能发现公司不再想要它了。 敏捷方法通过交付价值和降低成本来获得组织的成功。 XP最令人瞠目结舌的一个主张就是你可以越过需求、设计、测试阶段以及与之俱来的文档工作。 与其更大,不如更好。 如果错误可能发生,它就一定会发生。 根源分析 记住:说教和惩罚措施...2016-02-14 15:21:39
三种类型的成功都很重要。没有个人的成功,你将很难为自己及其他员工提供激励。没有技术上的成功,你的代码最终将被它自身的重量压垮。没有组织的成功,你的团队可能发现公司不再想要它了。 敏捷方法通过交付价值和降低成本来获得组织的成功。 XP最令人瞠目结舌的一个主张就是你可以越过需求、设计、测试阶段以及与之俱来的文档工作。 与其更大,不如更好。 如果错误可能发生,它就一定会发生。 根源分析 记住:说教和惩罚措施通常效果都不好。与其期望大家总是做对,还不如让做错事变得很难。 决不能通过回顾来进行责备和个人攻击。 不管我们今天发现了什么,我们理解并且深深相信,以他们当时所了解的情况、技术和能力、拥有的资源和现场的情形,每个人都尽了他们最大的努力。 机会有时是会降临到等待的人头上,但那也只是争取它的人挑剩下的。 只有诚实地对待真实的情况,我才能有效地控制结果。 以后无论多难,都要记住一点:只要别人不赶你走,你就厚着脸皮待下去,这样你才有可能熬到项目成功。--IT项目经理成长手记 一个问题修复得越晚,修复的代价就越大。而且,没有修复的bug往往意味着更大的问题。 当你被卡在一个地方没法继续的时候,丢弃最近的所有修改从头开始。 我们为成功而计划。 TDD。它属于那种很快就能学会却需要一生去掌握的东西。 简单并不代表单纯。 简单,而不是单纯。 Once and Only Once. 不要重复自己。 Don't Repeat yourself.
回应 2016-02-14 15:21:39 -
原文:“After a couple of weeks an area below the “todo” section evolved into a[n] “on hold” section —and we asked the interrupter to initial the card when we moved it.”。 译文: 一两周之后,原先”待完成“区域的下方出现了一块新的”搁置“区域——我们要求打断我们的人在我们移动卡片的时候,在这个区域建立新的卡片。 疑问:打断”进行中“的一个事,程序员把打断者带到白板前,将其正在做的事情的卡片...
2011-11-10 14:56:58
原文:“After a couple of weeks an area below the “todo” section evolved into a[n] “on hold” section —and we asked the interrupter to initial the card when we moved it.”。 译文:
一两周之后,原先”待完成“区域的下方出现了一块新的”搁置“区域——我们要求打断我们的人在我们移动卡片的时候,在这个区域建立新的卡片。 引自第414页 疑问:打断”进行中“的一个事,程序员把打断者带到白板前,将其正在做的事情的卡片从”进行中“区挪回到”待完成“区,新建的卡片是什么,”搁置“区域是怎么形成的?
回应 2011-11-10 14:56:58
-
chimney (来~来~大家来读书~~~)
三种类型的成功都很重要。没有个人的成功,你将很难为自己及其他员工提供激励。没有技术上的成功,你的代码最终将被它自身的重量压垮。没有组织的成功,你的团队可能发现公司不再想要它了。 敏捷方法通过交付价值和降低成本来获得组织的成功。 XP最令人瞠目结舌的一个主张就是你可以越过需求、设计、测试阶段以及与之俱来的文档工作。 与其更大,不如更好。 如果错误可能发生,它就一定会发生。 根源分析 记住:说教和惩罚措施...2016-02-14 15:21:39
三种类型的成功都很重要。没有个人的成功,你将很难为自己及其他员工提供激励。没有技术上的成功,你的代码最终将被它自身的重量压垮。没有组织的成功,你的团队可能发现公司不再想要它了。 敏捷方法通过交付价值和降低成本来获得组织的成功。 XP最令人瞠目结舌的一个主张就是你可以越过需求、设计、测试阶段以及与之俱来的文档工作。 与其更大,不如更好。 如果错误可能发生,它就一定会发生。 根源分析 记住:说教和惩罚措施通常效果都不好。与其期望大家总是做对,还不如让做错事变得很难。 决不能通过回顾来进行责备和个人攻击。 不管我们今天发现了什么,我们理解并且深深相信,以他们当时所了解的情况、技术和能力、拥有的资源和现场的情形,每个人都尽了他们最大的努力。 机会有时是会降临到等待的人头上,但那也只是争取它的人挑剩下的。 只有诚实地对待真实的情况,我才能有效地控制结果。 以后无论多难,都要记住一点:只要别人不赶你走,你就厚着脸皮待下去,这样你才有可能熬到项目成功。--IT项目经理成长手记 一个问题修复得越晚,修复的代价就越大。而且,没有修复的bug往往意味着更大的问题。 当你被卡在一个地方没法继续的时候,丢弃最近的所有修改从头开始。 我们为成功而计划。 TDD。它属于那种很快就能学会却需要一生去掌握的东西。 简单并不代表单纯。 简单,而不是单纯。 Once and Only Once. 不要重复自己。 Don't Repeat yourself.
回应 2016-02-14 15:21:39
-
chimney (来~来~大家来读书~~~)
三种类型的成功都很重要。没有个人的成功,你将很难为自己及其他员工提供激励。没有技术上的成功,你的代码最终将被它自身的重量压垮。没有组织的成功,你的团队可能发现公司不再想要它了。 敏捷方法通过交付价值和降低成本来获得组织的成功。 XP最令人瞠目结舌的一个主张就是你可以越过需求、设计、测试阶段以及与之俱来的文档工作。 与其更大,不如更好。 如果错误可能发生,它就一定会发生。 根源分析 记住:说教和惩罚措施...2016-02-14 15:21:39
三种类型的成功都很重要。没有个人的成功,你将很难为自己及其他员工提供激励。没有技术上的成功,你的代码最终将被它自身的重量压垮。没有组织的成功,你的团队可能发现公司不再想要它了。 敏捷方法通过交付价值和降低成本来获得组织的成功。 XP最令人瞠目结舌的一个主张就是你可以越过需求、设计、测试阶段以及与之俱来的文档工作。 与其更大,不如更好。 如果错误可能发生,它就一定会发生。 根源分析 记住:说教和惩罚措施通常效果都不好。与其期望大家总是做对,还不如让做错事变得很难。 决不能通过回顾来进行责备和个人攻击。 不管我们今天发现了什么,我们理解并且深深相信,以他们当时所了解的情况、技术和能力、拥有的资源和现场的情形,每个人都尽了他们最大的努力。 机会有时是会降临到等待的人头上,但那也只是争取它的人挑剩下的。 只有诚实地对待真实的情况,我才能有效地控制结果。 以后无论多难,都要记住一点:只要别人不赶你走,你就厚着脸皮待下去,这样你才有可能熬到项目成功。--IT项目经理成长手记 一个问题修复得越晚,修复的代价就越大。而且,没有修复的bug往往意味着更大的问题。 当你被卡在一个地方没法继续的时候,丢弃最近的所有修改从头开始。 我们为成功而计划。 TDD。它属于那种很快就能学会却需要一生去掌握的东西。 简单并不代表单纯。 简单,而不是单纯。 Once and Only Once. 不要重复自己。 Don't Repeat yourself.
回应 2016-02-14 15:21:39 -
原文:“After a couple of weeks an area below the “todo” section evolved into a[n] “on hold” section —and we asked the interrupter to initial the card when we moved it.”。 译文: 一两周之后,原先”待完成“区域的下方出现了一块新的”搁置“区域——我们要求打断我们的人在我们移动卡片的时候,在这个区域建立新的卡片。 疑问:打断”进行中“的一个事,程序员把打断者带到白板前,将其正在做的事情的卡片...
2011-11-10 14:56:58
原文:“After a couple of weeks an area below the “todo” section evolved into a[n] “on hold” section —and we asked the interrupter to initial the card when we moved it.”。 译文:
一两周之后,原先”待完成“区域的下方出现了一块新的”搁置“区域——我们要求打断我们的人在我们移动卡片的时候,在这个区域建立新的卡片。 引自第414页 疑问:打断”进行中“的一个事,程序员把打断者带到白板前,将其正在做的事情的卡片从”进行中“区挪回到”待完成“区,新建的卡片是什么,”搁置“区域是怎么形成的?
回应 2011-11-10 14:56:58
论坛 · · · · · ·
内容不错 | 来自Morgan Chen | 2010-10-31 15:39:23 | |
-___- | 来自救世猪 | 2010-07-27 12:23:16 |
这本书的其他版本 · · · · · · ( 全部3 )
-
O'Reilly Media (2007)9.3分 15人读过
-
东南大学出版社 (2008)暂无评分 10人读过
以下书单推荐 · · · · · · ( 全部 )
谁读这本书?
二手市场
订阅关于敏捷开发的艺术的评论:
feed: rss 2.0
0 有用 蝉 2014-03-20 11:04:12
: TP311.52/1629
0 有用 韩非子—— 2020-03-15 08:53:43
极限翻书 发现bug应立即修复它,不要堆积bug
0 有用 李喆 2014-09-21 18:50:33
写的很全面
0 有用 flyloong 2014-08-29 08:30:45
这是我目前读到的关于敏捷开发,最全面、最详实、论证最充分的一本书。
1 有用 Marco 2019-06-25 18:32:41
总觉得敏捷就是一堆屁话
0 有用 Sophie4World 2021-05-30 20:36:24
约1/4内容对我来说超出需要,于是加快速度浏览。翻译不严谨,几乎没有注释。书名略浮夸,实际上是讲清楚了极限编程的方方面面。开卷有益,不浪费时间。实际上项目管理专业资格考试,考验的是对知识体系的阅读理解能力,结合工作实际的领悟应用能力。希望6.20可以正常考试。
0 有用 sage.xiong 2020-12-22 10:49:23
一本关于极限编程的方法论工具书。看完之后的启发也是有的,让自己从另外的角度认识了软件工程的项目管理。半年之后再看一遍吧!
0 有用 毛毛 2020-05-06 08:21:15
这是一本古老的书,但写得还真棒。 如果想要了解XP和最初的实践方式,想要探寻这一切发生的本源,这就是为你量身打造的,可用于考古。 Kindle商城有售。
0 有用 韩非子—— 2020-03-15 08:53:43
极限翻书 发现bug应立即修复它,不要堆积bug
0 有用 CC先生之豆瓣 2020-01-23 11:06:52
09年的时候出版读起来应该有更多的收获。书中对XP的概念性描述偏多