Posts tonen met het label agile. Alle posts tonen
Posts tonen met het label agile. Alle posts tonen

maandag 3 augustus 2009

De agile checklist?

Via de blog van Alexander Lang kwam ik de volgende checklist tegen voor het aangaan van een agile project met een klant. De strekking is als volgt, het uitleggen van agile methodiek richting de klant is altijd een uitdaging. Om de agile denkwijze te verduidelijken en een betere communicatie met de opdrachtgever ten opzichte van de betekenis van agile in een project en om de opdrachtgever duidelijk te maken wat hij of zij kan verwachten of juist niet hebben we een checklist hiervoor vervaardigd.

Een agile project;

01] U krijgt werkende, beheersbaar, productie waardige, 100% kwaliteit software binnen een afgesproken tijdsperiode.

02] U krijgt de eerste werkende, beheersbaar, productie waardige, 100% kwaliteit versie van de software na een korte tijdsperiode (iteratie van meestal 1 tot 2 weken).

03] U krijgt uw software up and running op het door u gewenste tijdstip.

04] Wij programmeren altijd in duo vorm (pair programming) om zodoende de kwaliteit van de code hoog te houden en er voor te zorgen dat we altijd progressie maken.

05] Wij schrijven automatische test scenario's om de kwaliteit constant te toetsen en er voor te zorgen dat we altijd progressie maken.

06] Het is niet vanzelfsprekend dat alle features worden meegenomen in de eerste iteratie.

07] Daarom is zo belangrijk dat U uw features een prioriteit geeft naar gelang de wens.

08] Wij geven een schatting af, hoeveel tijd het kost om elke feature afzonderlijk en in het geheel te implementeren. Maar let wel op het is en blijft een schatting.

09] Wij gaan niet uit van functionele specificaties die u inbrengt als basis voor ons werk.

10] Wij geloven niet dat dit de werkwijze is omdat het gewoonweg niet mogelijk is om de software alleen goed te specificeren aan de voorkant binnen de aanvaardbare inspanning.

11] Wij gebruiken uw functionele specificaties wel als basis voor de discussie met u waarin wij per feature samen met U de user story uitschrijven. Deze uitgeschreven user stories per feature vormen de basis van ons werk.

12] Wij omarmen het wijzigen van de requirements doordat we in relatief korte iteraties software opleveren.

13] Wij leveren succesvol software projecten op wanneer we als hierboven werk verrichten.


__________________


Handtekening Opdrachtgever

woensdag 8 juli 2009

KANBANISME

Kanbanisme; het simpel denken, redeneren en handelen zodat er via visueel contact problemen in een vroeg stadium kunnen worden gesignaleerd waardoor er een effectief proces ontstaat.

Kanban de methodiek (geschikt voor zowel ict als industrie) voor de minimalist, de pure planner, de scrupuleuze dictator, de effectieve planner en natuurlijk kanban is de methodiek voor jou.



Kanban heeft zijn oorsprong in Japan, Kan staat voor visueel en Ban staat voor een kaart of bord. Kanban kan dus worden gezien als het signaleren door middel van kaarten. Het is dus een methodiek om te signaleren, een methode om door middel van een kaarten inzichtelijk te krijgen waar zicht een bottleneck van een project of deelproject kan gaan vormen. De werking van kanban is simpel, er wordt gebruik gemaakt van een push pull mechaniek (ook wel Two Bin, het voorraadsysteem genoemd). Het gehele push pull systeem wordt inzichtelijk gemaakt door middel van een bord, het kanban bord.



Het kanban bord wordt opgesteld in de project ruimte en geeft in een opslag aan het projectteam weer waar de bottlenecks kunnen gaan ontstaan wanneer er niet in wordt gegrepen (qua planning of productie). Het kanban bord heeft een aantal kolommen welke de verschillende tijdseenheden of faseringen kunnen zijn, in de afbeelding zijn er fasen gebruikt maar er zou ook gebruik kunnen worden gemaakt van dagen (voor korte deelprojecten), weken en maanden etc.. Het bord heeft als functie om per fase een aantal kaarten aan te brengen om zo inzichtelijk te krijgen wat er die periode moet gebeuren om de volgende te kunnen initiƫren. Boven elke kanban kolom wordt er een een limiet aangegeven, de kanban limiet. In de kanban limiet wordt aangegeven wat het maximaal aantal processen voor die fase mogelijk zijn zonder dat er een probleem zou kunnen ontstaan. Elk verwijderde kaart binnen een fase geeft de ruimte om een nieuwe te laten invoegen vanuit de vorige fase (het push en pull principe). Op elke kaart staat omschreven wat de actie inhoud en wie de actiehouder is, tevens wordt er gebruikt gemaakt van een start datum en een oplever datum. In de volgende afbeelding zijn de verschillende kaarten gevisualiseerd welke gebruikt kunnen worden.



Kanbanisme is de toekomst.
Kanban simpel en effectief.

Om maar even met de volgende uitsmijters te besluiten
Less is More en Keep it simple baby.


De afbeeldingen die hier zijn gebruikt zijn onderdeel van de Agile Business Integration process welke ontwikkeld is voor QNH Business Integrators. De afbeeldingen zijn vervaardigd door Leo Bekhuis in samenspraak met Olav Maassen (Agile Coach). Wanneer u meer wilt weten omtrent Kanban of het Agile Business integration process kunt u contact opnemen met Leo Bekhuis of Olav Maassen – QNH 030 698 20 00