XP e Xtreme Programming A gentle introduction Cleviton

XP – e. Xtreme Programming A gentle introduction. Cleviton Vinícius Jobson Ronan Thiago Rodrigues

Objective l The goal of this presentation is to provide an introduction and overview of Extreme Programming (XP).

The XP Philosopher In the early 1990 s a man named Kent Beck was thinking about better ways to develop software. l In March of 1996 started a project at Daimler. Chrysler using new concepts in software development l

The XP Philosophy l You need to improve communication l You need to seek simplicity l You need to get feedback on how well you are doing l 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 l This methodology also emphasizes team work l Managers, customers, and developers are all part of a team dedicated to delivering quality software l MORE INFORMATION. . . http: //www. extremeprogramming. org/what. html

Four dimensions XP is successful because it stresses customer satisfaction. l XP improves a software project in four essential ways: l • • Communication Simplicity Feedback Courage

When should Extreme Programming be Used? l Extreme Programming (XP) was created in response to problem domains whose requirements change. l XP was also set up to address the problems of project risk. l XP is set up for small groups of programmers

When should Extreme Programming be Used? l The real goal has always been to deliver the software that is needed when it is needed. l Environments dynamically changing

The Rules and Practices of Extreme Programming. l Planning l Coding l Designing l Testing MORE INFORMATION. . . http: //www. extremeprogramming. org/rules. html

Planning l User stories are written l Release planning meeting creates the schedule l Make frequent small releases l Move people around

Planning l The project is divided into iterations

Planning l The iteration planning starts each iteration

Designing l Simplicity l Choose a system metaphor l Never add functionality early l Refactor whenever and wherever possible.

Coding l The Customer is Always Available l Coding Standards l Pair Programming l Integrate Often

Coding l Use Coletive Code ownership

Coding l 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 l All code must have unit tests l All code must pass all unit tests before it can be released l When a bug is found tests are created l Acceptance tests

What We Have Learned About Extreme Programming l l l l Release Planning Simplicity System Metaphor Pair Programming Integrate Often Optimize Last Unit Tests Acceptance Tests

What We Have Learned About Extreme Programming