敏捷開發(fā)藝術(shù)

前言

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.

內(nèi)容概要

　　本書是講解如何利用敏捷開發(fā)方法構(gòu)建高價值軟件的實用指南，描述了什么是敏捷開發(fā)，以及它能幫助軟件項目獲得成功的原因。該書還將開發(fā)者、項目經(jīng)理、測試者和客戶所需信息整合在一起，以便直接運用?！　　睹艚蓍_發(fā)藝術(shù)》展現(xiàn)了敏捷過程的完整視圖，基于作者多年的極限編程（XP）經(jīng)驗，直截了當?shù)靥岢鲫P(guān)于計劃、開發(fā)、交付和管理等多方面實施的建議。它為開發(fā)者和測試者提供實用的技術(shù)練習，同樣也為非技術(shù)背景讀者提供了充分的信息。作者還介紹了如何處理敏捷開發(fā)中的棘手問題：建立團隊成員之間的協(xié)作和信任關(guān)系?！　　睹艚蓍_發(fā)藝術(shù)》針對下列問題給出明確的答案：  　如何采用敏捷開發(fā)？  　我們是否真的需要結(jié)對編程？  　應(yīng)該基于何種度量（metrics）報告？  　如何讓我們的客戶共同參與項目？  　我們應(yīng)該撰寫多少文檔？  　何時設(shè)計架構(gòu)？  　作為非開發(fā)者，該如何與敏捷團隊合作？　　我的產(chǎn)品路線圖在哪里？　　QA如何適應(yīng)敏捷開發(fā)？無論你是敏捷團隊的一員，還是剛剛對敏捷開發(fā)產(chǎn)生興趣，這本書都具備了你需要的所有實用技巧。它向你說明引入XP的過程，詳細描述其中每一項實踐，并且討論了如何修改xP和創(chuàng)建自己的敏捷方法等相關(guān)原則。該書將隨著你的經(jīng)驗提升而不斷深入，首先教你規(guī)則，然后告訴你如何突破它們，當你掌握了敏捷開發(fā)藝術(shù)之時，最終便可以擯棄一切規(guī)則。

作者簡介

作者：(美國)肖爾 (James Shore) (美國)活登 (Shane Warden)

書籍目錄

PrefacePart Ⅰ. Getting Started　1.Why Agile？　　Understanding Success　　Beyond Deadlines　　The Importance of Organizational Success　　Enter Agility　2.How to Be Agile　　Agile Methods　　Don't Make Your Own Method　　The Road to Mastery　　Find a Mentor　3.Understanding XP　　The XP Lifecyde　　The XP Team　　XP Concepts　4.Adopting XP　　Is XP Right for Us？　　Go!　　Assess Your AgilityPart Ⅱ. Practicing XP　5.Thinking　　Pair Programming　　Energized Work　　Informative Workspace　　Root-Cause Analysis　　Retrospectives　6.Collaborating　　Trust　　Sit Together　　Real Customer Involvement　　Ubiquitous Language　　Stand-Up Meetings　　Coding Standards　　Iteration Demo　　Reporting　7.Releasing　　"Done Done"　　No Bugs　　Version Control　　Ten-Minute Build　　Continuous Integration　　Collective Code Ownership　　Documentation　8.Planning　　Vision　　Release Planning　　The Planning Game　　Risk Management　　Iteration Planning　　Slack　　Stories　　Estimating　9.Developing　　Incremental Requirements　　Customer Tests　　Test-Driven Development　　Re factoring　　Simple Design　　Incremental Design and Architecture　　Spike Solutions　　Performance Optimization　　Exploratory TestingPart Ⅲ. Mastering Agility　10. Values and Principles　　Commonalities　　About Values, Principles, and Practices　　Further Reading　11.Lmprove the Process    Unedrstand Your Project    Tune and Adapt     Bread the Rules　12.Rely on People　　Build Effective Relationships　　Let the Right People Do the Right Things　　Build the Process for the People　13.Eliminate Waste　　Work in Small, Reversible Steps　　Fail Fast　　Maximize Work Not Done　　Pursue Throughput　14. Deliver Value　　Exploit Your Agility　　Only Releasable Code Has Value　　Deliver Business Results　　Deliver Frequently　15. Seek Technical Excellence　　Software Doesn't Exist　　Design Is for Understanding　　Design Trade-offs　　Quality with a Name　　Great Design　　Universal Design Principles　　Principles in Practice　　Pursue MasteryReferencesIndex

章節(jié)摘錄

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 thingtheir 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 about what goes into the product and what stays out. She must have the political savvy to align diverse stakeholder interests, consolidate them into the product vision, and effectively say "no" to wishes that can't be accommodated.Product managers of this caliber often have a lot of demands on their time. You may have trouble getting enough attention. Persevere. Theirs is one of the most crucial roles on the team. Enlist the help of your project manager and remind people that software development is very expensive. If the software isn't valuable enough to warrant the time of a good product manager——a product manager who could mean the difference between success and failure——perhaps it isn't worth developing in the first place.Make sure your product manager is committed to the project full-time. Once a team is running smoothly, the product manager might start cutting back on his participation. Although domain experts and other on-site customers can fill in for the product manager for a time, the project is likely to start drifting off-course unless the product manager participates in every iteration. [Rooney] experienced that problem, with regrettable results:We weren't sure what our priorities were. We weren't exactly sure what to work on next. We pulled stories from the overall list, but there was precious little from the Customer [product anager] in terms of what we should be working on. This went on for a few months.Then, we found out that the Gold Owner [executive sponsor] was pissed——really pissed. We hadn't been working on what this person thought we should.In a predictable environm nt, and by delegating to a solid set of on-site customers, a product manager might be able to spend most of his time on other things, but he should still participate in every retrospective, every iteration demo, and most release planning sessions.Some companies have a committee play the role of product manager, but I advise against this approach.The team needs a consistnt vision to follow, and I've found that committees have trouble creating consistent, compelling visi ns. When I've seen committees succeed, it's been because one committee member acted as de facto product manager. I recommend that you explicitly find a product manager.Her role may be nothing more than consolidating the ideas of the committee into a single vision, and that's likely to keep her hands full. Be sure to choose a product manager with plenty of political acumen in this case.Most software operates in a particular industry, such as finance, that has its own specialized rules for doing business. To succeed in that industry, the software must implement those rules faithfully and exactly. These rules are domain rules, and knowledge of these rules is domain knowledge.Most programmers have gaps in their domain knowledge, even if they've worked in an industry for years. In many cases, the industry itself doesn't clearly define all its rules. The basics may be clear, but there are nitpicky details where domain rules are implicit or even contradictory.The team's domain experts are responsible for figuring out these details and having the answers at their fingertips. Domain experts, also known as subject matter experts, are experts in their field. Examples include financial analysts and PhD chemists.Domain experts spend most of their time with the team, figuring out the details of upcoming stories and standing ready to answer questions when programmers ask. For complex rules, they create customer tests (often with the help of testers) to help convey nuances. The user interface is the public face of the product. For many users, the UI is the product. They judge the product's quality solely on their perception of the UI.Interaction designers help define the product UI. Their job focuses on understanding users, their needs, and how they will interact with the product. They perform such tasks as interviewing users, creating user personas, reviewing paper prototypes with users, and observing usage of actual software.NOTE Don't confuse graphic design with interaction design. Graphic designers convey ideas and moods via images and layout. Interaction designers focus on the types of people using the product, their needs, and how the product can most seamlessly meet those needs. You may nothave a professional interaction designer on staff. Some companies fill this role with a graphic designer, the product manager, or a programmer. Interaction designers divide their time between working with the team and working with users. They contribute to release planning by advising the team on user needs and priorities. During each iteration, they help the team create mock-ups of UI elements for that iteration's stories. As each story approaches completion, they review the look and feel of the UI and confirm that it works as expected. The fast, iterative, feedback-oriented nature of XP development leads to a different environment than interaction designers may be used to. Rather than spending time researching users and defining behaviors before development begins, interaction designers must iteratively refine their models concurrently with iterative refinement of the program itself. Although interaction design is different in XP than in other methods, it is not necessarily diminished. XP produces working software every week, which provides a rich grist for the interaction designer's mill. Designers have the opportunity to take real software to users, observe their usage patterns, and use that feedback to effect changes as soon as one week later. On nonagile teams, business analysts typically act as liaisons between the customers and developers, by clarifying and refining customer needs into a functional requirements specification. On an XP team, business analysts augment a team that already contains a product manager and domain experts. The analyst continues to clarify and refine customer needs, but the analyst does so in support of the other on-site customers, not as a replacement for them. Analysts help customers think of details they might otherwise forget and help programmers express technical trade-offs in business terms.A great product vision requires solid execution. The bulk of the XP team consists of software developers in a variety of specialties. Each of these developers contributes directly to creating working code. To emphasize this, XP calls all developers programmers.

媒體關(guān)注與評論

“我會將此書送給我訪問過的每一個團隊?！薄?Brian Marick，Exampler Consulting ...

編輯推薦

《敏捷開發(fā)藝術(shù)(影印版)》由東南大學出版社出版。

圖書封面

圖書標簽Tags

無

評論、評分、閱讀與下載

---

    敏捷開發(fā)藝術(shù) PDF格式下載

---