UBUSmart – lenig en flexibel

In de eerste maanden van het UBUSmart project hebben we requirements verzameld en use cases geschreven. Toen Jikke en ik daar naar keken, besloten we dat dit project geschikt was om te experimenteren met “Agile” werken. Eén van de kenmerken van Agile is dat je je project opdeelt in periodes (‘iteraties’) van ongeveer zes weken en dat je per periode een paar use cases behandelt. Aan het eind van zo’n periode test je de resultaten. Vaak testen heeft als groot voordeel dat eventuele bugs snel ontdekt worden. Ze kunnen dan worden opgelost voordat ze van invloed kunnen zijn op andere, nog te bouwen, onderdelen. Het betekent natuurlijk wel dat de testers vaker aan de slag moeten dan ze bij andere projecten gewend waren.

Voordat we begonnen met programmeren verdeelden we de use cases dus over de geplande iteraties. In de eerste iteratie kwam het gedane werk nog aardig overeen met het geplande werk. Maar naarmate we verder in het project kwamen, moesten we steeds verder afwijken van onze eerste planning. Het mooie van Agile is dat daar al rekening mee is gehouden. Geen enkel project kan immers helemaal volgens planning lopen. Daarom kijk je aan het begin van elke iteratie opnieuw welke use cases je gaat behandelen. Is er een use case blijven liggen? Moet use case 10 af zijn voordat je use case 9 kunt doen? Moet er eerst nog onderzoek gedaan worden voordat je verder kan met use case 12? Misschien zijn er wel use cases die je niet binnen het project af kunt krijgen, bijvoorbeeld omdat je afhankelijk bent van een leverancier die zijn schema niet aan het jouwe kan aanpassen. Binnen Agile kan dat allemaal, zolang je maar weet waarom je iets doet (of niet doet).

Bij Agile werk je altijd met meerdere mensen tegelijk. Terwijl er software geschreven wordt voor de use cases van deze iteratie, worden de requirements voor de use cases van de volgende iteratie verder uitgewerkt. Zo kon het zijn dat Maarten druk bezig was om de gegevens uit de Bibliograaf op de mobiele site te krijgen, terwijl ik uitschreef hoe de zoekresultaten van Aleph getoond moesten worden. Uiteraard verzon ik dat niet zelf: daarvoor heb je gebruikersvertegenwoordigers. Dus ik vroeg ze dingen als “moet het op de mobiele site mogelijk zijn om zoekresultaten te filteren op materiaalsoort” en “welke van de vele Alephvelden moeten getoond worden”. Hun antwoorden verwerkte ik in de requirements, waarna Maarten en ik samen zorgden dat de software daaraan ging voldoen.

De mobiele site is dus niet gemaakt door een stel techneuten die een paar maanden in hun kamer zijn opgesloten, waarna ze een kant-en-klaar product over de muur gooiden. Nee, de mobiele site is gemaakt door een heel projectteam, met gebruikersvertegenwoordigers, testers en software ontwikkelaars, die samen voor een mooi resultaat hebben gezorgd.

Nog een paar dagen en het resultaat is voor de hele wereld te bewonderen.