Extreme Programming is a term that refers to a software development methodology in Agile Development to implement a product and is aimed to improve code quality, and quality product delivery There are 12 major development practices that make up extreme programming.
Pair Programming – Code is produced by two programmers working at one workstation.
Planning Game – The meeting that occurs once per iteration and focuses on Release Planning and Iteration Planning and is aimed to guide the product into delivery
Test Driven Development (TDD) – Write a failing unit test first, then code and pass the test. Refactor as needed. Also called red-green-refactor.
Whole Team – The customer or end user should be a part of the team (or be on hand) to answer any questions or clarifications during the process of product design and development.
Continuous Integration – The developers should always be working on the latest versions of the software, thus they should commit the code often for other developers to obtain. Integration of the code should happen frequently.
Refactoring or Design Improvements – With TDD of eXtreme Programming, the design and development is kept simple and the coding is done based on what is known at that time, not designing for potential future changes. As the future requirements are known, designed and developed, the refactoring is done frequently to adjust the latter changes to produce a better piece of software.
Small Releases – Releases are done frequently, thus making them smaller and providing a chance to obtain feedback from the end users. The released product should provide some value to the customers.
Coding Standard – Developers follow coding conventions either obtained from programming language standards or defined by the team. Those conventions and standards are followed. Static code analysis tools like checkstyle can enforce that the teams follow coding standards.
Collective Code Ownership – Everyone is responsible for the code. Anyone can modify any part of the code. If developer pair A introduce some errors to the product, developer pair B can and should be able to modify the code to fix the errors, not just depend on pair A to go back and make the changes.
Simple Design – Always ask a question, can this be done in a simpler way? If so follow the simpler way of doing things. Find any existing complex code, feel free to refactor them in order to make them simple. Simple designs are understood by other team members and any future developers.
System Metaphor – Name you methods, variables, classes in such a way that even non programmers (e.g. customers, managers, product owners) can at least say how the system is working – for example by looking at the class diagrams or sequence diagrams.
Sustainable Pace – The development process should not take you extra hours to complete or deliver. It can occasionally happen from one iteration to another but should not repeat in most of the iterations. Simply designed, continuously integrated, thoroughly tested application should be easy to maintain without getting into complex situations where it needs your over time.
Having worked for several years in an agile development, I thought I would jot down some of the best practices that each developers should follow. This list is somewhat influenced by one of the agile survey I had to fill in to help a student.
Don’t fear to simplify the existing code where necessary – without changing the functionality.
If you see existing complex code, don’t fear to simplify it.
If you see redundancies in the code, don’t fear to eliminate those by doing a code refactoring.
Use pair programming – although pairing does not improve the productivity on the short run, it increases the code quality which means less of maintenance on the long run.
Do a continuous integration of your new code with the existing code.
Continually integrate your code with your co-workers code.
Always write and run unit tests – don’t just run your unit test – run all other existing unit tests. Get actively engaged in unit testing. Change your mindset about unit testing if you have to. It’s a good thing.
No-one owns the code. Or in another word, everyone owns it. Anyone should be able to change the existing code at any time without the fear. They should not be running around seeking permission from the person who wrote it originally.
Different developers have their own style of writing and unit testing code. There needs to be a set of agreed upon coding standards in your team. This helps maintain the uniformity of the code and helps those who maintain it (could be yourself !).
Have your teams co-located. It saves a lot of time and produces a good collaboration. All the members including developers, testers, requirement analysts, product managers, automated tester and if possible release managers should be co-located. Some companies have seating arrangements made to suit this co-location and open collaboration.
Retrospectives are important. Not only they help you celebrate on good things you did, they also give you opportunity in gathering lessons learned and things to be improved. They help you and your team become aware of things that you did well in the pas iteration and helps plan or take action on things you should be doing in the future iterations to improve.
Not all the items from the retrospective can be improved all at once. Pick the top three to five items and assign responsibility to individuals. Even though the work might have to be done by the whole team, assigning responsible individuals helps to track the progress, to follow upon and to enforce the action on those action items.
You customer should be reachable if not co-located. Having a reachable customer helps you get answers to your teams question as well as feedbacks quickly. Some companies allow the developers to contact the customers directly or through a customer contact person without bureaucratical hurdles. There are some companies who are picky on the communication protocols with the customers. In the team that I work on, our product owner is also the point of contact to reach out to customers with questions and request for feedback. If you have a contact person, it’s a good idea to have them get the responses from customers in a timely manner.
Have a show and tell after each iteration to get feedback from the stakeholders. The earlier the feedback, the better it is to make improvements to the application while it is still fresh on team’s mind.
Have you daily scrums or daily stand ups short, and focused on the purpose of the meeting. Don’t sway away into discussions that are not needed at the moment. If you have things to talk in detail on certain topics, put those on a parking lot and discuss afterwards with a subset of related people. Don’t kill everyone’s time by brining in irrelevant topics during daily scrum.
Although various companies and their agile teams might use their own “agile” format of story writing, a very popular and common way of agile story card writing is to follow three lines that mentions who is the user, what the user wants to do and what is the business value of doing that action or achieving that goal.
This is in sharp contrast to most of the waterfall model requirements writing where most of the time the requirements are written with System of Application in view rather the users in the view. It’s not uncommon to see those waterfall model requirements to be documented as “System shall…”.
One of the reasons behind the success of the agile model of programming is the care for the user role and the business value more than the waterfall one (despite the pros and cons of each type).
The diagram above shows a typical format of a agile story card.