The next phase in a typical WUP project is the development phase.

The start of the first increment

An increment starts with a couple of kick-off meetings with the whole team. The seniors know what the functionality is about, since they estimated the PPD’s, but the rest of the team must be filled in about the details. The functional decision maker presents the use cases for the increment; the technical seniors educate the rest of the team about the procedures if they’re not yet familiar with them.

It is advisable to have the team members picking the use cases that they would like to build themselves. In doing so, the team members will have to build the things that they like to build, and they are individually responsible for their choice. Obviously, there will be some use cases left that have to be assigned.

So, every developer signs up for a couple of use cases. This will result in use cases being designated technical, design or content use cases, or any mix of these components.

Since every team member is present at these meetings, it is clear for everybody what the product will look like at the end of the increment.

At this point in the process, we’re ready for some coding!

Stand-up meetings and the wyteboard

During development, the project manager and the functional decision maker organize an informal meeting, every morning at the work place. During these stand-up meetings the use cases and stories with highest priority are written on a wyteboard, preferably by the functional decision maker.

While the wyteboard is being filled for the day, the whole team is present and can react to changes in the requirement schedule immediately. The functional decision maker and the project manager can update their functional inventory; that is, since all developers are present, it will become clear what’s built and what’s not built from yesterday’s requirements.

The wyteboard must be visible at all times for the whole team during development. This might sound rigid, though the wyteboard has a central function in the process.

Next to the specified daily use cases the name of the responsible developer is written. When he has finished the specific use case, the developer simply points that out on the wyteboard and moves on to the next use case.

The daily updated wyteboard makes sure that even the smallest changes in requirements are picked up directly by the whole team. If anything is not clear, the functional decision maker can explain the difficult parts directly.

When monitoring the team’s progress, it is inevitable that use cases are switched from one developer to another at a certain point in the project. When names are changing for a use case, this will become clear in the stand-up meeting and pointed out on the wyteboard too.

It is key to keep communication direct at all times: so please let the whole team work together in one room, so that everybody can see the wyteboard!

Database- and stored procedure scripts

Although this is not directly an essential WUP feature, it is highly recommended to use database- and stored procedure scripts instead of fiddling around in database client software. During the development phase, these scripts have to be updated continuously.

If something goes wrong with the project database, you won’t have to rely on the accuracy of your system administrator to restore your database. Secondly, scripts are usually a necessity during deployment.

During development, every change in database or stored procedures has to be applied using the scripts instead of client software. This is the only way to ensure that developers keep the scripts up to date.

Automatically generated scripts are usually a mess, so you can’t rely on them, since the script has to be readable for any new developer joining the team. Manually changing the scripts demands a higher level of knowing what you’re doing anyway. The comment lines are a necessity too, to keep track of every change, since every developer is responsible for the scripts but also has to work with the resulting database.

It is advisable to assign one of the technical developers to be the script controller. He is not responsible for the contents, since every individual developer is responsible for his own changes, but he is Big Brother in database world.

Once a week the scripts are used to recover the database in a separate environment. A script from this recovered database is generated and compared with the generated script from the development database (it’s easily done using versioning software, usually). These scripts should be identical, and if they’re not, there’s a problem. If they are identical, tag a backup of the manual version for the current date and keep on developing.

Releases

During development, releases have to be done for every independent part of the system as often as possible. This could be just internal releases, for testing purposes, but it is advisable to have the customer looking over your shoulder too.

To facilitate these releases, the entire team (and this means entire as in including project manager, functional decision maker and event the designers) has to use a versioning software package. Within this kind of software versions of code and design can be labelled for a specific release number. If this is done consequently, the revision history of the whole project can be reconstructed whenever necessary.

Every release has a test procedure. As many tests as possible have to be automated instead of manually performed. For details on possible test methods, read the test manual and the test template document by the same author.

WUP Programming

The next set of rules should be taken into account in a WUP project.

• Collective code ownership
  All code is accessible for every team member. ‘Your own code’ does not exist! This makes all code the responsibility of every team member, and works as a control mechanism.
• Code conventions and version administration
  To make the rule of collective code ownership work, every programmer must apply the rules of the company’s code conventions, must document his code thoroughly and must use the versioning system.
• Simple design
  Code is simple when it reflects the physical reality (that is, when the code uses logical steps to get to a solution; and remember that logic is more important than technical efficiency!).
  Important is that clear, complete names are used for variables and that the code is logically structured, all according to the code conventions. Also, the source cannot contain double code!
• Refactoring
  Software entropy demands software to gradually become a total mess as new functionality is added. To prevent from this old code should be rewritten and enhanced constantly, even if it already works. This is called refactoring. If you don’t redesign the program constantly, functional additions will become more and more complex and thus cost more time and money!
• Development infrastructure
  The application should be developed, tested and deployed during the project within an infrastructure that is clear to every team member and the customer too. Everyone must know where to find which part of the application at any time in the project. This demands a standard infrastructure, like the one described in infrastructure specifications .
• Pair programming
  If the size of the project is large enough, two programmers could work together behind one screen. This prevents code from becoming messy, keeps the programmers focused and last but not least, it’s more fun! The RSI monster doesn’t like pair programming, either.
  In the best case, programmers should switch pairs at least once a day.

Testing

All kinds of testing methods have to be performed continuously during development and releases. Especially for testing the business logic layer, automated test procedures have to be written. Don’t wait with this until you’re ready for testing, but start with the test classes right away.

Functional testing procedures have to be determined by the functional decision maker, based on real-life business scenarios. In practice, these scenarios are the use cases in reverse mode: stated as a question.

GUI (Graphical User Interface) testing does not have to be performed automatically, but can be done manually, preferably using some sort of checklists and the interaction design. According to the rules of structural programming, there is no business logic in the presentation layer. This means in practice, that the GUI bugs are relatively easy to fix. It is important, however, to verify that your GUI reflects the interaction design.