敏捷软件开发 英文版 电子书 下载 txt pdf mobi

本书是国际知名软件开发专家Alistair Cockburn通过采访项目开发组和总结自己二十多年的开发和管理经验，撰写的一本介绍软件开发新思想——Agile软件开发方法学的专著。

本书共6章，在第1章之前的引言部分，作者阐述了人要正确地认识事物和准确交流是非常困难的这一观点。第1章作者通过一个假想的诗歌创作的例子，指出软件开发中常见的问题，并试图揭示软件开发的特点。第2章探讨了在软件开发过程中占据决定性作用的人的因素。第3章论述了团队的交流与合作，说明哪些因素影响交流的效果，有哪些好的交流方式等等。第4章详细列出了方法论的要素、设计原则、词汇术语等内容。第5章作者从多个角度论证了一套方法应该是动态的、自适应的。第6章阐述了作者自己的水晶系列方法论。附录A给出了敏捷软件开发宣言，其主要内容是是四个核心价值和十二个指导原则。

本书提供了一个新的角度来看待软件开发活动，以及一个新的思路来设计开发方法。书中提供的材料大部分来自作者丰富的实践经验，对软件开发实践有很高的参考价值，本书适合软件开发人员、项目管理人员、软件工程研究人员，以及所有想要了解敏捷开发思想的各界人士参考

INTRODUCTION UNKNOWABLE AND INCOMMUNICABLE　1

·The Problem with Parsing Experience　3

·The Impossibility of Communication　8

·Three Levels of Listening　14

·So, What Do I Do Tomorrow?　19

CHAPTER 1　A COOPERATIVE GAME OF INVENTION AND COMMUNICATION　21

·Software and Poetry　23

·Software and Games　25

·A Second Look at the Cooperative Game　31

·What Should This Mean to Me?　38

CHAPTER 2　INDIVIDUALS　41

·Them's Funky People　43

·Overcoming Failure Modes　48

·Working Better in Some Ways than Others　55

·Drawing on Success Modes　67

·What Should I Do Tomorrow?　73

CHAPTER 3　COMMUNICATING, COOPERATING TEAMS　75

·Convection Currents of Information　77

·Jumping Communication Gaps　91

·Teams as Communities　99

·Teams as Ecosystems　109

·What Should I Do Tomorrow?　111

CHAPTER 4　METHODOLOGIES　113

·An Ecosystem That Ships Software　115

·Methodology Concepts　115

·Methodology Design Principles　141

·XP under Glass　165

·Why Methodology at All?　170

·What Should I Do Tomorrow?　172

CHAPTER 5　AGILE AND SELF-ADAPTING　173

·Light but Sufficient　175

·Agile　178

·Becoming Self-Adapting　184

·What Should I Do Tomorrow?　195

CHAPTER 6　THE CRYSTAL METHODOLOGIES　197

·Shaping the Crystal Family　199

·Crystal Clear　202

·Crystal Orange　204

·Crystal Orange Web　206

·What Should I Do Tomorrow?　212

APPENDIX A　THE AGILE SOFTWARE DEVELOPMENT MANIFESTO　213

·The Agile Alliance　215

·The Manifesto　216

·Supporting the Values　219

APPENDIX B　NAUR, EHN, MUSASHI　225

·Peter Naur, Programming as Theory Building　227

·Pelle Ehn, Wittgenstein's Language Games　241

·Musashi　254

APPENDIX C　BOOKS AND REFERENCES　261

INDEX　271

暂无相关内容，正在全力查找中

暂无出版社相关信息，正在全力查找中！

暂无相关书籍摘录，正在全力查找中！

在线阅读地址：敏捷软件开发 英文版在线阅读

在线听书地址：敏捷软件开发 英文版在线收听

在线购买地址：敏捷软件开发 英文版在线购买

暂无原文赏析，正在全力查找中！

书籍介绍

本书是国际知名软件开发专家Alistair Cockburn通过采访项目开发组和总结自己二十多年的开发和管理经验，撰写的一本介绍软件开发新思想——Agile软件开发方法学的专著。

本书共6章，在第1章之前的引言部分，作者阐述了人要正确地认识事物和准确交流是非常困难的这一观点。第1章作者通过一个假想的诗歌创作的例子，指出软件开发中常见的问题，并试图揭示软件开发的特点。第2章探讨了在软件开发过程中占据决定性作用的人的因素。第3章论述了团队的交流与合作，说明哪些因素影响交流的效果，有哪些好的交流方式等等。第4章详细列出了方法论的要素、设计原则、词汇术语等内容。第5章作者从多个角度论证了一套方法应该是动态的、自适应的。第6章阐述了作者自己的水晶系列方法论。附录A给出了敏捷软件开发宣言，其主要内容是是四个核心价值和十二个指导原则。

本书提供了一个新的角度来看待软件开发活动，以及一个新的思路来设计开发方法。书中提供的材料大部分来自作者丰富的实践经验，对软件开发实践有很高的参考价值，本书适合软件开发人员、项目管理人员、软件工程研究人员，以及所有想要了解敏捷开发思想的各界人士参考。

• 作者： o6z 发布时间：2007-11-19 01:49:32

  方法论研究者的必读书。

• 作者： dt1 发布时间：2011-08-16 00:25:23

  好艰难的看完了这本书，词汇量太少，看还算看得大概明白。

  很想再看，但近期还是歇歇。

• 不是书评，是短评

  作者：阳光123456-聪慧如你自然 发布时间：2010-09-08 23:31:36

  我不是一个专业的软件人，

  但我是一个在专业的项目式服务公司干了不少年头的年轻人。

  不管是生活，家庭，还是工作，我们离不开“合作”。然而究竟怎样是一个好的合作模式？

  遇到这本书纯属偶然，当时是在给家人写点东西，要谈到“Team”的概念。就上网搜索了一把，结果这本书就出现了。

  翻开来，发现居然是谈软件开发的。用“居然”这个词，因为我看到的部分，这本书都是在谈人，而不是在谈什么编码，技术，哪怕是在谈“项目管理”，也是在谈基于人的项目管理，所以都是以人为基础的。

  而且是在所谓的“极限”编程的实战的背景下来谈。技术和人文，科学和艺术好像有点交汇了吗。呵呵。

  顺便一说，我对个书名的副标题的翻译不是很满意，不过我也承认，我找不出更好的翻译方法。语言啊语言，有的时候就是这样的......

  创造和沟通的合作Game, 翻译成创造和沟通的博弈，说实话，我个人觉得不是特别合适。

  博弈只是Game的一部分而已。

  博弈只是Game的一部分。在英文里，Game不仅仅是游戏，也不仅仅是博弈。Game也是一个丰富的过程，其中包含很多有趣的元素，也包括一个创造性的结果，可能还是让人期待的结果。而且，游戏本身，也是包含合作的内容的。

  所以，翻译成什么好呢？高人们来考虑考虑吧，我正查英文字典呢。

  继续读，继续看。

  ......

  顺便转一段网上copy来的书评。书评人是

  Cockburn的书适合于管理者和高层开发人员阅读，

  他的书侧重分析开发活动，告诉管理者应如何调整开发团队，为其创造尽可能有利的条件，促进成员间的交流，最终获得软件开发的成功。

  他还详细介绍了如何根据不同项目，不同环境调整方法论，得到最适合当前团队当前项目的最敏捷的方法论。

  而Martin的同名书适合于开发人员，Martin详细分析了软件设计中的各种弊病，以及应如何解决它们。

  他甚至直接给出代码，向开发人员展示好的Agile的设计是什么样的。

  这两本书除了很少部分内容重叠，其他内容完全不同，作者侧重的角度和针对的对象也都不同。读者应根据自己的需要选择适合自己的一本。

  书评人YJ_Water

  来源：

  http://www.dearbook.com.cn/Book/ViewBook.aspx?pno=TS0012935

• 敏捷运动——被阉割的革命

  作者：黑枪王荣格 发布时间：2009-03-27 01:35:36

  本书是一本非常好的学习敏捷开发方法的书。书中列举了大量的事实，详细的介绍了如何在软件开发过程中实现敏捷方法，作者对敏捷的一些感悟等等。如果对敏捷方法没有深刻的认识，可以在看过敏捷宣言以后，仔细研读这本书，作为对敏捷方法的入门。我在这里不想过多的来吹捧这本书的优点，我想谈一下就这本书透露出来的敏捷运动的不足。

  我第一次了解敏捷大约是在4年以前，最开始只是了解了敏捷宣言，后来又了解了敏捷的前身—XP。本来我对敏捷运动报着很大的希望，因为敏捷宣言里面提到了一些在传统软件开发方法中没有注意到的思想，这些思想是真的可以为软件开发方法带来革命。而事情发展到今天，这场革命在各种因素的综合作用下，事实上已经失败了。现在大多数人提到敏捷（包括很多资深的敏捷运动成员），都认为敏捷仅仅只是对传统软件开发方法的改良，而非革命，它仅仅只是把传统软件开发过程中好的元素综合起来了而已，而最开始，事实并非如此。

  虽然敏捷宣言最开始有12条，但是事实上其中只有三条是核心“我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意”“在整个项目开发期间，业务人员和开发人员必须天天都在一起工作”“即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势”。这3条意味着，和传统开发方法相比，敏捷开发方法是一种用户驱动的开发方法，它事实上是通过用户最快速度的使用，让用户明白计算机可以为他做什么，然后再由用户重组他对目标解决方案的设计。进而，为了快速的达到这一目标，其他的方法最大限度的加快了软件开发速度。从软件工程的发展趋势上来看，敏捷方法将原来用户和软件开发人员相对剥离的状况转变为一种紧密结合，将软件开发过程看做是双方之间的协作而非双方之间的买卖。是的，这本来是一个革命性的思想，这个思想甚至意味着全行业对软件需求认识上的改变。

  然而最终，什么变化都没有发生，敏捷打开了一扇大门，又最终把它关上了。现在任何一个组织都宣称自己是敏捷的，甚至连敏捷本来的死对头UP也宣称自己是敏捷的，就连敏捷自己，也在实践中逐渐迷失了自己最重要的特性，最终泯然众人了。

  拿IBM的Rational平台来说（09年《程序员》3月刊28页），其宣称自己是敏捷的，甚至宣称自己是大规模敏捷的，但是就其介绍，我们丝毫看不出这个敏捷和紧密结合用户的思想有什么关系，而此所谓的“敏捷方法”，事实上是通过提供统一平台，提高实现级别来实现的，这实质上是一种减小含混性的方法，而并非敏捷宣言的初衷。这本身是两种完全不同的思想，却在他们的介绍下被莫名其妙的混在了一起。

  敏捷运动为什么失败了？是因为在最初其革命性太强了。敏捷方法一出，号称颠覆了传统的所有软件开发方法，其宣称的不写文档也确实存在大量拥护者。但其方法本身只是一个从实践走过来的方法，其缺乏扎实的理论根基和与其配套的完整理论体系（比如一种更好的客户开发人员的交流方法等）。相比于早期的UML，先从图形化入手，提供一套便于传统软件开发方法上手的工具，进而逐步向UP甚至模型转换方向发展这种稳定的步伐，敏捷一出来就锋芒壁炉，结果在锋芒中迷失。甚至直到今天，敏捷方法也没有拿出一个靠得住的需求获取方法，而这可是最初12条宣言中最看家的本领。

  敏捷失败了，未来会怎么样？

  从软件工程发展的历史上来看，从最初的自己自足，到混乱型，到瀑布模型，到原型法，到迭代方法，敏捷方法等等，其本质沿着混乱，到流水线，到一次迭代，到多次迭代，到用户主导，将来必然会更加趋向于协同合作，而非独立自治。而在实现级别上，由最开始的机器码，到汇编，C，面向对象语言，动态语言，SOA，甚至未来可能到达的模型转化，其实现的级别越来越高。未来的软件开发方法，必然更加强调用户主导，快速响应，协同工作，甚至随需而变，而我们的精力必然随着实现级别的拔高，不断的向更高层次的目标转移，不断的去挖掘用户的潜在目标，形成完整的软件服务链。

  敏捷虽然失败了，但是下一次变革必然带来更强烈的交互协同，这个大趋势是不会变的，必然会存在着一天，用户和开发者将摆脱当前这种被动的交流状态，转变为相互主动的交流，共同完成对目标的优化。

• 敏捷宣言

  作者：云水 发布时间：2009-10-23 21:13:24

  个人和交互胜过过程和工具

  可工作的软件胜过全面的文档

  客户的协作胜过合同协商

  对于变更的响应胜过遵循计划

  频繁的交付可工作的软件

  欢迎变动的需求【很惭愧】

  业务人员和开发人员每天工作在一起【不是不想,...】

  使用有主动性的人来组建团队。给他们所需的环境和支持，信任他们能够完成工作【阿喀琉斯之踵】

  不断的追求技术上卓越和优秀的设计

• 守破离是这本书的精髓

  作者：内向叔叔 发布时间：2012-01-12 12:03:30

• 这本书是敏捷的顶峰之作。

  作者：Chaos 发布时间：2007-07-19 17:39:37

  这里的敏捷是可以配置的！

  向不同行业扩展的：lean，cmm，心理学等等

  只要适应的就是最好的！

  这是我看过关于敏捷最好的书。