Catálogo de publicaciones - libros

XP is one of several Agile methodologies. It has 4 core values, 15 principles, and 14 practices (since we added to the traditional 12 practices). The principles of XP build on the values of XP, and the practices build on the principles. Although there are many other Agile methodologies to choose from, none of them define software development practices to the level of XP.

In the next chapter, we will get started with XP. We will look at assembling an XP team and setting up a workspace (environment) for that team.

In this chapter, we discussed two very important XP topics: the team and the environment. We covered the roles and responsibilities of the entire XP team. We highlighted the characteristics of the important XP roles of the development coach and business coach. Then we looked at the best order in which to assemble your XP team. Finally, we took a look at an effective XP working environment for that team.

In the next chapter, we are going to take a look at release planning, the place where you and your team’s XP adventure will begin.

Psychophysics sheds light on one of the key problems of psychology as a science, namely the applicability of mathematics to the measurement of psychic phenomena, an issue which had also been addressed, but left unresolved, by Kant. But as the question entered the realm of the exact sciences it carried with it the traces of metaphysical disputes.

Iteration planning involves selecting a subset of user stories, defining tasks, and then estimating and assigning tasks. The development team can focus on the resulting iteration plan and deliver features to the customer in a very short period of time.

The subset of stories selected for the iteration plan should be the customer’s highest priority user stories, so that the team is delivering the most important business features to the customer. The user stories selected for the iteration plan are broken down into detailed tasks. Developers sign up for and estimate tasks. If there are outstanding tasks that have not been signed up for or there are outstanding task points, the iteration plan must be balanced so that the team is not overcommitting its time.

The next chapter will guide you through an iteration. It will show you how to take the iteration plan and apply it to the team’s day-to-day activities.

This chapter has just begun to scratch the surface of what you can do with NAnt. Its purpose was to help you understand some basic aspects of an NAnt build file and to give you an idea of what you might do with such a tool. There hasn’t been anything here that automates the build process by itself. You need to couple NAnt with a few other tools to set up automated builds. One of these tools is NUnit, which is the subject of the next chapter.

This chapter has just begun to scratch the surface of what you can do with NAnt. Its purpose was to help you understand some basic aspects of an NAnt build file and to give you an idea of what you might do with such a tool. There hasn’t been anything here that automates the build process by itself. You need to couple NAnt with a few other tools to set up automated builds. One of these tools is NUnit, which is the subject of the next chapter.

In this chapter, you started to get your feet wet with unit testing and test-first development. Don’t worry if this approach to development doesn’t feel quite right yet. You will be practicing these skills throughout Part 3 of the book.

On the NUnit website, you’ll find a downloadable Quick Start document (www.nunit.org/index.php?p=quickStart&r=2.2), which covers the basics of developing test cases in NUnit. This document explains many useful types of test cases.

By coupling the NUnit tool with the NAnt tool, you have created a way of calling your unit tests for your application without needing to invoke the NUnit tool yourself. This will become important when you get to the CruiseControl.NET tool (in Chapter 9), which will automate NAnt and NUnit for you.

In the next chapter, you will add another important tool to your XP tool set, NMock. NUnit will take advantage of the NMock objects that you will create to test parts of your application that work with other resources, such as databases and legacy systems that are outside your application.

By expanding your tool set with a mock object tool, you can now test your application without worrying too much about external dependent resources. This will allow you to sustain a better velocity and improve the feedback that your application gives you.

The next tool that you will find valuable is CruiseControl.NET, covered in the next chapter. This tool will allow you to take all the other tools you have acquired and automate their use.

CCNet takes advantage of your other tools—NAnt as a way to build your source code, NUnit for testing, and NMock for mock objects when and where you need them—and wraps them in automation. By doing this, you have put in place a way to receive rapid feedback at steady intervals. You will still want all the developers to run their own local builds and unit tests, and perform their own integration testing before they check in their source code changes. But with the help of CCNet, you have a way of communicating the project’s status to everyone all the time. This will also help prevent your developers from getting lazy or sloppy about their source code check-ins, because they know that CCNet will always report the truth. This will also help you produce higher-quality software.

In the next chapter, you will add another valuable tool to your XP tool set: refactoring. It is not a tool that you automate with CCNet, as with NAnt and NMock, but you will use it every day that you write code.

In this chapter, we covered the refactoring tools that are built into Visual Studio 2005. We briefly explained each of the refactoring tools and when or why you might use them. You also saw examples of how the refactoring tools affect the code you develop.

There are numerous other refactoring techniques that are not automated in Visual Studio. We highly recommend reading Martin Fowler’s (Addison Wesley, 1999) to learn about the additional refactoring that can benefit your projects.

That wraps up the XP tools part of this book. In the next part, we will take you through XP in practice. You will have a chance to become more familiar with some of the tools in your tool set, too. So, sit back, roll up your sleeves, and let’s get down to business.