Transcript XP – eXtreme Programming

XP – eXtreme Programming
A gentle introduction.
Cleviton Vinícius
Jobson Ronan
Thiago Rodrigues
Objective

The goal of this presentation is to
provide an introduction and overview
of Extreme Programming (XP).
The XP Philosopher


In the early 1990s a man
named Kent Beck was
thinking about better ways
to develop software.
In March of 1996 started a
project at DaimlerChrysler
using new concepts in
software development
The XP Philosophy
You need to improve communication
 You need to seek simplicity
 You need to get feedback on how
well you are doing
 And you need to always proceed with
courage

What is Extreme Programming?

Extreme Programming (XP) is actually a
deliberate and disciplined approach to
software development
 This methodology also emphasizes team
work
 Managers, customers, and developers are
all part of a team dedicated to delivering
quality software
MORE INFORMATION...
http://www.extremeprogramming.org/what.html
Four dimensions

XP is successful because it stresses
customer satisfaction.
 XP improves a software project in four
essential ways:
•
•
•
•
Communication
Simplicity
Feedback
Courage
When should Extreme
Programming be Used?
Extreme Programming (XP) was
created in response to problem
domains whose requirements
change.
 XP was also set up to address the
problems of project risk.
 XP is set up for small groups of
programmers

When should Extreme
Programming be Used?

The real goal has always been to
deliver the software that is needed
when it is needed.

Environments dynamically changing
The Rules and Practices
of Extreme Programming.
Planning
 Coding
 Designing
 Testing

MORE INFORMATION...
http://www.extremeprogramming.org/rules.html
Planning
User stories are written
 Release planning meeting creates
the schedule
 Make frequent small releases
 Move people around

Planning

The project is divided into iterations
Planning

The iteration planning starts each
iteration
Designing
Simplicity
 Choose a system metaphor
 Never add functionality early
 Refactor whenever and wherever
possible.

Coding
The Customer is Always Available
 Coding Standards
 Pair Programming
 Integrate Often

Coding

Use Coletive Code ownership
Coding

Code the Unit Test First
- Easier to create your code
- just the requirements
*Some software systems are typically
building code first and testing second
Testing
All code must have unit tests
 All code must pass all unit tests
before it can be released
 When a bug is found tests are
created
 Acceptance tests

What We Have Learned
About Extreme Programming








Release Planning
Simplicity
System Metaphor
Pair Programming
Integrate Often
Optimize Last
Unit Tests
Acceptance Tests
What We Have Learned About
Extreme Programming