Organisatie en methodologieën van IT projecten

[Pawelotti]

Scrum

Ik heb nu ongeveer 7 maanden een team aangestuurd van programmeurs/web developers voor mijn bedrijf. Wij hebben gewerkt met de methode genaamd SCRUM. Dat is een methode die ontwikkeld is om zo effectief mogelijk een hoge mate van flexibiliteit en productiviteit te hebben gedurende de ontwikkeling van software. Een methode waarbij je (het liefst) een uitstekend team in zogenaamde sprints laat werken. Sprints zijn periodes die steeds aan het begin besproken worden en na afloop nabesproken worden. De al opgestelde lijst van taken wordt per sprint wordt telkens aangepast op prioriteit. Scrum is vooral ontzettend helder. De productiviteit ligt binnen enkele weken bloot, en de Burn down chart die naar beneden loopt(Aantal overgebleven taken verticaal op een horizontale verloop van tijd) laat zien wanneer het project klaar is, met in acht neming de aangenomen top productiviteit.

 

Belangrijkste aspecten van Scrum

[*]De term "af" is heel specifiek gedefinieerd. Alles wat gedaan wordt tijdens een sprint is van A tot Z. Een functionaliteit erin gooien is er niet bij. Af is zeg maar geprogrammeerd, getest + unit test en in wezen ready to ship.

[*]Er wordt niet gewerkt met een tot in pijnlijk geschreven design. Uiteraard plan je, en heb je ook taken de maken hebben met het "bedenken" van bijvoorbeeld database design - maar elke sprint maak je zaken "af". Des te meer tijd er voorbij gaat, des te minder er zaken "bedacht" worden en des te meer taken "af" worden gemaakt. Je begint met een basis functionaliteit en die maak je dus "af", en dan bouw je die uit.

[*]Per sprint schat elk teamlid de uren per taak. Naarmate het project vordert, stijgt het vermogen van elk teamlid eigen productiviteit in te schatten.

 

Voorwaarden

[*]Het team moet echt goed en gemotiveerd zijn, want er wordt bij Scrum veel vertrouwen gelegd in het team. Ze organiseren eigenlijk zichzelf. Je moet niet mensen hebben "die het wel kunnen".

[*] Scrum is flexibel en dat moet de organisatie ook zijn. Bij sterke hiërarchie, veel bureaucratie en zeer grote projecten is de effectiviteit van Scrum discutabel.

 

 

Het bovenstaande is enkel bedoeld als belichting van de methodologie, en is geenszins bedoeld als volledige uitleg. Er komt veel meer bij kijken, hoewel Scrum in wezen juist heel simpel en transparant is.

 

Ik zou graag eens een discussie op gang willen brengen over organisatie en methodologieën. Misschien wel specifiek in web projecten. Wie heeft hier ervaring mee? Wat werkte wel en wat niet? Waarom wel of niet?

 

Dit is een een aardige presentatie in-house van Google over Scrum:

http://video.google.com/videoplay?docid=-7230144396191025011&ei=dxrDSLmbDJGQ2wK44pS_BQ&q=scrum&hl=en

 

[DunneSloeber]

Binnen mijn bedrijf, doe ik onderzoek naar alles wat ik de afgelopen 12 jaar heb gezien in het Nederlandse bedrijfsleven, wat betreft de automatisering van gegevensverwerking. Ik vind dat een methode kiezen erg belangrijk is. Wat nog veel belangrijker is is de strategie van het informatiseringssysteem. Daarbij is de kernqualiteit, functionaliteit, het uitgangspunt.

 

Het draait dus in eerste instantie om het scenario van het systeem in de toekomst, en wat het systeem moet doen. Wat in de praktijk heel vaak gewoonweg even onder het tapijt geschoven wordt als none-functional requirements, zijn die definities van al die andere belangrijke qualiteiten, die rond de kernqualiteit functie opgebouwd moeten worden. Bruikbaarheid, verwerkingssnelheid, veiligheid, aanpasbaarheid, betrouwbaarheid, efficiëntie, effectiviteit, begrijpbaarheid. En zo zijn er wel een heel stel andere qualiteiten. De invulling van het totaal zal uitmaken of de productie succesvol is.

 

Ik denk dat het focussen op ontwikkelmethoden binnen afzienbare tijd resultaat kan geven. Wat het vaak niet geeft is inzicht, overzicht, en duidelijkheid in de beheerfase. Althans, het aantal hete en dichtgegroeide jungles van documenten die ik de revue heb zien passeren hebben mij dit beeld gegeven.

 

De beheerfase is waar geld verdiend kan worden. Meeste IT bedrijven zijn wel in staat een werkend systeem af te leveren op de deadline, hoewel er vaak ook andere resultaten geboekt worden. Of dat het resultaat uit blijft, en niet de kosten.

Maar als er een werkend resultaat is, begint het pas. Het beheren. Een werkend systeem op de deadline, of een beheerbaar werkend systeem zijn twee totaal verschillende producten. zet zich in voor beheerbare systemen. Hetgeen technologisch gezien een grote stap verder is, in vergelijking met de praktijk die ik ervaren heb.

 

Alles wat met de automatisering van gegevensverwerking heeft te maken is onzichtbaar, men ziet alleen resultaten. Alles is onzichtbaar van de fabricage, product, en productie. maakt zaken zichtbaar op een wijze dat inzicht, overzicht en duidelijkheid gegeven wordt aan de gebruikende organisatie. Daarom werk ik met resultaten en niet met uren.

Resultaten heeft een organisatie nodig, en hoe meer zaken er mis gaan hoe meer uren er geïnvesteerd zullen worden. Dit is niet ten gunste van de vragende partij. Zaken zichtbaar maken geeft de mogelijkheid om situaties ruim van te voren aan te zien komen, met meer mogelijkheden om succesvol te sturen, en te managen.

 

Waar het bij een geautomatiseerd gegevensverwerkingssysteem om gaat is dat de gestelde qualiteiten terug te vinden zijn in het product, dat actueel is in het productie platform. Dat zijn niet de enige qualiteiten, het totale spectrum bevindt zich in de aspecten fabricage, product en productie.

Het productieplatform is het doel, daarom pleit ik altijd om eerst een goed duidelijk beeld te hebben van het doel. Bij veel methoden vind ik dat het doel onvoldoende naar voren komt. Ik stel het doelplatform, de structuren die daar nodig zijn prominent. En het doel definieer ik als een verzameling onderling gerelateerde elementen, waarbij elk element dezelfde verzameling type qualiteiten heeft.

Uit die definitie zal blijken wat voor methoden er gewenst zijn om het logisch definierende deel van het systeem ( wat moet er gebeuren ) en het concreet definierende deel van het systeem ( hoe zal het gebeuren ) te maken. En die methoden moeten ook bewijzen dat er een beheerbaar product geleverd wordt. Als de beheerbaarheid op een gunstig niveau is, zal dat betekenen dat er veel geld bespaard wordt.

Uit het strategisch scenario moet blijken hoe vaak, en waarvoor een systeem aangepast dient te worden. Zo'n aanpassing kan tijdelijk zijn, met als gevolg dat er een tweede aanpassing komt. Bij marketing campagnes is dit vaak het geval. Door een overzichtelijke definitie te hebben van het systeem verlopen deze aanpassingen soepel en snel. Dit is een typisch kenmerk van hoog niveau beheerbare systemen.

 

Een methode moet aansluiten bij hetgeen gevraagd wordt voor het productiesysteem, waarbij het toekomst scenario stelt wat het beheer zal inhouden. Zijn deze zaken onvoldoende gedefinieerd, houdt dat in veel gevallen in dat er enorme kosten in het verschiet liggen. maakt beheerbare multi-qualiteitenprogrammering voor automatische gegevensverwerking.

[Pawelotti]

Hoi Stef,

 

Goed stuk! Inderdaad is dat een opvallend iets - beheren wordt bij die methodes weggelaten. Dat gaat ook meer de kant op van je business systeem. Ik ben daar ook ontzettend veel mee bezig. Welk proces vind plaats van prospect naar klant, dienst opstarten, goed afronden en factureren. Ik ga straks een tweede fase in ter afronding van de ontwikkeling en lancering van onze software, en ik zal dit aspect zeker veel aandacht geven. Moeizaam beheer kan bijvoorbeeld het verschil zijn tussen 3 mensen voor onderhoud of 6.

 

Tegelijkertijd blijf je doorontwikkelen en daarbij is Scrum wel prettig, zijn er meer mensen met een mening hierover?

 

[DunneSloeber]

@Pawelotti

Dankjewel voor je waardering.

Ik ben de door jou gerefereerde presentatie aan het bekijken over SCRUM, en het sluit erg aan met mijn kijk op systeemontwikkeling.

Het lijkt wel exclusief te focussen op software. Terwijl een gebruikende organisatie een systeem gebruikt. De qualiteiten worden gedefinieerd door het totaal op het platform, software, frameworks, operating system, hardware. Ik denk door een exclusieve focus op software er snel resultaat geleverd kan worden, en dat er ook een grotere waarschijnlijkheid is dat iets prominent belangrijks over het hoofd gezien wordt. Bijvoorbeeld de tuning van de Java Virtual Machine, of dat een aantal belangrijke systeemgebruikers blind zijn.

Desalwelteplus, multi quality focus in het totale ontwikkel- en beheer-traject brengt volgens mij gegevensverwerking met een veel hogere waarschijnlijkheid op succes.

[R.I.P. - Fred Wiersma]

Ik ben al een tijdje uit de actieve software engineering. Ik heb gewerkt met zowel de klassieke watervalmethode, als met incrementeel ontwikkelen (een voorloper van Scrum en Agile, denk ik, toendertijd o.a. beschreven door Cap Gemini).

 

Ik denk dat de methode minder belangrijker is dan het doel, zoals fraai verwoord door Stef In Form. Waar ik zelf al meteen enige allergie voel is bij deze quote:

 

" * Het team moet echt goed en gemotiveerd zijn, want er wordt bij Scrum veel vertrouwen gelegd in het team. Ze organiseren eigenlijk zichzelf. Je moet niet mensen hebben "die het wel kunnen".

"

 

Dat klinkt bij mij nl als een open deur. Hoe weet je of een team echt goed en gemotiveerd is? En is dat anders dan bijv bij een waterval project? Ik geloof het niet.

 

Daarnaast verwacht ik bij Scrum achtige projecten vooral problemen met het datamodel, zeker als een ontwikkelteam weinig rekening houdt met aansluiten op bestaande applicaties. Het wiel opnieuw uitvinden lijkt me een reele mogelijkheid. Of veel interfacing om een en ander aan elkaar te breien.

 

Het belangrijktste voordeel van incrementele ontwikkeling is grotere klantbetrokkenheid, en snellere functionaltieitsontwikkeling. Voor sommige klanten / omgevingen erg goed, voor andere minder (zware processing, bulkverwerking, etc).

 

[Pawelotti]

 

Dat klinkt bij mij nl als een open deur. Hoe weet je of een team echt goed en gemotiveerd is? En is dat anders dan bijv bij een waterval project? Ik geloof het niet.

 

 

 

"If your team is crap, they will deliver crap each incrementation of the software. Each sprint delivers more crap". Zoiets wordt er gezegd in de Google video. Omdat Scrum erg transparant is qua productiviteit op team niveau maar ook individueel, kan je snel zien hoe goed het team is. Daarbij heeft de grotere verantwoordelijkheid die het team heeft, meestal invloed op de motivatie. Het punt is dat bij Scrum er volledig wordt uitgegaan van de zelfredzaamheid van het team. Ze moeten in staat zijn hun eigen competenties zo goed mogelijk in te zetten en hulpmiddelen in te zetten waar zij die nodig achten. Dat is wel wat anders dan een technische specificatie onder je neus krijgen en dat hersenloos omzetten tot software. Dus je hebt wel mensen nodig met wat meer ervaring en competenties. Geloof me, er zijn programmeurs die aan oude methodes gewend zijn en die helemaal in de war zijn als ze in Scrum terecht komen. Die hebben telkens zoiets van "Ja, maar waar is de technische specificatie."

 

 

Daarnaast verwacht ik bij Scrum achtige projecten vooral problemen met het datamodel, zeker als een ontwikkelteam weinig rekening houdt met aansluiten op bestaande applicaties.

 

Waarom? Je hebt geen 500 pagina dik document, maar het bedrijf heeft wel duidelijke business doelen en als aansluiting op bestaande applicaties belangrijk is, dan wordt daar gewoon rekening mee gehouden. Het hele punt is sowieso dat Scrum juist rekening houdt met wijzigingen en veranderingen.

 

Ik ben het absoluut met je eens dat Scrum zich niet per se leent voor allerlei projecten,.. hoewel daar discussie over is. Voor zaken as innovatieve web projecten heb ik het gevoel dat het absoluut de beste methode is. Beter dan weken kwijt zijn dikke documenten die het project beschrijven tot in pijnlijk detail (Been there, done that).

[LittleBit]

Mij valt op dat in een bedrijfsvoorbeeld in de Google video het SCRUM-team multi-disciplinair wordt aanbevolen

en dat men verderop aangeeft dat een SCRUM-software team dient te bestaan uit gelijken.

Ik weet niet of ik het goed begrepen heb maar wat mij betreft

is de waarde in het team voor alle deelnemers identiek

maar kies je kwa expertise/domeinkennis sterk verschillende leden.

 

Overigens is Prof. Sjaak Brinkkemper van de Univ. Utrecht hard bezig om partijen in Ned

bij elkaar te brengen omtrent product management van software ontwikkeling.

Dan moet je wel meer denken aan partijen die een software product maken

dan aan partijen die sw ontwikkeling als dienst aanbieden.

De vraag is natuurlijk of de mensen hier dat als verschil ervaren.

 

[DunneSloeber]

Software ontwikkeling als dienst, of een softwareproduct aanbieden is verschillend. Hoewel in de praktijk er ook producten worden aangeboden die op basis van uren aangepast worden aan de wensen van de klant. Onder zulke voorwaarden vind ik het verschil klein. Voor mij ben je pas een pure product aanbieder als het bij het leveren van resultaten blijft. Op die manier trek je veel verantwoordelijkheid naar je toe als producent ( hoe sneller de gevraagde qualiteit geleverd wordt, hoe beter het is ). En het impliceert vooruitstrevende technologie, en minder problemen voor de gebruiker. Want als ik voor elk resultaat als leverancier enorm veel tijd kwijt ben met nazorg loop ik verlies op. Dus wat versta je onder een softwareproduct, en wat zijn de beheerqualiteiten van het softwareproduct? Ik zie het pas als een echt product als de qualiteiten per onderdeel opgelepeld kunnen worden, want dat is een eerste bewijs voor een goede opzet van de architectuur. Kan dat niet, is het waarschijnlijk een product met de bekende JBF opzet. Vaak moeten gebruikers dan betalen voor het onderhoud, hetgeen ik ongunstig vind voor die gebruikende organisatie.

[DunneSloeber]

@Pawelotti

Hoe is het nou met dat project? Doet het het nou?