De agile-aanpak voor softwareontwikkeling komt breder in de belangstelling door de populariteit van Web 2.0. Bij beide gaat het er namelijk om tijdens het ontwikkelproces al functionele delen op te leveren.
Web 2.0 valideert agile development. Beide leveren namelijk tijdens een ontwikkeltraject al kleinere, functionele delen op van het uiteindelijke totaalproject. Bij agile is dat specifiek de bedoeling, om ook te kunnen reageren op veranderingen. Dat kunnen wijzigingen in de markt maar ook andere vereisten vanuit de klant. De vantevoren opgestelde specificaties voor een project hoeven dus niet heilig te zijn.
Bij Web 2.0 is dit de schijnbaar eeuwigdurende béta. Zo biedt Google diverse online-diensten, ofwel SaaS-vormen (software as a service), aan die officieel nog niet af zijn. Webmaildienst Gmail is al sinds de start in 2004 een bèta, tot op de dag van vandaag. Ook nieuwkomer Microsoft, die het mantra software plus services uitdraagt, brengt zijn semi-SaaS Office Live in functionele delen uit.
Klant en verandering
Zowel de eeuwige bèta van Web 2.0 als het ontwikkelproces van agile development houden specifiek rekening met feedback van de klant. Gebruikers krijgen al tijdens de ontwikkeling werkende delen ter beschikking en kunnen daar weer op reageren. Dit betreft ook de uiteindelijke eindgebruikers, dus niet alleen het bedrijf maar ook de afdelingen binnen de organisatie.
Druk vanuit gebruikers, dus bedrijven én werknemers, zorgt voor toenemende aandacht voor dit interactieve ontwikkelmodel dat al vrij snel een eerste resultaat kan opleveren. Dit staat haaks op traditionele methodieken, zoals het watervalmodel waarbij projecten worden opgedeeld in gescheiden fases die achtereenvolgens worden doorlopen.
Discipline voor flexibiliteit
"Sommige grote bedrijven bezien zo'n Web 2.0-aanpak als ongeorganiseerd, maar dat is niet het geval", stelt analist Jeffrey Hammond van onderzoeksbureau Forrester. Hij zegt dat de benodigde discipline is ingebouwd in het ontwikkelproces dat juist weer de flexibiliteit mogelijk maakt. Agile-grondlegger Alistair Cockburn legt dit ook uit in een interview met Computable.
Het agile-ontwikkelmodel leert programmeurs en projectmanagers om niet aan grote, langdurende projecten te beginnen die pas aan het eind iets opleveren. Dat eindresultaat is dan namelijk vaak niet wat de klant wil, of wat die inmiddels wil. Veel projecten mislukken hierdoor; óf de kosten lopen enorm op óf het gehele project is niet (meer) valide. Een actueel voorbeeld is het geschrapte Wia-project (wet Werk en Inkomen naar Arbeidsvermogen) van uitkeringsinstantie UWV.
Levenscyclus
Ook leveranciers van 'traditionele' ontwikkeltools, zoals Microsoft en IBM (Rational), prediken al enige tijd de levenscyclus van softwareontwikkeling. Ict-managers moeten de barrière tussen ontwikkelaar en eindgebruiker afbreken en ook zorgen voor een constante feedback-loop. Dit moet de softwarekwaliteit flink verbeteren, maar ook echt opleveren wat de gebruiker nodig heeft.
Ik denk dat web 2.0 als bijkomend voordeel heeft dat het de afstand tussen de programmeur en de eindgebruiker verkleint. Door de diensten die web 2.0 levert (blogs, rss, podcasts, community created content etc.) wordt de gebruiker ook een beetje programmeur. Hij stelt zelf nieuwe functionaliteit samen door het combineren van bestaande web 2.0 features. Sites als Netvibes (http://www.netvibes.com/) zijn hier een voorbeeld van.
Doordat de gebruikers zelf ook intensief met creatie bezig zijn zien zijn ook wat nu niet goed werkt of wat nodig is. Zo kan je je gebruikersgroep mee laten werken aan het bedenken van nieuwe features en het oplossen van storende problemen.
Dit heeft dus heel veel raakvlakken met een agile aanpak waarin je de gebruikersorganisatie laat bepalen wat er voor de volgende sprint (iteratie) belangrijk is om gemaakt te worden.
Enige verschil in de aanpak is dat veel web 2.0 de hele internet community als potenti?le gebruiker zien terwijl een agile project in veel gevallen een beperkte gebruikersorganisatie hebben (nl vanuit de opdrachtgever).
Het gebruiken van web 2.0 mogelijkheden in projecten is dus een stimulans voor het vergroten van de communicatie tussen gebruikers en programmeurs. En dat is een van de uitgangspunten van agile.
Het is niet gewenst dat leveranciers toepassingen op de markt zetten als beta versie, terwijl het gebracht wordt als volwaardig product. Beta versies mogen alleen als gebruikers weten dat het een beta product betreft. Als je iets serieus wil gebruiken is het niet aangenaam om meerdere malen nieuwe versies en patches te moeten downloaden en hier op te moeten wachten.
Agile methodieken hebben zeker toegevoegde waarde. Wel is belangrijk dat er dan ook daadwerkelijk een methodiek toegepast wordt en dat er niet even snel iets in elkaar geknutseld wordt zonder een goede planning en een van te voren vastgestelde aanpak. Daarnaast hebben de meer traditionele ontwikkelmethodieken zich verder ontwikkeld. Deze methodieken ondersteunen o.a. incrementeel ontwikkelen. Hiermee krijg je het beste van twee werelden.
Afhankelijk van de aard van de toepassing (standaard software, maatwerk, groot, klein enz.) en of het nieuwbouw of onderhoud betreft moet gekozen worden voor de beste methodiek. Een professionele organisatie kan meerdere manieren van ontwikkelen aan.
Ik zie niet wat Agile en WEB 2.0 met elkaar te maken zouden hebben. Het eerste is een (project) aanpak om te komen tot een software product; de tweede is een bepaalde opzet van de architectuur van een software product. De aanpak van een project en de architectuur van een software product zeggen niets over elkaar.
Het is uiteraard heel verstandig om meer interactie te zoeken met de werkelijke gebruikers van het te bouwen software product.