To each project the methodology

Alister Koubern (arc@acm.org)
Humans and Technology
Humans and Technology Technical Report, TR 99.04, Oct.1999 7691 Dell Rd, Salt Lake City, UT 84121 USA
arc@acm.org

The summary

As soon as we try to understand, " of what the methodology consists ", at once it becomes clear, that metodology should be much. Thus for each concrete project one any methodology will be "optimum. Moreover, all people possess different propensities which are caused by their life experience, fears and principles. At a choice of methodology the special attention needs to be given three major factors: to the size of a team of developers, criticality of the project for the company and it(him) prioritetnosti. Besides it(this), on result will influence both cultural values of a team, and individual characteristics of its(her) members. In this clause(article) the structure and experience of use of these principles in design development are described.

The brief review

" The methodology from the big letter " is a name of how the organization repeatedly makes and delivers program systems: whom in it(her) employ and what for that expected by people from the colleagues, they observe what reserves, beginning(starting) from accommodation of workplaces at office and up to used working products. When any company places the announcement of employment in the newspaper, this announcement represents a certain artefact of the methodology accepted in this company. As it has appeared to receive practical results from studying methodology, we should consider(examine) it(her) from such wide point of view.

In this case, my purpose was to create frank dialogue between the people, adhering various sights at this question, and to designate principles according to which it is possible to recommend this or that methodology. So, all over again we should answer following questions: What is "methodology"? Whether Should metodology be much? Whether one Can be better", than another? How to learn(find out), what elements of methodology should be adopted? How to apply all this knowledge in the large project?

Existence of set metodology is absolutely necessary. They can be classified on the size of a team of developers and criticality of system (certainly, they can be classified on much lot of sizes, however these(thus) two is better approach(suit) for a primary estimation). Then those who are engaged in designing of methodology, define(determine) cases in point, roles, kinds of activity, and also delivered artefacts and standards which they are going to capture. They work, proceeding from the belief, paying paramount attention to some features of the given concrete project. All this should approach(suit) in the best way to people who are borrowed(occupied) in work above the project, and to their cultural characteristics.

In this clause(article) we shall consider(examine) how these ideas have been applied in a number of projects with various quantity(amount) of the developers used different technologies.

Components and volume of methodology

I understand that is written as the first interpretation of this word in American dictionary Miriam-Webster as "methodology": " a number(line) of the methods connected among themselves or tekhnik ". The Oxford dictionary interprets this word only as " studying of methods ". In this clause(article) I use the American variant. (for were interested(interested): in " the Explanatory dictionary of Russian " Ozhegova this word is treated as " principles and ways of the organization theoretical and practical activities " and " set of the methods applied in any science ". - a comment of translators)

Under "size" of methodology I mean number of elements of management in it(her) to which delivered artefacts concern, standards, kinds of activity, a measure of quality, etc. "Density" of methodology is measured by a level of detailed elaboration and the connectivity, necessary for its(her) realization. Higher density corresponds(meets) to the rigid control or a strong formalism. "Weight" of methodology is defined(determined) by multiplication of the size to density (only theoretically as I do not result(bring) here any figures concerning the size and density).

I shall speak also about " the size of the project ". I mean number of the people working above the project which activity is necessary for coordinating this term. Quite often there is an opinion, that the size of the project corresponds(meets) to the sizes of a task, but all not so is simple. The size of a task cannot be defined(determined) in absolute sizes as there can be a new person who will manage to make out in this task some simplifying pattern. For this reason I diligently differentiate concepts " the size of the project " and " the size of a task ".

Figure 1. Components of methodology (with examples).

The methodology includes, at least, those subjects and themes which are specified fig. 1: roles, skills, commands(teams) of developers, toolkit, technics(technical equipment), kinds of activity, standards, working products, measures of quality and system of the values accepted in a team of developers. In the majority, these items(points) do not require further explanations. Under "standards" we mean notatsionnye standards (for example, diagrams and programming languages) which are used at performance of the given project. There are also standards of management and decision-making, for example, use of incremental development. And, at last, we have some system of reserves - standards which are defined(determined) for the given concrete project.

It is less obvious, that such " system of the values accepted in a team of developers ". We understand to what the team as they prefer to communicate and work aspires As this term. For commands(teams) with various systems of values will be effective various methodology.

The methodology has "volume" which is defined(determined) by extent of life cycle of the project, itself of roles and kinds of their activity which methodology (see tries to cover itself fig. 2):

Figure of methodology of 2. "Volume".

Some companies work on metodologiyam which cover all process of development of software product - from the first call of the client before support and support of already working system. Thus all roles are paid from funds of the project. The Most part of those commercial books which are called "metodologiyami", roles of the designer/programmer are devoted, as a rule, to the description only to one role, namely. In such books it is told about how it is necessary to project(design), the big attention is paid to several various tekhnikam and to standards of the image of diagrams. If we shall compare that volume of tasks which the methodology should cover, to that information which contains in these books, at once it becomes clear, why in busy programmers such "methodology" cause only disappointment and irritation. Actually, what technics(technical equipment) or standards of the image of diagrams are used by the designer, creating design of system, does not render essential influence on final success of the project which certainly, is the most important factor in any business.

Principles

The essential role in searches of the necessary methodology is played with definition of principles after which it(she) could be developed. After creation poludyuzhiny various metodology both carrying out of several dozens interrogations and interview of various projects, I have managed to define(determine) four cores of a principle which I represent your attention. For today I can tell, that is practically assured(confident) of validity of any of them. Below we shall consider(examine) their use.

Principle 1. Greater(big) in the sizes methodology is necessary when in the project the big number of developers is borrowed(occupied).

" In the sizes " I name greater that methodology in which a plenty of elements contains. As the main applicability of any methodology - to coordinate work of people then, the more the project, the should be and methodology used in it(him) "more". The volume of methodology increases proportionally to number of roles and types of working products. [Harrison96].

The methodology which has well proved in a small team will not allow us to count this principle, that, will be as well to work and in big. Besides it(he) specifies that it is not necessary to use the methodology calculated at a greater(big) team of developers if above the project the small group of programmers works.

Principle 2. The greater(big) correctness of methodology (visible from) or, in other words, " the greater(big) density " is necessary when the latent mistakes(errors) in software product can cause significant damage (greater(big) criticality of developed system).

I classify program systems on following categories of possible(probable) damage (certainly, it it is possible to expand this list):

• Loss of comfort in work means, that at breakage of system people will be compelled(forced) to work more manually or to go to each other for conversation, to eliminate(erase,remove) a handicap in the communications. Present, for example, that the system supervising process of sale and purchase, or the program supporting(maintaining) a corporate infrastructure breaks.
• Loss of the insignificant sum means, that loss of monetary or other similar values on the importance brings the companies some inconveniences, but no more. It is possible to carry wrong payment of the salary or incorrect payments to this type under accounts(invoices) (all this can be corrected manually).
• Loss of the irreplaceable sum means, that loss of monetary or similar means on the importance is actually equivalent to bankruptcy of the company. In this category it is possible to carry program systems of national banks, etc.
• Loss of a life means, that as a result of a mistake(an error) in the program people can be lost. The enterprises working on an atomic energy, the projects connected with space concern to this category, control systems of flights of planes, etc.

According to this principle, additional expenses for more careful protection against mistakes(errors) can quite justify themselves - depending on in what of four set forth above categories there is a project.

Breakage at nuclear station is much more serious, than, for example, breakage in mine programmke which traces current of a match on bowling. Hence, at creation of software products for nuclear station it is possible to dare to use more labour-consuming and dear(expensive) methodology. In this case, the methodology will contain a lot of various elements, and these elements will have greater(big) "density".

Let's admit(allow), in both projects variants of use (use cases) are used. Children(guys) from League on bowling can quite write them in the form of several offers on a napkin or on a board and consider(count) it as the sufficient document. The team which builds nuclear station, will insist for certain on that all variants of use have been written by means of special toolkit that necessary fields have been filled all, etc. After they will necessarily demand revision, entering pravok and repeated signing of documents during life cycle of the project. Thus cost of again written variants of use increases. However advantage of this method consists that the a lot of "writers" and "readers" will cooperate among themselves, the it is less probability of occurrence of mistakes(errors) and nedoponimaniya. The increasing cost of development quite is justified by greater safety and reliability of an end-product.

The principle 2 specifies that there are situations when additional charges on development justify themselves. And it is good, as a following Principle, behind number 3, says, that "heavier" methodology goes a heavy burden on the budget of the project.

Principle 3. The insignificant increase in "sizes" or conducts "density" of methodology to essential increase in cost of the project.

The suspension of work of one team of programmers for coordination with other team demands not only additional time, but also additional concentration (see discussion of "stream" at DeMarko [DeMarco99] and Kouberna [Cockburn98]). For updating the documentation concerning requirements, design of system and to testing, a lot of time too is required.

This principle is fair for any project. As you have already noticed, we do not discuss, are favourable or the companies additional expenses are not favourable - exclusively the question of cost, here is mentioned(touched) no more. The problem of definition of conformity of additional charges concerns to the Principle 2.

So, we have approached(suited) to a point when it is already possible to discuss attitudes(relations) between the size of methodology, project and a task. To do(make) it it is uneasy enough, because there is a tendency to consider(count), that the more a task, the it is necessary people for its(her) performance more.

The sizes of the project and methodology are connected among themselves by a positive feedback. If above the project works a few(a little,little bit) people rather small methodology is necessary to them. The less the methodology "weighs", the the team more productively works. And the more productively people work, the it is more than tasks they can solve - in other words, the small team of developers using "easy(light)" methodology, is quite capable to solve large-scale tasks.

On the other hand, when in the project a lot of people participates, their work is more complex(difficult) for coordinating, i.e. "heavier" methodology is necessary. Such methodology will reduce their efficiency, therefore for performance of a task the greater number of developers is required. However, the size of methodology grows more slowly, than the size of the project, therefore in any point it is possible to come to such situation when the team will cope with tasks in view, and management will have time to coordinate work of programmers (under condition of competent and sensible management of process, certainly).

For this reason (see Figure 3) for the decision of a specific target is required to you of less people if you will use easy(light) methodology, and it is more - if heavy. However, there is a restriction on the size of a task which can solve the given number of people. At the big team using heavy methodology, this "threshold" above, than at a small team which uses easy(light) methodology. Thus, if your task is beyond such restriction you should increase, on the one hand, quantity(amount) of developers and, with another, to use heavier methodology.

Figure 3. The volume of a task and methodology in the direct image influences quantity(amount) of the personnel in the company.

The main difficulty consists that it is practically impossible to define(determine) precisely volumes of a task right at the beginning of the project and consequently, and the minimal number of people which can solve this task. Besides, the quantity(amount) of developers directly depends on what people will particularly work above the project.

And at last, if the sizes of the project increase, it can appear, that the optimum decision will apply other methodology.

Project С3 which has come to the end not so long ago (Chrysler Comprehensive Compensation [C3a, C3b]), can serve as a convincing example of everything about what I now spoke. After 26 person could not carry out a task in creation of system which was considered as " the greater(big) project ", the small part of this team has undertaken business - only eight person. Using new, as much as possible easy(light), but thus strict methodology [XP], they have begun the project with zero and in a year could finish that the greater(big) team applied heavy methodology could not make. It is possible to tell with confidence, that partially such success of methodology KHR has been provided by last, fourth Principle.

Principle 4. The Most effective form of the communications (for transfer of ideas) - direct interaction, face to face, as at drawing at a board.

The principle 4 says, that to developers who sit the friend near the friend and can freely communicate, is easier create software product, that is, expenses for development of this software product will be less. It also means, that if the project grows in such a manner that to provide the direct communications between developers any more it is not possible, its(her) efficiency will fall, so, the expenses connected by it(her) will increase.

In figure 4 the curve which shows how efficiency of the communications falls at transition from direct dialogue at a board to a phone conversation, interactive correspondence (to a chat, etc.), to videorecordings, and, at last, to the documentation on a paper is represented. The below there is a curve, the it is less at developers of an opportunity to communicate among themselves, the multimodality of the communications disappears, an opportunity to transfer(transmit) the information by means of intonation to ask questions in process of their occurrence.

Figure 4. Efficiency of the communications

However " the rule of the communications " at all does not mean it, that any software product should be developed by the several people sitting in one room. The author of methodology should know, that if prime factors are efficiency and cost of program development it is necessary to pay special attention to work as small commands(teams) and direct dialogue between employees (as, for example, it is made in Extreme Programming [XP]). This conclusion is confirmed by researches [Plowman95]. Besides in work Sillinsa [Sillince96] discussion of various aspects of the communications inside of one organization is resulted(brought).

And two more factors

Priorities

At all thus considerable value in a choice of methodology plays desire of sponsors of the project: whether they wish to receive software product quickly, with a minimum quantity of defects, or they need to observe of process in its(his) all displays. To different priorities there correspond(meet) different methodological recommendations.

In the some people metodologiyakh priorities are appreciable at once, in the some people are not present. So, for example, Martin's object-oriented methodology and Odella [Martin96] is enough the general(common) also approaches(suits) for many cases, however it is not absolutely clear, on what is concrete it(she) is directed, and whether it is possible to change this "orientation" for work above various projects. The family metodology OPEN [BHS97], most likely, the basic purpose believes a correctness of software products, yavnost and repeatability of process. The methodology under name The Personal Software Process of Humphreys [Humphreys97] has been developed for maintenance of predictability of works.

In three last metodologiyakh about priorities it is spoken openly: authors of family metodology Crystal [Cockburn98, Crystal] and Extreme Programming [XP, Beck99] have declared, that to their methodology are directed, first of all, on increase of efficiency and deprecication of works. Thus all of them differ from each other - Crystal calls to combine productivity and tolerance, unlike KHR where efficiency increases just due to reduction of tolerance. The methodology " Adaptive Software Development ", Jim Khajsmita's child [Highsmith], is developed specially for the extremely astable situations in development when requirements, designing and is impossible short terms are functions each other and constantly vary (so frequently occurs(happens) in a web-development).

Methodology and its(her) author

" Any methodology is based on fear ", - has written somehow Kent Bek in one of discussions metodology. Firstly this remark seemed to me insignificant, but then I have understood, that in most cases, it is absolutely fair. Each element of methodology is called to prevent occurrence of those problems with what the author of methodology already collided(faced) in the past. Be afraid, what programmers will make many mistakes(errors) in a code? Do not forget about checks of a code. It seems to you, what customers do not know, that it is necessary to them? Create prototypes of the user interfaces. Be afraid, what designers will leave in the heat of work? Make so that they wrote the detailed documentation of everything that do(make). If metodologi could (or wished) to designate obviously the basic fears and wishes, the purpose of methodology would be clear from the first sight.

And, at last, as last making characteristic of methodology, we should mention individual philosophy of its(her) author. This philosophy is made out during purchase by the author of personal experience, and also the extrapolations made on the basis of this experience. That the methodology "has approached"(suited") the certain project, it(she) should correspond(meet) to philosophy and fears as commands(teams) of developers, and the author of methodology.

To each project the methodology

In the previous sections of clause(article) we have already shown, that there is a set various metodology (and it naturally enough) - see fig. 5. All of them differ from each other from the point of view of quantity(amount) of the people borrowed(occupied) in the project, criticality of the project, priorities and, probably, philosophies of developers.

Figure 5. The methodology, the people organized by a principle kh criticality kh prioritetnost.

In figure 5 you see seven possible(probable) sizes of the project and four zones of its(his) criticality. Such division is conditional enough, though and is plausible - my experience prompts, what exactly such parameters testify to necessity of change of character of the methodology applied in the project. To each cell of the scheme(plan) can correspond(meet) simultaneously at once a little various metodology. The choice will depend on preferences of sponsors of the project - whether they on the first place put productivity, obozrevaemost, repeatability or a correctness of process. " The size " methodology grows as approaching the right party(side) of the scheme(plan) (more people, more than communication elements in methodology), and "density" - to its(her) top part (more strict control). According to the Principle 3, the more to the right or above, the cost of development of the project, therefore those who is anxious by the economic party(side) of a question there is more, should try to place the project as it is possible more to the left and below. There are situations when other stimulus, for example, the prestige of the project head or safety of own career, can force to consider(count) you the project " more significant and critical " even if it will lead to increase in cost of development.

The most remarkable, that this scheme(plan) really approximately corresponds(meets) to a real state of affairs. We can count quantity(amount) of the people borrowed(occupied) in the project, to discuss its(his) criticality and priorities. Using the principles described above, we can make certain base decisions concerning what methodology should be used in the given concrete project. Eventually, all rest is solved with personal preferences. Below I shall result(bring) some examples from personal experience and I shall tell, how I most managed to apply these ideas and principles in practice.

My experience in various projects

In the Central Bank of Norway works about 40 regular programmers and half less kontraktnikov, and it is necessary to tell, they should solve marvellously many various tasks.

When I there was, the basic project was project Y2K in which it has been borrowed(occupied) 35 person. An overall objective here was prevention of wreck of bank system of Norway which could take place on January, 1st, 2000. Criticality of the project corresponded(met) to " loss of the irreplaceable sum ", the main priorities were timeliness and a correctness of the project. Basic technology were traditional greater(big) COMPUTERS.

At the same time there was a work above other, internal project which consist in creation of the program for the bank personnel. It(she) included an opportunity to order a dinner in cafeteria and to trace the status of the made orders - and all this in the form of a web-appendix. Above this task worked one-two person which used Delphi or Java and the Internet-browser. Criticality of the project corresponded(met) to " loss of comfort ", priorities - to make quickly and without special expenses.

The same group of programmers bore the responsibility for work above system which should collect and check all data about interbank transactions in the country, and these development were conducted(ordered) together with one more company. In the project which I now shall describe in more detail, greater(big) COMPUTERS too were used.

One programmer used language SQL for formation of the various generalizing reports, concerning(touching) investments and expenses. One more project has been started to replace the existing systems working on greater(big) COMPUTERS, with the distributed systems using the Internet-technology, the object-oriented approach and the componental architecture constructed on the basis of CORBA/Java. Were also other projects, but I think, that have mentioned already enough that the reader has received the general(common) representation about a situation. As it seems to me, in a similar case it is impossible to speak about any one methodology which would be "correct" for all this variety of tasks and projects.

As to me I worked above the project connected with interbank transactions, and also above internal the Internet-project for tracking orders. First of them was especially interesting, as during work above it(him) it(he) should be moved" twice from one our cell(cage) of " a methodological lattice " (fig. 5) in another.

• In November to me have told, that this project is calculated on 15 working weeks, that all 3 persons participate in development, that the design of the program is already practically completed, and that people have a similar operational experience above the previous version of system. Proceeding from stated above the scheme(plan) metodology and my own experience, I have assumed, that this project corresponds(meets) to position D4 on the scheme(plan), and it meant, that three developers should create system simply working together, paying a minimum of attention to any bureaucratic features (our standard phrase was: " make the work and go home ").
• However, it has soon appeared, that all task has been estimated(appreciated) approximately, and besides, only partially. We have lead additional calculations, and it has appeared, that this project should be calculated on 130 working weeks. Besides we have reconsidered idea about that all three programmers can work in different cities. During work new technologies were used, introduction of the new, more sensitive scheme(plan) of processing of mistakes(errors) was required, the system should work in real time, and problems with mutually exclusive access inside of a basis for data in addition were found out. Besides it was found out, that they need also to work together with other team which was in other part of city. The leading architect in two months went on leave on care of the child, the project head had no operational experience neither in IT to sphere, nor in a management(manual) of projects, and meanwhile, the reporting under the project should be carried out at a high state level.
  At this moment I have decided to translate(transfer) our project in category E5. It meant transition to incremental development, planning of releases of system with the minimal risk, weekly teleconferences of all group of developers, the monthly report on a state of affairs, etc.
• The first iteration has passed(has taken place) in the beginning of February, and has passed(has taken place) in time. However right after it(this) the architect has gone on leave, one of leading programmers have thrown on the project " on struggle against a mistake(an error) of 2000 ", and we have found out a mistake(an error) in the design decisions which are responsible for restoration after erroneous situations and for the control over mutually exclusive access. Now on our project have allocated(removed) already ten person which majority had no an operational experience in the given area, besides worked in absolutely different places. Usual everyday meetings and dialogue were simply impossible.
  In the middle of February I have solved, that the project is time for translating in category E15. We have developed more a detailed plan of deliveries for each developer, have started the program of modelling of tests, began to pay greater attention to dialogue with each of group of developers. Because of shortage of time we did not begin to order to members of a team to do(make) also paper work, and have suggested to translate(transfer) all in frameworks of personal contact - conversations by phone, teleconferences and trips to each other by train.
• In a month the personnel managed to adjust the work, the plan was stabilized also. At last all history has come to the happy end. We have managed to find out all serious mistakes(errors) in design at an early stage of works. Our new project head has managed to find common language with the subordinates and well traced the planned releases of the program. The project has been finished in time in a year - in February. All heads were happy(enough) as the technical party(side) of the project, and for the reason, that the general plan of release of system has not changed even after March revision of the project.

In this project I for the first time in practice have applied the scheme(plan) about fig. 5 and with its(her) help consistently changed methodology directly during the project. However, neosoznanno I used all these principles and schemes(plans), since 1994. Here some more examples which I result(bring) in ascending order the sizes of the project:

• The Internet-project on tracking orders in cafeteria concerned to category C4, in other words, the "cheapest" projects. In it(him) there was no written documentation, except for several sketches of variants of use. All work passed(took place) in absolutely informal conditions, down to that moment when the decision to not develop this system was accepted, and to buy(purchase) an available product (all according to priorities of economic projects).
• The project of the Central bank of Norway under name BankLab represented development of the prototype for the future crucial bank program system. It(he) can be carried to category С5: all team of developers have planted(put) in one room and have tried to relieve of any handicapes in work. The head and the leading programmer send(have come) to a common opinion of that has led the project to success: " Take good experts, work as a small team, place all in one room, provide with their necessary information, and then do not stir(prevent) ". (As strongly all this differs from an atmosphere of work above project Y2K in the same bank!)
• As I already spoke, in project Chrysler Comprehensive Compensation (C3) the methodology " Extreme Programming " was used. They have replaced all written documentation with direct dialogue, drawing at a board, index cards and strengthened regressionnym testing. Were as well other innovations which are in detail described in [XP, C3a, C3b, Beck99]: constant change of partners at pair programming and deliveries of the next versions of system each three weeks. If to operate with concepts which we have entered in this clause(article) they used those principles which have allowed to pull methodology D6 on the project of size D14, and, thus, to cut expenses and raise(increase) efficiency.
• The project under the name "Winifred" was developed with use of language Smalltalk. It(he) has got in category D40, its(his) main priority was " to make in time ". All team of developers was placed in one place, internal communications were on the ball. A course of works above the project and the methodology zadokumentirovana also is published in [Cockburn98]. I mention this project in the given context as the choice of methodology was based on the size of a team, affinity of workplaces, and also priorities and criticality of the project. All these factors have led to increase in a role of direct interpersonal dialogue.
• The project "Rishi" (language Smalltalk) has got in category D90. Certainly, we tried to work in as much as possible "easy"("light") style, however even thus we needed some commands(teams) of designers. In this project we have entered special system of co-ordination of work inside of a team where various assemblies and documents entered.

Changes of methodology in a mode of real time

And, at last, last from the most important factors at creation of methodology - adjustment of the necessary methodology it is direct during works. Soon we understand Kohl, that each project deserves own methodology it becomes obvious, that it is necessary to use primary assumptions of what methodology, it only our first attempt to guess, that actually it is required to us. Here here also the role of incremental development becomes appreciable.

If we shall spend interrogation among developers in the middle of iterations and between them we shall have an opportunity to consider the freshest operational experience. If we shall consider this experience the team will have an opportunity to improve used methodology directly on a course of works.

However, the description of dynamic change of methodology is not included into frameworks of this concrete clause(article). Some information on this theme can be gathered in work [Cockburn98], but in more detail it(she) will be presented in separate clause(article).

The conclusion

Any methodology consists of ten basic elements: roles, skills, the kinds of activity used tekhnik, the toolkit, delivered artefacts, standards, measures of quality and priorities of the project. The main result of my work which I have generalized in this clause(article), became obligatory presence of many various metodology. Depending on the size of the project (number of people which work is necessary for coordinating), criticalities of the developed appendix and the basic priorities, in the project can be applied various methodology. For any point in space the size/criticality founders of methodology choose the certain number(line) of aspects (a role in the project, kinds of the activity, delivered products and standards) and try to minimize the risks connected with some qualities of the project. Thus they are based on the personal experience to which their intentions concern also, fears and philosophical views. At comparison various metodology it is necessary to consider all these moments, and also their parities(ratio) with needs of the project or the organization.

We have found out four basic principles of designing of methodology. In brief they can be described as follows:

• The more the team the is heavier" the used methodology should;
• Increase "density" of methodology at increase in criticality of the project;
• The "more hard" methodology, the above cost of the project;
• The most effective form of the communications - direct dialogue.

All these principles have found the acknowledgement(confirmation) during work of the author above various projects, however we know very few other researches on the given theme though development of the given question is represented very actual.

The bibliography

[Beck99] Beck, K., Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999.

[C3a] The "C3" Team, " Chrysler goes to ' Extremes' ", in Distributed Object Computing, October, 1998, pp. 24-28.

[C3b] Jeffries, R., " Extreme testing ", in Software Testing and Quality Engineering, March/April, 1999, pp. 23-26.

[Cockburn98] Cockburn, A., Surviving Object-Oriented Projects, Addison-Wesley, 1998.

[Crystal] Cockburn, A., Crystal/Clear: A Human-Powered Methodology for Small Teams, Addison-Wesley, 2000, in preparation, early version visible at http: // members.aol.com/humansandt/crystal/clear.

[DeMarco99] DeMarco, T., Lister, T., Peopleware: Productive Projects and Teams, 2nd Ed., Dorset House, 1999.

[Graham97] Graham, I., Henderson-Sellers, B., Younessi, H., The OPEN Process Specification, Addison-Wesley, 1997.

[Harrison96] Harrison, N., Coplien, J, " Patterns of productive software organizations ", Bell Labs Technical Journal, Summer, 1996, pp. 138-145.

[Highsmith] Highsmith, J., Adaptive Software Development, xxx press, 2000.

[Humphreys97] Humphreys, W., Introduction to the Personal Software Process, Addison-Wesley, 1997.

[Martin96] Martin, J., Odell, J., Object-oriented Methods, Pragmatic Considerations, Prentice Hall, 1996.

[Plowman95] Plowman, L., " The interfunctionality of talk and text ", CSCW, vol. 3, 1995, pp.229-246.

[Sillince96] Sillince, J.A., " A model of social, emotional and symbolic aspects of computer-mediated communication within organizations ", CSCW vol. 4, 1996, pp. 1-31.

[XP] Jeffries, R., Beck, K., et al., Extreme Programming, as described on the web: http: // extremeprogramming.com, http: // armaties.com/extreme.html, http: // c2.com/ppr/wiki/ExtremeProgrammingRoadmap/html.zip.