Project Method

All of xeexoo's software is developed in an agile way. This implies – briefly said – that software is build in short iterations of approximately one month. Also it occurs that – depending on expected overhead – an even shorter iteration could be used.

Sprints

Iterations are also known as 'sprints'. At the beginning of every sprint a very detailed planning is made according to items that are on the Product Back Log (PBL) and put on a Sprint Back Log (SBL). The PBL is a list of functionality that is wished for in the end product. Each item on the PBL has its own priority. During the entire development route both content and priority can be changed.

During the sprint it is entirely transparent how progress is made. Also there will be development builds each day available for testing.

At the end of a sprint – to our best knowledge and competence – a product is delivered that contains no known bugs. In other words: a stable beta build or release candidate (RC) is delivered.

Er wordt naar gestreefd om dit product ook vrij te laten zijn van 'losse eindjes' m.a.w. functionaliteit komt als geheel in de maandelijkse oplevering terecht of in het geheel niet. Doordat er geen zogenaamde dode code aanwezig is, bevordert dat de kwaliteit. Ook wordt aan het eind van elke iteratie gebruikersdocumentatie voor de ontwikkelde functionaliteit opgeleverd.

Delivery and after sales

The stable release candidate that is delivered at the end of the previous to last iteration is tested by the customer and accepted.

[todo: nazorg en bugfixing → daily builds, nadruk leggen op eindproduct dat klaar is en dat bugs kunnen voorkomen uiteraard]

[todo: tekening van iteraties + eindoplevering]

[todo: wikipedia link over agile projectmanagement].

[todo: de volgende paragraaf is niet specifiek voor maatwerk software, maar geldt voor software in het algemeen]

Unit and robot testing

Voor alle code worden unit testen en robot testen geschreven. Hierbij wordt altijd getracht om een zo hoog mogelijk dekkingspercentage te halen. Dit wordt gemeten met code coverage tools.

• een
• twee
• drie

The minimal criteria to deliver the release candidate are:

From a pragmatic point of view 95% is used for the in between deliveries on all three components. In the last sprint no functionality is added, but the said percentages are reached. Because of they focus on quality during each sprint, practice shows that the last sprint is shortened most of the time i.e. half of the time.

Project planning and tracking

The project planning and test reports are available at every moment through xeexoo.com/reports/. A customer account is required. The following account can be used to log in and see data of the real-life example project ParaDIS:

User name: demo
Password: demo

It must be said that during a sprint percentages can fluctuate heavily. The reasons of extreme low percentages are mostly due to bugs that cause a snowball-effect. Hence highest priority is given to solving issues that arise during development.

Up-scaling

If it is proven that your custom software can serve a more wider audience it is always possible to put it that way. Of course there is profit in multiple ways for you in this situation! Getting a discount/bonus and extra functionality for free are a some of them.