Principles of XP
XP is based on 4 basic ideas or principles.
To simply explain the 4 values. XP programmer communicates with clients and fellow team programmers to gather requirements and create tasks. Based on solid communication they strive to create a simple and efficient design for developing the software system. After designing, they conduct tests on all the use cases even before starting the development process. This enables them to introduce a very very early feedback system. Now with requirements chalked out correctly(communication), simple design in place(simplicity), and with early feedback system in place (test driven development) XP programmers embark on their software development journey without any fear and full of courage.
XP Core Practices
As we know that XP is an agile process. Apart from adopting common agile practices XP defines 12 of its own core practices.
- Whole team in one place – This means that whole team including developers, designers, project managers and the client work together in a common room. One member from client team who is expert on project subject matter is always present on the team premise. This results in enhanced communication where doubts of developers gets resolved quickly. They can create their test cases quickly and get instantaneous feedback.
- Small and frequent release – XP as any other agile process advocates small and frequent release. The release time is usually 1- 3 weeks. Small release have many advantages the main one being – client gets to see small features after every release and can run acceptance tests on them and thus create a very early feedback loop. As number of features per release is less, it reduces pressure on development team . An easy and steady development pace is established from very beginning which is good in long run.
- Testing – XP puts great importance on testing practices. Each task within the XP project must be unit tested. XP follows practice of Test Driven Development. After delivery all the features must have an acceptance testing. Each test must have binary result i.e. pass or fail. The tests should be automated and run with little or no human intervention. The acceptance test cases are written by customer themselves which are later automated by testing team. This ensure the product development as per client wishes.
- Release Planning Game – Goal of planning game is to capture the scope of next release. It usually takes half to one day to complete the Release Planning Game. In this process the customer writes Story Cards to describe the feature they wan’t. Based on the story cards developers then create a task list and provide estimates on how soon they can complete the tasks pertaining to Story Card. The pending story card from prior release is also considered in mix.
- Iteration Planning Game – With all the story cards and estimates present, the client decide which stories will be delivered during next release. Client can choose number of cards that can be delivered within a fix time frame. Or they can choose a fix number of cards and come up with release date based on these stories. Once the story cards are decided developers are asked to volunteer for tasks they will be taking up.
- Simple Design – XP advocates to avoid speculative designs based on possible future changes. XP also avoids designing any elements which are not to be delivered in current or near future release. The XP design promotes code re-usability and minimizes number of classes to be written.
- Pair Programming – All the code in XP are written by set of two programmers on a single computer. Pairs may change frequently with each task. And since in one single moment only one programmer can write code. The other programmer is constantly code reviewing, thinking about unit tests. XP claims that this practice improves productivity through peer pressure and constant review. This also promotes learning and reduced defects and procrastination.
- Frequent Refactoring – Since XP work with simple design and small iterations thus design of system is constantly refined to ensure it meet the specifications. Thus there are lots of refactoring involved in XP.
- Team Code Ownership – As we have seen that XP follows pair programming practice. The pairs often change and hence each person in the team gets to work on all the part of system. Hence the code is owned by entire team and not by few. This makes the entire team more efficient as anyone can step up and work on the any code issue and individual dependence reduces.
- Continuous Integration – The committed code is continuously integrated with main code, compiled and unit tested on a separate machine. Later on application is passed though battery of acceptance test. This loop of compiling, unit testing, acceptance testing goes on all the time and is autonomous.
- Sustainable Pace – Over work may create unhappiness within the team. Thus XP promotes no overtime practice.
- Coding Standards – Since all the developers work on all the parts of code hence it is easy to follow same coding principles and even style.
- System Metaphors – A large system will contain lots of subsystems, code templates etc. To make communication between programmers easy XP encourages team to come up with jargons for various subsystems.
So now we are equipped with core principles and practices about XP. Now let us find out how all of this fit in a XP product development life-cycle. Describing everything in details will take a book (and frankly I am not that knowledgeable) so I will just list out the steps with small amount of info.
- Exploration – Like any project, XP product development starts with an exploration phase. The customers write down general story cards explaining his requirements. The developers provides with a rough estimate and game starts.
- Release Planning Game – The customer and developer gather in one room where discussion takes place and then customer comes up with the story cards. The story card is handed over to developers. Developers break the stories into small tasks and provides their estimation for each of the story cards.
- Iteration Planning Game – The Customer then takes on all the story card and chooses which story cards will be worked upon this release. Based on story cards chosen, a task list is created and tasks are assigned to a pair of programmers. The task list also decide the time frame for the release. The time is chosen such that developers are not taxed overtly. Iterations forcing developers to overtime are never encouraged.
- TDD – Developers then create test cases and then write the code.
- Continuous Integration – The code is committed, unit tested, deployed and acceptance tested.
- Production Release – As the iteration is time boxed the code is released to production on fixed date. The tasks that remains are transferred to next iteration.
- Patch – If there are minor bugs in production code then they are fixed as part of patch release using the steps defined above.
- Relax – Generally a small time is given to developers to relax between two iteration.
- Start with next release
In this post we explained that XP is an agile methodology with a team related focus. XP team comprises of client, programmers and managers. Then we went on to enlist the 4 principles of XP i.e communication, simplicity, feedback on courage. These principles forms the foundation upon which whole of XP structure stands. Then we went through XP practices like pair progamming, team in common room. release and iteration plannings etc,
But like any other method it has pit falls. XP promotes a myopic view on upfront design, this may while save a lot of time upfront may also result in major design changes in future. Major design changes means lots of re-factoring which in turn increases project cost in terms of time and money. The pair programming is the most important practice of XP but lot f developers are reluctant to be part of pair team.
All in all XP is a pretty powerful method. It is often found that XP practices are used in conjunction of other agile methods like scrum and evo to create a more versatile methodology.
This is my first post in this year and phew it was hard. I though I will start with an easy non code post, but boy it turned into a marathon. I hope that you like this post and would drop some comments (my wishlist) to encourage me in writing more posts. 🙂 Untill then