Resultaat telt, niet het proces
“Agile Programming dwingt de bureaucraten hun zaakjes in orde te maken”
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."
- 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
- 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
<a href=" http://java-aap.blogspot.com/2008/07/agile-development-nadelen.html"> http://java-aap.blogspot.com/2008/07/agile-development-nadelen.html</a>
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?
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
08-02 Nij Smellinghe live met geïntegreerd...
03-02 BAM helpt SOR met unified communications
23-01 Marktplaats.nl benut met SAS markt- en klantkennis
06-01 Croon Elektrotechniek 'toekomstproof' met AppSense
04-01 Subsidieproces: eerst organiseren, dan...
02-01 Zorgverlener Goenhuysen werkt efficiënt mobiel
27-12 Rode Kruis werkt decentraal met centraal beheer
22-12 Diaconessenhuis Leiden over op ChipSoft CS-ENZIS
16-12 ROC werkt met RES Workspace Manager
09-12 Diaconessenhuis Leiden vernieuwt protocolbeheer
08-02 Nokia verplaatst smartphoneproductie naar India
08-02 'ICT-afdeling is te traag voor ontwikkeling apps'
06-02 Banometer: Topstart vacaturemarkt krijgt vervolg
06-02 Duitse PMCS.helpLine neemt Leidse MCH+ over
03-02 Siemens PLM Software introduceert Jack 7.1
03-02 Itemis betreedt Nederlandse markt via Warmer IT
01-02 Microsoft-partner Asapnet zet IT-University op
01-02 Kwaliteitscontroleur is nog geen testprofessional
01-02 Software AG noteert vlakke resultaten voor 2011
31-01 TU/e-eredoctoraat voor informaticapionier Harel
|
|
30-09-08 Web 2.0 haalt ontwikkelaar uit zijn hok
30-07-08 Web 2.0 geeft agile nieuwe impuls
28-07-08 Agile kon WIA-fiasco UWV voorkomen
28-07-08 Agile rekent af met falend projectmanagement
Gemeenten en ICT besparingen
Sommige gemeenten wijzigen hun autonome ICT omgeving in een samenwerkingsverband met als doel het verlagen van ICT......


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?