by: Christine Swartzendruber, Chief Technology Officer
In an effort to improve my team’s development process, I’ve begun researching some of the implementations used by others. After reading posts on twitter by some of my favorite web development experts, I came across an article on a methodology known as Extreme Programming.
Created as a solution to the problem of specifications that are always changing, Extreme Programming is a way to respond to changing requirements and technology. In the process, customers enjoy being partners in the software process, developers actively contribute regardless of experience level, and managers concentrate on communication and relationships. The theory is that the way a team works together is far more important than any process.
I have chosen a few key features and processes used in Extreme Programming, that I think could benefit my team:
Written by the customer as things that the system needs to do for them, user stories are the best way to begin collecting specifications for the project and can be used throughout the process as well. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customer’s own words without high-tech language. A user story should not include database design, GUI specifications or design layout. The story should only include user needs in the simplest terms.
One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications. The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face.
Developers estimate how long the stories might take to implement. Each story will get a 1, 2 or 3 week estimate in "ideal development time". This ideal development time is how long it would take to implement the story in code if there were no distractions, no other assignments, and you knew exactly what to do. Longer than 3 weeks means you need to break the story down further. Less than 1 week and you are at too detailed a level, combine some stories. About 80 user stories plus or minus 20 is a perfect number to create a release plan during release planning.
A Release Plan specifies which user stories are going to be implemented for each system release and dates for those releases. These user stories are then translated into individual programming tasks to be implemented during the iteration to complete the stories.
A release planning meeting is held for the development team. Following is a check list of tasks that should be completed at this meeting:
**Things you will need for the meeting: dry erase board and markers, blank white paper, a calendar.
- Ask for a helper, someone who writes very clearly. Have that person copy the final results on the board to a blank white paper.
- Have the group write their user stories. Pass out three index cards to each member of the team. Explain what a user story is, and ask them each to write three things that they would like to see completed in the development process.
- Use a large white board to organize the user stories. Make three columns on the board: 1 WEEK, 2 WEEKS, 3 WEEKS. Write each user story under the appropriate column, choosing the amount of time closest to how long you think development will take. If there are user stories that will take longer than 3 weeks, break them down into smaller stories.
- After all of your user stories are on the board, give each item a priority number, and a potential completion date (include testing).
- Schedule potential release dates. Based on the user stories and your priorities create a series of release dates, the first should be when you have enough of the user stories complete to publish development, and then each subsequent release date after another substantial portion is complete, etc… until the entire development scope has been scheduled.
- Assign user stories to your teams of two programmers. (see pair programming below)
One of the key team concepts, pair programming, is the idea that no one should code alone. By passing the keyboard between two programmers, the code is reviewed by at least one other person, and results in better design, better testing, and better production software.
One of the most valuable members of the team is the client. That’s right, a representative for whoever has hired the team to produce the software or deploy the web site, is present during all phases of development working with the team on a daily basis, providing constant feedback and current requirements.
Collective Code Ownership
On an Extreme Programming project, any pair of programmers can improve any code at any time. This means that all code gets the benefit of many people’s attention, which increases code quality and reduces defects.
Stand Up Meetings
Short meetings held each day first thing in the morning, where members of the team communicate problems, solutions, and promote team focus. Everyone stands up in a circle to avoid long discussions.
During a stand up meeting developers report at least three things; what was accomplished yesterday, what will be attempted today, and what problems are causing delays. The daily stand up meeting is not another meeting to waste people's time. It will replace many other meetings giving a net savings several times its own length.
Design in Extreme Programming is not a one-time thing, or an up-front thing, it’s done throughout the process. It starts simple and through the testing and improvement phases it stays that way. The team keeps the design exactly suited for the current functionality of the system. The framework is scalable and always ready for what comes next. In an incremental, iterative process like this, good design is essential.
Over the course of the project the team uses a concept called refactoring which focuses on removal of duplication, and on increasing the cohesion and lowering coupling, which is the degree to which each program module relies on each one of the other modules.
All code must be written to agreed standards. Coding standards keep the code consistent and easy for the entire team to read and refactor. Code that looks the same encourages collective ownership.
Never Add Functionality Early
Do not code or create specifications that have not already been laid out in the user stories and design/development process. Keep the system uncluttered with extra stuff you guess will be used later. Only 10% of that extra stuff will ever get used, so you are wasting 90% of your time. We are all tempted to add functionality now rather than later because we see exactly how to add it or because it would make the system so much better. It seems like it would be faster to add it now. But we need to constantly remind ourselves that we are not going to actually need it. Extra functionality will always slow us down and squander our resources.
Keeping your code ready for unexpected changes is about simple design. Adding extra flexibility beyond what you need now always makes a design more complex. Turn a blind eye towards future requirements and extra flexibility. Concentrate on what is scheduled for today only.
Making Small Releases
The development team needs to release iterative versions of the system to the customers often. Some teams deploy new software into production every day. At the very least you will want to get new software into production every week or two. At the end of every iteration you will have tested, working, production ready software to demonstrate to your customers. The decision to put it into production is theirs.