敏捷软件开发(英文影印版.第2版)
点击看大图基本信息
- 原书名： Agile Software Development: The Cooperative Game (2nd Edition)
- 原出版社： Addison-Wesley Professional
- 作者： (美)Alistair Cockburn [作译者介绍]
- 丛书名： 经典原版书库
- 出版社：机械工业出版社
- ISBN：9787111214571
- 上架时间：2007-5-28
- 出版日期：2007 年6月
- 开本：16开
- 页码：467
- 版次：2-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 软件方法/软件工程
编辑推荐
第17届Jolt大奖获奖作品 大师Cockburn讲授敏捷开发之道
内容简介回到顶部↑
本书是国际知名软件开发专家alistair cockburn通过采访项目开发组和总结自己20多年的开发和管理经验，撰写的一本介绍软件开发新思想——敏捷软件开发方法学的著作。
本书从更新软件开发就是“创造和沟通的合作博弈”这一强大的模型开始。在这些新观念之中，cockburn引入了：利用竞争产生动力而不破坏合作，从精益制造中学习教训以及为了沟通而平衡战略。作者还解释了如何在业务和工程项目上而不仅仅是在软件开发上进行合作博弈。
作者系统地演示了敏捷模型，展示了敏捷模型的演进，并且回答了开发人员和项目经理最常提出的问题，其中包括：
■ 哪些地方适合敏捷开发？
■ 如何将敏捷观念与其他观念融合在一起？
■ 如何对敏捷观念进行扩展？
书中呈现了造成很多敏捷项目失败的至关重要的错误概念。例如，将项目管理策略编码到固定的过程中会导致低效率的战略决策和高成本的错误。此外，本书还深入讨论了关于敏捷方法和用户体验设计之间的有争议的关系。
cockburn讨论了为团队建立敏捷方法学这一实践上的挑战，解释了如何对方法学进行调整并持续地再创造，以及如何管理不完全的沟通。
第2版主要增加了以下内容：
■ 敏捷与cmmi。
■ 自顶向下地介绍敏捷。
■ 重访“客户合同”。
■ 用“贴纸”来创建变更。
另外，cockburn还更新了关于crystal方法学的讨论，这种方法利用了“合作博弈”作为其核心的隐喻。
无论是敏捷开发新手，还是有经验的软件开发人员和项目管理人员，都会从本书中受益。
作译者回到顶部↑
本书提供作译者介绍
Alistair Cockburn，国际知名软件项目管理方面的专家，用例技术、对象技术和敏捷方法大师，于2001年和2002年两次获得Jolt生产力奖。他是Humans and Technology公司的资深顾问，负责帮助客户成功地进行面向对象项目。他在软硬件开发方面有20多年的项目管理经验。所涉及的领域有保险业、零售业、电子商务公司，并曾在大公司（如挪威中心银行和IBM）中任职。除本书外，他还著有《编写有效用例》（本书中文版已由机械工业出版社出版）、《○○项目求生法则》和《Crystal Clear：小团队的敏捷开发方法》。
.. << 查看详细
.. << 查看详细
目录回到顶部↑
preface
preface to 2nd edition
list of figures
list of stories
0 unknowable and lncommunicable
the problem with parsing experience
the impossibility of communication
three levels of listening
so,whatdoidotomorrow?
0.1 unknowable and incohhunicable：evolution
communication and shared experience
shu-ha-ri
chapter 1 a cooperative game of invention and communication
software and poetry
software and games
a second look at the cooperative game
what should this mean to me?
chapter 1.1 a cooperative game of lnvention and cohhunicatlon：evolution
the swamp game
competition within cooperation．
preface to 2nd edition
list of figures
list of stories
0 unknowable and lncommunicable
the problem with parsing experience
the impossibility of communication
three levels of listening
so,whatdoidotomorrow?
0.1 unknowable and incohhunicable：evolution
communication and shared experience
shu-ha-ri
chapter 1 a cooperative game of invention and communication
software and poetry
software and games
a second look at the cooperative game
what should this mean to me?
chapter 1.1 a cooperative game of lnvention and cohhunicatlon：evolution
the swamp game
competition within cooperation．
前言回到顶部↑
The agile model of software development took the world by storm in 2001. Within a year there were books and conferences on it around the orld. Within five years, it had influenced everything from project management and how corporate executives write contracts with their clients,to military procurement procedures, and even to college curricula. .
It is time to look at the changes and see what we can learn about the agile model, and more generally, the cooperative game.
At the time that the Manifesto for Agile Software Development was written-February 2001--I was already deep into writing about software development as a cooperative game and the tailoring of methodologies to individual projects.The manifesto merely echoed what I and others were already doing.
The agile model took the world by storm. Hundreds of developers signed the online signing board (the original,informal Agile Alliance, not to be confused with the AgileAlliance corporation that was formed later and runs the Agile conferences in the U.S.) to show their alignment with its values and principles.
After the initial questions around
"What does this mean?," people asked:
· "Where does it fit in the total set of development situations?"
· "How do we blend these ideas with others?"
· "How do we extend these ideas to other fields?"
These are the questions picked up by the additional text in this second edition.
The cooperative game model grew alongside the agile model. Originally constructed to explain software development, it struck a chord with business people, who tightly saw that business is also predominantly a cooperative (and competitive!) game of invention and communication.
You would imagine that during the past five years, something should have come as a surprise to me. I highlight four:
· Engineering is also a cooperative game of invention and communication. With a bit of refraining, we can now place software engineering as a proper member of the engineering fields.
I leave intact in the second edition the fairly strong words I wrote originally against the idea that software development should be treated as engineering. I do so because those words still apply to the way in which most people still incorrectly view engineering and draw from it correspondingly incorrect ways of how to manage software development. In this second edition text, I turn the investigation back to the question,"What is engineering?"
After the second world war, discipline envy of applied physics mused wishful thinking in engineering academia, and popular understanding of engineering got off track. Looking afresh at engineering practices, we notice that it is itself a coperative game of invention and communication. From this, we can create an updated notion of software engineering that makes sense both practically and pedagogically.
· The specialty area of user experience design has made strong inroads in the last five years. It was ignored by the authors of the manifesto, and deserves serious attention.
All of the early agile methodologies skipped completely over this issue, probably because none of the manifesto authors had strong expertise in that area. That area has been and still is an area of hot debate, with few solid
condusions. I discuss the conclusions andpoints of contention in that section.
· I have learned how to separate project management strategues
Project management strategies too often get placed--incorrectly--as part of a corporate process or methodology Encoding what should be on-thescene strategies as fixed policies often forces managers to make ineffective strategy decisions and costs the organization greatly. It is therefore important to learn to separate the two.
It is time to look at the changes and see what we can learn about the agile model, and more generally, the cooperative game.
At the time that the Manifesto for Agile Software Development was written-February 2001--I was already deep into writing about software development as a cooperative game and the tailoring of methodologies to individual projects.The manifesto merely echoed what I and others were already doing.
The agile model took the world by storm. Hundreds of developers signed the online signing board (the original,informal Agile Alliance, not to be confused with the AgileAlliance corporation that was formed later and runs the Agile conferences in the U.S.) to show their alignment with its values and principles.
After the initial questions around
"What does this mean?," people asked:
· "Where does it fit in the total set of development situations?"
· "How do we blend these ideas with others?"
· "How do we extend these ideas to other fields?"
These are the questions picked up by the additional text in this second edition.
The cooperative game model grew alongside the agile model. Originally constructed to explain software development, it struck a chord with business people, who tightly saw that business is also predominantly a cooperative (and competitive!) game of invention and communication.
You would imagine that during the past five years, something should have come as a surprise to me. I highlight four:
· Engineering is also a cooperative game of invention and communication. With a bit of refraining, we can now place software engineering as a proper member of the engineering fields.
I leave intact in the second edition the fairly strong words I wrote originally against the idea that software development should be treated as engineering. I do so because those words still apply to the way in which most people still incorrectly view engineering and draw from it correspondingly incorrect ways of how to manage software development. In this second edition text, I turn the investigation back to the question,"What is engineering?"
After the second world war, discipline envy of applied physics mused wishful thinking in engineering academia, and popular understanding of engineering got off track. Looking afresh at engineering practices, we notice that it is itself a coperative game of invention and communication. From this, we can create an updated notion of software engineering that makes sense both practically and pedagogically.
· The specialty area of user experience design has made strong inroads in the last five years. It was ignored by the authors of the manifesto, and deserves serious attention.
All of the early agile methodologies skipped completely over this issue, probably because none of the manifesto authors had strong expertise in that area. That area has been and still is an area of hot debate, with few solid
condusions. I discuss the conclusions andpoints of contention in that section.
· I have learned how to separate project management strategues
Project management strategies too often get placed--incorrectly--as part of a corporate process or methodology Encoding what should be on-thescene strategies as fixed policies often forces managers to make ineffective strategy decisions and costs the organization greatly. It is therefore important to learn to separate the two.
加载中...
