Watervalmodel nog bruikbaar in deze tijd?

[CodeCaster]

Modbreak:

Let op: afgesplitst van [MySQL] Ontwerpen van een grote database

tss68nl schreef op zondag 10 april 2011 @ 15:12:
[...]


Jij rekent helemaal niets extra door voor wijzigingen die de klant aanbrengt, tenzij je alles al tot in de puntjes vast had liggen. Kortom, we mogen er van uit gaan dat alles met de klant al 100% is doorgesproken en vastgelegd, en dat TS precies weet wat de klant wil. Zo niet, dan hoort hij nog geen datamodellen te bouwen

Met die insteek komt een project nooit van de grond.

[ Voor 9% gewijzigd door Creepy op 10-04-2011 20:25 ]

[kKaltUu]

CodeCaster schreef op zondag 10 april 2011 @ 15:17:
[...]

Met die insteek komt een project nooit van de grond.

Tuurlijk wel, eerst functioneel ontwerp vastleggen voordat je aan het technisch ontwerp bezig gaat.

[CodeCaster]

En functionele eisen veranderen niet gaandeweg een project?

[eamelink]

Precies, daarom zijn we ook allemaal tevreden gebruikers van het waterval model

[BCC]

Je kan met watervallen echt geen geld meer verdienen in Nederland... behalve als je het daarna laat uitwerken in india

[tss68nl]

CodeCaster schreef op zondag 10 april 2011 @ 15:25:
En functionele eisen veranderen niet gaandeweg een project?

Inderdaad niet. Want als je het goed hebt vastgelegd en je scope hebt bepaald, dan valt een nieuwe functionele wens netjes buiten de scope

[Gerco]

tss68nl schreef op zondag 10 april 2011 @ 15:46:
Inderdaad niet. Want als je het goed hebt vastgelegd en je scope hebt bepaald, dan valt een nieuwe functionele wens netjes buiten de scope

En dan reken je daar dus extra geld voor want "het moet toch". Het kost extra uren om het ontwerp aan te passen en de code om te schrijven en dat gaat de klant dus gewoon betalen. Dat het "buiten scope" is heeft de klant geen boodschap aan. Als het product die feature niet heeft in versie 1.0 hebben ze er niets aan.

Het idee dat je vooraf wel even alle functionele requirements boven tafel kunt halen is, wanneer je geen schoolproject aan het doen bent, een illusie.

[tss68nl]

Gerco schreef op zondag 10 april 2011 @ 15:53:
[...]
En dan reken je daar dus extra geld voor want "het moet toch". Het kost extra uren om het ontwerp aan te passen en de code om te schrijven en dat gaat de klant dus gewoon betalen. Dat het "buiten scope" is heeft de klant geen boodschap aan. Als het product die feature niet heeft in versie 1.0 hebben ze er niets aan.

Het idee dat je vooraf wel even alle functionele requirements boven tafel kunt halen is, wanneer je geen schoolproject aan het doen bent, een illusie.

Als je in de voorbereiding een requirement gemist hebt die uiteindelijk in increment I opgeleverd *moet* worden, dan ben je geen knip voor je neus waard als project manager of business analist. Succesvolle projecten steunen op heldere afspraken vooraf, en een correcte scopebewaking. Daar zal je als uitvoerende partij ook echt achter moeten gaan staan en je klant van moeten doordringen dat wijziging van de scope een recept is voor regelrechte mislukking. Een wijziging achteraf gaat dus gewoon niet gebeuren, en kan op de roadmap voor een volgend increment. Daar heeft de klant wel degelijk een boodschap aan, hij heeft immers zelf ingestemd met die aanpak, anders begin ik (en velen met mij) niet eens aan het project.

Maargoed, het is volgens mij niet de bedoeling om een les projectmanagement uit te schrijven hier. TS wil antwoord op zijn datamodel, en ik geef TS aan dat ik er vanuit ga dat zijn beschreven scope ook daadwerkelijk vastligt bij de klant. Zo niet, kan TS beter eerst met de klant om tafel om het functionele plaatje rond te krijgen, en dan kijken we daarna naar het datamodel/technische implementatie.

[Creepy]

Zo, even de discussie over het waterval model en (niet) veranderende klantwensen afgesplitst.

Mijn mening hierover: Wij leveren hier graag op wat de klant wil, dat houdt dus ook in dat er momenten zijn dat er zaken (kunnen) veranderen. Wat mij betreft is 100% opleveren van een specificatie document wat met de klant is kortgesloten aan de start zonder rekening te houden met veranderende of nieuwe wensen niet meer dan deze tijd. Je levert dan gegarandeerd iets op wat de klant niet (meer) wil hebben. Het is wel een manier van zaken doen zodat je weet dat je waarschijnlijk na de eerste opdracht er nog een paar uit weet te slepen. (of je dat vindt kunnen of niet is dan weer een andere discussie ). Persoonlijk lever ik liever gelijk iets op dat direct bruikbaar is voor de klant. Het grappige is dat (zeker grote ) klanten dat niet altijd verwachten en altijd blij zijn dat we flexibel zijn en meedenken met de klant.

[xzaz]

Ik zie de waterval methode als een methode die nog prima gebruikt kan worden hetgeen wel bij kleine projecten. Bij projecten die wat groter zijn en die meerdere klanten hebben zal het nooit werken. Zonder itereren zal je nooit het systeem krijgen wat de klant wilt er van uitgaan dat de klant ook niet precies onder woorden kan brengen wat hij echt wilt.

[Twazerty]

Zelfs voor kleinere projecten vind ik het waterval model niet handig. Mijn klanten weten niet precies wat ze willen en gaandeweg het project komen er telkens wat eisen bij of moet er bijgestuurd worden omdat het niet precies is wat ze nodig hebben. Zodra het buiten de scope valt van het originele idee dan geef ik dat aan. De klant vind dit erg prettig dat het allemaal flexibel is en aan het eind heeft de klant precies wat hij nodig heeft.

Waterval is bij mij een no-go.

[SeatRider]

Twazerty schreef op zondag 10 april 2011 @ 22:16:
Waterval is bij mij een no-go.

Bij mij ook, maar wat doe jij dan liever? Timeboxen met MoSCow? Of agile/scrum?

[kemphaas]

SeatRider schreef op zondag 10 april 2011 @ 22:25:
[...]

Bij mij ook, maar wat doe jij dan liever? Timeboxen met MoSCow? Of agile/scrum?

Wij werken nu in het 4e jaar van HBO Technische Informatica met Agile/Scrum, en een "echte" externe opdrachtgever. Dit vinden wij als projectgroep ideaal werken. Korte stukken, veel deadlines, dus je krijgt minder kans om achter te gaan lopen, en je hebt iedere 3 weken echt resultaat.

[MacWolf]

SeatRider schreef op zondag 10 april 2011 @ 22:25:
[...]

Bij mij ook, maar wat doe jij dan liever? Timeboxen met MoSCow? Of agile/scrum?

Agile / scrum werkt in mijn ervaring wel aardig. De elementen eruit halen die je handig vindt, de rest laten zitten. Iteratief ontwikkelen met regelmatig een testbaar product waarbij de klant betrokken kan worden dat werkt gewoon goed.

[chime]

Waterval heeft als nadeel dat het project enorm hard kan ontsporen: deadlines zijn makkelijk 6 maanden of meer weg => een vertraging van een paar maanden heb je dan snel bij elkaar, zeker bij grotere teams en complexere software.

Probleem: de klant krijgt ineens een hoop drek op zijn bord.
Komt erbij dat de klant vaak ook nog dingen op een andere manier wilt => weeral extra vertraging/kosten.

Bij agile/scrum gaat het allemaal wat geleidelijker.
- klant krijgt regelmatig een update
- het geeft hen ook een veel beter beeld over de kost van ontwikkeling. Ze zien vrij makkelijk hoeveel een team van x-man op 2 weken kan realizeren.
- kan makkelijker bijsturen (minder belangrijke zaken laten vallen ofzo, nieuwe inzichten toevoegen, ... )
- meer deadlines, minder kans dat er de ontwikkelaars het wat laten hangen (bij een deadline die 2 maanden ver is, is er gewoon minder stress dan als de deadline 2 weken weg is)
- niet te veel analyseren van tevoren: in veel gevallen vliegt dat toch buiten bij de eerste ontwikkeling.

[Marcj]

Twazerty schreef op zondag 10 april 2011 @ 22:16:
Zelfs voor kleinere projecten vind ik het waterval model niet handig. Mijn klanten weten niet precies wat ze willen en gaandeweg het project komen er telkens wat eisen bij of moet er bijgestuurd worden omdat het niet precies is wat ze nodig hebben. Zodra het buiten de scope valt van het originele idee dan geef ik dat aan. De klant vind dit erg prettig dat het allemaal flexibel is en aan het eind heeft de klant precies wat hij nodig heeft.

Waterval is bij mij een no-go.

Dit vind ik nog wel een belangrijkste reden waarom waterval niet werkt. Je kunt het wel willen om van te voren alles vast te leggen (in functionele / technische ontwerpen), maar de klant komt er halverwege toch achter dat ze toch iets anders willen.

Zelf heb ik het ook meegemaakt met een klant die zelf in het waterval model zat, maar wel een drietal releases wilde doen. Ik geloof dat we tijdens het traject zeker 30 versies van het functionele ontwerp hebben gemaakt, omdat ze steeds iets anders wilden. Gelukkig waren wij gewend om op een Scrum manier te werken waardoor dit geen probleem is, maar soms moet je met andere leveranciers samenwerken die niet zo flexibel zijn.

Moet je voorstellen: vind je een foutje in de WSDL van een ander systeem, moet je 3 maand wachten op de volgende release voordat je hier een update van krijgt. En dat terwijl de impact eigenlijk nihil is

[begintmeta]

Ik zit in een heel andere sector waar men zich aanvankelijk richt op het vinden van de vraag/het probleem van de klant (niet dat dat niet kan wijzigen in de tijd (en het kan ook best niet dat de sector heel goed te vergelijken is)). Als ik het hier zo lees vraag ik me af of/waarom het in de ICT zo lastig is uit te vinden wat de behoeften van klanten zijn.

[ Voor 10% gewijzigd door begintmeta op 11-04-2011 08:53 ]

[frickY]

Marcj schreef op maandag 11 april 2011 @ 08:31:
Dit vind ik nog wel een belangrijkste reden waarom waterval niet werkt. Je kunt het wel willen om van te voren alles vast te leggen (in functionele / technische ontwerpen), maar de klant komt er halverwege toch achter dat ze toch iets anders willen.

Is het dan niet juist ideaal dat je die wijziging los kunt ontwikkelen en vooral, factureren?

begintmeta schreef op maandag 11 april 2011 @ 08:50:
Als ik het hier zo lees vraag ik me af of/waarom het in de ICT zo lastig is uit te vinden wat de behoeften van klanten zijn.

In mijn beleving is wat een klant wil voor 25% een oplossing voor het probleem, voor 25% iets waarover zijn neefje op een verjaardag heeft verteld, voor 25% iets 'gaafs' wat ze elders hebben gezien en voor 25% wat jij hun adviseert

[ Voor 34% gewijzigd door frickY op 11-04-2011 09:09 ]

[CodeCaster]

tss68nl schreef op zondag 10 april 2011 @ 16:20:
[...]


Als je in de voorbereiding een requirement gemist hebt die uiteindelijk in increment I opgeleverd *moet* worden, dan ben je geen knip voor je neus waard als project manager of business analist. Succesvolle projecten steunen op heldere afspraken vooraf, en een correcte scopebewaking. Daar zal je als uitvoerende partij ook echt achter moeten gaan staan en je klant van moeten doordringen dat wijziging van de scope een recept is voor regelrechte mislukking. Een wijziging achteraf gaat dus gewoon niet gebeuren, en kan op de roadmap voor een volgend increment. Daar heeft de klant wel degelijk een boodschap aan, hij heeft immers zelf ingestemd met die aanpak, anders begin ik (en velen met mij) niet eens aan het project.

Maargoed, het is volgens mij niet de bedoeling om een les projectmanagement uit te schrijven hier. TS wil antwoord op zijn datamodel, en ik geef TS aan dat ik er vanuit ga dat zijn beschreven scope ook daadwerkelijk vastligt bij de klant. Zo niet, kan TS beter eerst met de klant om tafel om het functionele plaatje rond te krijgen, en dan kijken we daarna naar het datamodel/technische implementatie.

Dat is leuk als je een webshop aan het ontwikkelen bent en de klant besluit halverwege ineens dat er tóch een nieuwsbriefmodule gemaakt moet worden.

Als je complexe processen aan het automatiseren bent waarbij de opdrachtgever zelf amper weet wat er eigenlijk in de hoofden van de medewerkers zit, kom je er pas gedurende het ontwikkelen en testen achter wat er precies allemaal moet gebeuren. Als je dan halsstarrig gaat weigeren om aanpassingen in het ontwerp te doen terwijl het product zonder die aanpassingen onbruikbaar is...

Als je een klant van dermate omvang hebt dat de business analist exact alles weet: gezegend ben je. Helaas ben ik dat in mijn (toegegeven; nog niet zo lange) ervaring nog nooit tegengekomen.

Een ultieme oplossing hiervoor is agile/scrum. Korte iteraties, veel overleg met de klant, en vooral: de klant de prioriteiten laten bepalen. Je kunt wel, zoals hierboven al werd genoemd, zeggen: "dit hadden we afgesproken op moment 0, dus dit krijg je", maar dan heeft de klant niet wat 'ie wil. En ik dacht dat het daar toch om ging in dit vak.

[ Voor 3% gewijzigd door CodeCaster op 11-04-2011 09:45 ]

[mithras]

Het is een leuke discussie die ik meermaals met mijn mede-eigenaar heb gevoerd over de te volgen methode (we hebben een webapplicatie-bedrijfje). Ik hou liefst vast aan een waterval model, waarbij mijn partner liefst alles gaandeweg ontdekt, test en bijklust. Ik doe de programmeer-kant, hij doet de conceptuele kant Onze projecten zijn altijd een fixed price voor functionaliteiten.

1) Hoe kan je een prijs bepalen als je niet weet wat je uiteindelijk allemaal gaat klussen?
2) Hoe zorg je ervoor dat de software nog fatsoenlijk werkt en geen knip&plak werk wordt?

Ik heb daarom liefst deze methode:
1) Maken van FO, vervolgens maken van mockups/wireframes, vervolgens ontwerpen/programmeren en tot slot opleveren
2) Extra functionaliteiten kunnen altijd worden toegevoegd, maar is meerwerk en een akkoord verloopt via een extra offerte. Voor de nieuwe functies dus eerst ook even kort omschrijven, een mockup klussen en vervolgens implementeren in bestaande code base.

Ik ben bang dat je met "proberen" er tijdens user-tests pas achterkomt dat het niet werkt en het totaal anders moet. Je hebt van tevoren niet goed nagedacht omdat je snel naar een prototype toe wilt. Het resultaat is het telkens opnieuw omgooien van code, een kostenpost die vele malen hoger wordt en een resultaat waar je niet trots op kan zijn. Of zie ik het volledig verkeerd?

Ik sta zeker open voor veranderingen tijdens het traject, maar het agile/scrum idee geeft ook juist de gelegenheid aan de klant om elke week het plan om te gooien.

CodeCaster schreef op maandag 11 april 2011 @ 09:44:
[...]

Een ultieme oplossing hiervoor is agile/scrum. Korte iteraties, veel overleg met de klant, en vooral: de klant de prioriteiten laten bepalen. Je kunt wel, zoals hierboven al werd genoemd, zeggen: "dit hadden we afgesproken op moment 0, dus dit krijg je", maar dan heeft de klant niet wat 'ie wil. En ik dacht dat het daar toch om ging in dit vak.

Een klant heeft altijd een probleem waarvoor hij je inschakelt. Je moet zorgen dat het probleem goed omschreven is en je daarvoor een advies kan uitbrengen. De oplossing is (in mijn ervaring) grotendeels gebaseerd op je eigen advies.

Natuurlijk houd je regelmatig contact, maar het initiële probleem van de klant zal niet zo snel veranderen. Slechts zijn eigen ideeën over oplossingen veranderen en jij bent juist de expert die moet zorgen dat zijn ideeën, jouw adviezen en de producten die je op dat moment ontwikkelt goed op elkaar afgestemd zijn.

[ Voor 24% gewijzigd door mithras op 11-04-2011 12:15 ]

[chime]

Nee, je ziet het verkeerd.

Bij Agile, scrum is analyse belangrijk, maar er wordt gekeken naar functionaliteit voor de gebruiker.
Eerst is er sowieso een traject waar dat requirements worden vastgelegd.
Op basis daarvan ga je al prioriteiten vastleggen.

Vervolgens gaan deze functionaliteiten op basis van prioriteit geselecteerd worden in sprints en zo uitgevoerd.
(Ruwe schatting kan dan al snel gemaakt worden voor het volledige project, ... )

Belangrijk is wel dat je niet te veel gaat ontwikkelen ... dus niet van kom, dit is later misschien nog handig ik steek het in een aparte klasse, of misschien gaat de gebruiker het ook zo gebruiken ik voorzie dat al.
Nee, er wordt heel strak gekeken naar de doelen van de "story", eerst schrijf je de testen en vervolgens de code.
Op die manier programmeer je niet te veel en verspil je geen tijd met nutteloze code/testen te schrijven.

Ook ga je regelmatig eens kritisch naar je code kijken waar je die kan vereenvoudigen (refactoren eigenlijk) dit om de leesbaarheid te verhogen en de code eenvoudiger te houden.
Het grote voordeel van regelmatig te refactoren is dat de kost om de code om te gooien pakken kleiner wordt, maar ook om snel wat extra functionaliteit toe te voegen.

Eigenlijk is agile/scrum heel gestructureerd werken => zo maar wat proberen en gaandeweg ontdekken gaat dan ook op een ramp uitdraaien.
Enige voordeel is wel dat de klant vrij snel kan zien dat het een ramp gaat worden en aan de alamrbel kan gaan trekken om zo toch niet al te veel geld te verspillen.

[Gonadan]

tss68nl schreef op zondag 10 april 2011 @ 16:20:
Als je in de voorbereiding een requirement gemist hebt die uiteindelijk in increment I opgeleverd *moet* worden, dan ben je geen knip voor je neus waard als project manager of business analist. Succesvolle projecten steunen op heldere afspraken vooraf, en een correcte scopebewaking. Daar zal je als uitvoerende partij ook echt achter moeten gaan staan en je klant van moeten doordringen dat wijziging van de scope een recept is voor regelrechte mislukking. Een wijziging achteraf gaat dus gewoon niet gebeuren, en kan op de roadmap voor een volgend increment. Daar heeft de klant wel degelijk een boodschap aan, hij heeft immers zelf ingestemd met die aanpak, anders begin ik (en velen met mij) niet eens aan het project.

Baseer je deze mening op theorie of op werkervaring? Die mening heb ik namelijk 'vroeger' heel vaak gehoord van docenten die een vaste lijst met eisen hadden liggen. In de praktijk valt het mij op dat je over het algemeen heel ver kunt komen met het vooraf vaststellen van de eisen, maar dat je die lijst nooit 100% zult gaan vervullen. De klant komt altijd tot nieuwe inzichten tijdens de bouw, is van mening veranderd of heeft zaken over het hoofd gezien.

Netto blijft het effect natuurlijk hetzelfde, als de klant wat anders wil moet hij óf concessies doen aan tijd (kosten) óf concessies doen aan eisen. Echter is mijn ervaring dat met kortere iteraties je minder overbodig werk doet omdat het gemakkelijker is om de ontwikkeling op het juiste spoor te houden.

[EfBe]

Waterfall kan handig zijn, wanneer je bv productontwikkeling doet: je functionele eisen staan nl. vanaf het begin vast en dat wil je ook zo houden, anders release je nl. nooit. Veel software dat we dagelijks gebruiken wordt op deze manier gemaakt. Bijna alle microsoft software is feitelijk waterfall based: er wordt pas software gemaakt wanneer de functionele specs helemaal af zijn. Op zich is dit logisch, want development vindt veelal plaats in grote dev centra in India of China en dan wil je dat alles vastligt wat gemaakt moet worden.

Het kan ook onhandig zijn wanneer je bv maatwerk moet maken: veelal veranderen de functionele eisen gedurende het project en dan eerst alles vooraf bepalen is weggegooide moeite: veel wordt nl. toch weggekieperd.

Wat tegenwoordig hip en mode is is eigenlijk bullshit. 9 van de 10 developers doet maar wat en gebruikt helemaal geen methodiek. 'we zijn agile'. Sure, maar is dat wel zo? Ook is het hip en stoer om waterfall af te zeiken tot op het bot. Ik haal mn schouders er maar over op. Je gaat nl. echt niet een MRI scanner met 10 miljoen regels code 'agile' ontwikkelen. Je wilt echt wel dat je miljoenen regels code in je nieuwe TV doen met de hardware waar ze voor bedoeld is, en dat je niet 'moet refactoren', want daar is geen tijd en geen geld voor en het is ook onnodig: je weet nl. al wat er gemaakt moet worden.

Er zijn overigens vele gradaties tussen waterfall aan de ene kant en compleet adhoc maar wat prutsen aan de andere kant. Voor software productontwikkeling bv kan het ook de moeite lonen om 'feature driven' te werken, dus niet het complete project van te voren doen, maar per feature het ontwerp 'waterfall' oplossen. Ook dit werkt bv goed bij productontwikkeling (je weet wat je moet maken, en dat verandert echt niet) maar kan niet goed werken bij projecten met een moving target als einddoel.

Wat men overigens wel veelvuldig vergeet is dat ookal ben je nog zo agile bezig: wanneer specs / functionele eisen veranderen tijdens het project dan is dat altijd nadelig en kost altijd (veelal veel) geld en tijd. het is ook veelal de schuld van slechte voor-analyse en kortzichtigheid en slechte begeleiding / voorlichting van de klant.

[begintmeta]

EfBe schreef op maandag 11 april 2011 @ 13:26:
...
Wat men overigens wel veelvuldig vergeet is dat ookal ben je nog zo agile bezig: wanneer specs / functionele eisen veranderen tijdens het project dan is dat altijd nadelig en kost altijd (veelal veel) geld en tijd. het is ook veelal de schuld van slechte voor-analyse en kortzichtigheid en slechte begeleiding / voorlichting van de klant.

Dat zou ik inderdaad ook vermoeden.

[Killemov]

Zie ook: Killemov in "Developer tools noodzakelijk?"
Ik verwachtte dat daar verder discussie uit zou komen, echter werd het topic snel gesloten.

Het watervalmodel is wat mij betreft nagenoeg niet meer houdbaar als ontwikkelmethodiek.Het ontwikkelen van software heeft niet alleen een technisch maar ook een financieel aspect, wat altijd een spanningsveld oplevert. Als een project een vastgelegde fixed-price heeft en een bijbehorende fixed-functionality dan zou het watervalmodel nog wel bruikbaar kunnen(!) zijn. Echter is meestal maar één van de twee echt fixed, namelijk de prijs.

Er wordt heel veel moeite gesteken in het vooraf uitspecificeren van een systeem en vervolgens wordt er heel veel moeite gestoken in het onderhandelen of bepaalde wensen van de klant al dan niet binnen de scope vallen of zelfs dat de ontwikkelaar bepaalde zaken niet juist heeft geïnterpreteerd.

[begintmeta]

Als ik de bovenstaande post, dit topic en Killemov in "Developer tools noodzakelijk?" lees krijg ik de indruk dat de communicatie tussen klant en uitvoerder vrij vaak gebrekkig verloopt. Het maken van vroege prototypes is dan iets wat de communicatie zou bevorderen. Ik vraag me af of het mogelijk is het communicatieprobleem nog wat dichter bij de 'wortel' aan te pakken, en of het maken van die prototypen niet weer teveel andere problemen vergroot of nieuwe problemen introduceert (dat komt ook uit een aantal posts in dit topic naar voren).

Zou het bijvoorbeeld zinvol zijn de genoemde werkvloer/eindgebruikers meer te betrekken bij de planning/het aanvankelijk helder krijgen van de behoeften? (Hoe) Kan de vooranalyse vaak beter, zoals EfBe schrijft?

[ Voor 27% gewijzigd door begintmeta op 11-04-2011 14:32 ]

[drm]

Ik ben het boek "The Pragmatic Programmer" aan het lezen (waanzinnige aanrader trouwens), en daar staat in dit opzicht een leuk stukje in over wat ze "Tracer Bullets" noemen. Dit sluit aan bij wat EfBe zegt over feature-driven development, en houdt een beetje het midden tussen prototyping (wat meer binnen waterval past) en Scrum waarbij je toch meer adhoc bezig bent. De analogie die gebruikt wordt is wat je doet als je in het donker gaat schieten; je gebruikt dan Tracer Bullets (lichtkogels) waarmee je kijkt of je je doel wel raakt. (Ze zijn nog al fan van analogieën en metaforen in dat boek ). Je pakt 1 onderdeel uit je software (waar zich dat precies bevindt doet er niet zo toe) en je werkt dat uit totdat je conceptueel kunt zeggen: "Ja dit is wat we willen", zowel aan de klant-zijde als aan de ontwikkelzijde. Het voordeel ten opzichte van prototyping, is dat je een prototype meestal weggooit als je er mee klaar bent. Die tracer bullets kun je doorontwikkelen, en vastleggen als afgesproken functionaliteit. De documentatie ervan is dan ook eenvoudiger, want je kunt verwijzen naar een werkende "mock-up" zonder dat het echt een "mock-up" is. Mock-ups en wireframes wekken tenslotte vaak toch allerlei verwachtingen die niet per se reëel of zelfs uitgesproken zijn.

Ik weet niet of het in de praktijk echt werkt maar ik vind het wel een interessante gedachte.

[Grijze Vos]

Wat ik me afvraag bij al die mensen die zo hard agile fan zijn, hebben jullie dan geen klanten die graag willen weten wat het kost vooraf?

Wij itereren doorgaans over enkele versies heen, elk van te voren gespecificeerd en gebudgetteerd.

[xzaz]

Zo heeft iedereen eigenlijk zijn voorkeuren en heeft elke methode zijn voor en nadelen. Vaak combineren bedrijven ook wel bepaalde elementen of doen ze bepaalde fasen van RUP bijvoorbeeld in waterfall. Ik zelf vind XP altijd wel aardig.

[weerdo]

Agile heeft 1 echt nadeel: Het vereist een verantwoordelijke klant die continu betrokken is bij de realisatiefase van een project. Niet alleen een baas die iets wil, maar ook het personeel moet zich betrokken, actief, verantwoordelijk opstellen. Zij moeten alles vertellen, en vertellen. En nog meer vertellen. En testen, testen, en nog meer testen. Agile steunt zwaar op de feedback van de klant. Daar gaat het vaak mis. De meeste klanten zijn vaak niet echt verantwoordelijk (de baas wel, maar het personeel vaak niet), betrokken, en actief. En dat kun je vaak ook niet verwachten: de meeste klanten hun personeel moeten ook nog andere taken uitvoeren! Vaak zit er ook nog een relatief lang voortraject aan, en dat wil maar niet lukken.

Agile wordt echt nog bij lange na niet bij klanten doorleefd. Daarvoor is het een te nieuwe techniek. Voorlichten kan helpen, maar het moet doorleefd worden. Voelen dat een veranderend eisenpakket echt aanpassingen kost, dat slecht testen een slecht eindresultaat oplevert. Pas wanneer software development in de hoofden van de mensen zo wordt ervaren kan men echt stappen gaan maken.

Het idee van de tracer-bullets is ook zo slecht nog niet: de meeste mensen zijn slecht in iets "compleet nieuws" creëren, hebben vaak te weinig voorstellingsvermogen van wat iets moet worden. Daarom moet je iets "maken" wat werkt, maar vooral wat het voorstellingsvermogen van de klant prikkelt. Dan gaat het pas echt leven en komt het denkproces pas echt op gang. Het alternatief (van te voren veel tijd aan vooranalyse besteden, leidt vaak tot analysis paralysis omdat men er geen goede voorstelling van het eindresultaat kan maken. Bovendien mis je dan totaal het "voortschrijdend inzicht".

[BCC]

Wij leveren geen maatwerk, luisteren niet naar wat de klant wil, maar leveren agile oplossingen waar de klant echt iets aan heeft. Deze strategie heeft er voor gezorgd dat wij nu marktleider zijn in onze sector.

Klanten weten namelijk nooit wat ze precies willen.. je kan ze het wel vragen, maar dan kunnen ze alleen het huidige probleem verwoorden: ze kunnen niet ver genoeg out of de box denken om tot een echte oplossing te komen. Als je doorvraagt over hun probleem zeggen ze: "we willen dit, maar dan in de computer".

Dit zie je vaak terug in software: het digitaliseren van bijvoorbeeld formulieren. Dit lost echter niets op voor de klant. Vaak gaat het op papier zelfs sneller dan met de computer. Als je als leverancier het overzicht hebt in je markt, dan kun je een oplossing bedenken waarbij de klant bijvoorbeeld de formulieren helemaal niet meer nodig heeft. Door bijvoorbeeld een ander proces of door een technische oplossing. Dit is de kern van automatiseren.

Ik denk dat, zeker in Nederland, alles al gedigitaliseerd is wat er te digitaliseren valt. Als dit je business, is er dus weinig meer te verdienen. De echte meerwaarde zit nu in het echte automatiseren: processen wegnemen.

Bij ons is dit de kern van Agile: de specificaties uit de klant (of verschillende klanten) trekken. Zelf het overzicht krijgen en het probleem van de klant echt oplossen!

Grijze Vos schreef op maandag 11 april 2011 @ 16:46:
Wat ik me afvraag bij al die mensen die zo hard agile fan zijn, hebben jullie dan geen klanten die graag willen weten wat het kost vooraf?
Wij itereren doorgaans over enkele versies heen, elk van te voren gespecificeerd en gebudgetteerd.

Kortgezegd: nee. Wij leveren geen maatwerk, maar een oplossing. Vaak op basis van een diensten model. Alle initiële ontwikkelkosten en onderhoud zijn volledig voor onze eigen rekening. Dit geeft ons een waanzinnig voordeel op de concurrentie die nog aan het watervalmodel vast houdt.

[ Voor 33% gewijzigd door BCC op 11-04-2011 22:11 . Reden: Wat zaken verduidelijkt ]

[begintmeta]

BCC schreef op maandag 11 april 2011 @ 21:32:
...
Bij ons is dit de kern van Agile: de specificaties uit de klant (of verschillende klanten) trekken. Zelf het overzicht krijgen en het probleem van de klant echt oplossen!
...

Het is dus inderdaad een manier met de klant te communiceren, misschien wel de effectiefste manier, maar goed, daarvoor weet ik te weinig van ICT af.

[ Voor 3% gewijzigd door begintmeta op 11-04-2011 22:12 ]

[Verwijderd]

In het kort; ben stellig van mening dat er niet één methodologie kan zijn voor een 'groep projecten'. Hoewel XP/Scrum/RUP... en net zo goed het waterval-model goede best practices bevatten zal het zelden voorkomen dat één methodologie perfect geschikt is voor een project. Het met zijn allen periodiek reflecteren op elkaars werkaanpak is een basis die ik veel nuttiger acht. Hoe groter de ervaren problemen hoe meer nadruk je op de procesverbetering moet leggen; juist als de tijd en deadlines dit -weer- niet toelaten.

Om de hoofdvraag direct te beantwoorden: ja, waterval is de geprefereerde methode als je zelf de meeste domeinkennis hebt, dit domein stabiel is, en je alles zo kan specificeren dat je kan beginnen met programmeren door simpelweg bij punt 1 te beginnen en er lineair doorheen kan lopen. Lees: bijna nooit. Om dit punt te bereiken ben je ontzettend lang bezig (zo zou ik me kunnen voorstellen dat NASA alles vantevoren zo uitkauwd dat dit het geval is). Dit punt is zo duur dat elke project manager het project lang voor die tijd hoort te beeindigen.
Waterval 'paradox' (of beter planning paradox) is dat als je eenmeel dit punt als bedrijf bereikt je repetitief bezig bent en de noodzaak om alles te documenteren en vast te leggen bij de medewerkers verdwijnt; dit zou je dan moeten gaan afdwingen. Over het algemeen kan je d.m.v. code en architectuur een fatsoenlijke manier bedenken repeterend werk te versnellen waardoor je alleen de variabele code schrijft. Ik noem het niet voor niets variabele code; je verwacht dat dit nooit helemaal hetzelfde zal zijn en aan veranderingen onderhevig is, zoals bekend is het waterval model hiervoor niet ideaal. Andere termen hiervoor zijn generieke en specifieke code of abstractie en details. Zo heb ik ook ooit iemand horen zeggen een voorkeur te hebben voor waterval bij het definieëren van de kern van het programma en deze zo in te richten dat je verder agile aan de slag kan. Zelf niet zo'n voorstander van; heb nog nooit een architectuur gezien die volledig stabiel bleef, en als je dit wel nastreeft gaan mensen toch wel lelijke omwegen bedenken om het werkend te krijgen (of in zijn geheel nabouwen, iedereen wel bekend mee denk ik).

Wat me bij mijn eerdere werkgevers opviel dat alles over Xp/Scrum/DSDM/RUP/Waterval nooit fatsoenlijk word toegepast (we komen niet verder dan wikipedia). Zo heet een dagelijkse vergadering al snel scrum; en niemand die dat corrigeerd omdat we alles toch maar klakkeloos overnemen.
Niet dat dit slecht is, prima als het werkt, maar we schieten onderwater al snel door naar elementen van beide extremen (ad-hoc naar planned). Ad-hoc ging eerst prima maar we lopen tegen wat problemen aan; ow, laten we dat op deze en die manier voorkomen en schieten ons doel voorbij; we bouwen elementen in van wat we het waterval model of ad-hoc noemen. Twee voorbeelden:

• Documentatie wordt niet up-to-date gehouden (waar niet...?); we schaffen alle technische documentatie af omdat code zelf-documenterend hoort te zijn (degene die dit doorvoerde had een PhD)
• FO is ontoereikend; we vereisen een TO en verifiëren de uitwerking hiervan in code reviews

Bij het eerste voorbeeld lieten ze me (ik als buitenstaander) een stuk code zien die me een halfuur koste om te doorgronden waarvan ze zelf beweerden dat dit zelf-documenterend was. Abstracte/generieke code is NOOIT zelf-documenterend want hoe weet je precies hoe ik het wil gebruiken, wat mijn doelen zijn? Gelukkig zat er een unit-test bij en was dat effectief mijn documentatie (prima; helaas zitten lang niet overal unit tests bij).

Het tweede voorbeeld slaat door, en FO én controle. Wat als we de lijntjes tussen een analist en ontwikkelaar korter maken i.p.v. direct code reviews door te voeren en moeite nemen een TO op te stellen die vervolgens toch niet up-to-date wordt gehouden? Beide kosten toch extra resources. Of toch eens een keer wat pair programming met een senior developer bij het starten van een nieuw FO?

Ik noem hier de extremen ad-hoc en planned, en agile is wat mij betreft een variabele grens van gewenste formaliteit. Die formaliteit neemt toe/af door een waslijst aan variabelen (omvang, klant karakteristieken, kosten, wet & regelgeving, ...) en creëert de noodzakelijke (kortstondige) stabiliteit om vooruit te komen en je hoofddoelen te behalen, dus:
Ad-hoc (impliciet) --|-X-|------- Planned (expliciet)
Met X als een formaliteitsideaal en de |...| als Agile Margin (ik verzin het maar ter plekke).
Nu is dit nog maar één dimensie (ik heb er gezien met 9 die alleen Agile en Planned uitdrukken) maar hier al durf ik te stellen dat binnen de Agile Margin blijven bijzonder lastig kan zijn; hoe weet je welke expliciete procesaanpak je nodig hebt om het project tot een goed einde te brengen? Als je regelmatig reflecteert op je procesaanpak en formaliteitsideaal nastreeft dan ben je wat mij betreft goed bezig. Als je je zinnen zet op het toepassen van Xp/Scrum dan kun je in mijn ogen per definitie niet 'Agile' zijn. Evengoed zijn de meeste bedrijven dus wel -mogelijk onbewust- Agile bezig; gevoelsmatig komen we een heel eind. Het is alleen jammer dat dit proces zo pijnlijk kan zijn voor alle betrokkenen en we er pas werk van maken als het ons direct belemmerd in ons functioneren.

Van wat ik gelezen heb over Agile volgen de meeste Agile gurus deze redenering; de nadruk in de praktijk ligt hier echter vaak niet.

Handiger dan XP/scrum/etc. vind ik organizational patterns (een soort van voorloper en inmiddels paralelle stroming aan Agile). Er zitten ontzettend veel overeenkomsten in de twee en ze lenen veel onderlinge concepten aan elkaar uit. Patterns verschillen met Agile dat dit kleine best practices zijn op organisatieniveau (verwant -en vaak zelfs op dezelfde manier beschreven als- design patterns) die de meeste van ons vanzelf wel verzinnen en toepassen; ze geven alleen duidelijk aan waarmee ze verwant zijn en vormen zo een pattern language; een set aan best practices die elkaar versterken. XP, Scrum, RUP, etc. kun je zien als instanties van zo'n pattern language. Door te makkelijk te spreken over wat XP en Scrum zijn zien we niet hoe de individuele practices elkaar horen te versterken en werken we uiteindelijk met een halfbakken instantie van wat individuele best practices.

Hier is een voorbeelden van wat (bijna triviale maar daarom niet minder belangrijke) patterns:
http://users.rcn.com/jcoplien/Patterns/Top10OrgPatterns.html

Een daily meeting is bijvoorbeeld zo'n pattern (waarvan ik uitga dat binnen softwareontwikkeling deze praktijk voor het eerst in Scrum beschreven is, maar zeker weet ik dit niet; ben er wel zeker van dat dit al veel eerder en buiten softwareontwikkeling gangbaar was).

Je hebt een hele bak literatuur van die patterns, met name Organizational Patterns of Agile Software Development geeft de link tussen beide goed aan en is gelijk een goed naslagwerk van dergelijke patterns.

Ik denk dat je binnen die patterns het beste antwoord kan vinden op 'Is Waterval nog nuttig'? Elk element van je procesaanpak kan je formaliseren, de grote vraag is waarom je dat wilt. Bouw je pacemaker-software dan zou ik je testprocedures zo duidelijk maken dat een kind nog weet wat er precies gedaan moet worden, je wilt volledigheid kunnen garanderen. Maakt het dan veel uit of je ontwikkelproces daarvoor formeel is? Wat mij betreft totaal niet; als je het werkend krijgt schep je mogelijk de ruimte om sneller te innoveren. Of je dat aandurft of kan door wet en regelgeving is een tweede.

[ Voor 8% gewijzigd door Verwijderd op 12-04-2011 08:39 ]

[YopY]

Ik ben zelf sinds kort betrokken in een project dat onderdeel is van een groter waterfall-project, waarbij ons team eigenlijk alleen maar agile projecten doet. Het project dat wij gaan doen is ook fixed-price, en de klant weet nog weinig tot niks van het agile model van werken, dus die moeten we van alles gaan uitleggen. Er werd ook ietwat geschrokken / paniekig gereageerd toen we aangaven dat we eigenlijk elke week een sessie willen houden waarbij het programma getest wordt door de klant - daar hadden ze geen resources voor gereserveerd.

Een interessante eerste opdracht wel, ik vraag me af of het uiteindelijk goedkomt. De opdracht zelf is eigenlijk niet zo'n grote uitdaging (web front-end maken voor een setje back-end services, databasetabellen en JMX-interfaces die we allemaal aangeleverd krijgen), het projectmanagement en klantcontact lijken me de grotere uitdaging.

[Verwijderd]

Het waterfall model staat los van hoe je iets commercieel aanbiedt. Het is een sales discussie en geen project discussie. Ook bij scrum kom je in commerciële discussies terecht, het is aan de scrummaster om de betrokken daarin te sturen.

En zoals altijd moet je de methodiek pakken die het beste aansluit bij een project. Er is geen silver bullet, de ene keer is Scrum de beste aanpak, de andere keer Prince2 (in meer of mindere mate, je hoeft er niet alles van te gebruiken).

Daarnaast zijn veel zaken wél prima technisch in te schatten en is een fixed price insteek de basis om die opdracht binnen te slepen. Sometimes you loose, but most times you win.

Er zijn ook veel manieren om het voortraject aan te vliegen. Kleine trajecten kun je prima op een hoop gooien, maar in grotere trajecten kun je prima het requirements en analyse deel als losse opdracht aannemen.

Op basis van die requirements kan er dan een accuratere inschatting komen waarin je uiteraard een percentage hanteert voor de altijd aanwezige onvoorziene kosten.

Op basis van die requirements is de klant ook vrij om een andere technische partner aan te haken, maar dan gaat die altijd weg met een bruikbaar deliverable; een requirements document.

Alle discussies over geld, verwachtingen, scope, dienen al plaats te hebben gevonden voordat het project start. Als er geld bij moet, dan moet die mogelijkheid en de wijze waarop al in het sales traject besproken en beklonken zijn.

[ Voor 18% gewijzigd door Verwijderd op 12-04-2011 11:46 ]

[Killemov]

Verwijderd schreef op dinsdag 12 april 2011 @ 11:38:
Het waterfall model staat los van hoe je iets commercieel aanbiedt.

Dat is echt complete BS. Je projectfasering kan bijvoorbeeld direct gekoppeld zijn aan betaalmomenten. Als je Agile wilt toepassen, dan moet je dus afspreken dat de klant daar ook resources voor vrij maakt. Dat kan een argument zijn voor een klant om af te haken en daar moet je dus commercieel gezien rekening mee houden.

[majoh]

Werkend bij een groot consultancy bedrijf kan ik zeggen dat het heel moeilijk voor ons is om Agile projecten te doen. Terwijl wij (als dev onderdeel) dat heel graag zouden willen. Hieronder problemen die we tegen komen:

1. Klant is niet bereid om elke week bijeen te komen. Veel voorkomende uitspraak is, 'daar hebben we geen tijd voor'. Daarnaast willen ze wel kortere iteraties zien omdat ze gehoord hebben dat dat goed werkt. De klant moet willend zijn mee te doen in de iteraties, als dat niet gebeurd dan kun je nooit volledig Agile gaan werken.
2. Klant ziet stapje voor stapje functionaliteit verschijnen en ziet daardoor alleen maar dingen die missen. Omdat ze vaak alleen het grote plaatje zien, kunnen ze zich heel moeilijk inbeelden hoe alles samen gaat werken. Nu lijkt dit een persoonlijke kwestie, maar heb dit met meerdere klanten al meegemaakt.
3. Klanten willen graag documentatie goedkeuren voordat er ook maar iets begint. Ze willen weten wanneer alles klaar is, en hoe er precies gepland gaat worden.
4. Klanten missen controle en gevoel van zekerheid, doordat alles gaandeweg beslist wordt.
5. Alles moet goedkoper en dus offshore en veel juniors. Bij offshore wordt communicatie met de klant moeilijker. Er zijn wel mogelijkheden, maar het gaat allemaal minder prettig. En junioren kun je moeilijk loslaten zonder designs.

Dit zijn de voornaamste redenen dat wij moeilijk compleet Agile projecten doen. Een van de oplossingen is om gewoon een waterval methode aan te houden voor alles waar de klant inzicht en zeggenschap op heeft, maar het dev traject wel een soort van Agile doen. Echter moet je hier wel echt goede mensen voor hebben om het voor elkaar te krijgen. Meerdere junioren in een project hun 'gangetje' laten gaan zonder goed technisch design is vragen om problemen...

Waterval is mijn inziens ook een achterhaald concept. Theoretisch werkt het, echter wensen veranderen nu eenmaal, waardoor er te vaak een 'change' komt op de verwachte functionaliteit. Echter, het waterval proces is voor managers heel makkelijk. Ze hebben voor hun gevoel meer 'controle' op het geheel omdat overal een proces met goedkeuring voor staat.
Agile, en Scrum, is in mijn ogen een veel beter concept, waarmee veel sneller en beter applicaties gemaakt kunnen worden. Nadeel is wel dat je meer ervaren personen moet hebben om het in goede banen te leiden. Dit laatste is een probleem omdat alles goedkoper moet. Daarnaast moet de klant mee willen werken in het proces, en klanten zijn niet altijd te overtuigen.

[Signum666]

CodeCaster schreef op maandag 11 april 2011 @ 09:44:
[...]
Als je complexe processen aan het automatiseren bent waarbij de opdrachtgever zelf amper weet wat er eigenlijk in de hoofden van de medewerkers zit, kom je er pas gedurende het ontwikkelen en testen achter wat er precies allemaal moet gebeuren. Als je dan halsstarrig gaat weigeren om aanpassingen in het ontwerp te doen terwijl het product zonder die aanpassingen onbruikbaar is...

Je gaat processen automatiseren terwijl je niet weet wat de processen zijn? Ga eerst maar eens helder krijgen wat de processen precies zijn.. Als je er tijdens het ontwikkelen en testen pas achter komt doe je toch echt iets verkeerd.

Het is overigens niet "halsstarrig" weigeren van aanpassingen. Je moet pas gaan bouwen als het ontwerp klaar en afgetekend is. Kleine aanpassingen kunnen altijd, maar grote aanpassingen kun je gewoon niet doen. Dat is hetzelfde als een aannemer vragen het huis even een kwartslag te draaien terwijl de fundering er al in zit.

[CodeCaster]

Dat zeg ik toch niet? Wat ik in mijn (wederom toegegeven: niet enorm grote) ervaring heb meegemaakt is dat klanten (ja, meervoud) een proces volgens hen volledig op papier hebben staan, waardoor jij kunt gaan bouwen. Vervolgens komen er tijdens het regelmatige testen toch nieuwe randvoorwaarden en uitzonderingen naar boven, omdat er in het proces toch blijkbaar zaken voorkomen die slechts een beperkt aantal medewerkers weten en die niet op papier staan.

Dan kun je twee dingen doen: vasthouden aan het oorspronkelijke document, of met de klant in conclaaf gaan en kijken welke features voor hem het belangrijkst zijn, gezien tijd en budget niet eindig zijn.

Wederom, niet alleen in de ICT is het een utopie dat alles keihard volgens gangbare modellen op papier staat. Als dat zo zou zijn dan waren die processen bij die klanten allang eerder geautomatiseerd. Als het een kwestie is van papier vertalen in code zou het overleg en vele testen ook niet nodig zijn.

Ik kan me daarom nog steeds niet aan de indruk onttrekken dat "tegenstanders" van het doorvoeren van (let wel: niet fundamentele, hier sta ook ik pertinent niet achter) wijzigingen gedurende het ontwikkelproces zich bezighouden met het ontwikkelen van systemen waarvan zij meer weten dan de klant. De eerder door mij genoemde webshop bijvoorbeeld, die uit relatief kant-en-klare brokken bestaat, waarbij de basisfunctionaliteit behouden blijft als de klant iets niet beschrijft, omdat jij als ontwikkelaar weet wat er allemaal nodig is voor de processen die in dergelijke software lopen.

[ Voor 51% gewijzigd door CodeCaster op 12-04-2011 13:21 ]

[MSalters]

EfBe schreef op maandag 11 april 2011 @ 13:26:
Waterfall kan handig zijn, wanneer je bv productontwikkeling doet: je functionele eisen staan nl. vanaf het begin vast en dat wil je ook zo houden, anders release je nl. nooit. Veel software dat we dagelijks gebruiken wordt op deze manier gemaakt. Bijna alle microsoft software is feitelijk waterfall based: er wordt pas software gemaakt wanneer de functionele specs helemaal af zijn. Op zich is dit logisch, want development vindt veelal plaats in grote dev centra in India of China en dan wil je dat alles vastligt wat gemaakt moet worden.

Welnee. Neem nu een recent product als Visual C++ 2010. Dat is grotendeels gebaseerd op de C++11 drafts. Die specs waren dus nog niet eens af toen het product gereleased werd.

Ook wordt er door Microsoft niet eens zoveel ge-outsourced naar China en India. Dat zijn juist de projecten waarbij de functionele eisen niet vast staan, maar continu door een team hier worden geupdatet. Juist dan moet je nogal eens code weggooien, en helpt het dus het meest als de code goedkoop is.

[Remus]

Signum666 schreef op dinsdag 12 april 2011 @ 13:06:
[...]
Je gaat processen automatiseren terwijl je niet weet wat de processen zijn? Ga eerst maar eens helder krijgen wat de processen precies zijn.. Als je er tijdens het ontwikkelen en testen pas achter komt doe je toch echt iets verkeerd.

Het is overigens niet "halsstarrig" weigeren van aanpassingen. Je moet pas gaan bouwen als het ontwerp klaar en afgetekend is. Kleine aanpassingen kunnen altijd, maar grote aanpassingen kun je gewoon niet doen. Dat is hetzelfde als een aannemer vragen het huis even een kwartslag te draaien terwijl de fundering er al in zit.

Er is een verschil tussen het bestaande papieren (of legacy) proces automatiseren, of een verbeterd proces opzetten. Feit blijft (en blijkt ook gewoon uit jaren onderzoek naar requirements engineering, usability, software ontwikkeling ed), dat 1) klanten niet altijd 100% weten wat ze willen, 2) klanten niet altijd weten wat er allemaal mogelijk is, 3) klanten en ontwikkelaars niet altijd even duidelijk en helder met elkaar communiceren, 4) je vaak niet de mensen te spreken krijgt met de juiste domeinkennis, 5) gedurende een ontwikkelproces er toch nieuwe inzichten boven komen, etc etc.

De agile methodes zoals scrum bieden daar juist gestructureerd(!) invulling aan, dus niet ad-hoc zoals sommige mensen in dit topic lijken te denken. Je legt vooraf in hoofdlijnen vast wat er moet gebeuren, dat wordt verder uitgediept en gaandeweg het ontwikkelen wordt daar meer invulling aan gegeven en kan er bijgestuurd worden (zowel op volgorde als op inhoud) aan de hand van gewijzigde prioriteit, nieuwe inzichten of nieuwe kansen in de markt.

[Verwijderd]

Killemov schreef op dinsdag 12 april 2011 @ 11:47:
[...]

Dat is echt complete BS. Je projectfasering kan bijvoorbeeld direct gekoppeld zijn aan betaalmomenten. Als je Agile wilt toepassen, dan moet je dus afspreken dat de klant daar ook resources voor vrij maakt. Dat kan een argument zijn voor een klant om af te haken en daar moet je dus commercieel gezien rekening mee houden.

Lees svp wat ik schreef. Als je projectfasering is gekoppeld aan betaalmomenten dan is dat juist een sales discussie die zich vertaald in hoe ea financieel wordt opgepakt. Die betaalmomenten passen wij in zowel waterfall als in scrum toe. Bij milestones, cq. eindigen van een sprint.

De methodiek staat dus los van hoe je administratief de financiële afhandeling regelt. Desnoods is er door de account manager afgesproken dat er wekelijks, maandelijks, jaarlijks, per kwartaal, performance ratio, geheel vooraf, geheel achteraf, 40/60, 60/40, vul model in wordt gefactureerd.

Als je agile wilt ontwikkelen dan zijn er meerdere aanvliegroutes mogelijk. Op basis van je initiële backlog, op basis van het aantal sprints, op basis van de voor gealloceerde hoeveelheden aan resources.

Met scrum bepaalt de klant zelf op basis van de beschikbare tijd per sprint welke items hij uit het backlog wel en welke niet wil gaan meenemen in de demo.

Je stelt dat de allocatie van klant resources een argument kan zijn voor afhaken; misschien moet je me uitleggen waarom de klant bij een waterfall model geen resources hoeft vrij te maken. In mijn wereld is er ook bij de klant - om één van de vele voorbeelden te noemen - altijd een user acceptance test.

Als je bij scrum de backlog continue aanvult met nieuwe wishes dan zal er mogelijk een nieuwe sprint nodig zijn. Het is aan de klant (want die kiest immers als stakeholder) om binnen de ruimte die er is keuzes te maken. Als je bij waterfall de scope gaat uitbreiden idem.

Vanaf dat punt gaan simpelweg de financiële afspraken lopen die er zijn gemaakt en is het aan de klant om te kiezen wat hij/zij wil doen.

[Killemov]

@Gordijnstok: Ik dacht het toch al zo begrepen te hebben. Mijn punt is dat de te kiezen ontwikkelmethodiek wel van commercieel invloed of zelfs belang kan zijn.

Mijn ervaring heeft geleerd dat het soms wel eens handig kan zijn om een project "verticaal" op te delen. Dus van een groot systeem een kleiner deel geheel implementeren. Uiteraard wel rekening houdend met de rest van het systeem door bijvoorbeeld eerst een bepaalde architectuur uit te werken en de hoofdlijnen vast te leggen. Zo kan ontwikkeling van subsystemen ook geparallelliseerd worden.

[mOrPhie]

Het valt me op dat mensen Agile vooral koppelen aan "veranderingen van de klant accepteren" in plaats van "reageren op verandering". Een klant kan halverwege wel een wens hebben, maar zolang deze buiten scope is en de impact groot, dan is het killing voor een project om dan toch te zeggen: ok, we zetten het op de lijst. Dan blijf je namelijk dingen op de lijst zetten en heb je aan het einde van je iteratie niet meer opgeleverd wat je had beloofd. "Responding to change" is dan ook, in mijn optiek, vooral het gesprek met de klant aangaan die gepaard gaan bij de tradeoff van het veranderen van de spec vs. de wens opschuiven naar volgende fase. Als je functionaliteit op de lijst blijft zetten en daar geen functionaliteit voor inlevert, dan zul je op andere zaken moeten inleveren. En wat is dat dan? Kwaliteitswaarborging? Projectmanagement? Scope-creep is een enorm risico. Ook voor agile projecten.

Een fijn aspect van agile vind ik "working software". Ik heb projecten gedaan waar we na 1 iteratie al iets konden installeren bij de klant en de klant er al mee kon spelen. Dat werkt bijzonder prettig, want de klant ziet vooruitgang, ziet dat hetgeen gemaakt wordt overeenkomt met de specs en als er wensen/wijzigingen zijn, dan heb je die in een vroeg stadium gevonden. De big bang blijft zo uit en dat maakt het proces ook veel natuurlijker. Die feedback-loop krijg je niet met waterval. Het gesprek tussen klant en leverancier blijft abstract en met af en toe een gelikte demo waarbij je natuurlijk niet op de knopjes gaat klikken die crashen...

Het is de balans tussen flexibiliteit en standvastigheid die uiteindelijk procestechnisch je succes bepaald. Flexibel zijn is één ding, maar een professional zegt ook wel 'ns (onderbouwd) nee tegen een klant. Gek genoeg vinden (de meeste) klanten dat juist prettig.

[chime]

Bij agile zou elke sprint iets werkbaars moeten opleveren. Zo kan de klant inderdaad al wat spelen en ziet hij het project groeien.

Ook mag een sprint natuurlijk geen nieuwe scope krijgen => dat is dan eerder iets voor de volgende sprint.

[Janoz]

chime schreef op woensdag 13 april 2011 @ 08:57:
Ook mag een sprint natuurlijk geen nieuwe scope krijgen => dat is dan eerder iets voor de een volgende sprint.

[EfBe]

MSalters schreef op dinsdag 12 april 2011 @ 13:23:
[...]
Welnee. Neem nu een recent product als Visual C++ 2010. Dat is grotendeels gebaseerd op de C++11 drafts. Die specs waren dus nog niet eens af toen het product gereleased werd.

Bij C# is het wel degelijk het geval dat ze eerst alle specs helemaal uitkouwen en dan gaan bouwen. Te vaak in discussies gezeten met ze waarbij na een tijdje bleek dat ze helemaal geen veranderingen meer konden doorvoeren omdat specs al gefinalized waren, soms 1.5, 2 jaar voor release. Ook VS.NET an sig wordt zo gebouwd. Wellicht dat compilers op sommige gebieden flexibel worden gehouden wanneer specs nog niet gefinalized kunnen worden, mijn indruk was iig dat het merendeel compleet vooraf werd gedesigned.

Het is ook logisch, met duizenden klanten heb je ook duizenden meningen en dan kun je niet anders doen dan wat je zelf het beste vindt.

[OMX2000]

De vraag is van de TS is niet te beantwoorden. Ieder product/project/team/organisatie vergt een andere aanpak. Waterval is voor mij niet afgeschreven, vind er alleen heel weinig aan. Ik ben nogal sociaal/communicatief aangelegd. Ik vind het juist heel fijn om op het raakvlak tussen opdrachtgever en ontwikkelaar/bouwer/aannemer te zitten.

Ik vergelijk waterval eerder met het bouwen van een gemiddeld huis in Nederland (dus sorry Belgen dat zelf bouwen komt ff niet goed uit voor mijn voorbeeld ). Beide partijen hebben een goed overeenkomend beeld van wat een huis is en hoe het eruit moet komen te zien. Een architect ontwerpt het huis, en een aannemer stelt een planning op. De huizenkoper is in het begin betrokken bij eventuele selecteren van allerlei opties, en mag dan een klein jaar wachten tot het uiteindelijke resultaat daar is. Dat gaat over het algemeen goed.

Bovenstaande aanpak werkt zoals een aantal al gezegd hebben voor bijvoorbeeld het realiseren van bijv. een rekenmodel of een compiler. Bij maatwerk wordt het lastiger. Een klant weet vaak niet wat hij zal krijgen doordat hij niet bekend is met de (nieuwe?) technologie. Als je dan dingen hoort als "ik wil ook zo'n mooie HTML5 site" of "doe mij ook zo'n SharePoint" weet je dat je met een waterval aanpak niet ver zult gaan komen.

Waarom het nog als zo lastig ervaren om software te bouwen? Een belangrijke reden is slechte kennisborging (IT industrie wijd). Met slechte kennisborging bedoel ik dat de kennis die opgedaan wordt in projecten/bedrijven behoorlijk vluchtig is. Je hoort heel vaak dat oude rotten in het vak zeggen dat zij dezelfde problemen 30 jaar geleden ook al hadden. En waarom zijn die problemen er nog steeds dan? Omdat we te weinig van onze ervaring overdragen aan anderen.

Veel mensen zeggen dat project methodieken technologie agnostisch (yeah I said it) moeten zijn. Maar da's volgens mij kul. Door de tooling van tegenwoordig kun je in een heel korte tijd (soms zelfs real time) een klant/gebruiker een indruk geven van hoe de uiteindelijke toepassing gaat werken. Die mate van interactie creëert een hele andere dynamiek in projecten.

Ik denk dat we het onszelf veel te moeilijk maken. We lopen steeds maar achter alle nieuwe aanpakken (Scrum, XP, Lean/Kanban, RUP, DSDM etc) aan. We willen liefst met de nieuwste technologie werken. En onze applicaties moeten voorzien van de nieuwste fads (Social, Web 2.0, SOA, RESTful).

Ironisch genoeg denk ik dat als je met een redelijk vast team een paar jaar software bouwt op z'n Agiles, je eigenlijk geen Agile development meer hoeft te doen. Een ontwikkelaar heeft bij wijze van spreken aan een woord genoeg waarom zou je dan steeds bij elkaar komen om zaken af te stemmen die je toch al weet.

[drm]

Wie kan me een (aantal) goed(e) boek(en) aanraden over Agile methodes? E-books ook goed, natuurlijk. Ik wil me er iets meer in gaan verdiepen de komende tijd.

[leendertv]

Wij doen de grote projecten voor klanten tegenwoordig eigenlijk altijd op een agile manier.

Het begint dan met enkele meetings met de klant om duidelijk te krijgen wat ze willen.
De globale specificaties worden opgesteld en verdeeld in fasen (iteraties). Belangrijke beslissingen over de te gebruiken techniek en dergelijke worden genomen. Voor elke fase wordt in overleg met de klant het aantal benodigde uren geschat en dit in een contract vastgelegd.

Vervolgens duurt elke fase meestal zo'n maand. 3 weken programmeren en 1 week testen door ons en de klant + fixes. Elke fase begint met een meeting met de klant waarin de vorige fase geëvalueerd wordt.
Daarnaast worden de specificaties voor de nieuwe fase doorgesproken en verder uitgewerkt en vastgelegd.
Functionaliteit wordt gedefinieerd als must haves of nice to haves.
De must haves worden gerealiseerd in de gereserveerde tijd voor de fase, is er nog tijd over dan kunnen nice to haves ook mee genomen worden. De klant kan natuurlijk altijd tijd bijkopen om meer nice to haves te kunnen realiseren.
In de laatste week van de fase wordt de opgeleverde functionaliteit getest door klant en kunnen er nog fixes plaats vinden.

Ik vind dit voor veel grote projecten veel beter werken dan de waterval methode.
Er wordt veel gecommuniceerd met klant, de klant is erg betrokken bij het project en er kan snel bijgestuurd worden.

drm schreef op vrijdag 15 april 2011 @ 14:48:
Wie kan me een (aantal) goed(e) boek(en) aanraden over Agile methodes? E-books ook goed, natuurlijk. Ik wil me er iets meer in gaan verdiepen de komende tijd.

Als 't vaag is, dan willen we niet dat hier naar eventueel warez wordt gehint

[ Voor 12% gewijzigd door BtM909 op 28-04-2011 14:22 ]

[djluc]

Dat klinkt inderdaad top. Als ik het goed begrijp is hier dus geen budget, dat is de vraag die vrijwel altijd komt in kleinere projecten. Hoeveel kost het geheel dan? Dan past Agile simpelweg niet mijns inziens.

[OMX2000]

djluc schreef op vrijdag 15 april 2011 @ 15:12:
Dat klinkt inderdaad top. Als ik het goed begrijp is hier dus geen budget, dat is de vraag die vrijwel altijd komt in kleinere projecten. Hoeveel kost het geheel dan? Dan past Agile simpelweg niet mijns inziens.

Je kunt fixed price/time projecten goed doen met Agile. Is misschien zelfs nog beter ook. Je kunt het "spel" dan beter spelen. Je hebt alleen de te bouwen functionaliteit als variabele. En je blijft in onderhandeling met wat de opdrachtgever het belangrijkste vindt, en aan het eind van het project heeft ie misschien niet alles wat hij in het begin wilde, maar wel de belangrijkste dingen. Als blijkt dat er een belangrijke functionaliteit niet gebouwd is, is dat omdat a) de klant zij rol niet goed gespeeld heeft of b) het ontwikkelteam zelf de iteratie planning aan zijn laars gelapt.

[Janoz]

Maar misschien nog wel het aller grootste voordeel is dat de klant gedurende het hele traject al de progressie ziet. Al heel snel kun je op je BurnDown zien hoe je uit lijkt te komen. Als je op 10% van je project bent is het veel simpeler om met de klant de scope te heroverwegen. Bij waterval zie je over het algemeen dat enkele weken voor de deadline nog even compleet out of the blue gemeld wordt dat het echt niet te halen is en dat er een paar maand bij moeten.

[ Voor 43% gewijzigd door Janoz op 15-04-2011 15:36 ]

[leendertv]

Projecten volgens de waterval methoden hebben bij ons meestal ook een veel langere vervelende nasleep. Er komen na de oplevering allerlei apen uit de mouw, bepaalde dingen lijken in de praktijk toch niet zo lekker te werken...etc.
Het werkt veel beter als de klant bij elke fase al kan uitgebreid testen en er evaluatie en bijsturingsmeetings plaats vinden. Alles van te voren vast zetten in ontwerpen en daarna gaan bouwen + oplevering werkt in de praktijk vaak gewoon niet.

Meestal weet de klant ook helemaal niet echt wat ze willen. Daardoor zijn ontwikkelprojecten meestal zo lastig.
Een klant heeft meestal al een heleboel eisen, dingen die ze bij concurrenten gezien hebben enzo.
Beter is het om eerst een stap terug te doen. Wat is het probleem wat opgelost moet worden en wat wil je bereiken (de automatisering is niet het doel maar een middel).
De taak van de ICT organisatie is om de juiste techniek te kiezen om de klantbehoefte zo goed mogelijk te realiseren.

[Gomez12]

begintmeta schreef op maandag 11 april 2011 @ 08:50:
Als ik het hier zo lees vraag ik me af of/waarom het in de ICT zo lastig is uit te vinden wat de behoeften van klanten zijn.

Omdat de ICT zo snel veranderd...
Als je nu iets bedenkt en het over 6 maanden oplevert dan is er zoveel verandert (aan techniek en aan klantkant) dat het bij oplevering al zo goed als veroudert is...

Simpel voorbeeldje is bijv een notificatie dienst. Dat wil de klant erin, qua planning gaat er pas over 5 maanden mee begonnen worden. Dan kan je nu alles 100% gaan uitdenken en over 2 maanden een hyves/twittes/facebook een totaal nieuwe notificatiemanier zien uitdenken die jij bij oplevering er niet in hebt zitten, of je kan over 4 maanden eens dat gaan uitwerken en de nieuwe methodes meenemen...

Voor de klant is het veelal zien is geloven. Je kan droog alles opschrijven maar als de klant over 1 maand iets ziet wat hij leuk vindt bij een t.net/hyves/weet ik veel waar dan wil hij dat erin hebben.
Hij kan het nu niet weten als hij het pas over een maand gaat zien...

[Gomez12]

djluc schreef op vrijdag 15 april 2011 @ 15:12:
Dat klinkt inderdaad top. Als ik het goed begrijp is hier dus geen budget, dat is de vraag die vrijwel altijd komt in kleinere projecten. Hoeveel kost het geheel dan? Dan past Agile simpelweg niet mijns inziens.

Agile betekent niet dat je niet een scope in grote lijnen kan neerzetten.

Wat ik weet van enkele softwarehuizen is dat ze meestal het project in kleinere delen ophakken, per deel geven ze een schatting af hoelang het gaat duren / hoeveel het gaat kosten. De klant gaat akkoord met de grote lijnen.

En als dan gaandeweg blijkt dat voor een onderdeel wat ingeschaald is op 2 weken de klant zo weinig wensen heeft dat het in 1 week klaar is dan is er voor de rest meer tijd voor andere wensen.
Heeft de klant zoveel wensen dat het op 2 maanden uitkomt dan krijgt de klant gewoon de vraag wat hij wil :
- Extra mensen erop ( dus extra kosten )
- Extra uitloop (dus extra kosten )
- Op de overige delen beknibbelen
- Zijn wensenpakket voor dit gedeelte herevalueren naar wat hij er nu in wil hebben en wat er aan het einde van het project als extra bij kan komen.

Bij het merendeel van die softwarehuizen ben je dan ook goedkoper uit als de initiele prijs als je geen additionele wensen hebt. De prijs is berekend op enkele additionele wensen...

[Avalaxy]

drm schreef op vrijdag 15 april 2011 @ 14:48:
Wie kan me een (aantal) goed(e) boek(en) aanraden over Agile methodes? E-books ook goed, natuurlijk. Ik wil me er iets meer in gaan verdiepen de komende tijd.

Ligt er een beetje aan welke methode je wilt hanteren. De "algemene" boeken over Agile zijn naa rmijn ervaring niet zo geweldig, omdat ze heel algemeen de practices beschrijven maar niet uitleggen hoe je deze direct toe kunt passen.

Voor Scrum vind ik het boek Scrum and XP from the trenches een ontzettend goed boek(je). Niet te dik, geen vreselijk saai theorie, maar gewoon simpel (doch heel goed) uitgelegd aan de hand van illustraties en praktijkvoorbeelden

[Verwijderd]

drm schreef op vrijdag 15 april 2011 @ 14:48:
Wie kan me een (aantal) goed(e) boek(en) aanraden over Agile methodes? E-books ook goed, natuurlijk. Ik wil me er iets meer in gaan verdiepen de komende tijd.

Meeste boeken vind ik vrij slecht, twee zou ik zelf aanraden:
- Agile Software Development Ecosystems, meer de filosofische insteek van Agile. Niet zo'n goed geschreven boek maar wel één lang herkenningsverhaal en duidelijke beschrijving wat Agile nou is. Geen praktische toepassingen echter.
- Agile Software Development, Principles, Patterns, and Practices, stuk praktischer aan de hand van code voorbeelden de XP practices. Doorbijtertje maar ik vond het erg nuttig (zelfs als niet-programmeur).

Over Scrum heb ik twee boeken maar vind ze beiden bagger. Uit de trenches (Avalaxy) ken ik niet. Boeken die ik noem zijn waarschijnlijk wat zwaarder.

[BCC]

Voor Agile software developen is the agile samurai toch wel een beetje de nieuwe bijbel aan het worden: http://pragprog.com/titles/jtrap/the-agile-samurai

[Verwijderd]

Janoz schreef op vrijdag 15 april 2011 @ 15:36:
Bij waterval zie je over het algemeen dat enkele weken voor de deadline nog even compleet out of the blue gemeld wordt dat het echt niet te halen is en dat er een paar maand bij moeten.

Dat heeft meer te maken met gebrekkig project management (waaronder forecasting) dan de gebruikte methodiek. Daar bestaan dus de bekende highlight reports voor.

[ Voor 6% gewijzigd door Verwijderd op 28-04-2011 10:58 ]

[Verwijderd]

Ik geloof eigenlijk dat geen een methodiek de 'heilige graal' is en denk dat per project het zeker verstandig is te kijken wat in die specifieke setting (soort project, grootte, soort klant, etc) het beste kan werken.

Indien je hele strakke specs hebt die je goed qua uren in kunt schatten is waterval zeker geen slechte methode, maar gezien deze methode oorspronkelijk uit de bouw wereld komt betekent dit vaak wel dat het voortraject echt alles afgekaderd en uitgedacht dient te worden en er daar ook aan gehouden wordt tijdens het productie proces.

In web projecten, voornamelijk websites, heb ik gemerkt dat waterval vaak te stug is en dat er bijna altijd dingen over het hoofd worden gezien qua functionaliteiten, verwachtingen uiteenlopen of gewoon het feit dat er veel partijen zich mee bemoeien die allemaal een andere invalshoek en prioriteiten hebben (marketing, sales, directie) .

Ik heb meegemaakt dat een bepaalde afdeling van de klant al goedkeuring gegeven had voor een website waarna de marketing afdeling ook ineens zijn zegje wilde doen en het bij de klant intern bijna uitdraaide op een rel tussen verschillende afdelingen. Dit project liep uiteraard uit op een drama waarbij eigenlijk niemand meer overzicht had op de requirements, de uren of de planning.

Wat mij vooral bevalt aan scrum/agile/kanban is dat het heel simpel en plat is. Ook qua tools software heb je geen dure paketten nodig of grote onoverzichtelijke schema's. Nog een voordeel is dat alle partijen nauw betrokken worden bij het proces en er zou automatisch een betere communicatie plaats vind. Vooral bij scrum zijn de korte meetings erg prettig en 'dwingen' mensen om to the point te zijn.

Door gebruik te maken van kleine subtrajecten / sprints is het heel simpel om de planning in de gaten te houden, ook geeft tijdens een sprint een burndown chart in 1 oogopslag aan of alles op schema zit en is het ook altijd meteen inzichtelijk waar het eventueel fout gaat.

Dat laatste klinkt enigszins als ' de mogelijkheid hebben om vingertje te wijzen' en ja, dat is het ook wel een beetje, maar in mijn ogen kun je niets oplossen/verhelpen/volgende keer verhelpen als je niet weet waar het probleem ligt.

De ICT problemen bij de overheid is hier volgens mij wel een goed voorbeeld van, projecten lopen compleet uit de klauwen qua planning en kosten en niemand kan / wil / durft aan te geven waardoor of door wie dit komt.

Het is al erg dat er zoveel fout gaat en verspild wordt hierdoor, maar het is echt om te janken dat er dan ook geen les uit getrokken wordt.

[ Voor 4% gewijzigd door Verwijderd op 04-05-2011 00:17 ]

[Grijze Vos]

Verwijderd schreef op woensdag 04 mei 2011 @ 00:09:
De ICT problemen bij de overheid is hier volgens mij wel een goed voorbeeld van, projecten lopen compleet uit de klauwen qua planning en kosten en niemand kan / wil / durft aan te geven waardoor of door wie dit komt.

Als je weet hoe aanbestedingstrajecten gaan dan snap je ineens waarom zeg maar -elk- project uit de klauwen loopt.

Eerst wordt er een aanbesteding uitgevaardigd, bedrijven maken een offerte. Een extern bureau filtert dan de niet volledige offertes eruit (formuliertje X vergeten? -> weg). Van de overgebleven offertes gaan dan de drie goedkoopste naar de beslissers, en die kiezen er dan een uit.

Maar ja, als de duurste offertes een 30% boven de drie goedkoopste zitten, waar komt dat dan door? Iemand moet daar ergens een inschattingsfout maken, en dat zal vaak zat degene zijn met de goedkopere inschatting.

[Comp_Lex]

Volgens mij kun je gerust waterval gebruiken voor kleine (sub)systemen (< 25 kloc).

[D4V3]

offtopic:
Agile, Waterval...

[YopY]

Comp_Lex schreef op donderdag 05 mei 2011 @ 11:16:
Volgens mij kun je gerust waterval gebruiken voor kleine (sub)systemen (< 25 kloc).

Volgens mij zou projectgrootte ten eerste niet uitgedrukt hoeven worden in lines of code, en ten tweede geen factor moeten zijn in de gekozen aanpak. Immers, de keuze voor waterval of agile kun je maken voordat je project begint, en op dat moment weet je niet (lees: hoor je niet te weten) hoeveel code er uitkomt - je weet slechts wat er (ongeveer) gemaakt moet worden. Daar zijn ook wel systemen voor, maar de hoeveelheid daadwerkelijke code die daaruitkomt is niet te raden.

BCC schreef op donderdag 28 april 2011 @ 10:52:
Voor Agile software developen is the agile samurai toch wel een beetje de nieuwe bijbel aan het worden: http://pragprog.com/titles/jtrap/the-agile-samurai

Ziet er goed uit, ook al (alleen vanuit de beschrijving) veel herkenbare zaken uit het project dat we nu doen.

* YopY zit in een agile-boerderij, bij een project van een klant uit de waterval-boerderij. Culture shock much?

[ Voor 25% gewijzigd door YopY op 06-05-2011 23:53 ]

[Comp_Lex]

Je kunt uiteraard ook tijdens development gewoon switchen van proces als het huidige proces je niet bevalt
Een gehele switch is misschien niet altijd mogelijk, maar bepaalde elementen van je huidige proces zou toch makkelijk vervangbaar moeten zijn door elementen van een ander proces. Uiteraard doe je dit op een manier waarbij je de klant het minst lastigvalt

[Hydra]

Grijze Vos schreef op woensdag 04 mei 2011 @ 08:47:
Maar ja, als de duurste offertes een 30% boven de drie goedkoopste zitten, waar komt dat dan door? Iemand moet daar ergens een inschattingsfout maken, en dat zal vaak zat degene zijn met de goedkopere inschatting.

Er zijn ook gewoon bedrijven waar dat gewoon een onderdeel is van hun bedrijfsvoering. Die weten dat ze het makkelijkst scoren door onder de prijs te gaan zitten, iets op te leveren wat net het FO afdekt, en de rest van de uren als 'consultancy' te billen.

[BCC]

D4V3 schreef op vrijdag 06 mei 2011 @ 22:32:

offtopic:
Agile, Waterval...

Volgens mij is die site van Zed Shaw helemaal niet offtopic.

[djluc]

Gomez12 schreef op vrijdag 15 april 2011 @ 16:09:
[...]

Agile betekent niet dat je niet een scope in grote lijnen kan neerzetten.

Excuus, had je reactie over het hoofd gezien.

Wat ik weet van enkele softwarehuizen is dat ze meestal het project in kleinere delen ophakken, per deel geven ze een schatting af hoelang het gaat duren / hoeveel het gaat kosten. De klant gaat akkoord met de grote lijnen.

In dat geval hebben we het dus over een begroting. Dat kan absoluut een juiste manier zijn als de klant daarmee akkoord gaat. Het is gewoon heel eerlijk, we verwachten x uren nodig te hebben met een foutmarge van 10% bijvoorbeeld. Vervolgens weet iedereen waar hij/zij aan toe is. Als de specificaties gaan veranderen gaat het de klant wel veel meer kosten uiteindelijk maar dat is logisch.

En als dan gaandeweg blijkt dat voor een onderdeel wat ingeschaald is op 2 weken de klant zo weinig wensen heeft dat het in 1 week klaar is dan is er voor de rest meer tijd voor andere wensen.
Heeft de klant zoveel wensen dat het op 2 maanden uitkomt dan krijgt de klant gewoon de vraag wat hij wil :
- Extra mensen erop ( dus extra kosten )
- Extra uitloop (dus extra kosten )
- Op de overige delen beknibbelen
- Zijn wensenpakket voor dit gedeelte herevalueren naar wat hij er nu in wil hebben en wat er aan het einde van het project als extra bij kan komen.

Met name dat laatste vind ik interessant. Als je als IT partij een inschatting maakt voor een project, bijvoorbeeld: we hebben 10 ontwikkeldagen, 2 concept dagen en 2 testdagen nodig om een tool te maken die x en y kan. Dan ben je duidelijk.

Als er gedurende het traject verzonnen wordt dat er een heel ingewikkeld onderdeel in moet kan je aangeven dat dit 1 conceptdag + 2 ontwikkeldagen + 1 testdag gaat kosten. Het simpele alternatief past gewoon binnen het project zoals het gestart was. Dan krijgt een klant een goed gevoel omdat je beide doet wat je overeenkomt.

Bij het merendeel van die softwarehuizen ben je dan ook goedkoper uit als de initiele prijs als je geen additionele wensen hebt. De prijs is berekend op enkele additionele wensen...

Dat zie je inderdaad veel, ik probeer dat echt zo min mogelijk te hebben. Ik houd niet van de discussie maar als het nodig is dan moet het uiteraard. Meestal zie je dat soort situaties ontstaan bij prijskopers. Dat is een manier van inkopen maar zeker bij een custom made product zeker niet altijd de juiste methode.