Extreme programming (xp)
Extreme programming model
• Extreme programming was proposed by Kent Beck in 1999.
• Recommends taking the best practices to extreme levels
• If something is good, why not do it all the time.
Good practices to extreme:
• If code review is good:
• Always review – Pair Programming
• If Testing is good:
• Continually write and execute test cases – Test Driven Development
• If Incremental development is good:
• Come up with new increments every few days.
Good practices to extreme:
• If Simplicity is good:
• Create the simplest design that will support only the current require functionalities.
• If Design is good:
• Everybody will design daily. – Refactoring
• If architecture is important:
• Everybody will work at defining and refining the architecture (Metaphor)
• If Integration testing is important:
• Build and integrate test several times a day (Continuous Integration)
Values
• Communication
• Enhance communication among team members and with the Customers
• Simplicity
• Build something simple that will work today.
• May not pay attention for tomorrow.
• Feedback
• System Staying out of users is trouble waiting to happen.
• Courage
• Don’t hesitate to discard code
Pair Programming
Pair programming is an agile software development technique in
which two programmers work together at one workstation. One, the
driver, writes code while the other, the observer or navigator, reviews
each line of code as it is typed in.
The two programmers switch roles frequently.
Two co-workers pair programming
Pair programming
Also known as four eye principle.
An agile software development technique in which two programmers work together at one workstation.
Driver – one who writes the code.
Observer or navigator – reviews each line of code as they type in.
While reviewing they come up with ideas of improvements and adding features.
One writes the test cases and other writes the code that satisfies the test case.
Continuous integration
Practice of integrating a code several times a day and automating the testing of code.
By integration errors can be detected and located easily.
Less time can be spend on debugging and more time in adding new feature.
Improves software quality and reduces risk.
Committing code frequently.
Using continuous feedback mechanism.
Work flow of extreme programming
1. Planning or Listening
The planning activity (also called the planning game ) begins with
listening.
Planning of,
– XP team
– Analysis of “stories” written by customer
The customer assigns a value (i.e., a priority) to the story based on the overall business value
of the feature or function
Members of the XP team then assess each story and assign a cost —measured in development
weeks—to it.
more than three development weeks, the customer is asked to split the story into smaller stories
and the assignment of value and cost occurs again
Cont…
It is important to note that new stories can be written at any time.
During planning customer and XP team work together
the XP team orders the stories that will be developed in one of
three ways:
1. all stories will be implemented immediately (within a few weeks),
2. the stories with highest value will be moved up in the schedule and implemented first,
or
3. the riskiest stories will be moved up in the schedule and implemented first.
Release date (commitment)
2. Design
Break down of tasks
Test Scenario preparation for each task
Regression Automation Framework
“class-responsibility-collaborator (CRC)”
If a difficult design problem is encountered as part of the design of a story, XP
recommends the immediate creation of an operational prototype of that portion of the
design. Called a “spike solution”, the design prototype is implemented and evaluated.
Spike
• A task aimed at answering a question or gathering information, rather
than at producing shippable product. Sometimes a user story is
generated that cannot be well estimated until the development team
does some actual work to resolve a technical question or a design
problem. The solution is to create a “spike,” which is some work
whose purpose is to provide the answer or solution.
CRC Layout
Student crc
3. Coding
Coding
“Pair Programming”
4. Testing
Unit Testing
Execution of Manual test scenarios
Defect Report generation
Conversion of Manual to Automation regression test cases
Mid Iteration review
End of Iteration review
5. Listening
• Feedback from Customers.
Difference Between Scrum and XP
