De manier waarop we op dit moment onze software ontwikkelen, deugt niet. Projecten zijn te laat, te duur en sluiten niet aan bij de behoeften van de opdrachtgevers. Agile Development kan misschien verbetering brengen.
"Door een nieuw project te beginnen met een groot requirements-document, teken je gelijk het doodvonnis. Je kunt niet eerst negen maanden aanklooien en dan net voor deadline snel wat in elkaar programmeren. De verwachtingen van de opdrachtgevers zijn inmiddels al zo laag gezakt dat ze alleen nog het minimale van ons vragen: oplevering binnen planning en budget. Niet of het geld goed besteed werd en het resultaat aansluit bij hun behoeften."
Dat zegt Scott Ambler, als Agile Development evangelist in dienst bij IBM. Volgens Ambler is software veel te complex om in één keer te worden geschreven.
Kleine ontwikkelcyclus
Ambler zet zich met Agile Development (AD) af tegen de klassieke manier van software ontwikkelen zoals dat onder het waterval-model gebeurt. Daarbij worden eerst de requirements verzameld, en de modellen en een architectuur ontwikkeld. Pas daarna wordt begonnen met de implementatie, gevolgd door het testen.
Bij AD moet elke twee of vier weken werkende software worden opgeleverd. In die tijd wordt steeds een kleine ontwikkelcyclus doorlopen. De modellen en de architectuur moeten in de eerste twee slagen hun grove vorm krijgen. De details worden later uitgewerkt. Meer flexibiliteit wordt bereikt door de requirements te integreren in goed leesbare tests, en door bugs en requirements op dezelfde manier te behandelen. "Wij willen geen reproduceerbare processen. Wij willen reproduceerbare resultaten."
Slechte naam
"AD is op dit moment de norm aan het worden," aldus Ambler. "In de Verenigde Staten wordt het merendeel van de projecten al op deze manier uitgevoerd." Volgens hem wordt de opmars van AD vooral geremd door sceptici, vooroordelen en misverstanden. "De traditionele software developers raken in paniek van AD. Wij vormen een bedreiging voor hen. Vandaar dat ze veel FUD (Fear, Uncertainty and Doubt) rondstrooien. Daarnaast zijn er veel kleine hackersclubjes die zeggen dat ze AD-ontwikkelaars zijn. Ze gebruiken alle retoriek, maar doen geen AD. Die geven ons een slechte naam."
"Voor AD moet je juist meer discipline hebben en meer met elkaar en de opdrachtgever communiceren." AD vraagt dan ook veel meer van de ontwikkelaars. Ze fungeren tegelijkertijd ook als informatie-analist, software-architect en tester. Dat AD alleen geschikt is voor senior ontwikkelaars is dan ook een veelgehoord bezwaar. "Ontwikkelaars zijn misschien wel verlegen, maar hebben ook gewoon een vrouw en kinderen. Als je denkt dat ze niet kunnen communiceren, investeer je ook niet in vaardigheidstrainingen," aldus Ambler.
Visje
De veelzijdigheid moet software-development juist weer een aantrekkelijke en inhoudelijk interessante job maken. "Ontwikkelaars zijn net als katten. Ze luisteren niet. Als je katten vraagt of ze de kamer uit willen gaan, blijven ze gewoon zitten. Een memo sturen helpt ook niet. En met een aanvraagformulier dat ze het recht geeft om in die kamer te zijn wordt niets gedaan. Maar als je een visje voor hun neus houdt en naar buiten gooit, rennen ze er zo achteraan."
"Datzelfde geldt voor ontwikkelaars; je moet ze motiveren. Ze zijn waarschijnlijk slimmer dan het management. Dat denken ze in ieder geval." Ambler pleit dan ook voor software-architecten die meewerken in het team en een deel van hun tijd besteden aan het daadwerkelijk programmeren van code. "Laat het niet over aan de bureaucraten. Dit is werk voor specialisten."
PowerPoint-architecten
Op die manier dwingt AD de bureaucraten hun zaakjes in orde te maken. Daarbij spreekt Ambler smalend over de PowerPoint-architecten. "Geen wonder dat het niet werkt. Hoe langer je wacht met het schrijven van code, des te groter het risico dat het niet lukt. In PowerPoint kan alles. Pas als je het bouwt, weet je wat echt werkt."
"Veel van wat wij in de software-industrie voor waar aannemen, klopt niet. Ondanks dat we al decennia geleden hebben ontdekt dat we niet op de goede manier werken, is er nog maar weinig veranderd."
"Je kunt niet van ons verwachten om budget, tijd en scope van tevoren te voorspellen. Daarvoor heb niet genoeg informatie. Het management begrijpt niet wat het van de ontwikkelaars vraagt." Tegelijkertijd denkt Ambler dat de opdrachtgevers open staan voor verandering. "De business weet dat het huidige model niet werkt. IT-ers moeten van zich laten horen."
Voordelen van Agile Programming
-
Meer flexibiliteit
-
Schaalbaar model
-
Convergentie, evolutionair proces
-
Betere aansluiting bij de behoeften van de stakeholders
-
Planning, documentatie en code op as-needed basis
-
Requirements en tests geïntegreerd
-
Eerder bekend of risicovolle onderdelen en technologieën ook haalbaar
-
Eerder testen verlaagt de risico’s
Risico’s van Agile Programming
-
Stakeholders worden niet tevoren gedwongen om hun eisen en verwachtingen te formuleren
-
Planning en budget zijn moeilijk te bepalen
-
Slecht doordachte architectuur en modellen, risico op spaghetti-code
-
Belangrijke beslissingen op ad-hoc basis
-
Ontwikkelaars hebben te weinig skills
-
Veel code weggegooid
- AD vraagt een andere embedding in de organisatie
Scott Ambler
Scott Ambler is in Toronto (Canada) afgestudeerd in de computerwetenschappen en de informatica. Voordat hij bij IBM aan de slag ging als evangelist voor Agile Development, gaf hij leiding aan een team software-ontwikkelaars, daarbij gebruikmakend van de Agile modellen. Daarnaast is hij een van de grondleggers van het Eclipse Process Framework (EPF). Op dit moment helpt Ambler klanten van IBM bij het opzetten van hun software-ontwikkelprocessen. Daarnaast schrijft hij boeken, geeft hij presentaties en schrijft hij voor Dr. Dobb’s Journal.
Je moet natuurlijk wel mensen hebben die echt programmeren kunnen.
Niet in Java of in .Net.
Maar in relationele databases.
In query talen als SQL
In dialoogschermen bouwen
(hierbij vooral de ergonomsiche kant bekijkend. repsonse tijd < 0,2 seconde) Lijst uitvoer bouwen Programma's bouwen die de bedrijfsregels toepasssen op de invoer stromen en de uitvoer stromen, ongeacht herkomst of doel. Wie leidt in Nederland nog op voor cobol programmeur?
Mijn reactie is erg lang, vandaar dat ik er een blog item van heb gemaakt. Deze is te lezen op:
http://java-aap.blogspot.com/2008/07/agile-development-nadelen.html
Agile is geschikt voor single application development.
Echter, ik vraag me hoe het kan werken voor large scale service development waarbij alleen al voor 1 individuele use case meerdere systemen betrokken zijn (denk aan 5 tot 10 systemen per use case) en waarbij de diverse systemen soms door verschillende leveranciers worden gebouwd.
Hoe kun je dan de principes van Agile zoals snel opeenvolgend iteraties opleveren, wijzigingen in scope flexibel doorvoeren, Individuals and interactions over processes and tools effectief invoeren, etc. Voor mijn gevoel worden de planning, architectuur, en afstemmings problematiek door de (on)vermijdelijke (?) overhead tot onoverkoombare hordes.
De klant vraagt er om, ik wil het, en ik breek mijn hoofd over hoe we het voor elkaar kunnen krijgen. Wie weet de weg?
Agile programming is slechts een techniek, wat m.i. veel wezenlijker is bij systeemontwerp is hoe te komen tot een product waar de gebruiker iets aan heeft/iets mee kan en wat is afgestemd op zijn informatiebehoefte.
Om tot een conceptueel informatie model te komen zonder enige technologische of implementationele richting is het noodzakelijk met en in de taal van de gebruiker/klant tot dit model te komen.
Geschikte en in de praktijk bewezen methode hiervoor is NIAM