敏捷开发艺术(影印版)(The Art of Agile Development)
点此进入淘宝搜索页搜索分類: 图书,计算机与互联网,软件工程及软件方法学,软件过程,
品牌: 肖尔
基本信息·出版社：东南大学出版社
·页码：409 页
·出版日期：2008年
·ISBN：7564112417/9787564112417
·条形码：9787564112417
·包装版本：1版
·装帧：平装
·开本：16
·正文语种：英语
·外文书名：The Art of Agile Development
产品信息有问题吗？请帮我们更新产品信息。
内容简介《敏捷开发艺术》是讲解如何利用敏捷开发方法构建高价值软件的实用指南，描述了什么是敏捷开发，以及为什么它能帮助软件项目获得成功的原因。该书还将开发者、项目经理、测试者和客户所需信息整合在一起，以便直接运用。
《敏捷开发艺术》展现了敏捷过程的完整视图，基于作者多年的极限编程（XP）经验，直截了当地提出关于计划、开发、交付和管理等多方面实施的建议。它为开发者和测试者提供实用的技术练习，同样也为非技术背景读者提供了充分的信息。作者还介绍了如何处理敏捷开发中的棘手问题：建立团队成员之间的协作和信任关系。
《敏捷开发艺术》针对下列问题给出明确的答案：
如何采用敏捷开发？
我们是否真的需要结对编程？
应该基于何种度量（metrics）报告？
如何让我们的客户共同参与项目？
我们应该撰写多少文档？
何时设计架构？
作为非开发者，该如何与敏捷团队合作？
我的产品路线图在哪里？
QA如何适应敏捷开发？
无论你是敏捷团队的一员，还是刚刚对敏捷开发产生兴趣，这《敏捷开发艺术》具备了你需要的所有实用技巧。它向你说明引入XP的过程，详细描述其中每一项实践，并且讨论了如何修改XP和创建自己的敏捷方法等相关原则。该书将随着你的经验提升而不断深入，首先教你规则，然后告诉你如何突破它们，当掌握了敏捷开发艺术之时，最终便可以摈弃一切规则。
媒体推荐“我会将此书送给我访问过的每一个团队。”
—— Brian Marick，Exampler Consulting ...
目录
Preface. xiii
Part I. Getting Started
1. Why Agile? 3
Understanding Success 4
Beyond Deadlines 4
The Importance of Organizational Success 5
Enter Agility 6
2. How to Be Agile 9
Agile Methods 9
Don’t Make Your Own Method 10
The Road to Mastery 11
Find a Mentor 12
3. Understanding XP 15
The XP Lifecycle 18
The XP Team 27
XP Concepts 39
4. Adopting XP43
Is XP Right for Us? 43
Go! 51
Assess Your Agility 62
Part II. Practicing XP
5. Thinking 69
Pair Programming 71
Energized Work 79
Informative Workspace 83
Root-Cause Analysis 88
Retrospectives 91
6. Collaborating 99
Trust 102
Sit Together 112
Real Customer Involvement 120
Ubiquitous Language 124
Stand-Up Meetings 129
Coding Standards 133
Iteration Demo 138
Reporting 144
7. Releasing153
“Done Done” 156
No Bugs 160
Version Control 169
Ten-Minute Build 177
Continuous Integration 183
Collective Code Ownership 191
Documentation 195
8. Planning 199
Vision 201
Release Planning 206
The Planning Game 219
Risk Management 224
Iteration Planning .. 233
Slack 246
Stories 253
Estimating 260
9. Developing271
Incremental Requirements 273
Customer Tests 278
Test-Driven Development 285
Refactoring 303
Simple Design 314
Incremental Design and Architecture 321
Spike Solutions 331
Performance Optimization 335
Exploratory Testing 341
Part III. Mastering Agility
10. Values and Principles 353
Commonalities 353
About Values, Principles, and Practices 354
Further Reading 354
11. Improve the Process 357
Understand Your Project 357
une and Adapt 358
Break the Rules 359
12. Rely on People 361
Build Effective Relationships 361
Let the Right People Do the Right Things 363
Build the Process for the People 364
13. Eliminate Waste 367
Work in Small, Reversible Steps 367
Fail Fast 369
Maximize Work Not Done 370
Pursue Throughput 371
14. Deliver Value 375
Exploit Your Agility 375
Only Releasable Code Has Value 376
Deliver Business Results 378
Deliver Frequently 379
15. Seek Technical Excellence381
Software Doesn’t Exist 381
Design Is for Understanding 382
Design Trade-offs 383
Quality with a Name 383
Great Design 383
Universal Design Principles 384
Principles in Practice 387
Pursue Mastery 388
References 391
Index... 397
……[看更多目录]
序言We want to help you master the art of agile development
Agile development, like any approach to team-based software development, is a fundamentally human art, one subject to the vagaries of individuals and their interactions. To master agile development, you must learn to evaluate myriad possibilities, moment to moment, and intuitively pick the best course of action.
How can you possibly learn such a difficult skill? Practice!
First and foremost, this book is a detailed description of one way to practice agile development: Extreme Programming (XP). It’s a practical guide that, if followed mindfully, will allow you to successfully bring agile development in the form of XP to your team—or will help you decide that it’s not a good choice in your situation.
Our second purpose is to help you master the art of agile development. Mastering agility means going beyond our cookbook of practices. Agile development is too context-sensitive for one approach to be entirely appropriate, and too nuanced for any book to teach you how to master it. Mastery comes from within: from experience and from an intuitive understanding of ripples caused by the pebble of a choice. We can’t teach you how your choices will ripple throughout your organization. We don’t try. You must provide the nuance and understanding. This is the only way to master the art. Follow the practices. Watch what happens. Think about why they worked... or didn’t work. Then do them again. What was the same? What was different? Why? Then do it again. And again. ..
At first, you may struggle to understand how to do each practice. They may look easy on paper, but putting some practices into action may be difficult. Keep practicing until they’re easy.
As XP gets easier, you will discover that some of our rules don’t work for you. In the beginning, you won’t be able to tell if the problem is in our rules or in the way you’re following them. Keep practicing until you’re certain. When you are, break the rules. Modify our guidance to work better for your specific situation.
Parts I and II of this book contain our approach to XP. Part I helps you get started with Extreme Programming; Part II provides detailed guidance for each of XP’s practices. Parts I and II should keep you occupied for many months.
When you’re ready to break the rules, turn to Part III. A word of warning: there is nothing in Part III that will help you practice XP. Instead, it’s full of ideas that will help you understand XP and agile development more deeply.
One day you’ll discover that rules no longer hold any interest for you. After all, XP and agile development aren’t about following rules. “It’s about simplicity and feedback, communication and trust,” you’ll think. “It’s about delivering value—and having the courage to do the right thing at the right time.” You’ll evaluate myriad possibilities, moment to moment, and intuitively pick the best course of action.
When you do, pass this book on to someone else, dog-eared and ragged though it may be, so that they too can master the art of agile development.
文摘Two customers for every three programmers seems like a lot, doesn't it? Initially I started with a much smaller ratio, but I often observed customers struggling to keep up with the programmers. Eventually I arrived at the two-to-three ratio after trying different ratios on several successful teams. I also asked other XP coaches about their experiences. The consensus was that the two-to-three ratio was about right.
Most of those projects involved complex problem domains, so if your software is fairly straightforward, you may be able to have fewer customers. Keep in m ind that customers have a lot of work to do. They need to figure out what provides the most value, set the appropriate priorities for the work, identify all the details that programmers will ask about, and fit in time for customer reviews and testing. They need to do all this while staying one step ahead of the programmers, who are right behind them, crunching through stories like freight trains. It's a big iob. Don't underestimate it. The product manager has only one job on an XP project, but it's a doozy. That job is to maintain and promote the product vision. In practice, this means documenting the vision, sharing it with stakeholders, incorporating feedback, generating features and stories, setting priorities for release planning, providing direction for the team's on-site customers, reviewing work in progress, leading iteration demos, involving real customers, and dealing with organizational politics.
The best product managers have deep understandings of their markets, whether the market is one organization (as with custom software) or many (as with commercial software). Good product managers have an intuitive understanding of what the software will provide and why it's the most important thing
their project teams can do with their time. A great product manager also has a rare combination of skills. In addition to vision, she must have the authority to make difficult t ade-off decisions abo
……[看更多书摘]
