Extreme Programming is new development technique getting adopted in the software development and the key strength of this methodology is simplicity, team work, quality and testing.
XP suggests having very simple and clean design, which means almost every developer can understand the system better. So, XP development approach will suite with new product development where the complete product visibility is not clear or the system is not very complicated.
Teamwork, it encourages developers working closely with customer, ideally customer or product manager will work along with developers to have constant discussion whenever required. Other development hardly gets a chance to interact with customer which may lead to wrong development.
Very often complicated system design will have more difficulty if the customer comes up with changes, but XP can adopt changes very easily because of its simple design. Also, this gives more flexibility for our customer to freely change their requirement. Let's have quick overview on entire development life cycle:
- Planning
1.1. Stories
1.2. Release Plan
1.3. Iteration Plan
1.4. Stand-up Meeting
- Design
2.1. Simplicity
2.2. Spike Solution
2.3. Re-factor
- Coding
3.1. Customer Availability
3.2. Coding Standards
3.3. Unit Testing
3.4. Pair Programmed
3.5. Integrate Often
3.6. Optimization
- Testing
4.1. Unit Test
4.2. Acceptance Test
1. Planning
Planning phase we have to decide on our development strategy like finalizing requirement, release plan, iteration plan & developer meetings.
1.1. Stories
Stories are nothing but a simple use case in a system without having any visual representation. For example a typical story would look like this,
"I would like to see the list active customers in a tabular format with their contact numbers, and by clicking the number I should be able to make a call the respective customer"
The above one is a simple story explains the end user or customer need given in plain English. The story need not have complete description about the requirement, and the product manager or customer will give us detailed description about the requirement at the time of development.
The stories are created to have estimates, release plan, iteration duration etc. Typically a story should be implemented in two weeks of time.
1.2. Release Plan
After finalizing the list of stories the release plan meeting happens with technical team as well as product team. Typically technical team will be revealing the required effort & complication of stories and product manager or customer will evaluate the same and priorities the stories. Finally the system release plan & release date will be finalized.
1.3. Iteration Plan
Iterative development breaks whole requirement into small set of iteration and with fixed length of duration. Typically iteration is a small release with set of sorties or functionalities.
Iteration planning meeting happens at the beginning of iteration to generate Iteration plan with list of new development stories from the release plan. Iteration duration can be 1-2 weeks; mostly it will be a story complete execution period.
As part of each story completion, the developer has to complete acceptance & unit testing. Each completed stories will be singed off by customer. Failed stories, acceptance test will be analyzed in iteration plan meeting and new stories will be created to complete the same.
1.4. Stand-up Meeting
Stand-up meeting enables communication with everyday developer, managers. Every team members will be brief their yesterday task, today plan and they will be discussing technical problems, solutions and any other information useful to entire team.
This helps each to developer aware of new problems, solutions and helps everyone to get their issues clarified.
2. Design
2.1 Simplicity
Simple design is very easy implement and takes less time to complete than the complex one. XP development model recommends having simple and clean design, and break any complicated design into simple design if possible.
2.2 Spike Solution
Every design problems or technical complexity has to be addressed before staring the iteration to reduce the risk. The spike solutions are developed to solve or explore critical problems and it need to follow all the regular development procedures.
Ideally those programs will be thrown away once every developer gets clear idea about the problem.
2.3 Re-factor
Extreme programming recommends to refractor or review, confirming coding standard etc. Continuous re-factoring saves developer time and increase quality, the major motivation of re-factoring is to keep the code clean, re-use, extent and easy to maintain.
3. Coding
3.1. Customer Availability
Customer should be available all the time not only to help developers also part the project member. It's better to have face- face meeting with customer whenever to get any issues clarified before starting development with assumption.
Customer will be validating user completed stories and they will confirm the desired requirements.
3.2. Coding Standard
It's not new to XP but development strategy includes customer coding standard or common standard to keep the code consistency to have better maintainability and clarity.
3.3. Unit Testing
In XP modeling we have to create the test first with story and confirm the code later with test. Developing test helps to understand the requirement better and coding will be much faster than normal development. Also, we should create a test to cover the complete code written, which means changing single line of code has to make one of the test failed.
3.4. Paired Programming
It's little unusual than normal development model, but it really helps to improve the developer productivity. Paired development makes the developer to share their ideas to find quick solution for the given problem and it enables them to deliver the code quickly.
3.5. Integrate Often
We have to integrate our code very often to code repository or version control system. The version control system should confirm the entire acceptance tests to make sure that delivered source code has no impact on exiting functionalities, otherwise the deliverables are considered to be rejected.
3.6. Optimization
There is no optimization required till the end of the development, and it's recommended to make it work first and make it fast at last.
4. Testing
4.1. Unit Test
Every piece of code we develop should have Unit test to confirm the functionality. It should happen immediately after completing development of each story. Code will be delivered along with unit test and every one code delivery should make sure that exiting test is succeeding.
4.2. Acceptance Test
Acceptance test are created based on user stories to make sure the component or system is returning expected result. Usually customer gives a scenario (use case) and expected output of the system.
The developer will be creating the test scripts to capture the actual result from the system & and confirms with expected static data given by customer.
Each delivery customer will verify correctness of the expected result, and it should make sure that exiting tests are succeeding prior to current delivery to accept the deliverables.