XP - EXtreme Programming - An Overview

XP is one of Agile processes, which consists of a set of roles, strong principles and values that was born at the final of 90’s on USA.

Extreme Programming is based on simple rules, and they look like a jigsaw puzzle, on what nothing has a complete sense by itself, but when the pieces are combined together it can make sense. 


One of the main purposes of XP is the customer satisfaction, and it’s possible through on of its practices – on-site customer. It results in a constant and fast response to changes, even late on the life cycle of the project.

Additionally, XP teams are collaborative and self-organized – managers, developers and customers work together in an equal partnership in a simple, but effective environment. The improvement during a life cycle of a project is made by five essential values – simplicity, courage, respect, feedback and communication.

“Extreme Programmers constantly communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. Every small success deepens their respect for the unique contributions of each and every team member. With this foundation Extreme Programmers are able to courageously respond to changing requirements and technology.” - Extracted from  http://www.extremeprogramming.org 

XP doesn’t establish fixed roles for the members on the team, because the main purpose is to achieve the success through the skills each one have to offer. Fixed roles could interfere on the goal of that each one have to do its best. Although they don’t have a fixed role, I’m gonna write bellow a brief of the responsibilities of some of the members of a XP team.

Project Managers

Project managers are the bridge between the team and the customer. They ensure the communication inside and outside the team – so they act like a facilitator on the communication of the project, and ensure the customer attendance on the planning meeting, as well as a prompt communication.

They also monitor the team progress, and also motivate them by seeing the quality of the product they are developing. For this, project managers must do an external pressure and communicate what is happening for all the engaged members on the project.

Product Managers

Product managers define stories which help the product to be coherent and harmonic, as well as define priorities and make some clarification all over the project and reduce the scope when the team is late for some reason.

Users

Help the team to write the stories and to make decisions about the project domain. They are important because they have the domain of the business, and should contribute with the project with the experience acquired on the last projects. In XP projects the customer is involved all over the time, giving feedback in order to ensure the correct implementation of the functionalities that could generate values for the organization. 

In XP projects, the customer satisfaction and his feedback is more important than lots of pages of documentation and all the bureaucracy. The customer is present on the project since its start until the end, working together the team, giving feedback and defining the requirements not all at once at the beginning, but for each iteration, ensuring the possibility to changes on the project even late.

Agile, in a brief

Agile is a set of best practices which are used on software development in order to improve the quality of it. Among these practices, we could mention eXtremeProgramming (XP), Kanban, Scrum etc. 

We can use these practices together, or even combine just some of its directives. Agile methodology has a flexibility that it’s hard to find in another techniques, like Rational Unified Process (RUP), for example - while XP doesn't need all of the RUP artifacts.

The foundation of Agile came from the Agile Manifesto – a meeting where some software developers experts, like Martin Fowler and Kent Beck wrote a document defining approaches for agile software development. Based on it, were established the twelve principles behind Agile Software.

Agile, in a brief, values the simplicity, the quality of the software, small and continuous releases, as well as the customer working together release by release, to ensure the “this is what I really wanted” in the final of the project.

I'm gonna give a specific focus for these practices in another posts, as well as establish a comparison between them.

Agile Resources

Follow bellow some resources that I’ve read to learn about Agile. This is a great way to get start! Enjoy!

Books

User Stories Applied for Agile Software Development

The Agile Samurai

Related Sites

        1. Agile Software Development

        2. Agile Manifesto

        3. AgileJournal

        4. IBMRational e-book: Agility@Scale

        5. ModernAnalyst.com  
        
        6. Agile Software Development - A Gentle Introduction


       

A report about what had changed since the use of Agile

First of all, I’m gonna write about how the project I’m working was conducted  until I've started to learn and use some agile practices, and what had changed since then. 

The purpose of the project I'm working on is to develop a framework to spread forecast data through Web Services, in a easy way to provide answers for the frequent asked questions made by the people interested (TV channels, universities etc.). My project started on January 2010, as usual, with lots of work. In the beginning we had to set all the development environment, like the application server, IDE, DBMS to be used and so on. None of our tasks were organized, prioritized as they should be. We had lots of work, but not an established deadline, defined responsibilities or some point that gives us a right way to follow, a sequence to do the tasks. Additionally, the code we wrote was full of bugs (mainly because the design and lack of tests TDD) had lots of bugs and the classes had lots of useless methods. I had just a little experience with software development that time, and a basic knowledge with programming; that’s the reason why I didn’t get start since then to use good practices to make my project better. 

I have worked with some senior developers which give more value to the quantity of work than the quality of it…So, in these situations, the product is a code non tested with lots of defects (until now it’s been hard to make their minds to use a test suite in order to reduce the bugs and improve the quality), non established goals (like a unknown amount of work for a long term) and a non continuous integration environment (which results in troubles and unnecessary work on the time to deploy). 

By using some of the agile best practices, like making a list of deliverables, setting deadlines, priorities, working in pair and using the WIP (Work in Progress) limit (from Kanban template for software development), we had some improvements that make our work more organized and productive, besides it has helped us to have more focus in our activities. 

My goals for the next year are to set up the continuous integration environment and our test suite to do some user acceptance tests (UAT), now to improve the quality of our final product.

Just to get started

I confess I’m a little bit afraid in starting to write a blog to talk about an subject I’m studying and discovering day by day, but I found this way to share the knowledge that I missed when I didn’t know anything about Agile.  Because I’m not an expert, my intention here is to introduce some basic topics and concepts, for a better understanding and a first light to get use Agile, and also show you the difference using the traditional software development and agile software development, through practical examples.