In een ideale wereld loopt softwareontwikkeling van een leien dakje. Een goede start, een ontwikkeltraject zonder noemenswaardige problemen en een klant die uiterst tevreden is met het op tijd geleverde product. Helaas is de realiteit anders. Projecten gaan wel eens mis. Soms een beetje, soms compleet. De oorzaak? Er gaat iets fout in het traject. Waar precies, dat verschilt nogal. Wij zetten de meest gemaakte fouten in softwareontwikkeling op een rij.
1. Keuze van de ontwikkelmethode
De keuze is tegenwoordig groot als het gaat om ontwikkelmethoden. Waar we vroeger massaal te werk gingen op de watervalmanier, zijn er nu ook verschillende Agile werkwijzen, zoals Scrum, Kanban of Lean. Nieuw is echter niet altijd beter. Soms is een project nu eenmaal beter geschikt om op de klassieke manier aan te pakken. En soms is een Agile softwareontwikkeling beter.
Wanneer gebruik je de agile methode?
Agile staat voor wendbaarheid en flexibiliteit. Agile softwareontwikkelmethodes worden gekenmerkt door korte cycli waarin er steeds nieuwe software wordt opgeleverd. Tijdens het ontwikkelproces is er veel ruimte voor overleg. Ook kan het product voortdurend aangepast worden aan de (nieuwe, steeds veranderende) wensen van de klant. De Agile ontwikkelmethode is daarom vooral in het voordeel bij:
- Projecten waarbij de klant (nog) niet precies weet wat hij wil;
- Een klant die snel resultaten wil zien;
- Een klant die bereid en beschikbaar is om tussendoor mee te denken en software te testen;
- Een project met een wat grotere omvang waarbij vooraf minder vastligt.
Wanneer gebruik je de watervalmethode?
De klassieke watervalmethode is een voorschrijvende manier van werken. In dit geval ligt er vanaf het begin al wel heel veel vast. Tijdens het proces wordt er gewerkt volgens vaste procedures. Daardoor is er minder ruimte voor tussentijdse aanpassingen. Deze manier van software ontwikkelen past vooral bij projecten waarbij:
- Er een duidelijk gedefinieerd einddoel vaststaat;
- De klant vastomlijnde ideeën en wensen heeft;
- De klant niet beschikbaar is voor input tijdens het ontwikkelproces;
- Een kleiner project met weinig losse eindjes;
- Fixed price-projecten.
Uiteraard hangt de keuze voor een ontwikkelmethode ook af van de beschikbare medewerkers en de bedrijfscultuur. Agile is niet zomaar iets wat je even erbij doet; het is een hele andere manier van werken waarbij het hele bedrijf wordt betrokken. Is het ontwikkelteam niet bekend met, bedreven in of gecharmeerd van de agile werkwijze, dan kan het project alsnog mislukken.
2. De expertise van de ontwikkelgroep matcht niet met het project
Over het ontwikkelteam gesproken: het is natuurlijk van levensbelang dat de samenstelling van het team past bij de scope van de opdracht. Zowel qua grootte als qua inhoudelijke expertise. Dat kan alleen als je van te voren goed op de hoogte bent van wat de opdracht precies inhoudt. Onderzoek dus zorgvuldig hoe complex de opdracht precies is. Waar zitten de technische uitdagingen en welke experts heb je hierbij nodig?
Een ontwikkelteam met te weinig skills kan de opdracht waarschijnlijk niet aan en zal niet de gewenste kwaliteit opleveren. Dit wordt helaas vaak pas later in het project duidelijk wanneer de complexiteit toeneemt. Soms zorgt dit er zelfs voor dat de webapplicatie volledig herschreven moet worden.
Lees ook: Wat kost een webapplicatie?3. Onrealistische inschatting van uren en verwachtingen
Nog zo’n pijler waarmee je project valt of staat: een goede inschatting van het aantal uren. Natuurlijk heeft de klant het product ‘gisteren’ nodig, maar laat je niet verleiden tot een overoptimistische inschatting van de workload als je het project aan het plannen bent. Je zult niet de eerste zijn die deadlines mist, de klant om uitstel moet vragen of, erger nog, een product aflevert dat door de klant direct wordt afgewezen.
Voor een goede time management is het belangrijk te weten wat de klant voor ogen heeft. Alleen als je de verwachtingen goed in beeld hebt, weet je ook hoeveel werk er ongeveer in het project gaat zitten. En mocht hier nog onvoldoende zicht op zijn, zorg dan dat de verwachting van de klant hier op aansluit.
Wat verwachtingen betreft: zorg er ook voor dat alle teamleden helder voor ogen hebben wat er van wie wordt verwacht. Zo voorkom je dat er hiaten ontstaan of dubbel werk wordt uitgevoerd.
Een goede inschatting van uren en verwachtingen bereik je door middel van een goede voorbereiding. Een Sprint Zero-fase is hier bijvoorbeeld uitstekend geschikt voor.
Sprint Zero
Een Sprint Zero (Sprint 0) is onderdeel van de Scrum-methode. Het is de voorbereidende fase van een project, waarbij het team toewerkt naar de eerste sprint. Bij de sprint Zero worden de technische en organisatorische aspecten vastgelegd. Daarbij wordt goed gekeken naar de wensen van de klant. Ook worden de rollen verdeeld. Weet iedereen wat zijn of haar taak is in het team? Pas als alles duidelijk is, kan er een realistisch ontwikkelschema worden opgesteld.
Ook bij een klassieke werkwijze is het natuurlijk belangrijk om voor de start van het project een analytische fase in te lassen. Zo kun je goed in kaart brengen wat er precies wordt verwacht. Dit voorkomt een hoop stress bij alle partijen!
4. De verkeerde software-architectuur
Het is handig om vooraf goed te bedenken hoe de software-architectuur eruit komt te zien. Vraag je daarbij vooral ook af of jouw keuze geschikt is voor wijzigende wensen, groeiende datasets en of deze past bij het team. Python als programmeertaal kan bijvoorbeeld heel handig zijn, maar als de ontwikkelaars in het team vooral werken met PHP, kan het een struikelblok vormen waar je niet op zit te wachten. En een website bouwen met October CMS heeft veel voordelen, behalve als de gebruikers alleen ervaring blijken te hebben met WordPress.
Lees ook: Wat kost een WordPress website?Voor de software-architectuur fase is het raadzaam om een of meerdere experts in te schakelen. Deze bepalen voor een groot deel de lange termijn stabiliteit van de software. Bij het laten maken van een webapplicatie zijn er bij de database inrichting, het opdelen van de applicatie en het bepalen van de ontwikkelrichtlijnen geen tweede kansen.
Ook hier geldt: een goede voorbereiding is het halve werk. Overleg met de klant, de product owner(s) en met je team over welke software-architectuur jullie het beste kunnen aanhouden.
5. Grote oplevering in plaats van deelopleveringen (of andersom)
Een projectmanagement fout in softwareontwikkeling: een verkeerd oplevertermijn aanhouden. Er zijn mensen die denken dat alles met een grote oplevering online moet. Dat is een misverstand. De keuze voor een oplevertermijn hangt vooral af van de eisen van de klant, maar ook van het project zelf.
Zo is het bij een grote upgrade niet altijd beter om een langere opleverplanning aan te houden. Soms is het juist handig om tussendoor delen te releasen, zodat de gebruikers geleidelijk wennen aan de veranderingen en er alvast feedback kan worden verzameld. En bij kleinere opdrachten kan het zomaar zijn dat het beter is om de release in te plannen aan het einde van het project.
Hoe kies je de juiste opleveringstermijn? Door te overleggen met de klant en je ontwikkelteam, en door je in te leven in de gebruikers. Laat je dus niet leiden door wat ‘doorgaans’ gebruikelijk is maar kijk naar wat op dat moment het beste past bij het project. Mocht je het project Agile aanvliegen, dan kies je standaard voor deelopleveringen.
6. De Product Owner heeft te weinig tijd
De wensen van de klant staan centraal bij iedere opdracht. Maar die wensen moet je als ontwikkelteam dan wel goed voor ogen hebben. De rol van de Product Owner is daarbij essentieel. Hij/zij moet voorafgaand aan de start van het project feilloos kunnen aangeven wat de klant of gebruiker wil en aan welke eisen het product moet voldoen. Daarnaast moet deze persoon ook beschikbaar zijn voor feedback en vragen tijdens het project en is hij/zij verantwoordelijk voor het opstellen en beheren van de Product backlog. Dit alles kost aardig wat inzet.
Heeft de Product Owner onvoldoende tijd om zich hiermee bezig te houden, dan loop je het risico dat het project stagneert of dat het opgeleverde product niet voldoet. Wil je een ontevreden klant voorkomen, dan is het dus van belang om de rol van de Product Owner goed te definiëren. Zo stellen we bij Web Whales bij grote opdrachten altijd een Product Owner training (incl. certificering) verplicht.
7. Tussentijds contact en planningsbewaking mist
Wie trekt de kar van het ontwikkelproject? En wie houdt in de gaten of jullie nog op schema liggen? Bij gebrek aan tussentijds contact ontstaat er al snel onduidelijkheid. Dat geldt ook voor een planning die niet goed wordt bijgehouden. Deze verwarring kan een hoop extra tijd in beslag nemen en leidt bovendien tot irritaties, zowel bij de klant als tussen de teamleden onderling. Communicatie is dan ook een van de belangrijkste speerpunten binnen het software-ontwikkeltraject.
Werken jullie volgens de Scrum-methode, dan zal er regelmatig overlegd worden, bijvoorbeeld tijdens de Daily Scrum en de Sprint plannings en reviews. Bovendien zal er een Product Backlog worden aangemaakt waarin alle taken overzichtelijk op volgorde van prioriteit staan genoteerd.
Werken jullie volgens de klassieke watervalmethode, dan is het extra belangrijk om de communicatie en planningsbewaking in de gaten te houden. Bouw voldoende contactmomenten in, zowel tussen de teamleden als met de klant. Regelmatig overleggen voorkomt misverstanden en vertragingen.
Meer tips om fouten bij softwareontwikkeling te voorkomen
Web Whales heeft veel ervaring met het ontwikkelen van software. We weten dan ook als geen ander dat dit proces niet altijd eenvoudig is. Heb je hulp nodig of kun je nog aanvullende tips gebruiken om fouten in softwareontwikkeling te voorkomen? Laat het ons weten, we geven graag advies!
