As programmers, we should all be familiar with the object-oriented concept. Just in case you’re new to this, here’s a very quick summary of what it is: before starting anything (analysis, design or programming) you should get used to looking at everything as an object. An object has a set of attributes that describe it, and a series of methods that it can perform. The trick to mastering is being able to identify what identifies an object, and what an object is good at doing. That’s a really brief explanation, but I’m guessing it should be enough to help you understand this. If not, I recommend reading some more about it before continuing.
Agile refers to a methodology of software development that appeared after the infamous “Waterfall Methodology”. The general ideas of Agile Software Development are expressed in the Manifesto for Agile Software Development (available here: https://agilemanifesto.org/)
Agile begins with the user in mind. To represent each kind of user, we create what we call “personas” in order to represent a general customer description, with specific needs and a particular behaviour towards our program. To make sure that the project follows the right track, we have a product owner, who makes sure that the project works well, and keeps track of the progress of each team of developers.
This methodology arises in the 1990’s because of two major events. The first one was the “new” object-oriented programming paradigm, which was replacing the old procedural programming as the favoured paradigm. The second one was the rise of the internet. This caused requirements to rapidly change, resulting in sorter product life cycles, which was incompatible with the traditional methods for software development.
There are various versions of the Agile Methodology, but as mentioned earlier, they all share the same philosophy, made explicit by the Manifesto for Agile Software Development. These are some of the versions of Agile:
One of the most popular Agile frameworks, this version focuses on sprints, which are small sections of the whole project.
Each sprint has 3 major parts:
- Planning priorities
- Deciding which user stories can be achieved
- Daily meetings to communicate updates
After each individual sprint, the team shows the new functionality of the project, as well as a report of what was achieved during the sprint. The team then gets feedback from the product owner, and they discuss what can be done to improve the final delivery.
In Extreme Programming, we intend to improve software quality. Frequent releases in short development cycles are encouraged. We use checkpoints that allow us to have a better idea of when to add new customer requirements.
Pair programming is also a big part of extreme programming. With this, we have two persons looking at the same code. One is highly focused, while the other is looking at the bigger picture. This helps developers have a better idea of where to look for bugs.
Last, but not least, constant communication between client and developers is one of the most important aspects of extreme programming. With this, we make sure that the client is always on board with the decisions made by the team, and that all requirements are being fulfilled.