Welcome to the Seminar ON

Extreme programming
by Abhijeet A. Adsod

Introduction
y

Extreme programming (XP) is a lightweight methodology for smallto-medium sized teams developing software in the face of rapidly changing requirements. XP is a deliberate and disciplined approach to software development. XP stresses consumer satisfaction. An extreme attempt to dramatically simplify the process of developing software systems is made focusing on what delivers value: the requirements for the system or the code that implements the system.

The XP Practices
y y y y y y y y y y y y

Planning Game Small releases Metaphor Simple design Test Driven Development Refactoring Pair programming Collective ownership Continuous development Sustainable pace On-site customer Coding standards

User Stories
y

User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document. User Stories are written by the customers as things that the system needs to do for them. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented

Acceptance Tests
y

Acceptance tests are created from user stories. During an iteration the user stories selected during the iteration planning meeting will be translated into acceptance tests. The customer specifies scenarios to test when a user story has been correctly implemented Acceptance tests should be automated so they can be run often. The acceptance test score is published to the team. It is the team's responsibility to schedule time to each iteration to fix any failed tests. The name acceptance test was changed from functional tests

Unit Testing
y

Unit testing means testing a unit of code. A unit of a code is generally a class in an object oriented system. It could also be a component or any other piece of related code.

Release Planning
y

A release planning meeting is used to create a release plan, which lays out the overall project. The release plan is then used to create iteration plans for each individual iteration The essence of the release planning meeting is for the development team to estimate each user story in terms of ideal programming weeks An ideal week is how long you imagine it would take to implement that story if you had absolutely nothing else to do. The customer then decides what story is the most important or has the highest priority to be completed

System Metaphor
y

Choose a system metaphor to keep the team on the same page by naming classes and methods consistently. What you name your objects is very important for understanding the overall design of the system and code reuse as well. Choose a system of names for your objects that everyone can relate to without specific, hard to earn knowledge about the system. For example the Chrysler payroll system was built as a production line. There is also a metaphor known as the naive metaphor which is based on your domain itself

Spike Solution
y

A spike solution is a very simple program to explore potential solutions. Build a system that only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story's estimate. When a technical difficulty threatens to hold up the system's development put a pair of developers on the problem for a week or two and reduces the potential risk

Small Releases
y

The development team needs to release iterative versions of the system to the customers often. The release planning meeting is used to discover small units of functionality that make good business sense and can be released into the customer's environment early in the project. This is critical to getting valuable feedback in time to have an impact on the system's development. The longer you wait to introduce an important feature to the system's users the less time you will have to fix it.

Iteration

Bugs
y

When a bug is found tests are created to guard against it coming back. A bug in production requires an acceptance test be written to guard against it. Creating an acceptance test first before debugging helps customers concisely define the problem and communicate that problem to the programmers.

Project Velocity
y

The project velocity (or just velocity) is a measure of how much work is getting done on your project. To measure the project velocity you simply add up the estimates of the user stories that were finished during the iteration

Pair Programming
y

Different aspects of organizational and software engineering support pair programming as following
x Economics x Satisfaction x Design quality x Continuous reviews x Problem solving x Learning x Team building and communication x Staff and project management

Refactoring
y

Refactoring allows us to revise the structure or the design of an existing piece of software so that it becomes easier to add or modify functionality. It is important to be able to revise the softwares design in this manner because otherwise only additions or modifications that are in some sense consistent with the original design can be made A syntactic refactoring step is a change in some essentially syntactic aspect of the piece of the software Semantic Refactoring modify the logic of the software and how it functions.

Documentation
y

XP ensures that you have the communication you need, without increasing the documentation you have to write
x Documentation or Communication x Communicating Requirements x Release Planning Communicates Requirements x Iteration Planning Communicates Requirements x Acceptance Tests Communicate Requirements x Informal Conversations Communicate Requirements x Natural Communication of Requirements x Communicating Internal Design

Release Planning Communicates Design Iteration Planning Communicates Design Day to Day Development Communicates Design Pair Programming and Collective Ownership Communicates Design Refactoring Communicates Design Natural Communication of Design Communicating Status Standup Meeting Big Visible Chart Communicating Externally

Distinguishing Features of XP
y

Its early and concrete and continuing feedback from short cycles Its incremental planning approach which quickly comes up with an overall plan that is expected to evolve through the life of the project Its ability to flexibly schedule the implementation of functionality, responding to changing business needs Its reliance on automated tests written by programmers and customers to monitor the progress of development, to allow the system to evolve and to catch defects easily Its reliance on oral communication, tests and source code to communicate system structure and intent Its reliance on an evolutionary design process that lasts as long as the system lasts Its reliance on the close collaboration of programmers with ordinary skills Its reliance on practices that work with both short-term instincts of programmers and the long-term instincts of the project

Conclusion
y

Extreme Programming is a software engineering process and philosophy based on well-known practices. Extreme Programming tries to make things happen in ways that people find natural and pleasant. In the case of documentation, this is accomplished by recognizing that the point is communication, not simply documentation, then using the most effective forms of communication, and the most automatic forms, wherever possible. XP is different from established software processes. It also provides new challenges and skills as designers need to learn how to do a simple design, how to use refactoring to keep design clean and how to use patterns in an evolutionary style

Thank You