敏捷开发的艺术与实践

需积分: 50 107 浏览量更新于2024-07-27 1 收藏 9.53MB PDF 举报

"敏捷开发的艺术" 《敏捷开发的艺术》是一本深入探讨敏捷开发实践与益处的书籍，由Jim Shore和Shane Warden合著。这本书以其丰富的实例和实践经验，为读者揭示了极限编程（Extreme Programming, XP）的核心理念。作者不仅详细解释了各种敏捷实践，还解答了关于这些实践可能遇到的问题和误用情况，提供了如何在实际应用中避免陷阱的建议。例如，当缺乏现场客户时，他们提出替代方案以确保敏捷方法的有效实施。书中不仅关注技术实践，更强调团队合作和人际关系的重要性。作者讨论了建立信任和团队凝聚力的策略，使整个书籍内容更加全面，帮助读者理解如何在团队环境中成功推行敏捷开发。书中的见解和建议得到了业界专家的认可，如Ken Pugh（《Prefactoring》作者）和Brian Marick（Exampler Consulting创始人）都给予了高度评价。除了《敏捷开发的艺术》外，O'Reilly出版社还提供了其他相关资源，包括《Beautiful Code》、《极限编程袖珍指南》、《Prefactoring》以及《应用软件项目管理》等，这些都是进一步学习和深化敏捷开发知识的优秀读物。O'Reilly.com网站不仅是这些书籍的完整目录，还提供更多的学习资料和技术资源，是开发者获取专业信息的重要平台。通过阅读《敏捷开发的艺术》，读者将能够深入了解敏捷开发的精髓，掌握如何在实际工作中有效地运用敏捷原则和方法，提升团队效率，促进项目的成功执行。这本书对于希望改进开发流程，提高软件开发质量和速度的团队来说，是一份不可或缺的指南。

If you just want to learn enough to do your job, you can focus primarily on Part II. Start with

Chapter 3 in Part I to get an overview, then read through the practices in Part II that apply to your work.

Each practice starts with a description of the audience it applies to, such as “Programmers,” “Customers,”

or “Testers.”

If you’re merely curious about agile development, start by reading Part I. Again, Chapter 3 provides a

good introduction. Afterwards, take a look at the practices in Part II. Start with the ones that look most

interesting; you can read them in any order.

About the Études

Have you ever heard a musician playing scales? That’s an étude (if a boring one). An étude teaches

mastery through precise and careful repetition. Eventually, the étude is abandoned, but the skills

remain.

Extreme Programming is our étude for software development. We hope that practicing Extreme

Programming week after week will help you master agile development. Eventually, you’ll change your

practices, but the underlying principles will remain.

Besides the overarching étude of Extreme Programming, we’ve included a mini-étude for each major

theme of agile development. Beginning agile teams can use the études to refine their practice of agile

development. As you gain experience, look deeper; use the études to help connect Part II’s detailed

practices to Part III’s general principles.

NOTE

These études are also useful for teams not currently practicing XP.

Either way, the études require thought to be effective. Each étude provides information, but it doesn’t

tell you how to act on that information. Think about it. What did you learn from the étude? What was

frustrating or exciting? How does that information affect your work? What will you do about it? Without

attention and reflection—that is, mindfulness—the études are just games.

NOTE

It’s no coincidence that you need mindfulness to master the art of agile development

as well. You have to think about more than XP’s practices for it to be effective.

Like musical études, our mini-études work best when you repeat them. We’ve designed them to take

half an hour, so you can (and should) practice them every day for a week or more. Unlike musical

études, these agile exercises work best when you include your whole team. The more you all understand

about the process and where everyone fits in, the better you will work together.

To start, you need a quiet work area capable of holding everyone in your team comfortably. There

should be a whiteboard or wall where you can hang or post index cards between meetings. There must

also be sufficient space to break into groups of two or three people and to talk softly without disturbing

other groups.

We’ve found it valuable to use a timer, whether a stopwatch or a kitchen timer, to keep the session

moving. Each étude has a few parts of 5 to 10 minutes. Although that time will seem to flow quickly

P RE FA CE XV

on your first day, respect the time limits. You’ll perform the étude again tomorrow, so it’s OK if you

don’t finish everything.

Choose one member of your team to facilitate the étude by watching the time (perhaps calling out “one

minute remaining” when appropriate) and promoting discussion. Again, the first session may be hard,

but a good facilitator can encourage everyone to continue.

At the end of each étude, we recommend spending a few minutes debriefing. What did you learn? Are

there questions and ideas you can follow up on during your regular work? If you’ve been trying this

exercise for more than a week, are you still getting valuable results?

If you’re new to XP and agile development, we strongly recommend that you perform each étude while

you study the related chapter as a team. Besides exploring one particular theme in agile development,

each étude can illuminate an aspect of how your team works together on your agile project.

About Pronouns

We speak in first-person singular rather than first-person plural in the rest of this book. (We say “I,”

not “we.”) We include a lot of personal anecdotes and experiences, and the singular form works better

as a result. However, this book is unquestionably the result of a partnership between two authors and

our use of the word “I” is merely a convenience.

Using Code Examples

This book is here to help you get your job done. In general, you may use the code in this book in your

programs and documentation. You do not need to contact us for permission unless you’re reproducing

a significant portion of the code. For example, writing a program that uses several chunks of code from

this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly

books does require permission. Answering a question by citing this book and quoting example code

does not require permission. Incorporating a significant amount of example code from this book into

your product’s documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title, author,

publisher, and ISBN. For example: “The Art of Agile Development by James Shore and Shane Warden.

If you feel your use of code examples falls outside fair use or the permission given above, feel free to

Safari® Enabled

When you see a Safari® Enabled icon on the cover of your favorite technology book, that means the

book is available online through the O’Reilly Network Safari Bookshelf.

Safari offers a solution that’s better than e-books. It’s a virtual library that lets you easily search

thousands of top tech books, cut and paste code samples, download chapters, and find quick answers

when you need the most accurate, current information. Try it for free at http://safari.oreilly.com.

XVI P RE FA CE

How to Contact Us

Please address comments and questions concerning this book to the publisher:

O’Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

800-998-9938 (in the United States or Canada)

707-829-0515 (international or local)

707 829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You

can access this page at:

http://www.oreilly.com/catalog/9780596527679

To comment or ask technical questions about this book, send email to:

bookquestions@oreilly.com

For more information about our books, conferences, Resource Centers, and the O’Reilly Network, see

our web site at:

http://www.oreilly.com

Acknowledgments

We owe a debt of gratitude to Elisabeth Hendrickson for her contribution of the “Exploratory Testing”

section. Her expertise and writing skill made the material sparkle. For more of Elisabeth’s writing, visit

http://www.testobsessed.com/.

We stole good ideas wherever we could find them. Kent Beck, Ron Jeffries, and Ward Cunningham

each had a hand in the ideas that led to XP, and we stole liberally from those. In addition to XP itself,

Kent Beck introduced us to the idea of XP practices as études. Ward Cunningham introduced us to the

notion of technical debt, a concept we use heavily. Brian Marick’s series of essays, “Agile Testing

Directions,”

influenced our thoughts on agile testing and the role of testers on agile teams.

James had the opportunity to work with Joshua Kerievsky on an Industrial XP (IXP)

†

project for half a

year. He learned a lot from that project; the Vision practice in particular was inspired by IXP’s Project

Chartering practice. David Schwartz and Amy Schwab of True North pgs, Inc.,

‡

provided the specific

vision format that we use, as well as the term project community. Their Mastering Projects workshop is

excellent; take it when you have the opportunity.

Thank you to our editor, Mary Treseler O’Brien, for providing vision (where necessary), trust (where

appropriate), and deadlines (where frightening). This book would not be what it is without you gently

nudging us in directions different from our original ideas.

Thanks also to our army of reviewers, who provided over one thousand comments and suggestions on

our mailing list. In particular, thanks to Adrian Howard, Adrian Sutton, Ann Barcomb, Andy Lester,

http://www.testing.com/cgi-bin/blog/2004/05/26

†

http://www.industrialxp.org/

‡

http://www.projectcommunity.com/

P RE FA CE XVII

Anthony Williams, Bas Vodde, Bill Caputo, Bob Corrick, Brad Appleton, Chris Wheeler, Clarke Ching,

Daði Ingólfsson, Diana Larsen, Erik Petersen, George Dinwiddie, Ilja Preuß, Jason Yip, Jeff Olfert, Jeffery

Palermo, Jonathan Clarke, Keith Ray, Kevin Rutherford, Kim Gräsman, Lisa Crispin, Mark Waite,

Nicholas Evans, Philippe Antras, Randy Coulman, Robert Schmitt, Ron Jeffries, Shane Duan, Tim

Haughton, and Tony Byrne for their extensive comments. Special thanks to Brian Marick, Ken Pugh,

and Mark Streibeck for their comments on the completed draft.

James Shore

Every work builds on what came before. I was fortunate to have not just one, but many giants to stand

on. Without the inspired work of Kent Beck, Alistair Cockburn,Ward Cunningham, Tom DeMarco,

Martin Fowler, Ron Jeffries, Timothy Lister, Steve McConnell, and Gerald Weinberg, I wouldn’t have

anything close to the understanding of software development I have today. It’s thanks to their example

that this book exists. In particular, thanks to Alistair Cockburn for generously inviting me to his

roundtable and introducing me to the agile community.

If giants enabled me to contribute to this book, then Kim Eaves and the Denali team brought the

stepladder. Without their enthusiastic support, I never would have been able to try that crazy XP thing.

Thanks also to Rob Myers for his ever-friendly consideration of my rants.

I also gratefully acknowledge my coauthor and friend, Shane Warden. This project morphed from a

little 100-page second edition into a 400-page monster. You didn’t complain once. Thanks for putting

up with me. (And hey! Nice book.)

Finally, thank you, Neeru, my loving and patient wife. I used to think authors thanking their families

was cliché. Now I understand. I couldn’t have finished this book without your support.

Shane Warden

Thanks to Jim for arguing with me while writing the first version of this book (it’s better for it) and for

convincing me that the second edition was worth doing.

Thanks to Allison and Andrew for the tools we used to write this book.

Thanks to my family for supporting me (and not grumbling too much while I sat upstairs and wrote

very slowly), and to my friends for dragging me out of my house once in a while.

Thanks also to the other contributors to Parrot and Perl 6 for being unwitting collaborators, examples,

and victims of some of the ideas in this book. The work we do continually amazes me.

XVIII P RE FA CE

剩余431页未读，继续阅读

koen1000

粉丝: 0
资源: 27

敏捷开发的艺术与实践

信息安全_数据安全_dev-r04-agile-and-continuous-thr.pdf

Pragmatic Rails 3rd Ed: Agile Web Dev with Ruby on Rails 2.2.2

Rails 4th Edition: Agile Web Dev with Current Techniques & Compatibility

Rails 3.1 教材：《Agile Web Dev with Rails》第四版

Agile-Software-Dev-Refactoring：重构以实现高性能敏捷软件开发，重构以获取更好的代码。 重构就是通过简化代码来提高代码质量。 更简单的代码可实现敏捷性，快速更改代码，添加新功能，满足人们不断变化的需求的能力

Agile SCRUM for Trello boards-crx插件

Clean Code - A Handbook of Agile Software Craftsmanship

agile-brazil-hotsite:巴西敏捷网站

What CIO needs to know about the agile and DevOps

DevOps Essentials CI/CD / Agile / LEAN

最新资源

Agile-Software-Dev-Refactoring：重构以实现高性能敏捷软件开发，重构以获取更好的代码。重构就是通过简化代码来提高代码质量。更简单的代码可实现敏捷性，快速更改代码，添加新功能，满足人们不断变化的需求的能力