visual studio team system better software development for agile teams

Contents at a GlancePreface xxvii Acknowledgments xxxv About the Authors xxxvii Introduction: Broken Process 1 Section 1: Apply Sharp Tools and Values 9 1 Introduction to Visual Studio T

Visual Studio Team System

Better Software Development

for Agile Teams

marks Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.

The authors and publisher have taken care in the preparation of this book, but make no expressed or implied ranty of any kind and assume no responsibility for errors or omissions No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.

war-The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests For more information, please contact:

U.S Corporate and Government Sales

Visit us on the Web: www.awprofessional.com

Library of Congress Cataloging-in-Publication Data

Stott, Will.

Visual studio team system : better software development for agile teams / Will Stott, James Newkirk.

p cm.

Includes bibliographical references and index.

ISBN 978-0-321-41850-0 (pbk : alk paper)

1 Microsoft Visual studio 2 Computer software—Development 3 eXtreme programming I Newkirk, James II Title

QA76.76.D47S775 2007

005.3—dc22

2007008442 Copyright © 2007 Pearson Education, Inc.

All rights reserved Printed in the United States of America This publication is protected by copyright, and mission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system,

per-or transmission in any fper-orm per-or by any means, electronic, mechanical, photocopying, recper-ording, per-or likewise Fper-or information regarding permissions, write to:

Pearson Education, Inc.

Rights and Contracts Department

75 Arlington Street, Suite 300

Boston, MA 02116

Fax: (617) 848-7047

ISBN 13: 978-0-321-41850-0

ISBN 10: 0-321-41850-6

Text printed in the United States on recycled paper at Courier in Stoughton, Massachusetts.

First printing, May 2007

Contents at a Glance

Preface xxvii

Acknowledgments xxxv

About the Authors xxxvii

Introduction: Broken Process 1

Section 1: Apply Sharp Tools and Values 9

1 Introduction to Visual Studio Team System 13

2 Agile Values 33

Review of Section 1: Sharp Tools and Values 45

Section 2: Introduce Agile Development 49

3 Overview of Agile Development 53

4 Forming an Agile Team 65

5 Team Foundation Process Frameworks 81

6 Improving Your Process Framework 107

Review of Section 2: Introduce Agile Development 119

Section 3: Use Version Control 123

7 Managing Change 127

8 Setting Up TFS Version Control 149

9 Using TFVC in Your Project 173

10 Policing Your Project with TFVC 191

Review of Section 3: Use Version Control 205

Section 4: Build and Integrate Often 209

11 Building and Integrating Software 213

12 Working with Team Foundation Build 229

Review of Section 4: Build and Integrate Often 255

Section 5: Practice Test-Driven Development 261

13 Introduction to TDD 265

14 Developing Your First Tests 283

vii

15 Learning to Refactor 303

16 Code Coverage and Performance 325

17 Integrating TFP Code with a User Interface 339

Review of Section 5: Practice Test-Driven Development 351

Section 6: Explore by Modeling 357

18 Modeling with Agility 361

19 Creating Models 375

20 Using Models in an Agile Project 395

21 Modeling Solutions with Patterns 415

Review of Section 6: Explore by Modeling 433

Section 7: Implement Customer Testing 439

22 Involving Customers in Testing 443

23 Creating FIT Fixtures 459

24 Running FIT with Team Foundation Build 481

Review of Section 7: Implement Customer Testing 501

Section 8: Estimate, Prioritize, and Plan 507

25 Estimating and Prioritizing Stories 511

26 Agile Planning 527

27 Managing Agile Projects 545

Review of Section 8: Estimate, Prioritize, and Plan 571

Section 9: Practice for Deployment 577

28 Moving into Production 581

29 Developing Installation Programs 597

30 Deployment of Distributed Systems 625

Review of Section 9: Practice for Deployment 661

Section 10: Provide and Reveal Value 665

31 Producing Technical Reports 669

32 Generating Business Value 683

Review of Section 10: Provide and Reveal Value 693

Retrospective: Fixing the Process 697

Section 11: Appendixes 713

A Setting Up VSTS for the Exercises 715

B Software Project Environment for a Small Team 729

Preface xxvii

Acknowledgments xxxv

About the Authors xxxvii

Introduction: Broken Process 1

Welcome to the OSPACS Team 1

Team Background 1

Current Organizational Structure and Personas 2

The Team’s Road Map for Fixing Its Process 6

Section 1: Apply Sharp Tools and Values 9

Story from the Trenches 10

1 Introduction to Visual Studio Team System 13

The Purpose and Structure of VSTS 13

Server Parts of VSTS 27

Team Foundation Server (TFS) 27

Project Portal and Report Sites 27

Team Foundation Build 29

Software Values and Traditions 35

The Agile Alliance 36

Section 2: Introduce Agile Development 49

Story from the Trenches 50

3 Overview of Agile Development 53

What Is Different about an Agile Project? 53

No Separate Development Phases 54

Specifying Requirements with Customer Stories 55

Introduction to Extreme Programming 57

Software Project Life Cycle 58

Iterative and Incremental 58

Iteration and Release Cycles 59

Iterations Deliver Production-Quality Code 60

Project Closure 61

Isn’t XP Just Hacking? 62

Why XP Doesn’t Encourage Hacking 63

4 Forming an Agile Team 65

The Nature of Agile Teams 65

Working As a Design Team 66

Self-Organizing Teams 68

Team Size 68

Work That Doesn’t Suit Agile Teams 69

Agile Team Structure 70

Customer Roles 70

Developer Roles 72

Associated Roles 75

Reorganizing the OSPACS Team 76

Identifying Customers and Developers 76

Rearranging the Office Space 78

5 Team Foundation Process Frameworks 81

Team Projects and Process Frameworks 81

Artifacts Generated When a Team Project Is Created 82

Creating an MSF for Agile Software Development Team Project 85

Deleting a Team Project 87

Giving Users Membership of Your Team Project Groups 88

Gaining Access to Your Team Project Services 89

Administering Your Team Project Security Settings 91

Administering Your TFS Security Settings 92

Connecting to a Team Project 93

Microsoft Solutions Framework (MSF) 4.0 95

Frameworks for Specific Processes 100

MSF for CMMI Process Improvement 100

MSF for Agile Software Development 102

MSF for XP 102

Process Framework Comparison 103

6 Improving Your Process Framework 107

Providing a New Metric for an Existing Process Framework 107

Adding a New Work Item Type 108

Adding a New Query 109

Improving Your Process 110

Process Template Structure 111

Importing and Exporting Process Templates 112

Changing Your Process Template 115

Review of Section 2: Introduce Agile Development 119The Team’s Impressions 120

Agile Values 121

Section 3: Use Version Control 123

Story from the Trenches 124

7 Managing Change 127

Sharing Information among Your Team 127

Why You Shouldn’t Keep Source Files in Shared Folders 128

Keeping Source Files in a Repository 129

Using a Version Control System 133

Locking and Merging 136

Labeling and Branching 138

Software Configuration Management 142

VSTS Support for Version Control Tools 144

Integration with Visual Studio 144

TFVC Features 145

TFS Support for Eclipse and Other Types of IDEs 147

8 Setting Up TFS Version Control 149

Structuring Your Team Project 149

Production and Spike Folders 149

Organization of Visual Studio Solutions, Projects, and Directories 151

Deciding What to Put into Version Control 154

Version Control for Team Documents 156

Archiving Third-Party Libraries 158

Establishing the Initial Baseline for Your Project 160

Adding Files and Directories to Version Control 160

Check In and Label the Baseline 164

Other Set-Up Tasks 166

Importing Source Files 166

Team Project Version Control Options 167

Visual Studio Source Control Options 168

Setting Up Security 169

Backup and Restore 170

9 Using TFVC in Your Project 173

Using TFVC When Coding 173

Sample Programming Episode: Version Control 174

Common Version Control Tasks 177

10 Policing Your Project with TFVC 191

Protecting Your Source Code 191

Controlling Access to Individual Files and Folders 192

Setting Check-in Constraints 193

Content s xiii

Establishing Policies for Source Code 195

Coding Standards 195

Static Code Analysis 196

Setting Static Code Analysis As a Check-in Policy 198 Implementing New Coding Standards 200

Updating Static Code Analysis Rules 201

Overriding Check-in Policies 201

Review of Section 3: Use Version Control 205The Team’s Impressions 206

Agile Values 207

Section 4: Build and Integrate Often 209

Story from the Trenches 210

11 Building and Integrating Software 213

Software Construction 213

Building and Integrating As a Team 214

Automated Build Lab 214

Software Integration and Test Environment 216

Automated Software Testing 217

Smoke Tests 219

Functional Tests 219

Structural (Unit) Tests 220

Quality of Service Tests 220

12 Working with Team Foundation Build 229

Welcome to Team Foundation Build 229

Setting Up Team Foundation Build 230

How Team Foundation Build Works 230

The Role of MSBuild 231

Making a Build Validation Test 233

Setting Team Build Permissions 235

Creating Team Build Types 237

Scheduling a Daily Build 239

Sample Programming Episode: Integration Build 240

Deleting Build Products 243

Optimizing Package Dependencies for Building 251

Review of Section 4: Build and Integrate Often 255

The Team’s Impressions 256

Agile Values 258

Section 5: Practice Test-Driven Development 261

Story from the Trenches 262

13 Introduction to TDD 265

The Nature of Test-Driven Development 265

Settling into the Rhythm of Test-First Programming 265

Top Down versus Bottom Up 268

Simple Test-First Programming Exercises 269

Define the List of Tests 269

Set Up a Basic Test Harness 269

TFP Cycle for the First Test 271

TFP Cycle for the Second Test 273

Review of the Exercises 276

Getting Started with Test-First Programming 277

Applying TFP on Your Team 277

Creating a List of Tests 278

Finding Additional Tests 278

Refactoring 280

14 Developing Your First Tests 283

Creating Visual Studio Projects for TFP 283

How VSTS Supports Unit Testing 283

Setting Up Visual Studio Projects for Unit Testing 285

The Story behind the Tests 287

About the “Image Favorites” Story 288

Dividing the Story into Tasks 288

Create a Test List 289

Finding Your Initial Tests 289

Record the Test List 291

Organization of Your Test List Code 293

Shelving Your Test List Code 293

Implementing the Tests 294

Start with the Easiest Test 294

Fix a Failing Test and Refactor 296

Comments about the Refactoring 299

Do the Next Three Tests Yourself 300

15 Learning to Refactor 303

Doing Small Refactorings 303

Implement a Collection 304

Refactor the Test 306

Refactor the Production Code 308

Safely Changing Code Implementation 309

Comments about the Refactoring 312

Refactor As You Go 313

Implementing More of the Requirement 313

Refactoring Opportunities 316

Doing a Big Refactoring 318

Remove the Middle Man 318

Changing the Type of a Collection 319

Performance Analysis 331

Sampling 332

Instrumentation 332

Example Performance Profiling Session 332

Improving Your Library Code’s Performance 335

Improving System Performance 337

17 Integrating TFP Code with a User Interface 339

Implementing the User Interface 339

Define the User Interface 340

Create a Task List 341

Implement the Windows Forms Application 342

Aim to Create a Thin User Interface Layer 344

Simple Design 346

Code Criteria for Simple Design 347

Avoiding Big Design Up Front 348

Review of Section 5: Practice Test-Driven Development 351The Team’s Impressions 352

Agile Values 354

Reinforcement of Agile Practices 355

Pair Programming 356

Shared Code 356

Single Code Base 356

Ten Minute Build 356

Continuous Integration 356

Section 6: Explore by Modeling 357

Story from the Trenches 358

18 Modeling with Agility 361

Introduction to Modeling 361

Models and Process 362

Values, Principles, and Practices of Agile Modeling 363

Values 363

Principles 363

Practices 364

Content s xvii

Agile Modeling in Use 366

Group Modeling 367 Modeling in Pairs 370 Agile Model-Driven Development 372

20 Using Models in an Agile Project 395

Implementation Models 411

Structural Models 412 Dynamic Models 413

21 Modeling Solutions with Patterns 415

What Is a Pattern? 415

Pattern Languages 416 Example: The Façade Pattern 417 Sources of Patterns 419

Using Patterns in an Agile Project 421

Example: Evolving Legacy Code with the Façade Pattern 422

Implementation of Patterns and Models 424

Design Patterns versus Components 425

Reusable Components 425

Emergence of Domain-Specific Languages 426

Use of DSL in Horizontal Market Applications 427

The Language Workbench 427

Software Factories 429

Review of Section 6: Explore by Modeling 433

The Team’s Impressions 434

Agile Values 436

Section 7: Implement Customer Testing 439

Story from the Trenches 440

22 Involving Customers in Testing 443

Agile Customer Testing 443

Testing throughout the Project 444

FIT: Framework for Integrated Test 445

Relationship of Customer Testing to Your Release Process 457

23 Creating FIT Fixtures 459

Standard FIT Fixtures 459

Column Fixtures: Testing Decisions in the Business Layer 460

Row Fixtures: Testing Lists in the Data Layer 465

Action Fixtures: Testing Workflow in the User Interface Layer 470

Custom FIT Fixtures 476

Example of a Custom Fixture 476

Content s xix

24 Running FIT with Team Foundation Build 481

Performing Customer Tests in Your Build Lab 482

Wrapping FIT in a Generic Test 482

Running a Generic Test in Your Build Lab 485

Automated Customer Testing 487

Running Customer Tests in Team Foundation Build 487

Allowing Your Customers to Edit and Run Tests from Their PCs 489

Introducing Your Team to Customer Testing 491

Discussions around a Whiteboard 492

Putting the Information into a Table 493

Implementing the Fixtures for the Story 495

Using Sequences of Tables in Customer Tests 496

Top Ten Tips for Test Design 498

Review of Section 7: Implement Customer Testing 501The Team’s Impressions 502

Agile Values 504

Section 8: Estimate, Prioritize, and Plan 507

Story from the Trenches 508

25 Estimating and Prioritizing Stories 511

Working with Customer Stories 511

Overview 512

Generating Stories 514

Estimating 516

Sizing Stories 516

Absolute Values versus Relative Values for Estimation 517

Relative Estimate Scales 519

Task Points and Story Cost Estimation 519

26 Agile Planning 527

The Nature of Plans 527

Plans for Repeated Execution versus One-Time Plans 528

Agile Planning 528

Using Velocity to Measure Rate of Progress 529

Planning at Every Time Scale 530

Story Life Cycle 541

27 Managing Agile Projects 545

Using Visual Studio Team System for Project Management 545

Sample Programming Episode: Task Planning 560

Between Programming Episodes 561

Planning Customer Tests 562

Top Ten Tips for Managing Agile Projects 567

Review of Section 8: Estimate, Prioritize, and Plan 571

The Team’s Impressions 572

Agile Values 574

Content s xxi

Section 9: Practice for Deployment 577

Story from the Trenches 578

28 Moving into Production 581

Managing Deployment 581

The Release Process 582 Removing Bottlenecks 585 Handing Over the Release to a Deployment Team 586

Preparing for Deployment 587

The Installation Program 588 Deploying the First Iteration 589 Stubs and Scaffolding 591 Data Deployment 591

Monitoring the Production Environment 592

Logging 593 Creating a Support Web Site 594

29 Developing Installation Programs 597

Introduction to Windows Installer 597

Basic Concepts 598 Principles of Operation 600 Security 602

Creating an Installation Project with InstallShield 604

Using InstallShield with Visual Studio 604 Using the InstallShield IDE 605

Developing Installation Programs on an Agile Team 613

InstallShield Collaboration 614 Automating the Creation of Your Installation Program 619

ClickOnce Technology 620

Suitable Applications 620 Basic Concepts 621 Publishing and Deploying 622

30 Deployment of Distributed Systems 625

Distributed System Architecture 625

Distributed Components 626

Service-Oriented Architecture (SOA) 626

System Definition Model (SDM) 627

VSTS Distributed System Designers 628

Logical Datacenter Designer 629

Creating a Logical Model of a Datacenter 629

Endpoints and Servers in Your Toolbox 633

Properties, Settings, and Constraints 634

Importing Settings from Your Existing IIS 636

Review of Section 9: Practice for Deployment 661

The Team’s Impressions 662

Agile Values 664

Content s xxiii

Section 10: Provide and Reveal Value 665

Story from the Trenches 666

31 Producing Technical Reports 669

Revealing Valuable Information 669

Standard Queries and Reports 670 Gathering and Presenting Information 672 Big Visible Charts 673

Extracting Data from Team Foundation Server 674

Introduction to the TFS Data Warehouse 675 Accessing Data in the TFS Relational Database 676 Creating a Custom Report from the TFS OLAP Database 677

32 Generating Business Value 683

Lean Thinking 683

Specifying Value 684 Identifying the Value Stream 684 Making Value Flow 685

Allowing the Customer to Pull Value 686 Seeking Perfection 686

Changing the Economics of Software Development 688

Value Generated by an Agile Project 689 Value Generated by a Waterfall Project 689

Linking Agile to Other Process Improvement Initiatives 690

Agile Development in the Context of Design for Six Sigma 691

Review of Section 10: Provide and Reveal Value 693The Team’s Impressions 693

Agile Values 695

Retrospective: Fixing the Process 697

About Retrospectives 697

Preparation 698 Creating a Plan 699

The OSPACS Team’s Retrospective 700

Developing a Timeline 700

Other Exercises 704

Analysis of the Project Timeline 705

Structure of the Project 705

Things They Discovered 706

Has the OSPACS Team Fixed Its Process? 708

Is the OSPACS Team Extreme? 709

How the OSPACS Team Became Agile 710

Personal Agility 710

Appendixes 713

A Setting Up VSTS for the Exercises 715

Set Up a Single Evaluation Server 717

Setting Up Team System VPC 717

Setting Up TFS Trial Edition 719

Set Up TFS and Team Suite on a Network 720

Hardware Overview 720

Team Foundation Server for Workgroups 720

Setting Up a Software Project Environment 721

Actions for All Set-Up Options 721

Software Installation 722

System Settings 723

Setting Up User Accounts and Security Groups 724

Identification of Machines and Users Named in the Exercises 726

B Software Project Environment for a Small Team 729

Hardware Requirements 729

Computers 730

Other Equipment 732

Software Requirements 733

Software Tools to Buy and Install on the OSPACS Developer PCs 733

Software Products to Buy and Install on Server PCs 735

Software Supplied with Other Products 736

Open Source or Freely Available Software 738

Content s xxv

Licensing Issues for a Five-Person Team 739

Primary Domain Controller 739 TFS (DevServer) 740

Developer PCs 743 Architect PC 745 Tester PC 746 BuildLab PC 747 Standby TFS 748 Multiprocessor PCs and Multicore Processors 749

Increasing Your Team beyond Five People 749

C Agile Workspace 753

Basic Office Layout 753

Software Development Area 754 Kitchen Area 756

Hot-Desk Area 756 Library Area 758 Conference Room 758

Supplies and Equipment 759

Imposing the Team’s Individuality 760

SC I E N C E I S F O U N D E D on the principle of creating experiments that givethe same results each time they are performed Unfortunately, a softwaredevelopment project isn’t like a scientific experiment because the outcome

is always different Even teams that use the same tools and process will stillproduce different solutions to the same task, each unique in terms of codeset, bugs, performance, and so forth This variability arises because theresults of software development depend upon individuals and their inter-actions as much as the process and tools they employ

The idea that the outcome of a software project is largely dependentupon people and the way they work together caused Kent Beck to observethe habits of successful teams and then put them into a framework of val-ues and practices, which he called Extreme Programming (XP) This pro-vided an alternative to the decades-old notion that the only way to imposeorder upon software development was to apply expensive tools and a well-prescribed process XP joined a number of similar lightweight approaches

to software development, collectively known as Agile, which shared thecommon aim of satisfying customers through the early and continuousdelivery of valuable software Over the past five years, this Agile move-ment has grown to become a significant driver of change in our industry.Agile seems to have successfully captured the middle ground of soft-ware development methodologies Teams with too little process to guidethem have found that embracing Agile allows them to make significantimprovements in the outcome of their projects, without creating the sort of

xxvii

bloated bureaucracy they fear Teams with too much process have foundthat adopting an Agile approach has made them much more productiveand responsive, but without their projects descending into the sort ofchaotic hacking they fear Thousands of projects have been run along Agilelines They haven’t all succeeded, but this is to be expected because anyworthwhile software project involves a degree of risk However, plenty ofthese projects have produced spectacular results, and once people havetried Agile, they seldom want to return to their old ways of doing things.

We suspect this is simply because most people find it, as we do, to be a morepleasurable and rewarding way to develop software

Who Should Read This Book?

This is a book for people on real teams who are transitioning to Microsoft’sVisual Studio Team System (VSTS), but who might not yet be ready to fullyembrace a process such as MSF for Agile Software Development It is writ-ten for people who want an easy way to gain value from the tools and at thesame time lay the foundations for future process improvement We envi-sion our readers to include the following:

• People new to software development—Teaches you how to useVSTS and gives you the core skills you need in order to work effec-tively on an Agile team There are few assumptions about your

NOTE

This book is primarily based on the values and practices of Extreme

Programming as described in Kent Beck’s book, Extreme Programming

using Microsoft’s Visual Studio 2005 Team System

1 [XPE2] Beck, Kent, with Cynthia Andres Extreme Programming Explained, Second Edition

(Addison-Wesley, 2005).

technical background, but some knowledge of using Visual Studio

will help when completing the exercises

• Experienced developers—Puts what you already know into the text of an Agile project and explains how to make good use of the

con-new tools provided by VSTS People who are encountering

Microsoft technology for the first time should find the exercises and

glossary particularly useful

• Architects—Explains the new VSTS tools for software architects, butits real value lies in helping you to adapt your skills so that you can

add value to an Agile team

• Testers—Helps you understand the expanded role of testers on an

Agile team and explains how to use the basic VSTS tools needed to

test software in this new Software Project Environment

• Business analysts and customers—Explains how an Agile approachcan give your business a better return on investment You’ll also

learn how an Agile team works to make sure you get the software

you want, when you need it

• Project managers—Describes how to transition your people onto a

small Agile team so that they can deliver better-quality software, in

less time and for less cost In addition, you’ll discover how VSTS

gathers information about a project into one place to make the

run-ning of the project more transparent

• Software entrepreneurs—Provides you with a road map for setting

up a small, top-performing software team It reveals the key

techni-cal and people issues you need to address through a series of

anec-dotes and comments gleaned from the decades we’ve spent working

in the industry

This book is not about process improvement applied from the top of anorganization downward, it’s about empowering teams to change things forthemselves from the bottom up

Tools Needed

In order to follow the exercises in this book, you will need access to an ing installation of VSTS or have the ability to install Visual Studio TeamSuite in one of the following environments:

exist-• Desktop PC able to host the Microsoft Virtual PC

• Single-server PC running Windows Server 2003 (SP2 or R2)

• Network comprising a server and several desktop PCs

You will be glad to hear that Visual Studio Team Suite is freely availablefrom Microsoft’s technical Web site2as a trial edition (full functionality, butexpires after 180 days) as well as for purchase from your usual Microsoftreseller In addition, MSDN subscribers can obtain Team System VPC,which is a “ready to run” virtual machine image of VSTS for use with thefreely available Microsoft Virtual PC Appendix A covers how to set upVSTS in all of these environments

Structure of the Book

The book’s Introduction contains a story about a fictional software teamcalled OSPACS that has a broken process; the team always delivers late, hashigh staff turnover, and is surprised to discover that its software is full of

NOTE

Framework for Integrated Test (FIT) is required for Section 7, but it isfreely available from the C2 Web site.3InstallShield and InstallationCollaboration are needed for the exercises in Chapter 29, but free eval-uation editions are available on the Macrovison Web site.4

2 Microsoft’s Web site for Visual Studio Team System (http://msdn.microsoft.com/ teamsystem).

3 Ward Cunningham’s C2 Web site for FIT (http://fit.c2.com).

4 Macrovision’s Web site for InstallShield (www.macrovision.com/downloads).

bugs and has gone three times over budget The rest of the book is abouthow the team fixed these problems, but along the way we aim to give youinsight into the use of VSTS and the meaning of better software develop-ment for a small Agile team.

The main body of the book is divided into ten sections, each concernedwith a specific aspect of software development as practiced by Agileteams These sections are ordered into a sequence that helps build up ateam’s proficiency in a step-by-step manner For example, we don’t pres-ent information about project planning until we’ve covered material such

as testing and Team Build because clearly your team’s plans will not bevery reliable until you can dependably deliver quality software How-ever, with that said, each section is largely self-contained, so you can readthem in any order that makes sense to you Indeed, we expect this to hap-pen as each reader will have different priorities for things they want tolearn about

Each section starts with a short story and ends with a review describinghow the OSPACS team put the ideas into practice, the team’s impressionsabout the material, and its relationship to a set of Agile values In this way,

we provide you with some light relief from the technical stuff while senting another perspective on the subject matter that might help youapply it on your own team Within each section, the chapters usually start

pre-by explaining some basic concepts and then put them in a practical context

by giving you a series of exercises to follow using the tools provided byVSTS You will also find sidebars in various chapters that summarize par-ticular XP practices relevant to what is being discussed In this way, theoryand practice are put together into something that is hopefully reasonablyentertaining and interesting to read

NOTE

At the back of the book is information about relevant resources, a

glos-sary, a bibliography, and a number of appendixes, as well as a list of

the XP practices and a complete list of all the exercises

The XP practices listed on the inside cover are described in appropriateplaces throughout the book as sidebars which are given a different font andlayout to distinguish them from the main body of the text In addition tonormal printing conventions, the following special conventions are alsoused in the book:

File | New | Team Project Shorthand for “select the menu item

New from the File menu and then selectits Team Project submenu item.”

Right-click | Delete Shorthand for “choose Delete from the

selected item’s context menu.”

… the Agile team Words that are capitalized are used in a

specific sense, so here we mean a team

that shares the values of the Agile

About the Book’s Web Site

We have created a Web site for this book that contains most of the code

cre-ated for the exercises, information about any errors in the text found after

publication, and other supplementary material which we feel might be

use-ful to readers:

www.BetterSoftwareDevelopment.org

We strongly encourage people to visit this site for the latest information

about both VSTS and Agile software development We would be delighted

to receive feedback from readers and will try to respond to you as promptly

as our other work commitments allow

Preface xxxiii

NOTE

James Newkirk and Will Stott collaborated in the production of this

book, but as Will did most of the writing, it’s his voice you hear when

you read something such as “I did so and so” or “We did this and that.”

TH E I D E A F O R T H I S B O O K came from Sam Guckenheimer after Will Stottmet him at a conference in Germany at the end of 2004 He has been hugelysupportive of this project and we couldn’t have done it without him Inaddition, Joan Murray at Addison-Wesley has been a constant source ofencouragement to us and handled a lot of administrative work so that wecould get on with the writing There are also many behind-the-scenes peo-ple at Addison-Wesley, including Audrey Doyle and Lara Wysong, whoseprofessionalism and hard work in terms of getting the book from Word files

to bookstore shelves need to be acknowledged, so thank you all

The process of reviewing a manuscript is an essential part of the lishing process and adds considerably to the quality of the final work Ourformal reviewers have done an outstanding job of pointing out our mis-takes and suggesting improvements, as well as telling us what needed to bepruned from the text Therefore, we gratefully acknowledge the help ofScott Ambler, Raimond Brookman, Peter Himschoot, Jason Schmitt, andDavid Yak In addition, we received many useful comments about the man-uscript’s first draft from George Bullock, Stuart Celarier, and Matt Ranlett

pub-We also want to express our appreciation to Linda Rising for her commentsabout the Retrospective, as well as to Chris Page, Corey Ferengul, and BobCorrigan at Macrovision for their input about InstallShield in Chapter 29.Though many people at Microsoft have helped us in various ways over thepast two years, we must especially thank Bill Essary and Ajay Sudan fortheir comments about the licensing issues in Appendix B

xxxv

Will Stott would like to express his gratitude to James Newkirk, as well

as to the people at Exoftware who encouraged him to write this book, cially Sean Hanly He is also indebted to the many people he met throughthe London Extreme Tuesday group for their assistance and insights intothe then-emerging field of Extreme Programming, particularly Tim Bacon,Peter Brown, Rachael Davies, Peter Lappo, Duncan Pierce, David Putman,and Karl Scotland In addition, he thanks Chris Jones and Andy Ryan ofUniversity College London for providing the idea for the OSPACS project.Will also thanks his family and friends for their love and support, as well asthe many other people he has met who have helped him in ways both largeand small over the years In particular he remembers the great inspirationprovided by his physics teacher, the late Mr Brown of Rossall School, andthe practical help given during the writing of this book by Mark Brearley,Liz Hooper, Simon and Ann Battensby, Damain and Marnie Hopkins, andLee Hyde and Anna Acland

espe-James Newkirk would like to thank Will Stott for his dedication to theproject The book simply would not have happened without Will I wouldalso like to acknowledge the support of my wife, Beth Over the years, shehas supported me through my various career moves and side projects.Thank you

NOTE

We owe a huge debt to Kent Beck and others in the Agile communityfor promoting Extreme Programming, which forms the solid and well-proven foundation of our book

About the Authors

Will Stottis a freelance consultant originally from the United Kingdom

who now lives in Switzerland He is an associate of Exoftware, a Europeancompany helping organizations to become more Agile in their software

development practices Will has worked with Microsoft technologies sincethe early days of MS-DOS and now specializes in C++ and C# developmentusing Visual Studio He has published a number of articles about Agiledevelopment and has spoken at various conferences in the United King-dom and Europe

James Newkirk is the product unit manager for CodePlex, Microsoft’s

community open source project hosting site In this role, he is responsible

for the site’s strategic direction and product development He is the

coau-thor of Test Driven Development in Microsoft NET (Microsoft Press, 2004).

Prior to joining Microsoft he coauthored “Enterprise Solution Patterns in

.NET” (Microsoft patterns & practices) and Extreme Programming in

Prac-tice (Addison-Wesley, 2001) In between writing books and consulting on

software projects, James led the development of NUnit V2

xxxvii

Broken Process

IF Y O U R P R O C E S Sto leave your team and it reliably delivers the best possible value to theisn’t broken, don’t fix it! That is to say, if nobody wantsbusiness in the required time without any unexpected quality or cost issues,think carefully about adopting Visual Studio Team System (VSTS) orbecoming an Agile team This book is not written for people who alreadyhave a sound software development process, but rather for those who want

to change their process because it is broken in some way

Welcome to the OSPACS Team

The OSPACS team is entirely fictional and none of its members are intended

to represent actual people However, the team’s problems are typical ofthose we’ve actually encountered over the past couple of decades whileworking for numerous organizations, and the characters are woven togetherfrom some of the individuals we’ve met during this time Therefore, wehave no reservations about treating the OSPACS team as though it were real

Team Background

The OSPACS team is part of a small IT company in the healthcare business.Eighteen months ago it entered into a joint venture agreement with the OldSainsbury (OS) Hospital for the development of a new Picture Archivingand Communication System1(PACS) intended to capture, store, and dis-play digital images such as X-rays and ultrasound scans The team released

1 Find out more about PACS at the AuntMinnie Web site (www.auntminnie.com).