WGR Werk, Geldzaken, Recht en de Beurs
Hier kun je alles kwijt over sollicitaties, werksituaties, belastingen, (handelen op) de beurs, hypotheken, beleggingen en salarissen, arbeidscontracten of geschillen met je (huis)baas. Alles over werk, geldzaken en recht dus.
Je vermoeden klopt als een bus. Als je echt Agile wil gaan, zul je eigenlijk ook een continuous build proces moeten hebben. DWZ, dat als een programmeur een nieuw stuk code maakt (of veranderd), deze wordt ingechecked. Op dat moment wordt er een aparte versie gebouwd, die op dat punt alleen toegankelijk is voor de betreffende programmeur. Over die versie wordt een eerste bak unittests gedraaid. Geven die geen fouten, dan wordt de versie automatisch gedeployed.quote:Op vrijdag 21 januari 2011 14:43 schreef Erlandil het volgende:
Beetje laat nog met reageren (dacht dat het topic niet meer bijgewerkt was).
Nee, OTAP hebben we wel. O, ontwikkelomgeving, hierin zitten de ontwikkelaars om velerlei niveaus te werken, afhankelijk van het systeem hun eigen O omgeving of niet.
T: Testomgeving, hierin wordt een eerste oplevering gedaan voor ketentest.
A: acceptatieomgeving, productielike, hierin wordt eigenlijk een groot gedeelte van de FAT en GAT gedaan.
P: productie natuurlijk.
Waar wordt er nu gescrumd en opgeleverd? Antwoord: in O en T (mogelijk dat daar al de fout zit hoor).
Dus je hebt eigenlijk meerdere releases per dag, als de programeurs een beetje doorpezen kan je elk uur een nieuwe release hebben.
Ik heb zo'n vermoeden dat julie daar nog niet helemaal zijn, qua proces.
Metalman. Maar ook ESF fan. Solo vakantiefietser met tentje. Dichter.
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
Wat voor soort programeertaal/omgeving is het?quote:
Dat zijn dus 8 weken waarin de scrumteams ondertussen enkel in O bezig zijn, maar er kan daar blijkbaar geen volledige integratie plaatsvinden.
Metalman. Maar ook ESF fan. Solo vakantiefietser met tentje. Dichter.
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
Nee. Nee.quote:Op woensdag 19 januari 2011 20:02 schreef MoneyTalks het volgende:
Is het mogelijk als student een bijbaantje als software tester te vinden? Zo ja, weet iemand bedrijven die part time softwaretesters aannemen?
Part time softwaretesters bestaan wel, maar dat zijn dan mensen van de afdeling die het product gebruiken, en uitgeleend worden om te testen.
Voor het uitvoeren van software tests worden soms wel uitzend krachten gebruikt, als het om vrij dom invulwerk gaat. Dan ben je geen software tester. Maar een uitvoerder, die gewoon een lijstje moet afwerken.
Testen is meer dan wat lukraak op knoppen drukken en door een applicatie heen wandelen.
Metalman. Maar ook ESF fan. Solo vakantiefietser met tentje. Dichter.
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
Nee dat absoluut niet, maar ook niet op dag niveau, en zelfs niet op week niveau en soms zelfs niet op sprint niveau (mijns inziens).
Het grote dilemma alleen is wel dat indien je echt agile wilt gaan, dat je dan alle systemen waar mee gemoeid is wel staande moet houden. Er mag dus niet in het volgende systeem iets omdonderen. Dit gaat binnen een systeem dus nog wel goed, maar zodra je over systemen heen gaat wordt het ingewikkelder.
Programmeertaal.. goede vraag. Heb ik weinig mee te maken. Ik maak enkel gebruik van XML om services mee te checken. Er zit zowieso stukken JAVA in, binnen de services wordt spul van IBM gebruikt. Cordys is een onderdeel (geen idee in welke taal die werkt).
Het grote dilemma alleen is wel dat indien je echt agile wilt gaan, dat je dan alle systemen waar mee gemoeid is wel staande moet houden. Er mag dus niet in het volgende systeem iets omdonderen. Dit gaat binnen een systeem dus nog wel goed, maar zodra je over systemen heen gaat wordt het ingewikkelder.
Programmeertaal.. goede vraag. Heb ik weinig mee te maken. Ik maak enkel gebruik van XML om services mee te checken. Er zit zowieso stukken JAVA in, binnen de services wordt spul van IBM gebruikt. Cordys is een onderdeel (geen idee in welke taal die werkt).
Eigenlijk bedenk ik me net hoe een continuous buildproces zich verhoudt tot een businessproces wat meerdere dagen overstijgt of zelfs tot aan een week of wat gaat. Zonder mogelijkheid tot tijdreizen per systeem of systemen gaat dit sowieso conflicten geven.
Mag ik vragen op welk gebied je te maken krijgt met software testers? Misschien kunnen we dan ook al vragen beantwoorden die je mogelijk hebt?quote:Op vrijdag 21 januari 2011 15:29 schreef Citizen.Erased het volgende:
TVP. Ik krijg binnenkort ook met software-testers te maken dus een extra inzicht is nooit weg.
1 van de dingen die echt moeten als je gaat scrummen, is dat je requirements gaat opknippen in hapklare brokken. Idealiter, worden alle changes zo klein opgeknipt dat een programeur ze in 1 dag af krijgt. Dat lijkt me bij jou al een probleem, als ik het zo hoor.
Metalman. Maar ook ESF fan. Solo vakantiefietser met tentje. Dichter.
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
Euh, er bestaan ook wel echte softwaretesters die deeltijd werkenquote:
[..]
Nee. Nee.
Part time softwaretesters bestaan wel, maar dat zijn dan mensen van de afdeling die het product gebruiken, en uitgeleend worden om te testen.
.Vorige klus als freelance testcoördinator was 16 uur/week. Daarvoor in vaste dienst 32uur/week.
Maar bijbaantjessoftwaretesters ben ik nog nooit tegengekomen, en het lijkt me er ook niet geschikt voor.
ik moet verrassend weinig
Es ist heute schlecht und wird nun täglich schlechter werden, – bis das Schlimmste kommt
Es ist heute schlecht und wird nun täglich schlechter werden, – bis das Schlimmste kommt
Ja, dat is absoluut wel een probleem. Ik zal eerlijk bekennen dat wat dat betreft het requirementsproces uberhaupt een ramp is. Maar dat neemt niet weg dat je, zelfs al heb je het zo klein opgeknipt dat je dan alsnog een probleem hebt. Als je op dag 1 iets wijzigt in programmatuurcode a kan dit op systeem niveau prima werken. Maar zodra je dan over een hele lange keten heen gaat kijken waarin een offerte van aanbod naar contract en financiele verwerking moet dan is een wijziging halverwege zo'n looptijd dus funest. Met name tijdtechnisch gaan we dan vaak nat (ook het uitrollen van een nieuw stukje code kan precies op moment T vallen waardoor die keten onderbroken is).quote:
1 van de dingen die echt moeten als je gaat scrummen, is dat je requirements gaat opknippen in hapklare brokken. Idealiter, worden alle changes zo klein opgeknipt dat een programeur ze in 1 dag af krijgt. Dat lijkt me bij jou al een probleem, als ik het zo hoor.
Vandaar ook mijn eerste vraag zo. Eigenlijk moet ik de vraag dus nog beter stellen, hoe verhoudt scrum zich tot een hele lange keten met afhankelijkheden van ook legacy systemen. (in dit geval een mainframe wat niet 24/7 open is maar van 10-17) en een doorlooptijd van meerdere dagen.
Ik kom terecht in een projectmanagement-team. Het ontwikkelen en vervolgens testen van bepaalde software is een onderdeel van dat project. Ontdekte dat er op dit moment nog niet echt gestructureerd getest wordt en dat daar dus nog wel enige verbetering in aan te brengen is.quote:
[..]
Mag ik vragen op welk gebied je te maken krijgt met software testers? Misschien kunnen we dan ook al vragen beantwoorden die je mogelijk hebt?
Niet. Ik kan me voorstellen dat je na een scrum periode, de changes van de verschillende teams samenvoegt, en die dan door die keten heen jaagt. Terwijl dat gebeurt, gaat het scrumteam gewoon verder met ontwikkelen. Een scrumteam is een klein softwarefabriekje, waar afgevaardigden in zitten van alle disciplines. Het moet niet veel groter zijn dan een man of 8.quote:
Eigenlijk moet ik de vraag dus nog beter stellen, hoe verhoudt scrum zich tot een hele lange keten met afhankelijkheden van ook legacy systemen. (in dit geval een mainframe wat niet 24/7 open is maar van 10-17) en een doorlooptijd van meerdere dagen.
Niet elke organisatie is er geschikt voor, het vergt wennen, leren en aanpassen.
Metalman. Maar ook ESF fan. Solo vakantiefietser met tentje. Dichter.
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
ja, je kan deeltijd werken, maar dan ben je wel fulltime testerquote:Op vrijdag 21 januari 2011 15:37 schreef sigme het volgende:
[..]
Euh, er bestaan ook wel echte softwaretesters die deeltijd werken
Met alle kennis, training en ervaring die nodig is!
Metalman. Maar ook ESF fan. Solo vakantiefietser met tentje. Dichter.
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
Oeh, dan wil ik graag een heel brutaal adviesje geven. Probeer gelijk te achterhalen of er iemand specifiek verantwoordelijk is voor het testen van de ontwikkelde software, zowel door de ontwikkelende partij als de accepterende. Liefst voor beide. Indien deze er niet is (en met name niet op projectmanagement niveau) dan aan de bel trekken. Dat gaat je waarschijnlijk een hoop kosten schelen als je daar nu al iemand voor hebt die het testproces voor je in kaart brengt.quote:
[..]
Ik kom terecht in een projectmanagement-team. Het ontwikkelen en vervolgens testen van bepaalde software is een onderdeel van dat project. Ontdekte dat er op dit moment nog niet echt gestructureerd getest wordt en dat daar dus nog wel enige verbetering in aan te brengen is.
En uiteraard, als dit niet mogelijk is, probeer dan te achterhalen wat de verantwoordelijkheden zijn van de software testers zelf. Hieruit kun je ook een hoop zaken afleiden waar je 'winst' mee kunt halen.
Tja.. daar neig ik dus ook heel erg naar. Een aparte ketenomgeving waarin gewoon om de zoveel tijd (zeg maar release kalender) een boel nieuwe stukjes gehangen worden en afhankelijk daarvan de boel naar A en P knikkeren. Ik ben me ook wel goed bewust van het feit dat onze scrumteams van foutieve samenstelling zijn (business ontbreekt soms, test ontbreekt soms, er is een apart scrumteam voor ontwerpquote:
[..]
Niet. Ik kan me voorstellen dat je na een scrum periode, de changes van de verschillende teams samenvoegt, en die dan door die keten heen jaagt. Terwijl dat gebeurt, gaat het scrumteam gewoon verder met ontwikkelen. Een scrumteam is een klein softwarefabriekje, waar afgevaardigden in zitten van alle disciplines. Het moet niet veel groter zijn dan een man of 8.
Niet elke organisatie is er geschikt voor, het vergt wennen, leren en aanpassen.
)
Dude...technisch gesproken scrummen julie totaal niet!
Bedrijven geven vaak een eigen draai aan ontwikkelmethodes, maar dit klinkt heel, uh, aardig zeggen, 'creatief'
Bedrijven geven vaak een eigen draai aan ontwikkelmethodes, maar dit klinkt heel, uh, aardig zeggen, 'creatief'
Metalman. Maar ook ESF fan. Solo vakantiefietser met tentje. Dichter.
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
Nog brutaler, is er eigenlijk wel een goede acceptant? Die ook zich dusdanig gedraagd? Als de softwaretesters iemand nodig hebben die knopen kan doorhakken als het onzeker is of iets volgens specificatie is bijvoorbeeld, is die er dan?quote:
[..]
Probeer gelijk te achterhalen of er iemand specifiek verantwoordelijk is voor het testen van de ontwikkelde software, zowel door de ontwikkelende partij als de accepterende.
Inderdaad...aan wie geven de testers input? Wat voor soort? Er zijn bedrijven waar projectmanagers een go/no go beslissing laten maken door de testafdeling. Lekker makkelijk, maar dus ook fout. Testers geven inzicht in risiko's en kwaliteit. De acceptant moet beslissen of je ermee live gaat. Als tester speel je een belangrijke riool in dat proces, maar je bent geen beslisser!quote:En uiteraard, als dit niet mogelijk is, probeer dan te achterhalen wat de verantwoordelijkheden zijn van de software testers zelf. Hieruit kun je ook een hoop zaken afleiden waar je 'winst' mee kunt halen.
Metalman. Maar ook ESF fan. Solo vakantiefietser met tentje. Dichter.
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
Ik ga met bovenstaande post helemaal mee 
(en ook met het 'creatieve scrummen' , dit kwam ook reeds uit onze evaluatie van testteam)
(en ook met het 'creatieve scrummen' , dit kwam ook reeds uit onze evaluatie van testteam)
Agile is gek, maar OTAP en agile kunnen elkaar ook redelijk bijten (als je echt snel als een madderfakker wil gaan doe je niet aan otap, gewoon alleen O en misschien A).quote:
[..]
Je vermoeden klopt als een bus. Als je echt Agile wil gaan, zul je eigenlijk ook een continuous build proces moeten hebben. DWZ, dat als een programmeur een nieuw stuk code maakt (of veranderd), deze wordt ingechecked. Op dat moment wordt er een aparte versie gebouwd, die op dat punt alleen toegankelijk is voor de betreffende programmeur. Over die versie wordt een eerste bak unittests gedraaid. Geven die geen fouten, dan wordt de versie automatisch gedeployed.
Dus je hebt eigenlijk meerdere releases per dag, als de programeurs een beetje doorpezen kan je elk uur een nieuwe release hebben.
Ik heb zo'n vermoeden dat julie daar nog niet helemaal zijn, qua proces.
Bovendien hoeft Agile niet elke dag een oplevering te zijn, agile is meer een manier van werken dan wat anders. Iedereen valt een beetje over elkaar heen dat agile perse snel en kort moet zijn, maar dat is niet waar. Zelfde idee als dat requirements en ontwerpen niet nodig zijn bij agile (blabla geen tijd etc), maar dat heeft niets met agile te maken.
IMHO is agile niet meer dan een hele dynamische manier van werken, waarmee je in korte iteraties en met korte lijnen tussen ontwerp-bouw-test zo snel mogelijk resultaat wilt halen. Soort van prototyping on steriods.
De hele invulling van een agile werkmethode staat vrij los, hoewel er een aantal kenmerken als scrum en daily standups zijn die wel vereist zijn. Oja, en een team van mensen die goed met elkaar kunnen werken, flexibel en communicatief vaardig zijn is ook wel handig.
Hmm. ja, ergens is Agile en OTAP natuurlijk in beginsel conflicterend. Het ene gaat uit van alles in een keer en het andere gaat uit van een gefaseerd model.
Verder, volledig eens dat het een dynamische manier van werken is waarin vaak de misstap gemaakt wordt dat requirements en ontwerp er minder (of niet) toe doen.
Maar dan nog, het kenmerkt zich wel door relatief vaak en snel kleinere delen opleveren (wel werkend uiteraard). Dit is ook de reden dat het vaak naar management gecommuniceerd wordt als zijnde: ' kan snel iets opleveren' --> korte time to market producten. Maar dat is dus lang niet altijd waar als aan de grondbeginselen getornd wordt.
Verder, volledig eens dat het een dynamische manier van werken is waarin vaak de misstap gemaakt wordt dat requirements en ontwerp er minder (of niet) toe doen.
Maar dan nog, het kenmerkt zich wel door relatief vaak en snel kleinere delen opleveren (wel werkend uiteraard). Dit is ook de reden dat het vaak naar management gecommuniceerd wordt als zijnde: ' kan snel iets opleveren' --> korte time to market producten. Maar dat is dus lang niet altijd waar als aan de grondbeginselen getornd wordt.
Het argument is inderdaad vaak; ja we gaan agile doen want dan hebben we snel resultaat.quote:
Hmm. ja, ergens is Agile en OTAP natuurlijk in beginsel conflicterend. Het ene gaat uit van alles in een keer en het andere gaat uit van een gefaseerd model.
Verder, volledig eens dat het een dynamische manier van werken is waarin vaak de misstap gemaakt wordt dat requirements en ontwerp er minder (of niet) toe doen.
Maar dan nog, het kenmerkt zich wel door relatief vaak en snel kleinere delen opleveren (wel werkend uiteraard). Dit is ook de reden dat het vaak naar management gecommuniceerd wordt als zijnde: ' kan snel iets opleveren' --> korte time to market producten. Maar dat is dus lang niet altijd waar als aan de grondbeginselen getornd wordt.
Overigens kunnen agile en otap elkaar heel goed aanvullen, maar dan moet je je agile traject wel wat structureren. En structuur is op 1 of andere manier altijd een woord wat mensen die agile doen niet tof vinden, net zoals plannen
Sommige organisaties zien Agile als een excuus om niet meer te ontwerpen of te documenteren. ' Want daar hebben we geen tijd voor' . Dat is onzin natuurlijk. Je maakt alleen niet een ontwerp voor je begint, dat vrijwel vaststaat, maar TIJDENS je iteratie. Met alle disciplines erbij. Er komen dus geen dingen in te staan die leuk klinken, maar voor de programmeur bijna onmogelijk zijn om te bouwen, bijvoorbeeld. Daar kom je nu gelijk achter ipv na een paar maanden. Is best handig.
Omdat je beter snapt wat je doet kun je de zaken beter, korter, gerichter documenteren. Maar sommige mensen noemen zodra ze Agile gaan alle documentatie 'waist' . Dat is best jammer.
En ja, je krijgt snel EEN resultaat. Maar acceptant en management zullen moeten accepteren dat ze soms functionaliteit in brokken opgeleverd krijgen. Uitgangspunt zal dan wel zijn dat elke opgeleverde componenten waarde heeft voor de business, maar het zal niet gelijk zijn wat ze willen. Als dat niet goed gesnapt wordt, kun je na een paar iteraties, halverwege het project (om zo te zeggen) last krijgen van management dat niet snapt dat het nog niet af is 'want je zou sneller gaan werken met dat Agile gedoe!'.
Je moet echt committent hebben van hoog in de boom om succes te hebben.
Omdat je beter snapt wat je doet kun je de zaken beter, korter, gerichter documenteren. Maar sommige mensen noemen zodra ze Agile gaan alle documentatie 'waist' . Dat is best jammer.
En ja, je krijgt snel EEN resultaat. Maar acceptant en management zullen moeten accepteren dat ze soms functionaliteit in brokken opgeleverd krijgen. Uitgangspunt zal dan wel zijn dat elke opgeleverde componenten waarde heeft voor de business, maar het zal niet gelijk zijn wat ze willen. Als dat niet goed gesnapt wordt, kun je na een paar iteraties, halverwege het project (om zo te zeggen) last krijgen van management dat niet snapt dat het nog niet af is 'want je zou sneller gaan werken met dat Agile gedoe!'.
Je moet echt committent hebben van hoog in de boom om succes te hebben.
Metalman. Maar ook ESF fan. Solo vakantiefietser met tentje. Dichter.
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
Hmm ja, dat is zeker waar. Ik moet wel eerlijk zeggen dat we hier zowel een documentatie probleem alsook wel een specifiek ontwerp team, dus die documentatie wordt er wel heel belangrijk van. Het is alleen nog wel zo, eerst ontwerpen, en dan verder scrummen voor de uitwerking. Wat natuurlijk ook al raar is. Komt ook nog eens bij dat mensen van ontwerp lang niet alle onderdelen helder voor ogen hebben.
Verder is het acceptatieproces nu ook ter discussie
Laten we hopen dat het voor komend jaar wat anders ingericht gaat worden (dan zijn we ook effectief in beheer.. dat is ook al wat apart)
Verder is het acceptatieproces nu ook ter discussie
Laten we hopen dat het voor komend jaar wat anders ingericht gaat worden (dan zijn we ook effectief in beheer.. dat is ook al wat apart
)
De wat lossere benadering van documentatie binnen Scrum maken het niet voor elke plek geschikt...als jij je moet houden aan de regels van de FDA bijvoorbeeld, dien je te voldoen aan hun normen qua documentatie over je testproces, en resultaten. Dat is niet makkelijk met elkaar te verzoenen.
Maar goed dat je de moed er in houdt, testers moeten altijd oppassen niet te cynisch te worden
We hebben best een leuk vak tenslotte.
Maar goed dat je de moed er in houdt, testers moeten altijd oppassen niet te cynisch te worden
We hebben best een leuk vak tenslotte.
Metalman. Maar ook ESF fan. Solo vakantiefietser met tentje. Dichter.
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
26-10 Attila/Eskimo Callboy (Amsterdam), 21-11 The Algorithm (Haarlem)
Ik had me dit jaar voorgenomen om vooral niet te cynisch te beginnen.. Ik zondigde al gelijk na het eerste overleg
maar goed, voorlopig hebben we voor de komende release een hele zware No Go afgegeven, ons advies is om dit vooral niet in productie te nemen. Sterker nog, niet eens in acceptatie te zetten. Ik heb na 2 weken nog geen enkele succesvolle keten scenario gezien
maar goed, voorlopig hebben we voor de komende release een hele zware No Go afgegeven, ons advies is om dit vooral niet in productie te nemen. Sterker nog, niet eens in acceptatie te zetten. Ik heb na 2 weken nog geen enkele succesvolle keten scenario gezien
Dat zijn ook zaken die ik zeker ga doen. Het daadwerkelijk gestructureerd testen van de ontwikkelde software staat daar nog in de kinderschoenen en zag daarin al een aantal verbeterpunten.quote:
[..]
Oeh, dan wil ik graag een heel brutaal adviesje geven. Probeer gelijk te achterhalen of er iemand specifiek verantwoordelijk is voor het testen van de ontwikkelde software, zowel door de ontwikkelende partij als de accepterende. Liefst voor beide. Indien deze er niet is (en met name niet op projectmanagement niveau) dan aan de bel trekken. Dat gaat je waarschijnlijk een hoop kosten schelen als je daar nu al iemand voor hebt die het testproces voor je in kaart brengt.
En uiteraard, als dit niet mogelijk is, probeer dan te achterhalen wat de verantwoordelijkheden zijn van de software testers zelf. Hieruit kun je ook een hoop zaken afleiden waar je 'winst' mee kunt halen.
Lees hier even mee om te kijken wat er een beetje speelt bij het testen van software en wat voor technieken daarvoor gebruikt worden.
Tip van de dag, probeer ze zover te krijgen om een consult te krijgen van gespecialiseerd extern bedrijf. Advies van buitenaf wil vaak wel een beetje helpen 
Advies is niet gratis, maar kan wel veel opleveren.
Advies is niet gratis, maar kan wel veel opleveren.
Jep, zeker voor eenmalig inzicht in je situaties zijn zaken als Quickscans zeer nuttig, bijvoorbeeld van TPI (next) of TMMI.
Geven vaak een heel grondig inzicht in de situatie en hoeft niet veel te kosten. Het kan je wel de punten geven die je kan oppakken ter verbetering.
Geven vaak een heel grondig inzicht in de situatie en hoeft niet veel te kosten. Het kan je wel de punten geven die je kan oppakken ter verbetering.
Wat een rust hier 
Valt er nog wat te testen?
Valt er nog wat te testen?
Knapen die storneren willen moeten mannen met automatische incasso's zijn
|
|
