Softwareontwikkelmethoden in de praktijk

[Tjop]

Op mijn werk (klein internetbureau, ~10 medewerkers) zijn we aan het kijken of onze softwareontwikkeling niet wat gestructureerder kan (we gebruiken nu 'cowboy coding', als ik het goed begrijp). Ik ben mij nu aan het verdiepen in de verschillende methoden die er bestaan (Agile en aanverwanten / waterfall / RAD etc). Het verbaasde me dat er op dit forum weinig over te vinden is over dit onderwerp, daarom wilde ik hier de discussie over starten. Aangezien er hier mensen zullen zitten met verschillende soorten ervaringen in softwareontwikkeling, lijkt het me nuttig om de kennis hierover te delen.

Met welke methoden hebben de gebruikers hier ervaring? Wellicht is het handig om het in de vorm van een lijstje te doen, zodat de ervaringen makkelijker vergeleken kunnen worden.

Gebruikte methode:
Type bedrijf (activiteiten/grootte etc):
Werking methode in de praktijk:
Belangrijkste voor- en nadelen:

Aanvullingen/ideeën zijn welkom

[djluc]

Goed topic waar veel te weinig over geschreven wordt. Ik denk dat de massa op cowboy stijl werkt.

Op dit moment zijn wij bezig met een compleet andere werkwijze. Met name ondernemers die veel kleine projecten doen met veel klantcontact e.d. zullen in de methodes die je beschrijft niet veel oplossing vinden. Daarom is het interessant om even een stap verder te kijken dan alleen programmeer-strategie. Er zit veel meer achter een organisatie.

[keejoz]

Cowboy methode in een bedrijf die een custom CMS verkoopt aan immo kantoren.

[NMe]

keejoz schreef op donderdag 03 februari 2011 @ 12:55:
Cowboy methode in een bedrijf die een custom CMS verkoopt aan immo kantoren.

Laten we dit soort korte opmerkingen verder maar achterwege laten, juist de beweegredenen en het effect op je werkwijze zijn interessant. Opsommen wat iedereen doet is voor niemand echt boeiend omdat er geen betekenis aan te hangen is.

[Jory]

Bij ons (ook een internet bureau, ~35 man) hangt "het proces" ergens tussen RUP, waterval en v-model. (Niet in die zin dat "we maar kijken wat we waarvan pakken", maar in de zin dat "we een proces hebben dat elementen uit die methodieken gebruikt".)

Wel gaan we steeds meer richting een agile/lean or rad achtig iets, waarbij de klant meer betrokken wordt en eerder (delen van) het product kan bekijken en feedback geven. Persoonlijk zouden we nog wel een stuk meer die kant op mogen gaan. Laat de klant maar gaandeweg ontdekken wat 'ie wil. (Dat gebeurt toch wel, maar nu hebben we dus eerst iets op papier staan, waarvan de klant later bedenkt dat 'ie het toch anders wil. Dat zou bij agile/lean niet of minder snel moeten gebeuren.)

[mOrPhie]

De discussie over softwareontwikkelmethoden is zo enorm breed, dat 1 topic bij lange na niet genoeg is. Tegelijk moet je er wel de juiste en voldoende personen voor hebben om die discussie te voeren.

Jouw post lezende is de ontwikkelmethode zelf het probleem niet, maar het veranderingsproces om tot een betere methode te komen. Het is namelijk een utopie om te denken dat je voor de volle 100% een ontwikkelmethode kan implementeren in je bedrijfsvoering. Elke klant is anders, dus elke aanpak is anders. Daar pas nooit één absolute methode bij. Ook termen als "best practice" zijn gevaarlijk. Je kunt eerder spreken van een "most fitted practice for a specific kind of scenario". Ik zou me dus nu vooral richten op het aanzwengelen van de discussie.

Verder moet je stapje voor stapje verbeteren. Sommige verbeteringen werken beter dan de ander. Als je direct "all in" gaat heb je de kans dat het finaal faalt en je terug naar de tekentafel moet terwijl je ondertussen de rommel op kan ruimen van het falen. Kijk naar de elementen van het ontwikkelproces en kijk waar je kunt verbeteren. Doe dat stap voor stap.

Ikzelf werk bij een bedrijf dat zichzelf als "lerende onderneming" beschouwd. Daarmee bedoelen we dat we altijd bezig zijn met het verbeteren van het proces nadat we een project hebben gedaan. We trekken er lering uit en proberen het een volgend project beter te doen. Zo'n evaluatie (of "retrospect" in Agile) is essentieel. Hiervoor moet je dus binnen het bedrijf de discussie voeren over wat er beter kan en wat je ideaalbeeld is van waar je naartoe wilt.

Wij doen zelf een combinatie van Agile methodes. Invloeden zijn DSDM en MSF, maar tegelijk pakken we ieder project weer anders aan. Wat we wel merken is dat je een "stick to the plan" attitude moet hebben. In het projectplan bespreek je een aanpak en tenzij het echt niet anders kan, blijf je bij je plan en volg je dat waar je eerder over nagedacht hebt. Tijdens het project aan het proces zitten is niet efficiënt.

Verder om te leren lees ik blogs en luister ik podcasts. Een aantal bekenden zijn:

SE-Radio: http://www.se-radio.net/
Grady Booch on archictecture: http://feeds.feedburner.com/onarchitecture
Pragmatic podcast: http://pragprog.com/podcasts
Ivar Jacobson: http://www.ivarjacobson.c...entre/resources/podcasts/

Daarnaast lees ik boeken over software proces verbetering. De laatste die ik aan het lezen ben ik "Perfect Software - And other illusions about Testing" (http://www.amazon.com/Per...ons-Testing/dp/0932633692).

Nog een goeie is user group meetings bijwonen en met anderen praten over hun ervaringen. Daar heb ik veel van geleerd.

[roy-t]

Gebruikte methode:
Voornamelijk cowboy coding, maar wel worden eerst netjes de hoogste risicos getackeled in prototypes, ook wordt er iteratief gewerkt, met +- elke twee weken feedback momenten (maar meestal werkt maar 1 persoon aan 1 project)
Type bedrijf (activiteiten/grootte etc):
Afdeling van Rijksuniversiteit Groningen (veel in opdracht, vast +-10man, maar slechts 1 of 2 programmeurs)
Werking methode in de praktijk:
Werkt prima, maar af en toe is er een 'dure' miscommunicatie door niet iteratief genoeg werken en niet strak genoeg uit te leggen wat men wil. Wel is het duidelijk dat we dit niet lang meer gaan volhouden, daarom zijn wij ook opzoek naar een beter systeem, maar eerste tests bleek het toch wat onpraktisch, meer geschikt voor teams met meerdere programmeurs.

[Grompie]

Gebruikte methode:
Bij kleine projecten cowboy coding, bij de grotere projecten probeer ik een hoop aspecten van extreme programming toe te passen (weliswaar voor 1 programmeur, voor mensen die geintereseerd zijn dit werk heeft me heel wat geholpen http://www.smr.co.uk/presentations/xp-for-one.pdf)
Type bedrijf (activiteiten/grootte etc):
BW (beschutte/sociale werkplaats) Waak. Werk ik als solo programmeur aan allerlei projecten om via de computer de mensen te helpen om "moeilijker" werk te laten doen. Met meer dan 1700 werknemers en heel wat ideeën of projecten voor slechts enkele werknemers heb ik mijn handen vol .
Werking methode in de praktijk:
Cowboy coding werkt goed, tot er veranderingen bij komen want meestal is deze code het slordigst of minst over nagedacht. Deze manier heeft me wel het snelst een resultaat (wat niet wil zeggen dat dit altijd meteen een goed resultaat is).
Bij de grotere projecten zorgt XP ervoor dat wanneer er wijzingen plaats vinden dit sneller kan gebeuren en heb ik een veel beter overzicht over de tijd die een project zal innemen. Ik moet echter ook heel wat tijd stoppen in code refactoring, wat mijn baas jammer genoeg niet altijd graag ziet (hij ziet het als verloren werk... zucht).

[Avalaxy]

Gebruikte methode:
Scrum, aangevuld met XP en binnenkort met TDD.
Type bedrijf (activiteiten/grootte etc):
Tweedejaars HBO-informatica studenten Kortom: op school in projecten.
Werking methode in de praktijk:
Best goed, heeft een aantal nadelen die ik hieronder zal beschrijven. Deze nadelen gelden voornamelijk voor het gebruik door studenten, maar andere punten gelden ook voor Scrum in het algemeen.
Belangrijkste voor- en nadelen:
Voordelen:
- Heel direct.
- Gericht op het opleveren van functionaliteit in plaats van eindeloos blijven doorkutten waardoor je gedwongen wordt flexibel te zijn en snel te reageren op problemen.
- Gelijk feedback in de vorm van sprint retrospectives.
- Het promoten van overzichtelijke weergaves zoals het scrumboard.
- Het multi-role aspect. Je doet niet meer puur één ding maar bent verantwoordelijk voor meerdere taken.
- Geen eindeloze documentatie moeten typen zoals bij waterfall methodes en sommige andere agile technieken.

Nadelen:
- Iedereen moet altijd aanwezig zijn en beschikbaar zijn anders kun je geen goede standup meetings houden en gaan andere communicatie-aspecten ook deels verloren.
- Het leent zich niet echt voor distributed development, meerdere vestiging wordt een probleem, en thuiswerken ook.
- Door de korte sprints heb je vaak geen tijd om eerst uitgebreid na te denken over de architectuur, je richt je meer op refactoren.
- Het product backlog leent zich niet echt voor technische items (multi-threading toevoegen, webservice bouwen, etc.). Deze taken zul je dus onder moeten brengen bij andere taken die gericht zijn op echte functionaliteit vanuit de ogen van de klant. Kortom, het moet business value hebben.
- Er moet continu een product owner beschikbaar zijn. Nu weet ik niet hoe dit gaat in bedrijven, maar op school wordt het problematisch als je een externe product owner hebt (of meerdere mensen die je van advies voorzien, waardoor je eigenlijk een soort gedeelde product owner hebt).

Dan heb ik nog een tweetal vragen over scrum waar anderen misschien ervaring mee hebben:
- Wat nou als je product owner halverwege de sprint zegt dat taak X uit je huidige sprint ineens niet meer zo belangrijk is, maar dat je daarvoor in de plaats taak Y uit moet gaan voeren die écht, écht, écht belangrijk is? Hou je je aan je sprint of pas je je sprint aan?
- Wat nou als je later ineens belangrijke extra functionaliteit moet inbouwen die niet is verwerkt in het product backlog en dus logischerwijs ook niet in je sprint backlogs? Voeg je dit zomaar toe?

Dan nog een losstaande vraag:
Scrum, niet heel handig voor studenten omdat die niet 40 uur per week op school zijn om aan het project te werken... Wat is nou een handige methodiek voor studenten?

[Anoniem: 134147]

Momenteel aan het afstuderen op dit onderwerp (nu nog in de oriëntatie). Nog niet heel ver maar ik onderschrijf mOrPhie's opmerking dat er niet één methodologie is. Zo hoeft in kleine projecten een cowboy aanpak niet te misstaan, op elkaar ingespeelde professionals in een klein team kunnen mogelijk ook prima zonder structuur door. Anderzijds als zij met een zeer lastige bureaucratische klant te maken hebben dan wil je misschien wel weer het één en ander kortsluiten om de gewenste klantbetrokkenheid te verhogen. De organisatie en het project spelen hier allebei een rol.

Wat ik wel alvast wil benadrukken is dat hoewel veel methodologieën in de praktijk maar deels gebruikt worden (en dit volgens de meeste literatuur prima is), sommige practices elkaar goed aanvullen. Mocht je experimenteren met één practice dan leid dit mogelijk niet tot het gewenste resultaat; begrijp goed welk doel word nagestreefd. TDD is niet alleen test-first maar ook een refactor stap. Als je daarmee geëxperimenteerd hebt begrijp je mogelijk het nut van ATDD/BDD. Begin je met BDD zonder eerdere ervaring dan kan die leercurve wel eens te hoog zijn.

Avalaxy schreef op dinsdag 08 februari 2011 @ 23:25:
Dan heb ik nog een tweetal vragen over scrum waar anderen misschien ervaring mee hebben:
- Wat nou als je product owner halverwege de sprint zegt dat taak X uit je huidige sprint ineens niet meer zo belangrijk is, maar dat je daarvoor in de plaats taak Y uit moet gaan voeren die écht, écht, écht belangrijk is? Hou je je aan je sprint of pas je je sprint aan?
- Wat nou als je later ineens belangrijke extra functionaliteit moet inbouwen die niet is verwerkt in het product backlog en dus logischerwijs ook niet in je sprint backlogs? Voeg je dit zomaar toe?

Kan niets zeggen uit ervaring maar wel wat over gelezen;
1) in principe liggen de items voor de iteratie vast, ze zijn juist bedoeld om de veranderlijkheid overzichtelijk en beheersbaar te krijgen zodat het team zich kan focussen op iets wezenlijks. Dat gezegd hebbende moet je de klant ten dienst staan en de gevolgen voor zijn gewenste aanpassing aangeven. Embrace change (aldus de Agilists). Als het echter vaker gebeurd kun je je afvragen of de iteraties niet te lang zijn (scrum houd 2 tot 4 weken aan geloof ik, XP zelfs 1). Als door alle veranderingen minder functionaliteit kan worden opgeleverd en de klant wil het zo, prima, maar hij moet hier dan wel van op de hoogte zijn (en je even afvragen of de doelstelling van de applicatie bij de klant niet té vaag is). Je volgende iteratie plan je dan ook minder functionaliteit in naargelang van wat de vorige iteratie af is gekregen, zo voelt de klant de pijn snel. Geef in ieder geval goed aan wat één van de doelen van een iteratieve ontwikkeling is; de verandering beheersbaar houden.
2) Je moet belemmeringen wegnemen die voortgang in de weg zitten; als hier missende functionaliteit bij hoort die nodig is om de ingeplande items op te leveren dan geld dat net zo goed. De schatting was dan verkeerd. Juist omdat planningen vaak onnauwkeurig zijn word juist op de kortere termijn gepland.

Als je overigens erg veel architectuur mist; er zijn genoeg Agile methodologieën die hier aandacht aan besteden. XP in de vorm van een metaphor, de ander met een 0-iteratie die voorafgaat aan het project en in feite als enige iteratie niets bruikbaars voor de klant oplevert. DSDM is al heel wat zwaarder die een langer voortraject kent waarin de architectuur duidelijk kan worden. Zo kan je ook kiezen een end-to-end skeleton architecture te bouwen.
Over al je genoemde nadelen is wel het één en ander geschreven; distributed scrum is een heel boek van. Zoals gezegd; niet één project en organisatie zijn dezelfde.

[ Voor 57% gewijzigd door Anoniem: 134147 op 09-02-2011 19:29 ]