Kwaliteitsproducten en -diensten met Scrum

05-02-2013 10:22 | Door Ben Linders | Lees meer artikelen over: IT-auditing, Testing, Agile, Scrum | Er zijn 20 reacties op dit artikel | Permalink
Computable Expert
Ben Linders
Ben Linders

Senior Consultant

Expert van Computable voor de topics: Management en BPM

Meer

Steeds meer organisaties passen Agile toe om softwareproducten en -diensten te ontwikkelen. Redenen die genoemd worden om Scrum te gebruiken zijn: flexibel inspelen op wensen van de klant, sneller ontwikkelen, en hogere software kwaliteit. Over flexibiliteit en snelheid is al veel geschreven, dit artikel vertelt wat Scrum voor de kwaliteit van producten en diensten kan doen en beschrijft de Agile kwaliteitstechnieken die daarbij gebruikt worden.

Even vooraf: Agile is geen silver bullit voor kwaliteit, er bestaat geen specifieke Agile kwaliteitsaanpak en Agile pretendeert ook niet dat het alle kwaliteitsproblemen kan oplossen. Maar een Agile werkwijze, bijvoorbeeld met Scrum kan zeker bijdragen aan een hogere kwaliteit. Laten we eens kijken hoe dat dat mogelijk is.

Wat is Kwaliteit?

Om te beginnen, mijn definitie van kwaliteit: Kwaliteit is de mate waarin voldaan wordt aan de behoeften van de gebruikers, en aan de eisen van de opdrachtgevers. Dat kunnen zowel functionele behoeften zijn (iets wat het product of dienst moet doen), of “performance”of niet-functionele eisen (hoe snel, hoe veel, de betrouwbaarheid, etc), vaak is het een combinatie van beide. De gebruikers zijn diegenen die met het product of dienst iets doen en er voordeel aan hebben. De opdrachtgever is de eindverantwoordelijke die beslist heeft dat het product of de dienst ontwikkelt moest worden en die de middelen (geld, mensen, etc) beschikbaar heeft gesteld.

Met bovenstaande definitie wordt de kwaliteit van een softwareproduct of -dienst dus duidelijk bepaald door de gebruikers en opdrachtgevers, en niet door het Scrum team. Scrum teams kunnen m.i. alleen kwaliteit leveren als ze de behoeften van de gebruikers kennen en een daarbij passende oplossing leveren.

Agile waarden

Het belang van kwaliteit wordt door de waarden waar Agile op gebaseerd is onderstreept. Het agile manifest beschrijft de waarden:

Manifest voor Agile Software Ontwikkeling
'Wij laten zien dat er betere manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen. Daarom verkiezen we
Mensen en hun onderlinge interactie boven processen and tools
Werkende software boven allesomvattende documentatie
Samenwerking met de klant boven contractonderhandelingen
Inspelen op verandering boven het volgen van een plan
Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd.'

Mijn mening is dat de Agile waarden de levering van kwaliteitssoftware ondersteunen. Bijvoorbeeld door 'werkende software boven allesomvattende documentatie', wat het belang aangeeft van het leveren van producten aan gebruikers. Agile moedigt aan om vroeg en vaak te leveren, waardoor gebruikers de software kunnen gaan gebruiken en die voor hun waarde oplevert, kwaliteit dus. Ook 'inspelen op verandering boven het volgen van een plan' resulteert in hogere kwaliteit omdat het Agile-teams aanmoedigt om software aan te passen die niet aan de behoeften van de gebruiker voldoet. 

Vaker en tijdiger actie ondernemen

Agile verschilt met 'traditionele' kwaliteitssystemen die de nadruk leggen op het borgen van de kwaliteit met documenten. Die systemen hanteren veelal een waterval aanpak met milestones waarop documenten formeel geïnspecteerd en goedgekeurd moeten worden. Ze kennen kwaliteitsdoelen, rapportages en audits, en geven veel aandacht aan het testen van producten. Maar de kwaliteit van een product kun je er niet in 'controleren'. Van milestone checks, reviews en testen wordt het niet beter. Een controle geeft signalen, maar pas als je met die signalen wat doet dan wordt het product of de dienst beter. Het gaat om een balans tussen controleren en het nemen van actie en daar gaat het vaak mis.

Projectteams komen om in de grote hoeveelheid fouten die gevonden zijn en kunnen maar een deel ervan oplossen. De diepere oorzaken van de fouten zijn onbekend en daar wordt niets aan gedaan, waardoor er steeds nieuwe fouten bijkomen. Kwaliteitssystemen die voornamelijk gebaseerd zijn op controleren blijken vaak niet de gewenste kwaliteit op te leveren, of doen dat tegen zulke hoge kosten dat ze in de praktijk niet uitvoerbaar zijn.

Een Agile-aanpak gaat uit van minder controleren en van beter gebruiken van de  resultaten van de controles door vaker en tijdiger acties te ondernemen. En van leren van fouten en de manier van werken (het proces) te veranderen. Daarmee wordt de kwaliteit beter en gaan de kosten omlaag. Scrum levert, door het kortcyclisch werken in sprint en de frequente feedback, volop informatie over de kwaliteit van de producten. Deze informatie wordt gebruikt om de producten te verbeteren (Sprint Review / Demo -> Planning Game) of om effectiever samen te werken (Sprint Retrospective -> Definition of Done). Op die manier wordt continu het product en de manier van werken verbeterd.

Samenwerken met gebruikers

Samenwerking met de gebruikers van de software is essentieel als je wilt begrijpen welke kwaliteit nodig is. Bij het plannen en ook tijdens de ontwikkeling werken de eigenaar van het product en het Scrum-team nauw samen om zo de vereisten te kunnen definiëren en te bepalen wat prioriteit heeft, door gebruik te maken van gebruikersverhalen (User Stories). 

Het begint al met de planningsgame, waarin het team en de Product Owner (die de gebruikers vertegenwoordigt) afstemmen wat de gebruiker van de volgende sprint mag verwachten. Telkens opnieuw wordt gekeken wat de hoogste prioriteit heeft, om ervoor te zorgen dat de juiste dingen gemaakt worden waar de gebruikers wat aan hebben. In de dagelijkse stand-up bespreken de teams hun voortgang en benoemen dingen die mogelijk de levering kunnen bemoeilijken. Aan het einde van de sprint is er de product review waarin met de gebruikers bekeken wordt of het product voldoet. Die product review geeft veel bruikbare feedback, die meegenomen wordt in de plannings game van de volgende sprint.

Samenwerken met korte communicatielijnen is een sterkte van Scrum, die helpt om de kwaliteit te verhogen. Ontwikkelaars hebben een beter inzicht wat gebruikers willen en waarom. Gebruikers zien het product in een vroeg stadium, en kunnen het ook eerder gaan gebruiken. Een duidelijke win-win!

Agile kwaliteitstechnieken

Omdat de Agile-waarden kwaliteit onderstrepen en de Scrum-teams intensief samenwerken met de gebruikers, is het geen verrassing dat veel Scrum-teams software van hoge kwaliteit leveren. Maar hoe doen ze het, welke technieken gebruiken ze?

Een voorbeeld is 'pair Programming', waarbij twee ontwikkelaars samen een keyboard en scherm delen. De ene ontwikkelaar typt terwijl de ander de code leest en mogelijke problemen aankaart en daar verbeteringen voorstelt. Bij pair programming wordt de code nagekeken terwijl hij geschreven wordt, waardoor er snel feedback wordt gegeven aan de ontwikkelaar en fouten voorkomen worden. Bijkomend voordeel is dat meerdere ontwikkelaars de code leren, waardoor men minder afhankelijk is van individuele teamleden.

Een andere manier die de kwaliteit van producten verhoogt is Test Driven Design (TDD).  Als eerst de test geschreven wordt en daarna pas de code, dan weet je door het uitvoeren van de test dat de software werkt. Tests worden toegevoegd aan de regressietest, die het team tijdens de ontwikkelingsfase gebruikt om te controleren dat de software correct blijft werken. 

'Refactoring' past bestaande code aan, waarbij het product hetzelfde blijft werken. Het kan gebruikt worden om de prestatie van een product te vergroten of om het voor te bereiden zodat een nieuwe functionaliteit toegevoegd kan worden. Teamleden ontwikkelen hun ‘refactoring’ vaardigheden, zodat zij de code efficiënt kunnen aanpassen en tegelijkertijd de kwaliteit van het softwareproduct kunnen waarborgen. Om er zeker van te zijn dat het product correct blijft werken worden regressietesten gedaan, TDD en refactoring worden op die manier gecombineerd.

Scrum-teams verbeteren hun manier van werken constant door te werken met retrospectives. Door te reflecteren na een sprint kan het team zien welke dingen goed gingen en welke beter kunnen en ze evalueren ook wat ze geleerd hebben. Agile vindt verbetering erg belangrijk en teams leren constant om beter te worden in wat ze doen, waardoor zowel hun effectiviteit als efficiency vergroot worden.

Conclusie

Scrum-teams worden gedreven door de Agile-waarden die kwaliteit ondersteunen. Door frequente feedback nemen Scrum-teams vaker en tijdiger actie om de kwaliteit te verbeteren. Ze werken nauw samen met de gebruikers van de software en gebruiken kwaliteitstechnieken om softwareproducten en diensten van hoge kwaliteit te leveren.

Reacties op dit artikel
De redactie vindt deze reactie: OKCees Kuijpers, 05-02-2013 13:18
Scrum: sneller ontwikkelen en een hogere software kwaliteit. Het is informatief om te lezen over Agile waarden, vaker en tijdiger (nb als iets tijdig is, hoe kan het dan nog tijdiger?) actie ondernemen, samenwerken met gebruikers etc. Maar wat levert Agile/Scrum nu echt op ? Wat is het nuttig effect op het aantal uren/functiepunt en wat is het effect op de projectduur vergeleken met gelijksoortige projecten in het verleden?
De redactie vindt deze reactie: OKEmiel van der Linden, 05-02-2013 14:11
@Cees: Mijn ervaring met Agile software ontwikkeling zijn:
 
- meer betrokkenheid van de eindgebruikers (worden regulier uitgenodigd om de voortgang te tonen, goed in het kader van verwachtings- en veranderingsmanagement).
- problemen/fouten worden sneller gevonden (en kunnen dus ook sneller opgelost worden, kosten omlaag en kwaliteit omhoog)
- ontwikkelteam hoort uit eerste hand wat de klant wenst en kan ook sneller met de klant om de tafel over (on)mogelijkheden en alternatieven
- risico wordt verkleind (de klant wordt niet aan het eind geconfronteerd met het product)
- projectmanagement eenvoudiger (voortgang veel beter meetbaar)
- invloed klant vergroot (klant kan aan het eind van een sprint de prioriteit bijstellen en continu functionaliteit toevoegen)
 
Zo maar wat redenen die Agile software ontwikkeling bijzonder veel toegevoegde waarde geeft. Wel moet ik erbij vermelden dat ik dit vanuit een ontwikkelaarsperspectief geschreven heb :)
De redactie vindt deze reactie: OKBen Linders, 05-02-2013 15:45
@Cees Dit artikel gaat juist niet over hoeveel sneller en efficienter Agile/Scrum is (daar schrijven anderen over), maar over de kwaliteitsverbetering met Scrum. Eerder op Computable is wel een boek besproken wat over de business case van Agile gaat, zie http://www.computable.nl/artikel/nieuws/detachering/4569590/3484209/lezers-lezen-agile-werkt.html.
 
Mbt kwaliteit en Agile, ik heb onderzoek gedaan samen met het Software Engineering Institute (SEI). Zie http://www.benlinders.com/2011/lean-software-ontwikkeling-introductie-en-verminderen-van-verspillingen/. Het onderzoeksrapport laat zien dat de kwaliteitswinst beperkt was. Maar wat wel een groot voordeel was, is dat het juiste product gemaakt werd: Dat wat de klant nodig had! En dat sluit aan op mijn definitie van kwaliteit, een product wat beter voldoet aan de wensen van de klant.
De redactie vindt deze reactie: OKMarcel Kouwenberg, 05-02-2013 18:38
Leuk artikel waar ik op maar een paar elementen niet mee eens ben. Zo is de kwaliteit voor mij de bijdrage aan het doel van de opdrachtgever. Dus bv de omzetgroei. Daarvoor moeten gebruikers hun doel kunnen vervullen, ze leveren (misschien ongemerkt) een belangrijke bijdrage aan het uiteindelijke resultaat.
 
Verder zie ik wederom dezelfde foute manier van eindgebruikers betrekken > quote 'product review waarin met de gebruikers bekeken wordt' Maar ook de goede > quote 'kunnen het ook eerder gaan gebruiken'.
 
Ik pleit ervoor om gebruikers echt te laten werken met de deeloplevering zodat je echt de gebruiksvriendelijkheid en begrijpelijkheid kunt testen. Neem een gebruiker, zet hem achter het scherm en vraag hem wat te doen. Heel leerzaam.
 
Als aanvulling op het artikel kan ik aangeven dat wij tegenwoordig bij nieuwe diensten/producten vaak in sprint 1 een ontwerp maken en testen adhv een simulatie. In sprint 2 wordt dan het product ontwikkeld. Zo weet je heel zeker dat het gaat werken wat je ontwikkelt en je krijg optimale performance van de developers omdat ze niet hoeven te wachten op businessbeslissingen etc.
De redactie vindt deze reactie: OKBen Linders, 06-02-2013 8:13
@Marcel Ben het met je eens dat je de gebruikers zo vaak en intensief als mogelijk is bij de ontwikkeling moet betrekken, des te eerder en beter de feedback die je van hun krijgt. En dat helpt een team om betere kwaliteit te leveren.
 
Ik heb agile teams gezien die dagelijks met de product owner stukjes van het product bekijken, en het laten accepteren. Heel effectief! En teams die juist de demo benutten voor een brede exposure in het bedrijf. Voor mij is er geen foute of goede manier, het zal afhangen van de situatie wat werkt.
 
Je oplossing om in sprint 1 een ontwerp en test te doen, en in sprint 2 het product te ontwikkelen kan een prima aanpak zijn of risico's aan te pakken, en beslissingen voor elkaar te krijgen. Is dat dan ook de klantwaarde van de 1e sprint? Je levert in sprint 1 dan nog geen 'werkende software'.
De redactie vindt deze reactie: OKNumoQuest, 06-02-2013 9:40
Ik vind dit een zeer informatief artikel maar.... soms heb ik dat wel eens ... telkens als ik dit soort artikelen lees, dan heb ik het idee/gevoel 'oude wijn/nieuwe zakken. Met alle Respect, uiteraard.
 
Wat ik namelijk in veel artikelen mis is namelijk materie kennis. Materie kennis in de zin wat IT als materie is, hoe het zich beweegt, aan welke wetmatigheden die onderhevig is .... minor detail, een kleinigheidje heb je al gauw.
 
De reden dat ik dit regelmatig naar voren breng is namelijk dat veel IT specialisten, en nog veel meer Non IT- ers, nu eenmaal met die wetmatigheden te maken krijgen en daar zo vaak tegen in gaan. De gevolgen laten zich telkens raden. Van een simpel incidentje tot gevolgen a la KPN vs een hacker of een Vodafone brand en de gevolgen daarvan.
 
Scrum ontbeert ook dat onderdeel en inzicht. Als je namelijk je even heel sec en eenvoudig richt op de werking van de materie end e wetmatigheden, en die informatie deelt met je klanten, dat je dan plots met zeer eenvoudige methoden toe kan i.p.v. weer een 'nieuwere' methode je aan moeten leren.
 
Gewoon even mijn bescheiden gedachte hier over.
De redactie vindt deze reactie: OKCK, 06-02-2013 10:33
In de basis zorgt dus de communicatie tussen business en ontwikkelteam ervoor dat de kwaliteit goed wordt. Dan kan dus ook in een niet Agile omgeving. Het gaat tenslotte om de communicatie. Dat is de oplossing die ook werkt als je waterval o.i.d. gebruikt.
De redactie vindt deze reactie: OKitk_08348, 06-02-2013 12:12
@Ben: Dank voor jouw reactie. Even citaat uit de boekbespreking:
"Ronduit tegenvallend is het onderzoek. Het probleem zit ‘m vooral in de basis. Huijgens heeft slechts twee organisaties onderzocht. Weliswaar 278 projecten waarvan 29 Agile. Helaas is een groot deel van deze projecten beperkt van omvang en doorlooptijd"
 
Ik zie in mijn eigen omgeving ook vaak organisaties die naar SCRUM grijpen voor releasematig onderhoud. Vooraf onderhoudsvensters afstemmen, kleine partjes per keer. Die techniek hadden we met z'n allen al jaren gelden bedacht en nu noemen we het Agile. Ik zie wel positieve ontwikkelingen in kleinschalige projecten met modeldriven tools als Mendix en Outsystems. Maar ook daar gaat het meestal om kleine trajecten.
 
Nu ben ik zelf ook een groot voorstander van kleine beheersbare projecten. Maar dan zijn we weer bij af. Kijk maar naar FPA statistieken van NESMA. Zodra een project de 1000 funtiepunten passeert gaan doorlooptijd, uren, kosten met sprongen omhoog.
 
Ik hou het erop, dat zolang we project size laag kunnen houden, is de boel beheersbaar. Dat hadden we vroeger met het prototypen ook al bedacht. Agile/Scrum: Oude wijn in nieuwe zakken, goed voor de commercie.
De redactie vindt deze reactie: OKBen Linders, 06-02-2013 12:26
@NumoQuest en @itk_08348 Agile en ook Scrum is deels inderdaad oude wijn in nieuwe zakken, eens. Als je teruggaat naar bv EVO van Tom Gilb dan zie je al hoe belangrijk het continu leveren van waarde is, feedback van de klant. Scrum is een bruikbare verpakking. En ja, communicatie en samenwerken zijn en blijven cruciaal.
De redactie vindt deze reactie: OKBen Linders, 06-02-2013 12:26
@itk_08348 Ik zie organisaties die met Scrum ook grotere projecten beheersbaar krijgen. Bv door User Stories op hoog niveau te schatten, en daarmee te bepalen welke functionaliteit na X sprints geleverd kan worden (met een marge/risico).
 
De product owner heeft veel meer mogelijkheden om te sturen met Scrum: iedere sprint. Dat is veel effectiever dan requirement specificaties en change requests. Moet de product owner dat uiteraard wel benutten, waar ik dat heb zien gebeuren werden projecten inderdaad succesvoller met Scrum.
De redactie vindt deze reactie: OKBen Linders, 06-02-2013 12:29
@CK Als je frequent en veel communiceert in waterval projecten, dan gaat de kwaliteit inderdaad ook omhoog. Maar als je met die communicatie actie onderneemt, dwz product bijstellen, betere werkwijze, dan krijg je al snel een iteratieve manier van werken. Wordt je vanzelf een beetje Agile...
De redactie vindt deze reactie: OKCK, 07-02-2013 12:31
@Ben Linders Daarom begrijp ik die giga omslagen bij die grote partijen niet. Ineens moet alles Agile. Let op: ik ben niet tegen Agile. Wel tegen kortzichtigheid.
De redactie vindt deze reactie: OKBen Linders, 08-02-2013 13:05
@CK Herken het. Ook ik ben voorstander van stapsgewijs en continu veranderen, ook als je Agile en/of Lean gaat toepassen. Wel met doel in het vizier maar flexibel in de reis er naar toe. Top down voorwaarden scheppen, en bottom up verbeteren. Agile en opleggen, iets zegt me dat je self steering teams niet kunt afdwingen ;-)
De redactie vindt deze reactie: OKJurgen Prins, 09-02-2013 18:12
Ja, jullie berichten begrijp ik allemaal, maar mijn vraag is: where is the money.
Uiteindelijk gaat het daarom.
Niet 'gek' doen, maar met de (big) chief meedenken.
De redactie vindt deze reactie: OKJurgen Prins, 09-02-2013 18:14
Aanvulling, zou je zo maar beter van kunnen worden.

De redactie vindt deze reactie: OKCK, 10-02-2013 11:44
@Ben Linders Helemaal mee eens. Maar naast dit issue speelt er naar mijn mening nog een issue. Namelijk dat men Agile als excuus gebruikt. Een "gedegen" fase om specs duidelijk te krijgen is minder van belang als je weet dat je dit in de toekomst toch nog recht kan en mag breien. Een dergelijke instelling zorgt voor extra tijd en kosten. Is hier wel eens naar gekeken?
De redactie vindt deze reactie: OKBen Linders, 11-02-2013 13:07
@Jurgen Hele valide opmerking, wat levert agile op vanuit kwaliteitsperspectief? De kwaliteitswinst die ik zie voor bedrijven is dat het juiste product gemaakt wordt, dat wat de klant nodig heeft, en waar hij/zij dus ook geld aan uit wil geven omdat het voor hem/haar waarde heeft. En dat komt juist door de samenwerking tussen ontwikkelteams en de klant, en het continue bijsturen.
 
Kunnen we hard maken dat agile deze kwaliteitswinst levert? In cijfers blijkt dat lastig, je weet niet of er met een waterval project ook een juiste product uitgekomen zou zijn (alhoewel er volop horror stories zijn waar het met waterval mis is gegaan). Maar agile past bij "no cure - no pay", al na enkele sprints heb je producten die waarde hebben, en heb je een return on investment. Als dat niet zo is, dan lijkt me dat iets om samen als business en IT eens heel kritisch te onderzoeken (retrospective?), en actie te ondernemen!
De redactie vindt deze reactie: OKBen Linders, 11-02-2013 13:18
@ck jazeker! Er zijn agile frameworks, zoals Disciplined Agile Delivery die ingaan op hoe je specificeren en architectuur inpast in Agile. Real options, wat ingaat op hoe je mogelijkheden open kunt houden, maar wel beslissingen neemt. Er is volop aandacht voor technical debt en refactoring. Geen eenvoudige materie, maar wel iets waar zeker voor agile in grotere organisaties / enterprises heel belangrijk is.
 
Agile is niet bedoeld om 'later recht te breien', maar om bij nieuwe kennis (feedback!) en groeiend inzicht (ervaring!) betere beslissingen te nemen, en bij te sturen waar nodig. Niet je kop in het zand steken aan het begin, maar wel reeël zijn en beseffen dat je gewoon niet alles kunt weten als je start.
De redactie vindt deze reactie: OKwilco charite, 03-03-2013 22:13
Oude wijn in nieuwe zakken zit ik hier te lezen. Klinkt een beetje negatief maar het is positief uit te leggen denk ik. Niet alleen door puir over kwaliteit te praten maar in zekere zin is Agile de nieuwe uitleg van wat al jarenlang "gezond verstand" heet. Agile breekt een groot en complex geheel op in kleine brokjes en die pak je stuk voor stuk aan. Eenvoud en overzicht. Ik vergelijk het vaak met een mooie gebeurtenis uit 1969. Toen zijn drie mannen in witte pakken weggeschoten vanaf een lanceerplaats, in een raket richting de maan. Ze vlogen weg, reisden door de ruimte en ze landden ook daadwerkelijk.... op de maan! Eén stapt eruit en maakt een wandeling. De tweede stapt uit en loopt ook een rondje. De derde bleef binnen (en dat terwijl hij daar waarschijnlijk nooit meer terugkomt, maar dat terzijde). Op een mooie dag stijgen ze weer op, reizen door de ruimte en landen weer op de meter nauwkeurig op de plek die al lang van tevoren was berekend. En dat in een tijd waarin Prince II nog niet bestond, computers super langzaam waren, er gerekend werd met slechts 2 cijfers achter de komma met slechts een paar K geheugen en...... geen Agile. Althans, dat denken we! Maar zoals ik al zei, Agile brengt ons weer terug bij gezond verstand. Zo kwamen we op de maan en zo lossen we tegenwoordig een goed deel van de IT-projecten op. En als je Agile leest, het IS gewoon gezond verstand! Alleen is iemand zo slim geweest het nog eens op te schijven en zo het door vele ingewikkelde methodieken verstoorde wereldje weer even wakker te schudden. Die oude wijn, dat klopt dus wel. Maar wat als niemand Die oude wijn nu "Agile" had genoemd?
De redactie vindt deze reactie: OKBen Linders, 03-03-2013 23:45
@Wilco gezond verstand en agile heeft zeker overeenkomsten. Het agile manifesto klinkt logisch, en Scrum is in 1 A4tje te beschrijven. Agile denken en doen blijkt soms toch lastiger. Ik blijf mij daarover verbazen. Common sense is not that common zegt men in het Engels. Zou dat dan echt waar zijn?
Gerelateerde artikelen

30-05-13  Scrum wint populariteit buiten ICT-afdeling

Proactief en voorspellend beheer

Leveranciers van beheertools en organisaties die IT-beheer uitvoeren prijzen veelvuldig hun proactief karakter. Maar is......

36 vacatures
Project Manager / Business Analyst

GlobalOrange BV , Amsterdam

Service Delivery manager

Belastingdienst , Apeldoorn

Business intelligence specialist

De Nederlandsche Bank , Amsterdam

IT Security Consultant

FastFlex , 's-Gravenhage

Technical Project Lead bij T-Systems

Linkit Projectmanagement , 's-Gravenhage

Top 10 Reagerende members
  Aantal reacties
met 3+ sterren
Gemiddelde
waardering
Klik voor meer info1 1561 6.2
Klik voor meer info2 1297 6.0
Klik voor meer info3 1266 6.2
Klik voor meer info4 1068 6.2
Klik voor meer info5 976 6.1
Klik voor meer info6 901 6.1
Klik voor meer info7 755 6.2
Klik voor meer info8 520 6.1
Klik voor meer info9 397 6.0
Klik voor meer info10 391 6.2