eXtreme .NET: Introducing eXtreme Programming Techniques to .NET Developers [Electronic resources] نسخه متنی

If Chris hadn''t been there to work with the developers, one of several things might have happened:

The developers might have thought "that''s cool, we''ll try to remember to tell Chris about that next time we see him" (and then most likely they would have forgotten).





The developers might have assumed Chris wouldn''t want it and because timeframes were tight, not bothered to mention it in case Chris asked for it as well as everything else they were doing.





The developers might have assumed it was valuable for Chris and implemented it, but then not had time to finish story Y, when actually Chris would have preferred not to have story X delivered.

Any of these (or other) outcomes would have been making assumptions about what the customer actually wanted. Having the customer on site to answer these questions as they come up becomes incredibly valuable.

Planning Game

The planning game practice provides a mechanism for planning out the features in a piece of software. The planning game helps a team estimate timeframes for delivering the software with the features. This practice involves the whole team, including the customer. By including the whole team, the communication between the team members is enhanced. The developers sit with the customer to define the required features and prioritize them. The practice takes the form of a cooperative game. The aim for all participants is to achieve the same end goal: maximize the value of the software produced.

Consider how our eXtreme .NET team interacts during part of their planning game:

Pete: Panic! Time for another planning game. Chris: Hi guys, I''ve been talking to marketing, and they''ve been doing some research into usage and sales of the application we''re developing. They think that we need to make the application support Tablet PC features. Sue: No way! Why Tablet PC? We already discussed doing a version for the Pocket PC at a later stage. Chris: Many more of the users are mobile than we thought. This section of mobile PC users is moving to Tablet PCs. None of our competitors are supporting Tablet features. We can grab that share of the market if we can do this. Deepak: Okay, a Tablet PC will run our application fine. Tablet PCs run Windows XP professional with extra bits for the tablet. Chris: Okay that''s good, but what about support for writing in the forms? Eddie: Which forms? All of them? Where is the most value? Chris: We think if you can get the onsite report forms and expense claim forms to support handwriting that would be a good start. Pete: Panic! I have never done anything on the Tablet before; I have no idea how long that will take. Deepak: Chill Pete, it''s easy. The Tablet SDK just extends the .NET Framework. Eddie: Yeah, we need to tell Chris how long it will take! Any idea Deepak? Deepak: I reckon about a day for each form. Chris: Okay cool, I''ll expect that in the next milestone then. Eddie: Hold on Chris. You''ve already given us the stories for the next milestone; If you want us to do this Tablet stuff as well, then you''ll have to take something else out! Chris: Oh yeah! Okay can you swap that with the file-backup feature we discussed last time? You said that was going to take two days. Eddie: Fine, so we''ll add Digital Ink support to the onsite report and expense claim forms, and we won''t do the backup stuff for the next release. You can see how this conversation involves all the members of the team. By involving everyone, no knowledge is hidden. Everything is out in the open. Each member of the team knows the current goals. Pair Programming Pair programming refers to developing code with two developers sitting at one computer. In an XP team, you work with a partner on every piece of production code. Pair programming provides a constant peer review of the code. It helps to spread knowledge throughout the team and trains developers to communicate their intentions more fully as they work together. The aim is to increase the overall intelligence creating each part of the system. The combined intelligence of two developers should be greater than either one of them alone. As far as information dissemination goes, I have never seen anything work as effectively and as fast as pair programming. One developer learns a new trick on the IDE while messing around after work one evening. The next morning that developer shows her partner what she has learned. The pair then splits when they have finished a task (unit of work, discussed further later on) and work with another two people whom they both show the new trick. Before lunch, four developers have all learned the new technique. By the end of the day, everyone on a team of 12 could easily have learned this new trick. Now imagine this working when each of those 12 developers is learning new things. If they all learn one new thing each evening and then spread the word the next day, the entire team is learning 12 new things a day. In reality, most developers learn more than one new thing a day when they are developing software. This works best when you have a very dynamic environment with rapidly rotating pairs. I recommend that everyone attempt to swap pairs at least twice a day. The more the better. Some of the best eXtreme .NET teams I have worked with swap pairs between four and six times a day; this is where the extreme comes in! Test-Driven Development Test-driven development (TDD) is the practice of writing tests before writing the production code. These tests are a cornerstone that supports many of the other practices, such as refactoring and simple design. The tests communicate the intention of the code and validate that intention each time they are run. This validation helps to increase confidence in the software developed. TDD is a fantastic example of developers providing their own safety net before walking the tightrope of a new development language or framework. Consider how our eXtreme .NET team has benefited from TDD: Eddie: So we thought the framework provided this function to perform X. Sue: Yes, so we wrote a few unit tests and ran them. Eddie: And, of course, they failed because we hadn''t put any code in yet. Sue: Yeah, Eddie insists we run the tests before we fill in the code; I hate it, but I know he''s right. Eddie: So then we created a class A and called method B on it. Sue: And one of the tests still failed! Eddie: We couldn''t work it out because that function in Java does just what we wanted, but in the .NET framework it appears to behave slightly differently. Sue: Good thing we wrote all the tests; otherwise, we could have made a wrong assumption! In this example, Eddie and Sue were pretty sure the class library would behave as they expected it to, based on their experiences with a different class library. The fact they wrote tests meant they could move forward quickly, fix the problems early, and learn how the class library worked. The team had another conversation: Sue: So the next thing we needed was to complete the X task. Pete: Yes, Sue made us write all the tests first. Sue: Well, Eddie always does that, and he''s pretty smart, so I thought I''d copy him! Pete: Anyway, we ran the tests, they failed, and we started coding to get them to pass. Sue: After writing the code to make only two of the tests pass, we noticed that actually four tests had passed; somehow we had got two tests to pass without doing anything! Pete: It turned out that the .NET class we were using already does those things for us and so saved us a load of coding. Sue: So it was worth writing all the tests first. Thanks, Eddie! Here Sue and Pete discovered through writing the tests some functionality that the .NET Framework classes provided. This meant they could move ahead more quickly without writing code that duplicated the functionality already provided. The combination of TDD and pair programming meant that two members of the team learned the new feature in the .NET Framework. XP teaches that the more of the practices you use, the greater the benefit you get. The practices play off each other, and the last conversation was a good example of that in action. Constant Refactoring Refactoring refers to the [4] for what we are doing. Eddie: You''re right. Will you look it up? Sue: Sure.

Teams I have worked with who have previously developed large-scale enterprise applications in Java and C++ have been both surprised and pleased with the architectures they have developed. They have told me that if they had done a big architecture design up front, they would never have built the system that way, and it would have been far more complicated than was needed.

Spiking

XP promotes a form of experimentation and research known as spiking or "doing a spike." Spiking is experimentation to validate a theory. When the development team needs to know something, a thin vertical slice can be "driven" into the technology to get some answers. These answers can help the project succeed. Most spiking is done without the safety harness of TDD. Spiking is often carried out by solo developers who believe they need a break from pairing. Spikes are also "driven" by the one left out of a team when there are an odd number of developers, so not everyone can pair.

Driving a spike into the area of functionality the development team is planning to work on next will often produce some valuable information. In .NET projects I have worked on I have seen spikes effectively expose new information in the following areas:

C# performance





Web-service compliance for Remoting servers





Issues with COM interoperability





Transactional support in ADO.NET

All of these examples were areas in which the development team had uncertainties. In a traditional development approach, someone would have been given the task of dealing with that particular issue. That one person would have become the specialist in that area. For some developers, this is fine because they believe they are securing their jobs in the future by being the top gun in that area. This is a false belief. They are in fact acting as a bottleneck to the team''s overall knowledge attainment. By driving a spike and then reporting the result back to the team, the knowledge gets spread, and more perspective can be given to a task. Pairing with another developer to write the tests and production code after a spike is done also helps to spread the knowledge.

Here''s an excerpt from a meeting with our eXtreme .NET team:

Pete: I spiked the transactions in ADO.NET yesterday, and they''ll do the job fine, so I''ll pair with someone to write the code for task X this morning. Deepak: Did you think about how it works with our project? I''m worried about the threading and that some issues might arise from that. Pete: Panic! Oh no, I didn''t think of that. Deepak: Okay, I''ll pair with you this morning, and you can show me what you discovered while we spike how it works across threads. Pete: Okay, cool.

Here this team discovered that the spike had taken them some of the way to knowing the answer, but more work still had to be done.

Continuous Integration

After each task is complete, the code written gets integrated with the entire solution. The entire code base is compiled, and all the tests are run to ensure the code just created does not break anything. This continuous integration practice enables the team to ship early and often and enables them to deliver the short iterations on a regular basis.

As part of this practice, automated build and test scripts are developed. These scripts compile and test the entire solution. The scripts are set up as part of the development environment to make the entire process run more smoothly. This practice eliminates the element of human error from the process.

The practices of a methodology are aimed at reducing the chances of something going wrong. In the past, many projects would design and develop modules or components of the system independently. Near the end of the project, the team would attempt to integrate these modules to produce the final solution. This has become known as the big bang approach and is often a rather painful experiencean experience that involves lots of swearing and cursing because the components do not work together as expected. The XP practice of continuous integration aims to prevent this problem from arising by insisting that developers integrate their code after each task is complete and run the entire suite of tests to ensure that their code has not broken anything.

This practice is valuable when developing systems that consist of distributed components, such as Web services, remoting, custom components, or class libraries. Solutions developed in .NET often include many of these components. Even a simple ASP.NET Web site is likely to include some user controls (ASCX files). By carrying out the continuous integrations, the developers get immediate feedback on the changes they have made. The team can then work to fix any issues that arise. When working with a new toolkit, developers are much less likely to fully understand all the implications of the changes they are making. This XP practice helps these developers to cope with this issue in a far more manageable way.

Stand-Up Meetings

The practice