 |  | |
 |
 |
 |
 |
|
|
|
|
|
The Development Process
12 core practices
http://c2.com/cgi/wiki?ExtremeProgrammingCorePractices
We will now take a look at the individual practices, detailed information and debate on all of them is available on the c2 wiki http://c2.com/cgi/wiki?ExtremeProgrammingCorePractices.
Test Driven Development. we write unit and acceptance tests before we write code. Our Acceptance tests are for both UI interaction and domain correctness. This gives us a great degree of confidence, both in the new code we write, and that changes we make have not broken old code.
The Planning Game. User stories are created for the next release by the customer team and placed on index cards. They are then scored by the development team, the customer team then chooses and prioritises the cards for the next iteration. A project/release is made up of multiple iterations.
Customer Team. Have a real Customer (onsite customer) available to answer team questions in the same room as the development team. The role may however have to be filled by several people due to practical considerations and the amount of work involved. In 3Q we have a primary onsite customer, but consider the interaction design time, sales and marketing to collectively make up our Onsite Customer Team. We like to keep as many of these people in the same room as our developers as possible.
Pair Programming. 2 Programmers at one workstation for any non trivial development task. One Driver (has the keyboard) and one navigator.
Continuous Integration. We build our entire source base every 60 minutes, we will show you the 3Q Continuous integration process in detail shortly.
Design Improvement. This is the refactor portion of Test, Code, Refactor. We refactor (Improve the design of our code) as we work. This is as much about throwing out old code as it is about improving it. It's also a no broken windows philosophy in action.
Small Releases. We release working installers to our customers on an hourly basis. Each of these installers should be bug free, but not complete (until the last one). Bugs which do creep through our automated tests get a high priority to try and remove them before the next installer is generated. Our interaction design team checks theses releases up to several times a day.
Simple Design. Do the simplest thing that can possibly work, and obey the YAGNI (You ain't gonna need it) principle.
System Metaphor. A shared story of how the system should work. Shared vocabulary for describing the system. A means of keeping everyone on the same page.
Collective Code Ownership. Code belongs to the project not to individual developers. We don't have a web guy or a database guy. Everyone works on everything. Pairing helps spread knowledge. Collective ownership prevents hold ups because Joe is out sick.
Coding Standard. We have a coding standard and we stick to it. It should be impossible to tell who wrote a particular piece of code. Helps with collective code ownership as everyone can read any piece of code as easily as their own. I tend to forget which parts of the codebase I have and have not written.
Sustainable pace. We work a 40 hour week, we do not do death marches. Code written when tired is never up to scratch and broken windows creep in. The absence of boom and bust death marches makes planning more reliable. Of course you could just stick with heroic death marches and have the guy in the picture write your code....
We are not going to be covering the basics of continuous integration. We are assuming you all have working ant build scripts, a source control system, and a continuous integration tool like cruisecontrol, anthill, luntbuild or something similar. If you don't I can recommend reading the pragmatic starter kit, which will bring you fully up to speed. If you have no idea what continuous integration is, don't panic, I'm going to start off by walking you through our existing setup.
Automating delivery, meaning having the automated build produce a fully functioning, burn tested installer solved out problems with delivery time and confidence. The finished installer is automatically uploaded onto the company intranet, allowing our customers to try out the application several times a day and constantly provide us with feedback. We still need some manual testing for builds that reach the hands of end users, Chiefly platform testing. But we are working on automating a lot of this as well. The next big step for us is to automatically install the application on the customer teams machines as part of the build process.
The customer teams relationship with the developers became far more proactive. Rather than approaching us for status updates they where now providing corrections and updated stories. The development team now spends a minimal amount of time deliberately updating the customer team. As the build rarely produces a broken or non-functional product. The confidence level both the customer team and we have in the build has increased enormously.
While the automation of delivery gave our customer team a lot more information, a lot more could still be done. The customer team knew the status of the products at all times. But where still missing a lot of the big picture. How are the development team performing, are there any problems, how far through the current iteration are we? Yet again we automated passing this information to the customer team
The particular tools we used to accomplish this are referred to as Information Radiators. Information radiators are environmental sources of information. The information is pushed rather than pulled. The most common information radiator, which almost every XP team will be familiar with, is the card wall. Everyone who walks in the rooms can see how many cards are on the wall and get a sense of progress over time. Other tools we use include build monitors, systray applets, our intranet and several other toys.
The goal of using these tools is yet again to allow your customer team to become more proactive and reduce the communication burden on your team
|
Here you see the build monitor as it is situated in our offices. The important detail here is that it is right beside the coffee machine, the fridge, and the exit. This guarantees that everyone in the company walks by it several times a day. Our customer team begins to notice if the build has been broken for a long time, or velocity has been static for a while by osmosis. They don't have to actively seek out the information, they are bombarded with it. While they might not consciously look at the data, they become accustomed to it's natural rhythms and are quick to notice when the screen fails to match them
Simple Python GUI that dumps card details to MySQL |
In order to radiate all of this information, it has to be gathered. In the case of the build status, this is pretty simple. We simply collect the data from the build in webserver included with cruise control. As far as our velocity goes we use the simple tool above. In the past one of the developers sat down 2 or 3 times a week and put all of the data into an excel spreadsheet. This was a poor solution. It was a boring thankless task, and for the most part no one ever looked at the spreadsheet. The solution was this little tool. Every time a developer finished a card he takes a few seconds to log it's details. The app launches from the system tray and dumps the data into a database. It took only an hour to write the python script for this application. The end result is a source of raw data for tools like the burndown to use, and a very low cost when it comes to collecting the data.
A Simple PHP site to display and manipulate the Database of logged cards. This was coded over a few lunch breaks. |
For management and mining of the data we created a simple PHP site on the intranet. The burndown charts are simply part of this site. It also provides us with an ability to easily view the results of past iterations, allowing more accurate estimation.
http://www.3q-solutions.com/XPE/ |