0% found this document useful (0 votes)
101 views21 pages

Extreme Programming (XP)

Extreme programming (XP) is an agile software development framework that recommends taking common development best practices like code review, testing, and incremental development to extreme levels. It proposes doing these activities continuously and integrating code multiple times per day through practices like pair programming, test-driven development, and continuous integration. The goal is to improve software quality and reduce risks through more frequent feedback cycles.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
101 views21 pages

Extreme Programming (XP)

Extreme programming (XP) is an agile software development framework that recommends taking common development best practices like code review, testing, and incremental development to extreme levels. It proposes doing these activities continuously and integrating code multiple times per day through practices like pair programming, test-driven development, and continuous integration. The goal is to improve software quality and reduce risks through more frequent feedback cycles.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 21

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

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy