Flexibele ontwikkelmethodieken betrekken de gebruiker meer bij het programmeerwerk. De programmeur moet daardoor vaker opleveren en meer luisteren. Web 2.0 en agile helpen allebei de kloof tussen ontwikkeling en gebruik dichten.
Van oudsher is de ontwikkeling van software vaak een afgescheiden proces. Vooraf worden de behoeften bij de gebruikers in kaart gebracht en vervolgens wordt er een ontwikkelplan gemaakt. Na het hele ontwikkeltraject volgt een afgerond product, waarbij een bèta-versie nog een feedback-mogelijkheid is voor de gebruikers.
Dit verandert door de huidige populariteit van flexibel ontwikkelen, met en voor Web 2.0 maar ook volgens de aloude agile-methodiek. Die twee aanpakken voor programmeren hebben nogal wat gelijkenissen. Zo is er bij beide de verplichting ingebouwd om voortijds al functionele delen van het eindproduct op te leveren. Het Computable-expertpanel Development ziet hierdoor de ontwikkelaar deels gedwongen uit zijn hok komen.
Combineren van functies
"Ik denk dat Web 2.0 als bijkomend voordeel heeft dat het de afstand tussen de programmeur en de eindgebruiker verkleint", zegt Robbrecht van Amerongen, projectmanager en ict-consultant bij AMIS Services. "Door de diensten die Web 2.0 levert (blogs, rss, podcasts, community created content, etcetera) wordt de gebruiker ook een beetje programmeur. Hij stelt zelf nieuwe functionaliteit samen door het combineren van bestaande Web 2.0-functies. Websites als Netvibes zijn hier een voorbeeld van."
Doordat de gebruikers zelf ook intensief met creatie bezig zijn, zien zij ook wat nu niet goed werkt of wat nog nodig is, aldus Van Amerongen. "Zo kan je je gebruikersgroep laten meewerken aan het bedenken van nieuwe features en het oplossen van storende problemen."
Raakvlakken
"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." Van Amerongen ziet ook een onderscheid: "Het enige verschil in de aanpak is dat veel Web 2.0-ontwikkelaars de hele internetgemeenschap als potentiële gebruiker zien. Een agile-project heeft in veel gevallen een beperkte gebruikersorganisatie; namelijk de opdrachtgevende organisatie."
In de basis is dat verschil echter niet zo groot, stelt hij. "Het gebruik van Web 2.0-mogelijkheden in projecten is een stimulans voor het vergroten van de communicatie tussen gebruikers en programmeurs. En dat is weer één van de uitgangspunten van agile."
Bèta is niet af!
Panellid André Weber maakt een kanttekening bij tussentijds of voortijdig iets opleveren. "Het is niet gewenst dat leveranciers toepassingen op de markt zetten als bètaversie, terwijl het gebracht wordt als volwaardig product." De manager Test Factory (teststraat) bij Getronics PinkRoccade is streng. "Bètaversies mogen alleen als gebruikers wéten dat het een bètaproduct betreft. Als je iets serieus wil gebruiken is het niet aangenaam om meerdere malen te moeten wachten op nieuwe versies en patches, en die te moeten downloaden en installeren."
Weber wijst agile en Web 2.0 niet af. "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."
Traditioneel
Hij ziet ze dan ook niet als alomvattende vervangers voor traditionele ontwikkelmethodes. "De meer traditionele ontwikkelmethodieken hebben zich ook verder ontwikkeld. Deze methodieken ondersteunen onder andere incrementeel ontwikkelen. Hiermee krijg je het beste van twee werelden."
De keuze voor een ontwikkelaanpak is dus gekoppeld aan het project, stelt Weber. "Het is afhankelijk van diverse factoren. De aard van de toepassing; standaardsoftware, maatwerk, groot, klein enzovoorts. En of het nieuwbouw of onderhoud betreft. Op basis daarvan moet je kiezen voor de beste methodiek. Een professionele organisatie kan meerdere manieren van ontwikkelen aan."
Web 2.0 en Agile development zijn nuttige ontwikkelingen die helaas door veel marketing afdelingen binnen IT bedrijven veel te veel opgeklopt worden. Als je voorbij de hype kijkt dan zijn er maar weinig bedrijven die echt ?agile? werken en is het vaak oude wijn in nieuwe zakken. Het gebruik van bestaande doorontwikkelde ?objecten? als Blogs en RSS is absoluut een positieve ontwikkeling maar het op een zinvolle manier integreren van deze zaken vergt nog steeds een hoop specifieke technische kennis. Ook bij gebruik van Web 2.0 en ?agile? development blijft goede communicatie tussen bouwers en afnemers cruciaal. Veel techneuten trekken zich nou eenmaal graag terug in de ?veilige? techniek, daar veranderen deze nieuwe technieken niets aan. Software ontwikkeling is mensenwerk en voor succesvolle projecten zijn het de mensen die de brugfunctie tussen techneut en klant vormen die het verschil maken, niet een methodologie of technische ontwikkeling.
Onafhankelijk van de methodiek en het wel of niet gebruik van Web 2.0 kan je tegenwoordig als ontwikkelaar het niet meer veroorloven om je te beperken tot de techniek. Als goede software engineer moet je de veranderingen in de omgeving volgen en hierop inspelen. Dit kan zowel vanuit traditionele methodieken als vanuit Agile.
Vanuit Agile zit contact met de buitenwereld (buiten het hok) in de kern verweven. Van de 12 principes van het Agile Manifesto (http://agilemanifesto.org/principles.html) gaan er 6 over communicatie en samenwerken. Deze werkwijze stimuleert de ontwikkelaar om verder te kijken dan de (veilige) technische wereld en samen met de gebruikers, opdrachtgevers, klanten en andere stakeholders tot een goed eindproduct te komen.
Agile is niet nieuw. Een agile methodiek als DSDM heeft zijn oorsprong al in 1990.
Ik ben het eens met Andr? Weber waar hij de keuze voor de ontwikkelaanpak koppelt aan de aard en type van het project. Binnen DSDM wordt via een suitability filter duidelijk aangegeven welk type projecten niet geschikt zijn voor deze agile aanpak. Dit zijn vooral die trajecten waarin alle functionele requirements in 1 keer (zonder tussenversies) moeten worden opgeleverd zonder veel betrokkenheid en communicatie met de opdrachtgever en de stakeholders. Het is kenmerkend van een Agile werkwijze om dan tegen je opdrachtgever te zeggen dat deze methodiek niet past voor dit project.
Communicatie, interactie en feedback zijn naar mijn mening de belangrijkste factoren voor het slagen van een softwareproject. Hiervoor zal je als ontwikkelaar meer contact meten gaan zoeken met de gebruikers van je systeem (en vice versa).
Ik kan me wel vinden in de opmerking dat veel bedrijven wel stellen aan Agile te doen, maar waar het in de praktijk neer komt op oude wijn in nieuwe zakken.
Web 2.0 staat binnen onze organisatie voor procesmatig automatiseren. Ga in overleg met je klanten welke processen er bestaan en zorg dat je software die processen ondersteund. Heel verleidelijk om daarbij de fout te maken om schermen te gaan ontwerpen. Die doen in feite niet terzake en verbloemen vaak dat opdrachtgevers niet goed in staat zijn om hun processen te beschrijven. Hoe vaak zitten de problemen niet in de uitzonderingen van processen? Het praten over de layout van schermen leidt de aandacht van die processen af en verbloemt dergelijke hiaten. Wanneer je de processen helder hebt gedefinieerd met alle uitzonderingen, is de werkelijke productiefase vaak een no-brainer en zal de user interface weinig spannend zijn.
Met Web 2.0 is die differentatie tussen procesmatig automatiseren en de interfacing naar de gebruiker in ieder geval een uitstekende technische mogelijkheid geworden. Of men op andere gebieden dan de techniek ook die shift kan maken: het kost meer tijd en is daarmee duurder. Gaat men voor de korte termijn winst of lange termijn strategie…?
De stelling die genomen wordt om een selectie van ontwikkelaanpak te koppelen aan het soort applicatie dat gerealiseerd moet worden deel ik volledig. Dit geldt overigens ook voor de software architectuur die bij de applicatie past, maar dat terzijde.
Het begrip programmeur, daar heb ik meer moeite mee. In mijn praktijk zie ik dat een programmeur veelal geassocieerd wordt met de persoon die puur en alleen code schrijft. Die vorm van programmeur bestaat wat mij betreft niet meer. We hebben het eerder over een software ontwikkelaar. Dat is een persoon die zowel het ontwerp maakt en dat uitwerkt tot een implementatie.
In de praktijk betekent dit veelal dat een software ontwikkelaar verantwoordelijk is voor een deel van de implementatie. Iemand is gefocust op de user interactie, de persistentie (de mogelijkheid om objecten in een database op te slaan) of juist op het business domein.
Vooral deze betrokkenen geldt dat ze, in min of meerdere mate, informatie nodig hebben van een gebruiker hoe het systeem moet functioneren. Ze kunnen het zichzelf niet veroorloven om zonder afstemming met een gebruiker software te realiseren. Korte lijnen zijn van belang.
Interessant is overigens ook de andere kant. Vaak wordt ik gevraagd een voorstel te doen om een oplossing te ontwikkelen op basis van een pakket functionele specificaties. Na het doornemen van de specificaties heb je dan een beeld van het systeem. De vraag is hoeverre dat beeld daadwerkelijk overeenstemt met hetgeen de auteurs van de specificaties bedoeld hebben. In de praktijk blijkt dit ver uiteen te lopen. Dit gebeurd omdat degene die de specificaties opstellen een proces doorlopen om tot de specificaties te komen. Dat wat vastgelegd wordt is slechts een deel van de bevindingen die tijdens het proces naarvoren komen. Als de ontwikkelaars betrokken zijn bij de vastlegging (het ontdekken) van de specificaties krijgen ze veel meer het gevoel dat nodig is om de context en dus de benodigde software te begrijpen.
De betrokkenheid van de ontwikkelaar heeft nog een ander voordeel: zij zijn instaat om de complexere specificaties om te zetten in executeerbare modellen. Dan kunnen de gebruikers ook daadwerkelijk zien wat de specificaties voor resultaat opleveren. Dit levert de gebruiker ook weer inzicht op of de gestelde eisen en wensen wel tot het gewenste resultaat leiden. Vaak zie je dan dat bijgesteld wordt en er zelfs andere software opgeleverd wordt dan men initieel verwacht had. Dit is een goede ontwikkeling.
Conclusie is wat mij betreft dat een Agile aanpak voor complexere software, dat is software die het platte formulier niveau (CRUD) ontstijgt, een must is. Dit is noodzakelijk om tot de juiste implementatie te komen. Terugkerend naar de programmeur betekent dit dat deze dus zeker met de gebruiker in overleg moet. Dit staat echter los van het gebruik van Web 2.0. Het geldt even goed voor de grote hoeveelheid “rich-clients” (Windows of Java- gebaseerd) die nog steeds ontwikkeld worden.