Systems need to be changed every few months, and therefore Extreme programming (XP) exist. Which means, the programs would be delivered when needed. Extreme programming puts an emphasis on on the teamwork, so that managers, developers and clients are a part of the team. Programmers are authorized to independently respond to changes in customer requirements, even in the final stages of development.
Regarding the team members there is also a limit of extreme programming, which is that it is applicable only to projects with fewer employees. Ideal group ranges from 2 to 12 employees. In general, the projects with the dynamic changes in the requirements or high-risk, smaller group that applies the principles of extreme programming can be more efficient than a large team.
Four major systems development processes are: planning, design, programming and testing.
Planning refers to the two main issues in the development process: what will be done by a certain day and determining what needs to be done next.
When planning, user stories are used, which are similar to the user scenarios and are used for planning outings of particular version of the application. They are used instead of long requirements documents, and here users describe what the system should do in a few sentences (the user, not the technical terminology). For each user story there must be made at least one test that will confirm the fulfillment of user stories. The purpose of these stories is to estimate the duration of implementation, i.e., prior to implementation developers have to get a more detailed specification. Each user story should be estimated last 3 weeks, and if it takes longer it must be divided into more stories. At the end, there must be about 80 user stories (plus / minus 20) for planning.
At the joint meeting, a schedule of system versions is created. This schedule serves to create plans for each iteration. It is recommended to issue a lot of versions often, however, they don’t have to be improved all the time, but they are used to identify what benefits from its functionalities, a user can have, furthermore they need to be delivered as soon as possible.The system is developed in iterations that last 1-3 weeks where they should be approximately the same length. All program activities don’t have to be planned at the outset of the project, but the activities are planned at the beginning of each iteration. This is the so-called Just In Time iterations planning, which allows fast tracking of user requirements change.
Every programmer estimates how many ideal working days are required for the task to be done, and if the estimate is greater than 3 working days, the task needs to parse into smaller tasks. In the case that within the iteration is not possible to accomplish tasks, deadlines should not be disturbed and therefore should throw out some of the tasks.
It is necessary to measure the speed of development of the project. In doing so, the estimated duration to fulfill clients’ stories in some iterations based on the previous iteration is evaluated.
Simplicity is one of the main goals when designing the system because the project with a simple design can be performed faster. For this purpose, you never should add new functionality to it before the deadline.
When designing it is necessary to use appropriate metaphor for a consistent definition of classes and objects. For the purposes of designing a system it is desirable to use Class Responsibility Collaboration cards. They are used for designing object-oriented programs and help figure out which program classes are needed and how they will interact.
In the case of complex technical or design problems potential alternative solutions need to be created.The aim of this is to reduce the risk of possible technical problems or increase the reliability of user stories estimates.
When designing it is necessary to be careful not to add unnecessary functionality, since only 10% so extra added functionality is ever used. And at the end of the design is required for redesign to be applied or to reject unnecessary functionality, and eliminate redundancy.
The availability of an end-user is an important prerequisite during the development of the system.
It is recommended that the basic tests are pre-created to verify functionality prior to the development of program code. This does not extend the production of the underlying programming code, and later it is not needed to spend more time on writing tests.
One of the recommendations that the developers may initially find weird, is programming in pairs. This means that one person writes the program code while the other controls him. In the end, this should result in a much higher level of system quality and the same amount of functionality as if the developers worked separately.
Also very important is that, in the inclusion of the new code in the whole system, sequential integration is used. This prohibits situations in which different developers simultaneously involve program code and test it.
What regards the integration of the source code, there is a rule, and that is that the program code is often integrated. It is recommended that the program code is included in the system every few hours and cannot wait longer than a day, but under a rule of sequence integration. It is important that during the project joint ownership of the program code appears, i.e. all the developers are free to modify the finished code, not write themselves, to add new functionality or correct errors.
All additional optimizations should be left to be the final actions, and employees on the project should avoid working overtime.
One of the foundations of extreme programming is the use of basic tests to verify the correctness of the implemented function. For just testing it is necessary either to take or to develop own programming environment that enables automated tests to be created. Tests need to be created before the development of the system programming code. Therefore, developed software system can’t be integrated into the whole system if it is not followed by the accompanying tests.
Tests for checking errors, need to be created when error is detected in the programe code. Defined user stories result with tests for system acceptance. Customer defines scenarios to be tested on the basis of user-defined story, and for one story there can be defined one or more tests.
With regard to testing as the basis of software packages development, often we come across to the principle of Test Driven Development, and the principle is the same as with extreme programming. Prior to its development and on the basis of defined functionalities, basic tests that developed system must meet are being made.