eXtreme+Programming

toc =EXTREME PROGRAMMING=

**1.0 INTRODUCTION TO EXTREME PROGRAMMING**
Agile Methods (AMs) are a set of development techniques designed to address some problems of modern software development (i.e. projects over budget and over schedule). Such methods do not pretend to be useful in any kind of software project or to be the solution to reduce costs and increase quality of any product. AMs simply helps developers to focus on the objectives of their customers and deliver the right product for them without wasting time and effort in activities that are not able to generate value for the customer (Sillitti and Succi, 2007).

Extreme programming which is also known as XP is one of the hottest agile method in recent years. This method is more related to the engineering development practices like test-driven development than project management techniques. This method was introduced by Beck, Jeffries, et al in 1998 and was further generalized by Beck's extreme. Most of XP popularity was owes to developers which were sick of traditional methods and also developers looking for something new and extreme as explained by Highsmith .J (2002). Xp planning are as follows:- XP have 12 rules, true to the nature of the method itself, are concise and to the point. the method can be implemented without consulting a page in Beck's book.
 * Agile team receieving the user stories from the customer
 * assessing and cost by the agile team.
 * group the stories for a deliverable increment.
 * project velocity is obtained after the first increment to also know when the subsequent delivery dates for the other increments.

**1.1 12 RULES IN EXTREME PROGRAMMING**

 * Rules in extreme programming as explained by Cohen .D et al (2004)**
 * **The planning game**: At the beginning of each iteration, customer, managers and developers conduct a meeting to collect, analyse and estimate the importance of the requirements to be considered for this iteration. These requirements should be written in simple language which is understandable by all the meeting participants.
 * **Small release**: Getting customer approval by completing some of the first important iterations, it enables the management to put the initial version of working software on the production stage. Subsequently, each iteration will add some more functionality to this this initial version with the passage of time.
 * **Metaphor**: Major participants like customers, developers and managers construct it by modelling.
 * **Simple design**: Quality focus is the major feature of any of the agile methods but to maintain the simplicity has the same priority. Developers should maintain the simplicity of the work throughout the iteration to avoid any complex problems while proceeding to the next iterations. Simple design in all stages require less refactoring in the later stages.
 * **Tests**: Unit testing as well as proper smoke, integration and regression testing should be performed at the end of each iteration. Developers should write the test cases for the developed code and customers should provide the acceptance criteria for the functional testing.
 * **Refactoring**: With the passage of time and as a result of continuous integration, the developers work should be properly re-factorised and restructured to keep the design and code base as simple as possible.
 * **Pair programming:** In pair programming, two developers use the same computer to develop the code and they mutually handle the requirements.




 * **Continuous integration**: New functionality is added into the existing system more often by the developers. This continuous integration can create a massive trouble if not taken care in each iteration. Simplicity in design leading to simplicity in code is the basic principle to avoid any integration failures.
 * **Collective Ownership**: Agile teams are self-managing so the generated code is the collective effort of all tram members and to fulfil their commitment to the customer, anyone can change the code where it is felt necessary for the better results.
 * **On-site Customer:** A customer works with the development team at all times to answer question because the developer might need to ask some questions if the user story is not clear to them, perform acceptance tests and also ensure that the work is moving as expected.
 * **40-hours weeks:** Developers should select the requirements for each iteration so as to avoid puting overtime in any iteration.
 * **Open workspace**: Developers work in a common workspace set up with individual workstations around the periphery and common development machines in the centre.

**1.3 5 VALUE OF EXTREME PROGRAMMING**
But the strength of extreme programming does not result from the 12 rules alone as tend to agree by the practioners, but also form the propertises arising from thier contribution. highsmith(2002) lists 5 keys value of extreme programming, all the principle are enhanced by its practices, they are:
 * Communication: Developers of the system requires proper communication in the system inorder to achieve their goals by sharing views.
 * Simplicity:This methods encourages the design and coding to bein its simplest solution, which extra funtionality can be updated later. it also faces the needs for today instead of tomorrow's or later needs which might also serve as disadvantage when its needed later because it will require more effort to change the system because its simplicity of design and coding are always based on the today's aim not tomorrow or next.
 * Feedback: Feedback helps developers keep tabs on the different dimensions of the system development and helps in improvements which arise from responses to differnt test from various users or the system itself
 * Courage: Courage is embodied in a number of ways,from refactoring codes when necessary to knowing a source is no longer relevant and has to be discarded and in some other cases being persistent enough to tackle a complex problem irrespective of the time it takes
 * Quality work: Customer expect good quality coding and design from the developers.

1.5 Diagram of extreme programming
Diagram of extreme programming as explaine to Beck .k, & Fowler, M (2004)

1.5.1 Stages in extreme programming and their activity
(a) **User Story** : this are words written in simple sentence on a card from the customer to the developers. (b) **Iteration plan:** it divides the an iteration into the user stories and development task, it usually take 2 weeks to be accomplished. (c) **Release plan**: Is a program plan for planning software release. (d) **Metaphor**: it explains how the system operates, it is normally written as a sentence. (e) **Development task**: activities carried out to satisfy the customer's requirement. (f) **Acceptance Test**: to know if the iteration satisfies its acceptance criteria which is usually checked and written by the customers. (g) **Unit Test**: where the software components are being examined to confirm whether they are working properly.

=2.0 REFERENCES=

Beck K., & Fowler, M. (2004). Planning extreme programming. Upper saddle River, NJ; Addison-Wesley.

Beck K., “Embrace change with extreme programming”, IEEE Computer (Oct. 1999) 70–77.

Cohen .D, Lindvall .M & Costa P(2004) "An Introduction to Agile Methods" [|http://www.cs.umd.edu/~mvz/cmsc435-s09/pdf/agile-paper.pdf]

Highsmith J., Agile Software Development Ecosystems, Addison–Wesley, Boston, MA, 2002.

Sillitti, A.and Succi,G. (2007) Foundation of Agile Method. England: John Wiley and Sons Ltd.

The C3 Team, "Crysler goes to extreme, in Distributed computing, Oct 1998, pp. 24-28