Study Group Work

1.0 Project definition 3

2.0 Introduction to XP 3

3.0 Six subjects of interest 4

3.1 Preparation Phase 4

3.2 Customer Contact 6

3.3 Workflow 7

3.4 The Programming Phase 8

3.5 Testing 8

3.5.1 Unit testing 9

3.5.2 Acceptance tests 9

3.6 Documentation 9

3.7 Resume 10

4.0 Conclusion 10

4.1 Conclusion on the choice of method 11

Bibliography 12

1.0 Project definition

eXtreme Programming (hereafter XP) – how is this method introduced to a newly educated development team?

A large amount of information and experience descriptions about XP exists on the Internet.

All this information can seem overwhelming and confusing, if the knowledge about XP beforehand is minimal.

It is our goal to create a document/manual/guide, which shortly, but usefully prepares new teams for XP. Furthermore it is a goal that this document is sufficient to find out whether XP will work for a team or not.

The document can help to avoid some of the prevailing pitfalls occurring in inexperienced teams by providing XP-related answers to questions asked by people who have never worked with the method before.

2.0 Introduction to XP

Development of software according to the methodology XP, forces the customer to take a larger responsibility in the project than normally, i.e. using other, older methods.

The advantage is more knowledge to the customer and better quality of the code, which in the end also means a better and more satisfying software product.

The method is extreme in the sense that it is using a set of practices, which are already well known, but it is driving each practice to its extremes.

Looking back and realizing that testing the code has proven useful and effective, makes the founder of XP, Kent Beck say: “Then let’s do testing all the time, if it has proven that good”.

The rest of the practices have been driven to their extremes through the same way of thinking.

The set of practices mentioned before, give some guidelines to ensure that the method is being stuck to.

Determines the scope of the next release by combining business priorities and technical estimates.

Restructure system, by simplifying code wherever possible, without changing its behavior.

Write all code in accordance with rules emphasizing communication through the code.

The practices will overlap each other, so where a practice is weak, another practice will cover its weak spots and finally ensure a thoroughly constructed product.

Basically, XP is all about making the best software by just-in-time development ^²and making short iterations, which make complex design decisions and analyses redundant because of the frequent feedback.

XP includes techniques about how to maintain and control e.g. the workflow, customer relation and coding standards to make sure that developers enjoy using the practices and then also making it easier for them to adopt these.

The practices should also have long-term and short-term benefits, making it obvious for the team to stick to the practice under pressure.

3.0 Six subjects of interest

The XP methodology has been divided into six subjects of interest to “newbees” in XP. For each subject, a couple of questions have been posed prior to the first time experience with XP^³.

3.1 Preparation Phase

Which physical settings are required for becoming successful with an XP-process?

Unfortunately XP does not really have a recipe for how to become prepared to start an XP-project. It is all about using common sense, but it is possible to get some tips for avoiding pitfall situations in the inexperienced and critical start period.

It is certainly necessary to gain knowledge about XP from books and also from other developers, who have experience, to be able to learn the overall idea.

The twelve practices mentioned before works along with four basic activities^⁴ and four values^⁵. Each developer should keep these in mind during the process, because these keywords are the ones describing what XP stands for and what is important in an XP process. Forgetting these could result in a product, which does not seem structured and the goals made for the process would eventually not be reached.

In the preparation phase it is very important to confront Business^⁶ with the demands required for the XP process, i.e. for example explaining about the roles in the process. Failing to reveal all aspects of the XP process could result in dispensable surprises, which could have been avoided by performing good briefings with Business. Through the creation of a detailed contract between the Business and the Technical people, these pitfalls should be avoided.

While conferring with Business, it is also important to agree on physical setting conditions according to the Facilities Strategy^⁷.

This strategy explains about the importance of having nice surroundings while developing, so that it is possible for the developers to use all their energy on the work to be done, instead of grumbling about poor conditions or physical settings.

It is suggested that there are to be lots of food, drinks, toys and nice, comfortable tables and chairs in the working room. It is furthermore a need that all developers sit together in the same room to achieve the best atmosphere and feedback.

One of the twelve practices: “40-Hour Week” also has an important point to have in mind, in order to keep up the inspiration. Kent Beck says^⁸: “No one can put in 60 hours a week for many weeks, and still be fresh and creative and careful and confident. Don’t do that!”

An XP process might have economical consequences. These can of course be analyzed and taken into consideration.

You might use more resources to develop a system; i.e. more programmers and more feedback meetings with Business.

It could seem that the Business’ time is used too much and taking this time will have a large cost, but here it is important to underline the benefits, which an XP process will add to a project.

Because the Business is solicited throughout the process, the finished product is more satisfying and already customized before it is finished. This reduces the cost for the future, because no further customization is needed.

After the practical decisions, about e.g. the physical settings, are done, it is time for deciding on a scope for the project together with Business.

A row of stories, which cover the descriptions of what the system is supposed to be able to do, is written down in cooperation between Business and the Technical people. Every story will be narrowed down into a row of assignments, which need to be solved to finish the story^⁹.

3.2 Customer Contact

Customer contact is an important issue of the XP methodology. The short iterations and the minimum planning and maximum coding can only be done successfully if the project is fully backed up by the customer.

Ideally an XP project should have at least one end-user working with the development team full time, throughout the project lifetime. The customer on-site has several tasks, one would be answering questions of functionality that might not be defined properly beforehand or have an ambiguous definition. In this way the developers will always keep on the right track according to the customer. Another task for the on-site customer is to write and describe user stories, to let the programmers envision the purpose of the functions and enable them to write useful acceptance tests^¹⁰.

As described above the customer plays a central role in the XP project. The extended responsibilities require extra work and time for the customer, but it is important to realize the value gained by this approach. The direct feedback reduces the risk for the developers to implement unneeded functionality or make wrong assumptions about the direction and purpose of the project.

The customers increase their knowledge of the product and build their feeling of ownership from the fact that they have direct feedback and results corresponding to their requirements.

To prepare a customer for an XP project, the development team must give the customer a clear view of these extended responsibilities compared to a traditional approach. The team should also explain why the extra cost introduced in the development stage would increase the value of the end product.

From our research we have concluded that because customer contact and the short development cycles are so closely connected, it must be so that if a customer is not available full time for giving feedback, it is necessary to perform more analysis and in-depth descriptions of functionality before each iteration, to ensure that the team has enough knowledge to remain productive and on track until the end of the iteration.

3.3 Workflow

XP is based on an iterative^¹¹ approach meaning that only a small step is taken at a time and can be taken again and redone later if necessary. Each iteration may last a week or several weeks depending on the kind of project. While iteration is done, the state of the project is evaluated constantly between the pair programmers to avoid failure. Actually, the idea of pair programming involves much evaluation of what is done in order to secure the understanding. Between the different programmer pairs, there might also be meetings during the day to secure that their product can be combined at the end of the iteration.

Finally, a certain meeting for all groups is held at the beginning of each iteration to plan what to do and who to do what, based on the customer’s feedback on the product from the previous iteration.

From the feedback of the customer, User Stories^¹² are generated that take their origin in a scenario corresponding to that of the customers. The purpose of the stories is simply to describe a situation/need that the system should be able to handle and fulfill. This makes evaluation easier since the User Stories are concrete and simple to understand for both developers and customers^¹³. It is then up to the programmers to add the code necessary to perform the User Story^¹⁴.

Since the development is based on iterations, it is also easy to change direction if the customer comes up with another requirement or wants something changed completely. Time will still be wasted when this occurs, but not compared to time spent on useless design and planning, since that is done on the fly with the customer. This assures that time is spent as efficient as possible.

Since design and planning do not have a large phase of their own, the need for a task force consisting of only system developers is obsolete. The developing groups in XP are treated in the same way due to the fact that they do the same job: Programming. Therefore the members of each group will also play the same roles in turn.

However, while evaluating with the customer and getting feedback, there might be a need for assigning different tasks for the groups. A group would perhaps have to help the customer getting creative and innovative in his feedback on the product, while another group would have to organize the mixture of pair programmers for the next iteration.

In other words; a certain division of programmers and system developers does not exist.

XP does not require the project group to be of a specific size, since the method relies more on personality and discipline, rather than on the outer circumstances. Therefore there can be a small or large number of people participating and forming groups.

Of course, like with any other project there is a limit on how many people that can work together efficiently, but that goes for all development approaches.

3.4 The Programming Phase

Since XP is based on teamwork, it is of greater importance that the developers participate in the work and are capable of communicating with one another and exchanging feedback and ideas.

This is assured since XP’s idea of pair programming forces you to take responsibility and part in the process.

In short the idea of pair programming evolves from the synergy effect^¹⁵ that arises when two people are working together. The person programming at the keyboard will have the tactical overview while the partner is responsible for the strategical overview^¹⁶. This division of focus will eliminate many of the stupid mistakes that solo programmers will be wasting time. Only two are working together since more programmers will produce an overhead.

Besides increased productivity, the outcome will be shared knowledge that will benefit not only the system being developed, but also the developers.

When using XP, the pair programmers will have a collective ownership^¹⁷ of the code being produced, since they change role once an hour or more often while programming. In this way both are able to continue the development and come up with suggestions since they will both know what is happening. To take this to the extreme, the same code standards^¹⁸ will also have to be followed by all programmers. This will assure that it will be easier for both programmers to refactor^¹⁹ the code later if needed.

To avoid unnecessary errors only a small piece of code is added at a time and tested carefully^²⁰.

XP rules are hard to stick to, since they require much attention and discipline while developing. These could easily become the major exercise for a non-expert with less routine in working together with others and taking responsibility.

Time has to be allocated for the activities besides the coding; like planning, evaluation and discussion, whenever doubt or misunderstanding occurs. It is also important that all developers agree about the idea of having these activities and respect them.

Otherwise, the whole idea of pair programming in XP will fail and become a barrier instead of an advance to the developers.

Using XP for developing systems as a non-expert is in other words primarily a matter of personality and not programming skills.

3.5 Testing

There are two types of testing in an XP project. Both are essential to the success of the methodology.

The general rule of testing in an XP project is that tests are always written before the implementation.

3.5.1 Unit testing

Unit tests are the tests the programmers write for two reasons: firstly to define their goal, secondly to test the robustness of their code. Unit tests are a way of defining requirements to exact functionality. If a requirement is stated in a test case code, the specification cannot be misunderstood. Unit tests are always written before the implementation of the function they test, and in the making of unit tests, new test cases might be found and added to the collection of unit tests^²¹.

The idea is that every time the programmer wants to add new functionality to the existing system, it be a module or class, he first writes the test that should check the functionality and then the coding of the new feature could start.

The tests should be written to be as automated as possible, so every time the code has been compiled the tests can be run and success factors logged automatically. Code is reviewed and changed until all unit tests succeed.

3.5.2 Acceptance tests

Acceptance tests are what the traditional approach to software development would call ‘black box’ testing. The tests are made from ‘stories’ written by the customer about how the system is supposed to work and which results are to be expected from certain uses of the system.

At every Planning Game, when one or more new functionalities are planned to be completed within the iteration, corresponding customer ‘stories’ are rewritten as acceptance tests. The acceptance test can be written as a function, like the unit tests, or if the story requires user interaction, the test could be a list of a sequence of user actions and specific input values.

Either way, the test should always specify the expected result so it is possible to measure the success of the test. Then, when all acceptance tests for a certain customer story are passed, the story is complete, and the implementation of a new user story can be initiated.

To make the definition of Acceptance tests easier, it might be an idea to use a testing framework or some standard template, for example^²² using a scripting language or setting up the input and expected output in a spreadsheet.

3.6 Documentation

Will experience with UML be an advantage when using XP and how and when will documentation take place?

The UML approach to developing systems is not applicable in XP, since the way of developing a system is very different in this context.

UML is “design-code-test”-oriented whereas XP is “test-code-design”-focused.

However, the skills from UML in visualizing the development process is an advantage, though they will not serve as a pointing finger, but only as a mean to keep the overview of the current state of development and documentation. This might be diagrams of User Stories or the allocation of developers in groups etc.

Some might argue that you will lose overview without having documentation guide-lining the development process. However, the idea in XP is to take a small piece at a time whereby long term plans and design idea for the future becomes obsolete.

In XP, the documentation is actually mostly the tests, because they document the direction of the system being developed and its success or failure. The User Stories and the participation in the development process by the customer will simply lower the need for documentation.

It can be argued that you would need to document in order to remember what you implemented a long time ago. This is however solved by the fact that old tests are always done together with the newest ones whereby the documentation of previous development is continuously done. See the section about testing.

When it comes to documentation of code, XP does not differ that much from ordinary documentation standards. Documentation done by the different programmers should have the same form. This would make it easier to understand and simplify the code later when refactoring. XP suggests that a class should have a comment or short description about its purpose, special conditions etc. The same could be done to functions if there is something that requires attention. Generally the documentation should become less important when the code is made simpler.

The documentation in XP is in other words done differently than in UML. UML developers will have to change their approach upside-down^²³.

3.7 Resume

New XP developers can start their XP-exploration by learning and following a few basic rules:

4.0 Conclusion

It takes time to explore the current XP documents and guides found on the Internet. We have succeeded in making a short presentation of the methodology by gathering the information we find most important to new developers. We have presented the ideas expressed in XP from questions asked by developers with no prior experience in XP. This document can be used as an introduction to further research in XP using the reference list used by the authors.

4.1 Conclusion on the choice of method

As mentioned earlier, the methodology “Future Workshop”^²⁴ has been used for brainstorming topics and questions on these.

The group had only had a brief introduction to XP^²⁵ before the questions were made, so they resemble the concerns that would arise for inexperienced developers.

The group brainstormed on all the criticism, uncertainties, and ignorance there was about XP and after that it was separated into six overall subjects.

The group fantasized and imagined how it was possible to turn the negative; the critics into desirable situations or conditions.

The realization came through research and studying relevant literature about the XP methodology and the experience of others. The conclusions were written down and together with the questions, it formed the basis for writing this document.

Bibliography

BOOKS

LINKS

19 The idea of refactoring is that the code should be checked again and again to simplify it as much as possible. Whenever an error occurs it is also solved immediately before anything else is done.

1	http://www.extremeprogramming.org/ (Contains brief descriptions of all the buzzwords of XP)
2	http://www.extremeprogramming.dk/ (General site about XP)
3	http://www.xprogramming.com/ and http://www.xprogramming.com/software.htm (General site about XP)
4	http://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm (A research paper on pair programming)
5	http://users.vnet.net/wwake/xp/xp0105/index.shtml (Some good notes on XP by an experienced developer)
6	http://xp123.com/g4p/ (XP game)
7	http://www.kuro5hin.org/?op=displaystory;sid=2001/4/3/182249/2098 (Critics for XP)
8	http://www.cuj.com/experts/1902/martin.htm?topic=experts (A real episode of XP)
9	http://debat.computerworld.dk/debate.asp?Mode=1&ContributionID=6475&DebateID=847 (How bad can it go in a development project? A good reason to start using XP)
10	http://ootips.org/xp.html (Extreme Programming Practices)
11	http://www.computerworld.dk/vis_artikel.asp?ArticleID=11638 (Article about a company’s experience with XP)
12	http://www.speakanet.com/ (Company using XP as development process)
13	http://www.bestbrains.dk/ (Company using XP as development process)
14	http://c2.com/cgi/wiki?ExtremeDocuments (Discussion medium about e.g. eXtreme Programming)
15	http://www.jera.com/techinfo/xpfaq.html (FAQ about XP – really good for beginners)
16	http://www.objectmentor.com/publications/xpepisode.htm (A description of a pair programming episode)
17	http://linux.oreillynet.com/pub/a/linux/2001/05/04/xp_intro.html (An introduction to XP)
18	http://sunrize.nada.kth.se/usor/jml.cgi/Methods/future.jml?graphics=true (Introduction on the brainstorming method: Future Workshop)

Table of Contents