Ontwikkelmethodes geschikt voor een kleine ontwikkelstraat

[Kentsfield]

Binnen het overheidsbedrijf waar ik werk starten we een kleine ontwikkelstraat om de zogenaamde End User Development en de problemen die dat met zich mee brengt in "betere" banen te leiden.

Het gaat om kleine applicaties ter ondersteuning van grote massale processen die nu vaak door eindgebruikers in access of excel ontwikkeld worden. Dergelijke applicaties zijn vaak traag niet netjes ontwikkeld en veroorzaken onnodig veel netwerk belasting (access). Ook zijn ze vaak niet multi-user etc.. het is vrij amateuristisch.

Het is de bedoeling dergelijke kleine applicaties met een korte doorlooptijd te kunnen opleveren.
Webbased, zeer waarschijnlijk het .net platform. Nu ben ik opzoek naar een ontwikkelmethode voor relatief kleine applicaties die niet te veel overhead met zich meebrengt. De gangbare methodes vind ik te log, DSDM, RUP etc.

Een waterval methode lijkt me het handigst voor kleine applicaties. Maar vraag me af of er ook methodes speciaal bedacht zijn voor kleine projecten / ontwikkel teams. Iemand tips?

Ik ben me er van bewust dat ik waarschijnlijk nog te weinig eigen onderzoek gedaan heb.

[Appesteijn]

Scrum of Kanban ?

Hoe groot is het team wat gaat ontwikkelen?

[Kentsfield]

Man of 6 denk ik. Waarvan de applicaties in sommige gevallen zo klein zijn dat 2 man voldoende zijn.

[SeatRider]

Kentsfield schreef op donderdag 30 september 2010 @ 22:00:
Man of 6 denk ik. Waarvan de applicaties in sommige gevallen zo klein zijn dat 2 man voldoende zijn.

Ik zie scrum niet werken in een situatie waarbij er niet 1 product is wat "doorontwikkeld" wordt. Denk dan eerder aan kanban, eigenlijk een veredeld ticketing systeem, maar het werkt wel.

[Kentsfield]

Weet je toevallig waar ik informatie kan vinden over kanban als ontwikkelmethode? Google levert niet direct veel op.

[Janoz]

Het gaat niet om de korte ontwikkel tijd. Het gaat over de perceptie van de eindgebruiker. De reden waarom dergelijke tooltjes ontwikkeld worden is juist vaak omdat eindgebruikers het idee hebben dat ze hun vraag neerleggen en dat er dan oeverloze discussies volgen en uiteindelijk iets wordt gebouwd wat ze eigenlijk niet wilden en het ook nog eens een eeuwigheid duurt.

De oplossing is helemaal niet om de applicatie maar zo snel mogelijk af te hebben. De oplossing is juist dat de eindgebruiker zelf het gevoel krijgt dat hij serieus genomen wordt.

Waterval zou ik iig vergeten. Waterval vereist dat je, voordat je begint, de exacte specificaties boven water hebt. Juist bij dit soort tooltjes is dat heel erg lastig. Dat geeft precies dat beeld van oeverloze discussies. En omdat de specificaties door verschillende interpretatie lagen gaan zal er altijd verschil zijn tussen de wens en het opgeleverde.

RUP is inderdaad redelijk uitgebreid (je moet zo ongeveer een halve bibliotheek aanleggen aan documentatie), maar je kunt ook redelijk selectief zijn in wat je overneemt. DSDM kan ik niet goed genoeg om een oordeel over te vellen.

De oplossing voor jullie straat is Agile/Scrum. Heel kort door de bocht is het een beetje RUP zonder bureaucratie, maar met die opmerking doe ik niet echt recht aan Agile/Scrum.

[SeatRider]

Agile ja, scrum nee. Scrum werkt bij de gratie van een 2 of 3 wekelijks sprint-ritme waarbij er een duidelijk feed aan workitems is, en aan het einde van de sprint alles gedemonstreerd wordt. Dat gaat gewoon niet lukken met kleine scriptjes, hacks of tooltjes. Dat moet je gewoon via kanban doen, kun je nog steeds iteratief werken, zit je alleen niet "vast" aan te lange sprints.

[DiedX]

Klinkt als dsdm, maar mocht je in een gekke bui zijn: Extreme Programming?

[Kentsfield]

Nou ja sommige applicaties die door eindgebruikers in elkaar geknutseld zijn zijn nog best omvangrijk. Soms zijn het zelfs halve datawarehouse applicaties. Maar gezien de beschikbare capaciteit en het aantal teamleden lijkt agile het meest geschikt.

Scrum spreekt mij eigenlijk wel aan, over kanban heb ik nog weinig informatie gevonden.

[Janoz]

SeatRider schreef op donderdag 30 september 2010 @ 22:16:
Agile ja, scrum nee. Scrum werkt bij de gratie van een 2 of 3 wekelijks sprint-ritme waarbij er een duidelijk feed aan workitems is, en aan het einde van de sprint alles gedemonstreerd wordt. Dat gaat gewoon niet lukken met kleine scriptjes, hacks of tooltjes...

Eens, maar als ik de vraag van de topicstarter vertaal naar wat ik vaak om mij heen zie, dan gaat dit niet over de kleine scripjtes, hacks of mini tooltjes. Het begint er vaak wel mee, maar meestal groeien ze uit tot redelijk afdelingscruciale toepassingen die vervolgens eigenlijk alleen maar door die ene handige persoon op de afdeling onderhouden kunnen worden.

[Kentsfield]

Klopt

[Appesteijn]

Kanban lijkt er wel op maar is handiger voor kleine opleveringen (bv het oplossen van incidenten) waarbij een tijdsplanning minder van belang is. Je probeert met het team de software zo snel mogelijk naar productie te krijgen (daar heeft de klant er pas wat aan), waarbij je erg let op focus (max 2 taken per ontwikkelaar/tester/...) en een limiet zet op je verschillende processtappen (bv max drie taken klaar om getest te worden, maximaal 4 taken waaraan ontwikkelt kan worden). Hierdoor maak je opstoppingen in je ontwikkelproces duidelijk en zorg je ervoor dat het team pas gaat beginnen aan werk, als er ook daadwerkelijk ruimte is om dit werk snel af te ronden. Hierdoor krijg je 'flow' en stroomt de software constant uit je 'ontwikkelproces'. (Vergelijkbaar met een lopende band waar auto's vanaf rollen)

Natuurlijk is een ontwikkelproces niet in vijf regels uit te leggen en is elke situatie anders, maar omdat je aangeeft dat de applicaties die jullie gaan vervangen nogal verschillen in omvang (qua bouwtijd), je duidelijke begin en eindmomenten kunt aanwijzen (de acces applicatie is vervangen) en de klant een grove einddatum vaak wel erg fijn vind om te horen, zou ik voor Scrum gaan.

Hier staat een (korte) video uitleg over Scrum: http://www.youtube.com/watch?v=Q5k7a9YEoUI.

[Avalaxy]

Ik crosspost mezelf even uit een ander topic:

quote: http://gathering.tweakers...message/34748926#34748926

Een aanrader die ik hier nog niet voorbij heb zien komen is AUP. Dat is een meer agile versie van RUP. Het is gebaseerd op het 'just barely good enough' principe, wat neerkomt op onder andere geen eindeloze documentatie. Er is een hele theorie over, wat betreft de hoeveelheid tijd je in documentatie steekt, en de extra benefit die het heeft om er nog extra tijd in te steken. Volgens AUP is dat een soort bergparabool, waar de meest efficiënte manier dus in het midden zit (bij de top).

Ik zal het verder niet teveel uitleggen, maar iedereen die RUP interessant vindt maar het net iets te zwaar vindt moet zeker even een kijkje nemen naar AUP:
http://www.ambysoft.com/unifiedprocess/agileUP.html

Dat is wellicht wat voor je, benodigde documentatie is minimaal