Extreme programming

« In the real world even programmers can appear normal people. Extreme programming is an opportunity to check up, to be itself, an opportunity to understand, that all this time the problem was at all in you, and that you have chosen to yourselves a wrong environment ».

The first edition of the book of Kent Beka « Extreme Programming Explained – Embrace Change » (in Russian translation) was issued « Extreme programming » in October, 1999. Extreme programming (KHR) can be loved, it is possible to hate, and here to wave away as from something insignificant already it is impossible . This book, on sale in huge circulations and translated(transferred) on tens languages, has opened road to all variety flexible metodology. Flexible the methodology can apply in full or in part, to not apply at all, but any serious expert in the field of programming cannot disregard them. Now each management(manual) on programming necessarily includes the chapter(head) about flexible metodologiyakh and extreme programming.

Five years later Kent Bek has again drawn to itself attention the publication of the second version of this book – this time in the co-authorship with TSintiej Andres (Cynthia Andres). Be assured, it is a question not of simple reprinting with small corrections. In the second edition authors critically survey everything, that has occured(happened) in this area for last five years, and practically completely reinterpret extreme programming (the truth, keeping initial principles of methodology, or at least, the desire to follow them).

In the first edition of the book extreme programming totaled four basic values, fifteen base principles and twelve expert. Moreover, Kent Bek precisely and unambiguously wrote, that full and unconditional following by all by this(thus) well-known to twelve experts can be considered as extreme programming only. In the second edition no twelve expert is present already and in a mine! The new version of extreme programming has five basic values, fourteen principles, thirteen main things an expert and eleven additional. Thus new 24 experts(practices) only partly remind initial twelve. Two of them, a metaphor and standards of a writing(spelling) of a code, also have at all disappeared.

In this review I shall try to describe briefly new concepts of extreme programming, and to you, dear readers, I shall leave pleasure to read the original – the book of Kent Beka and TSintii Andres « Extreme programming: what to do(make), when all constantly changes », published in publishing house Addison Wesley in 2005.

The basic values

The new version of extreme programming is based already on five values which as considers(counts) Bek, are the main things slagatelnymi success of any project on development of the software. The basic values is not only a management(manual) on development ON, it also a source of inspiration of all methodology. You know four values under the first book. Now to them the fifth is added – respect. So, here the basic values of extreme programming in the second edition:

Dialogue: the most part of problems and mistakes(errors) is always connected with lack of dialogue. Hence, it is necessary to increase as much as possible dialogue between members of a command(team) of programmers, and also between programmers and customers. The most effective is direct dialogue between people. It is impossible to forget also and about other kind of dialogue – between artefacts and people who read them. All artefacts should bear(carry) the adequate, not out-of-date information. Besides them should be conveniently read.

Simplicity: the most rational all of them values KHR. It(she) consists in the following: « Stop on the most simple decision which allows to carry out a problem(task) ». However (simple, instead of primitive) it is the just most difficult to find the simple decision. The the decision is easier, the it is more behind it(him) costs(stands) experience, ideas and heavy work. Such decisions demand dialogue, for them it is required much less code, they improve quality of the program appendix. The basic requirement sounds as « it is not necessary to plan a reuse of the same decisions in advance; the easier the system, the is easier to add in it(her) functionality as required ».

Feedback: you always should have an opportunity to define(determine), how much(as far as) the system which you write, is far from a necessary set of functionality. The best tools of a feedback is a direct dialogue with the customer and a set of the automated tests which grows together with system. On the one hand, the feedback is the important component of dialogue: to learn(find out) opinion of the customer, you should communicate with it(him). With another, the data received thus become a theme for the subsequent dialogue. The feedback helps(assists) to find the simple decision. Frequently simple decisions are reached(achieved) by a trial and error method. And besides, the easier the system, the is easier to support(maintain) a feedback.

Boldness, spirit: all existing methodology and processes of development are intended to bridle and reduce our fear. The more fear we test before any project, the there should be a methodology more seriously and "more hard". Dialogue, simplicity and a feedback enable us to start safely even to serious refaktoringu systems or greater(big) changes in requirements. The boldness and spirit in itself are dangerous enough, but in aggregate with other values is the most powerful tool for realization of greater(big) changes in system.

Respect: all four predyshchushchie values mean respect of members of a command(team) to each other. If programmers do not respect each other and the work any methodology will not help(assist) them. You should show respect for fellow workers, their work, for your company, and also for what life will include the appendix written by you. As you can see, in the basic values of extreme programming there is no advice(councils) how to supervise over the project or how to write a program code. It is described in experts KHR but before to pass to experts, we should stop on principles.

Principles of extreme programming

In new version KHR principles are as an intermediate link between rather synthetic both abstract values and experts in which concrete instructions(indications) on development are given ON. Now in KHR distinguish the following fourteen principles:

Humanity: the software is created by people, therefore the human factor remains the basic key to development of qualitative software product. Extreme programming sets as the purpose benefit both separate people, and the whole organizations that the advantage(benefit) of use of methodology was felt as both parties(sides). Certainly, here the balance is necessary: if we shall overestimate needs of collective of developers, it can lead to decrease(reduction) in efficiency of work, people will not work as appropriate image that will lead the company to losses. And losses, in turn, can lead to closing of the project or even all firm that will painfully strike on people who in it(her) worked. If you overestimate needs of the organization, people will start to process, between them conflicts will become frequent. It too will lead the company to losses. In the new book Kent results(brings) the following list of needs(requirements) of a command(team):

Economics: the software which you make, should possess a certain value (business value). In KHR there are two key economic moments: value of software product by the current moment and value of additional opportunities (value of options). According to the first, the dollar earned today, costs(stands) more, than dollar earned tomorrow, therefore the more quickly we let out(release) software product and we start to earn money, the it is more profit. It directly is connected with by additional opportunities of the program. So, if you can until postpone architectural changes when their necessity becomes abundantly clear will save up the company greater(big) money. Experts KHR welcome inkrementalnyj design, attention to that brings benefit to the client, and the attitude(relation) to development which could be characterized words « pay for what you use ». All this considerably simplifies decision-making process.

Mutual benefit: any activity should bring benefit to the involved people and the organizations. It, perhaps, itself important from principles KHR though it is very complex(difficult) to adhere to it(him). It is easy(light) to find a way out at which one of the cooperating parties(sides) will suffer of any problem. And quite often we very much would like to go such by. However similar decisions always worsen position as they spoil attitudes(relations) and destroy a working environment. To not increase quantity(amount) of problems, to you skills which will provide favourable cooperation and to you, and will be necessary for your clients, and and now, and in the future.

Similarity: in the nature often meet fraktalnye the structures very similar among themselves, but existing on different levels. Precisely same principles can be applied and to development of the software: we can use the same ideas for the decision of the problems arising in different contexts. For example, one of the basic components of methodology KHR consists in all over again to write tests which obviously will not pass(not take place), and already then – to write a code after which tests will pass(take place) successfully. The same can be scaled" on different levels of a time(temporary) scale: within the whole quarter you make the list of problems(tasks) which the appendix should solve, and then short "stories" which describe them in more detail. In the beginning of week you choose those "stories" where problems(tasks) above which you will work within this week are described, and already then write tests of acceptance (acceptance tests) and, eventually, start a program code owing to which these tests will work. If to narrow a time interval till several o'clock – you all over again write unit tests, and then a code which provides their performance.

All is better and better: constant development and advance – a key to understanding KHR. Certainly, perfection is unattainable, however it is necessary to aspire to it(him,them) constantly. Every day it is necessary to try to work as it is possible is better and to think out new ways to make work of even more effective. Thus, with each iteration a product all becomes better and better – both from the point of view of quality of a code, and from the point of view of functionalities. It is provided due to responses of the customer, automatic tests, and certainly, the command(team) of developers.

A variety: if all members of a command(team) are similar against each other, work in it(her) can appear very comfortable, but ineffective. It is better, when in a command(team) there are representatives from different fields of knowledge, different characters. It allows to find and solve problems better. Certainly, in such command(team) there can be conflicts which should be solved somehow. However if you are capable to resolve disputed situations and to define(determine) best of alternative opinions, prefer "non-uniform" commands(teams). They are able to find unexpected decisions in complex(difficult) situations, that in our area it is very important.

Considering: effectively working programmers not simply write a code. They wonder, as they work and why they do(make) the given system so, instead of differently. People need to see precisely the reasons, standing up for success (or a failure) their product. It is not necessary to hide mistakes(errors). Where more usefully openly to recognize them and to try to bear(take out) from them a useful lesson on the future. During quarterly and weekly iterations allocate(remove) some time for discussion of how the project moves, and what improvements could be brought in process of development. But it is not necessary too to direct to it(this) attention. In our industry there are many examples of how programmers were so switched to perfection of process of work, that for work at them does not remain to time! First there is a work – then considering – then again work.

Current (flow): in this case, it means the constant measured development of the qualitative software including all corresponding(meeting) kinds of activity. In methodology KHR it is considered to be, that all kinds of activity on development ON should proceed continuously, similarly to a stream. It(this) it(she) differs from others metodology where development breaks up to sequence of the certain phases, last of which is release of software product. Only owing to continuous current of development programmers can early learn(early find out) opinion of customers on system, receive confidence, that work is conducted in a due direction, but also, to avoid difficulties of last integration, this(thus) eternal "tram-тарарама" before release of a product.

New opportunities: in problems it is necessary to see first of all an opportunity something to improve. Problems are inevitable but to reach(achieve) perfection poorly simply « to solve a problem ». It is necessary to transform a problem into an opportunity to learn(find out) something new, to find the best decision. Perhaps, at you it is impossible to make long-term plans? Then try to make to plan quarterly, and each three months correct(adjust) that have planned. In your command(team) there is a programmer who does(makes) too many mistakes(errors)? Plant(put) it(him) to program in pair from the guru! Practice of methodology KHR have proved the efficiency to that the old problems existed, perhaps, since time of occurrence of the branch of manufacture ON solved.

Redundancy: really complex(difficult) or critical problems for the project should be solved in several ways simultaneously. In this case, if one decision will appear insolvent, others can help(assist) to prevent accident. In such cases as a result redundancy with interest pays off. The problems connected with functionality of the software, it is necessary to search and solve in the various ways: the pair programming, the automated tests, work in the general(common) premise(room), – many lacks will be found out by active involving of the customer, etc. Certainly, in it(this) there is some redundancy several times. However quality of a product – the most important purpose – will pay back all. However, if by means of any practice it is possible to find out only already known defects, it(she) should be cancelled as superfluous.

Failures: if something is impossible, be not afraid of failures. Do not know, how it is better to write a part of new functionality? Try to make it three-four different ways. Even if everyone will appear unsuccessful, you learn much. Whether failures are useful? Yes, if we bear(take out) from them valuable lessons. Therefore be not afraid of failures. Where worse to postpone something till last moment, trying to find the true decision is unique.

Quality: quality always should be on the ball. To let out(release) a product of poor quality, to save means or time, - obviously wrong decision. Just opposite, work above quality of system promotes improvement of its(his) other properties, for example, to productivity and efficiency. It is not necessary to confuse, however, quality and perfektsionizm. If you postpone an active phase of development, in hope to find the ideal decision, you will not move ahead. To try(taste) any variant much more effectively, to find out, in what its(his) lacks, and quickly to correct them.

Small short steps: if long to prepare for serious greater(big) changes, and then to bring them in system "at one stroke", the project can appear under threat of failure. It is much more reliable to move ahead small short steps – let these steps are insignificant, but you can be assured, that the project moves in the necessary direction. Besides small short steps it is possible to move quickly enough: for short time the command(team) of programmers can make many such "short steps", thus is constant to receive responses and to correct(adjust) promotion of works. One more plus of little changes consists that little change, as a rule, can lead to only small problems. And here than step more and the changes are more serious, the it(he) can bring greater potential harm to the project.

The responsibility: the responsibility can be incured only in the voluntary order. Certainly, any chief can order to the programmer: « Do(Make) that, do(make) it », but such approach does not work. You will inevitably demand or much less that is necessary, or – that happens to a thicket – much more than that the given programmer can. Therefore receiving instructions(indications), the person himself should make a decision: whether it(he) on itself(himself) takes the responsibility, or let someone is engaged in this problem another.

Experts KHR

The new version of extreme programming totals thirteen cores an expert and eleven additional. In the beginning it is necessary to apply the basic experts, and each of them can improve process of development in appropriate way. Only after that it is possible to start additional experts which demand an operational experience with the basic experts, and are practically inapplicable without them.

As a whole it is possible to tell, that all 24 experts(practices) are very important for process of development, and should be applied completely. Only so the project will receive benefit from extreme programming.

Kent Bek in any way does not classify practice, however it seems to me pertinent to divide(undresse) them into four categories:

The analysis of requirements and planning;
Command(Team) and the human factor;
Designing;
Programming and release of a product.

I pay your attention that many experts it would be possible to carry at once to several categories. So, « pair programming » appears at me in group « the Command(Team) and the human factor », however with the same success it(she) could be placed in a category « Programming and release of a product ». Further I shall describe each practice only once – in that category which has seemed to me of the most pertinent.

The basic experts

The analysis of requirements and planning

"Stories": functionality of the appendix is described by short "stories" in which work of system is stated from the point of view of the customer. These "stories" also are the basic motive power of development of the appendix.
Weekly cycle: all development of the project occurs(happens) in the form of turns of weekly cycles. In the beginning of week there is an assembly on which the customer chooses, what "stories" should be made for this week.
Quarterly cycle: planning in greater scale occurs(happens) every quarter. It consists of discussions of work of a command(team) and rates of development.
Slabina: avoid promises which cannot execute. In any plan include problems(tasks) which you can throw out if will not meet the deadline. In this case you will have an output(exit) even in case of unforeseen problems.

Command(Team) and the human factor

Work in one premise(room): the command(team) of developers should sit in one big premise(room) is facilitates dialogue.
Command(Team) as a single whole: the command(team) should consist of the people possessing all skills necessary for the project and knowledge. The feeling of an accessory(a belonging) to a common cause should unite all of them, they should support(maintain) in every possible way each other.
Informativnost environments: in the worker pomeshchenim there should be informative posters and other visual aids which would show the status of the project and other information on the done work.
Vigorous work: people should not be exhausted by work, they should keep freshness and vigour to be focused on problems(tasks) and to be able to solve effectively them. Hence, it is necessary to limit rigidly overtime work so that everyone still had time and for private life. In the former version of methodology it referred to « priemlimyj rate of development ».
Pair programming: the code is written always by two programmers sitting at one computer.

Designing

Incremental designing: according to(agree) KHR, it is not necessary to be engaged in detailed designing of system right at the beginning of works. Instead of it(this) the command(team) of developers tries as soon as possible to start to write a program code to receive responses of users about system, and to improve it(her) therein. Certainly, to write a good code, the system should be properly designed. It(this) KHR does not deny. A question only – when to be engaged in designing. According to extreme programming, designing should occur(happen) inkrementalno during a writing(spelling) of a program code. It is especially useful to do(make) it to clean(remove) unnecessary duplication.
First tests: before editing an old code or to write new, it is necessary to write tests which will check it(him). It will help(assist) to solve four problems:
« Programming on-ковбойски »: during a writing(spelling) of a code so it is easy(light) to take a great interest and start to write a code for all problems(tasks) successively which occur. If all over again to write tests which then will check a code, we willy-nilly should concentrate on a problem(task) which we try to solve, and also to check up, how much correctly we have designed the given part of system.
Coordination and unity: if to write the test difficultly, means, at you a problem with design of system, instead of with testing or programming. When the program code is broken into functionally connected modules with a minimum quantity of bilateral dependences between them, to test it(him) will not make the big work.
Trust: if you write a code which works, and document it(him) by means of the automated tests, your colleagues will trust you.
Rhythm: during programming it is possible to take a great interest and wander easily in a code within several hours. If you accustom yourselves to a rhythm « the test, a code, refaktoring, the test, a code, refaktoring », it(this) never happens.

Programming and release of a product

Ten-minute assembly: the system can be collected (in view of run of all tests) for ten minutes. It will allow to repeat often operation and to receive responses about a developed product.
Constant integration: developers should spread in a repository results of the work each two hours to avoid problems with integration of a new code