Extreme Programming to go for another level
The Extreme Go Horse bulletproof guide
Agile methodology has significantly increased its presence in companies led by the IT sector.
The main reason is its capacity to deal with changes in the middle of a project.
If you know something about agile methodology then you have heard of Scrum, the primary method chosen by the market. Maybe you even consider Scrum and agile methodology as synonyms.
Let me introduce you to another great one that you should be aware of. The Extreme Programming method.
Overview
Extreme programming or XP for the closest is a bunch of good practices that you should apply in your company.
Pretty close to what is The Extreme Go Horse (XGH) guide, but the XP put you in the opposite direction. And as its name suggests this methodology focuses on software development teams.
It was created by Kent Beck, who is one of the 17 original signatories of the Agile Manifesto.
The 5 Principles
Communication
The XP is recommended for teams between 2 to 10 members. Teamwork is important and is required.
Low centralization of information. Questions and problems are solved more quickly when spread. Encouraging interaction between people is a good thing and leads to productivity.
Simplicity
- Watch out for overengineering
- Focus on the problem
- Work on them in baby steps.
- Do just what is asked for
Aren’t these some common advice that we hear when we are juniors? =)
Feedback
This kind emphasizes the communication principle. Hear the most, work much and talk little.
Courage
Say “no” to changes are as important as saying “yes”. Pointing problems, changing the project's direction, disagreeing when necessary… hard things, but necessary.
Respect
This is the basic, without it we even couldn’t be called professionals.
The Practices
Extreme Programmers implement most of these practices. Note that some of them can’t be directly applied to remote jobs.
Implementing all of them is not required.
The practices can be divided by the steps of the delivery process.
- Panning
- Managing
- Designing
- Coding
- Testing
Planning
User Stories
User Stories are detailed content about a given task. All user stories should be written e published on a common field where everyone can see them.
Iterations
Like most agile methodologies, work on an iteration model, these iteration also can be called sprints. Small iteration for 1 to 3 weeks between each delivery.
Planning Iterations
At the beginning of each sprint, the team needs to make the “planning game” which is brainstorming with the client that results in the user stories.
After that, the team estimates the cost and time to implement each feature.
Finally, the client prioritizes the tasks. With all that we create or update the project’s backlog.
Release schedule
Plan how the releases gonna work, when they will be publicized, and which feature has in each release.
Small Releases
Releases are better managed when small. That leads to quickly found errors and accurate feedback.
Managing
Open workspace
Create an environment that encourages communication, and lets the work office be comfortable and without barriers between the desks. Give the team a whiteboard to express themselves.
Stand-up Meeting
Keep communicating but make it quick. In a meeting let everyone stand up so they will want it to end fast. About 10 to 15 minutes is ideal.
Sustainable Pace
There’s nothing like “let’s speed up the project now…”. From the beginning, create a sustainable routine for the team.
Something like 8 hours of work per day is great. Programming and communicating are hard tasks, we need rest to keep focused.
Project velocity
Keep the track of the project’s velocity. It can be measured by the number of tasks delivered.
Sometimes the team will ask for more tasks because they will end up the iteration tasks faster than expected, and sometimes tasks will be not done in time.
Move people around
Changing the acting areas of each member avoids the centralization of knowledge and improves communication.
Fix XP
Do not hesitate to change things when they do not work well. Have retrospective meetings to find what is not working.
Designing
Use CRC Cards
Class-responsibility-collaboration (CRC) cards tools to design software that helps people to have more object-oriented thinking.
Simple Design
Simplicity principle. Always start with the most simple version each system features.
Metaphor
The client can have no technical knowledge, so be prepared, and use metaphors if necessary.
Have empathy! “Fast” and “safe” can have different meanings for a lawyer and a programmer.
Spike solutions
A spike solution, or spike, are quick sets of experimental tests to find the cause of a giving problem.
No extra features
Focus on what the project needs, It’s tempting to improve a feature that you like, but most of the time it will not be used. So focus on following the planning.
Coding
Customer Always Available
Customers are an important resource of information. Let them know that they will create the product with us. Questions and feedbacks are quite usual.
Pair Programming
The team is divided into pairs, usually someone with more experience and a newbie. Each pair will work on a user story.
This practice encourages communication, decentralization of information, and the leveling of technical knowledge.
Coding Standards
The code needs rules! Create an environment where each dev member can easily understand the friend’s code.
Integrate Often
As soon as a new feature is ready, submit a merge with the base code. Keep everything updated! This can avoid unnecessary code conflicts.
Integrate one code per time
New tasks can contain conflict code with each other, because of this just one team deliver the task at a time, and the next team must guarantee a working code with the last merge.
Dedicated integration computer
Just one computer to deploy the release. It works as a flag to everyone know that a release is been published and who is releasing it.
Collective Ownership
Everyone has editing access to the code. This practice is to make everyone aware of the code’s state. But do not forget to review the changes submitted.
Refactoring
Always that is possible, try to improve the code quality. Continuous improvement of the system. Nothing is so good that can’t be better. Easier to say than make. Changing a working feature requires courage and professionalism!
Testing
Acceptance Tests
Create tests that guarantee each delivered feature. The client is fundamental to designing these tests. This will help us to keep the software’s quality assurance.
Test Driven Development (TDD)
Work driven by the tests. This means creating the tests before the feature implementation. This will help us to think before acting.
Unit tests
All code must have unit tests for it. Code without tests should not be released.
Tests for bugs
Where you find a bug, a test is created. This will assure that it won’t come back.
CONCLUSION
Extreme Programming is a cluster of practices that a software development team should consider adopting.
It’s not exclusive to other agile methodologies. For instance, can be integrated with Scrum and Kanban.
Some of the practices like TDD and Pair Programming are hard to use and it's recommended to have an extreme programmer by your side when implementing them.
Are you interested in agile methodologies? Check out my article about the 5 most common mistakes for agile teams.
If you want to read more of my thoughts and programming tips, then check out my articles and follow me for upcoming content.
