Agile principes in een maintenance omgeving
|
|
- Frieda Lenaerts
- 2 jaren geleden
- Aantal bezoeken:
Transcriptie
1 versie: 1.0 Opleiding Master in Projectmanagement Academiejaar Vak: Docent: Business Excellence Nathalie Claes Student:
2 Inhoudopgave Inhoudopgave Inleiding Bedrijf Visie, missie en waarden Team Hulp Aanpak Huidige situatie Beschrijving werking Aannemen van werk Release werking Microplanning Probleem Beschrijving probleem Vaststellen van de hoofdoorzaak Beschrijving van enkele oorzaken Belangrijkste oorzaak Geen oorzaken Onderzoek naar oplossing Agile principes Standpunt van bedrijf Project vs. maintenance omgeving Nieuwe situatie Context Beschrijving In de praktijk Voorstudie Eerdere ervaring Experiment Experiment Experiment Verdere ontwikkeling Evaluatie van het onderzoeksproces Nevenprojecten opgestart Gebruikte afkortingen Bronvermelding van 22
3 1 Inleiding 1.1 Bedrijf Het bedrijf waarvoor ik deze paper geschreven heb, is KBC Global Services NV. KBC Global Services NV is het ICT bedrijf van de KBC Groep NV en staat in voor de ICT infrastructuur, ICT voorzieningen en ICT oplossingen voor de KBC Groep NV Visie, missie en waarden De waarden van de KBC Groep NV (de moedermaatschappij van KBC Global Services NV) zijn algemeen bekend als PRO: Professioneel, Respectvol en Open. Deze waarden worden ook uitgedragen door de verschillende niveaus. Je kunt deze waarden terugvinden op affiches binnen het bedrijf, tijdens presentatie van management en werkuitvoering, en je kunt ze zelfs horen tijdens een gesprek in de koffiehoek. De visie en missie van de KBC Groep NV en KBC Global Services NV zijn minder algemeen bekend, maar wel beschikbaar op het intranet. 1.2 Team De teams, of ook pools, waarop de principes toegepast worden zijn OKP Application & Infrastructure Consumer en Provider. Het Consumer team bestaat uit 5 teamleden en is verantwoordelijk voor de applicatielaag van de KBC Online website, de KBC Merchant Banking website en de KBC Online For Business website. Het Provider team bestaat uit 5 teamleden en is verantwoordelijk voor de applicatielaag van de KBC kantorenplatformen, het hoofdkantoorplatform, het intranetportaal, de KBC Corporate Banking website enz. Voor beide teams is er één teamleider (hiërarchische aansturing en evaluaties), Koen Janseghers, en één teamcoördinator (niet-hiërarchische aansturing),. Om beide teams niet te belasten, wordt het leeuwendeel van de principes van deze paper toegepast binnen het Consumer team. Het Provider team zal minder deelnemen aan de experimenten, maar kan als referentiegroep gebruikt worden. De verdere tekst is dan ook geschreven in naam van het Consumer team. Wanneer er naar het Provider team verwezen wordt, zal de lezer hiervan op de hoogte gebracht worden. 1.3 Hulp De experimenten in deze paper waren niet mogelijk geweest zonder de hulp en steun van mijn diensthoofd, teamleider en teamleden. Van alle rollen was er betrokkenheid vereist op verschillende punten in het proces. 3 van 22
4 2 Aanpak Deze paper gebruikt de PDCA-cyclus (Plan Do Check Act) om het probleem te beschrijven en aan te pakken. Plan Do Check Act Het probleem en de gewenste oplossing beschrijven. Dit wordt aangepakt in sectie "3 Huidige situatie". De nieuwe manier van werken introduceren. Dit wordt beschreven in sectie "4 Onderzoek naar oplossing". Controleren of de nieuwe situatie een verbetering is en of de gewenste doelstellingen van de Plan fase gehaald worden. Dit wordt beschreven in sectie "5 Nieuwe situatie". Identificeren van de verschillen en deze proberen op te lossen in een nieuwe PDCA cyclus. Dit wordt beschreven in sectie "5 Nieuwe situatie" en verwezenlijkt met behulp van verschillende experimenten, de evaluatie en de analyse daarvan. Verder komen er ook enkele elementen terug uit het 8D framework in sectie "3 Huidige situatie". Om de resultaten op te volgen, worden er geen metingen vast gelegd. Wel wordt de werking van het bord geëvalueerd door de leiding en besproken tijdens de poolmeetings. 3 Huidige situatie 3.1 Beschrijving werking Aannemen van werk De teamleden kunnen op volgende manieren werk voorgeschoteld krijgen (in volgorde van dalende prioriteit): 1. Incidenten (NGO): productieproblemen die via de tweede lijn bij ons terecht komen. De prioriteit varieert hier van 1 (extreem dringend) tot 6 (helemaal niet dringend). Incidenten met prioriteit 4 tot en met 6 worden niet onmiddellijk opgenomen. 2. ECARs: binnenkomende aanvragen voor nieuwe, geplande ontwikkeling. 3. Defects: problemen aan code in ontwikkeling of test. Na de overgang van Acceptatie testen naar Productie mogen er geen defects meer zijn: deze worden dan allemaal incidenten Release werking Binnen OKP wordt het verouderde V-model gebruikt voor applicatieontwikkeling. De applicatiecode doorloopt verschillende fases: ontwikkeling, functionele testen, acceptatie testen en productieovergang. De productieovergang is geleidelijk en bestaat uit drie fases: piloten 1, piloten 2 en full park. Voor OKP zijn er zo er vier release momenten per jaar: maart, mei, augustus en oktober. 4 van 22
5 3.1.3 Microplanning Voor beide teams wordt er door de teamcoördinator een microplanning opgesteld. In deze microplanning staan de taken voor elke teamlid en wordt er tot 3 maanden vooruit gepland (meest ideale situatie). Bij het inplannen wordt er rekening gehouden met de ontwikkelingscyclus beschreven in "3.1.2 Release werking", maar deze work breakdown zit niet in de microplanning zelf. Voor elk teamlid wordt er een buffer van 1 tot 2 mensdagen voorzien voor NGO-taken. De microplanning wordt éénmaal per week op maandag overlopen tijdens de poolmeeting. Hierin wordt de haalbaarheid van de huidige planning afgetoetst en worden de teamleden gewezen op de geplande taken voor de komende week. 5 van 22
6 3.2 Probleem Beschrijving probleem IS Who Who is affected by the problem? Teamleden, teamleider, projectleider, klanten, teamcoördinator. Who first observed the problem? (internal/external) Teamleider, diensthoofd. To whom was the problem reported? Teamcoördinator What type of problem is it? Organisatie, prioriteiten IS NOT Who is not affected by the problem? Niemand Who did not find the problem? Teamleden What does not have the problem? Planning van andere domeinen What Why Where When How Much/ Many How Often What has the problem? Planning van teamleden What is happening? Deadlines worden niet gehaald Do we have physical evidence of the problem in our possession? Boekingen van de teamleden Why is this a problem? Niet volgen van gemaakte afspraken, veel overwerk Is the process where the problem occurred stable? Ja Where was the problem observed? Op de werkvloer, in de wandelgangen Where does the problem occur? Op de werkvloer When was the problem first noticed? Altijd geweest When has it been noticed since? Nvt. Quantity of problem? Continu overwerk met pieken tijdens FET en ACC How Much is the problem causing in dollars, people, & Time? What is the trend (continuous, random, cyclical)? Cyclisch tot continu Has the problem occurred previously? Ja What could be happening but is not? Teamleden melden zelf onduidelijkheid rond taken en prioriteiten What could be the problem but is not? Te veel werk ingepland Why is it not a problem? Uiteindelijk geraken we er wel Where could the problem be located but is not? Tijdens de poolmeetings Where else could the problem be located but is not? Bij de FrontEnd domeinen When could the problem have been noticed but was not? Bij de vorige teamleider en dienst How many could have the problem but don t? Alle domeinen van de hele afdeling How big could the problem be but is not? Teamleden vallen uit door stress, verloop What could the trend be but is not? Continu Problem Description - Combine the relevant information, this will be your Problem Description Het actuele probleem wordt geformuleerd als "medewerkers werken aan de 'foute' zaken". 6 van 22
7 3.2.2 Vaststellen van de hoofdoorzaak Om de verschillende oorzaken te kunnen identificeren, is er een visgraat diagram opgesteld. 7 van 22
8 3.2.3 Beschrijving van enkele oorzaken Release werking Omdat er vier ontwikkelingsfases en vier releases per jaar zijn, is er een zekere overlap tussen de verschillende releases. Door deze overlap is het vaak moeilijk om de juiste prioriteiten tussen incidenten, ECARs en defects te bepalen. Officieuze vragen, telefoontjes en s Natuurlijk moet deze optie altijd mogelijk zijn, maar momenteel wordt te veel tijd gestoken/verloren in dit illegale circuit van aanpassingen en ondersteuning. Een open landschap als kantooromgeving laat deze mogelijkheid nog eens extra toe. Poolmeeting Wanneer het zeer druk wordt, dreigt de poolmeeting wel eens weg te vallen. Hierdoor wordt de werkelijkheid niet meer afgetoetst en worden de teamleden niet meer gewezen op de geplande taken van de komende week. De poolmeetings kunnen ook van lange duur zijn. Standaard wordt er één uur ingepland, maar in de praktijk blijkt dit vaak uit te lopen tot anderhalf en zelfs twee uur. Softwarepakketten Er zijn veel verschillende organisatorische instrumenten waar de teamleden mee moeten werken: Lotus Notes, Quality Center, Service Center, MisKBC,... Deze softwarepakketten houden elk apart prioriteiten bij die door de indieners ingesteld kunnen worden. Er zijn verschillende interpretaties van de prioriteiten binnen deze softwarepakketten. Vanuit de softwarepakketten kunnen ook s verstuurd worden en deze worden niet altijd automatisch door het softwarepakket opgeslagen. Hierdoor zijn de verstuurde s niet altijd beschikbaar voor alle belanghebbenden. KPIs Er zijn KPIs binnen de verschillende softwarepakketten voor procesopvolging, maar het belang van deze KPIs is niet duidelijk. Algemeen kan er gesteld worden dat de KPIs niet gehaald worden... en dat dit genegeerd wordt op alle niveaus in de hiërarchie Belangrijkste oorzaak Als belangrijkste oorzaak wordt de onduidelijkheid van taken en prioriteiten geselecteerd. Deze oorzaak bestaat zelf uit verschillende oorzaken: - Ieders taken worden ingepland met de microplanning en deze wordt regelmatig doorlopen. - Er worden prioriteiten gesteld op verschillende niveaus in de hiërarchie en door verschillende leidinggevenden tegelijk (ook bekend als "het probleem van meerdere managers"). - Problemen in productie hebben voorrang op al de rest, behalve bij bepaalde prioriteiten (4, 5 en 6) van productieproblemen. - De softwarepakketten hebben aparte en verschillende prioriteiten. Samengevat weten de teamleden gewoon niet meer wat er eerst gedaan moet worden Geen oorzaken Onderstaande zaken werden geïdentificeerd als geen oorzaak te zijn voor het gestelde probleem. Microplanning De microplanning is flexibel genoeg om wijzigingen in prioriteiten en tijdelijke blokkeringen op te vangen zolang er geen nieuw werk bijkomt of er ernstige wijzingen zijn. 8 van 22
9 4 Onderzoek naar oplossing Dit probleem is niet nieuw: er zullen genoeg bedrijven zijn wat met soortgelijke problemen te kampen hebben. Het is dus niet nodig om iets nieuws uit te vinden, maar we kunnen kijken wat de markt aanbiedt. Eén van de nieuwe trends binnen software development is Agile werken. Van deze manier van werken heeft de auteur al eens een paper geschreven en voor de theorie zou ik graag verwijzen naar [02]. In de volgende paragrafen zullen enkele bruikbare principes uitgelegd worden en deze worden aangepast naar de behoeften binnen de OKP teams. 4.1 Agile principes De Agile methodologieën maken gebruik van het iteratieve en incrementele software ontwikkelingsmodel, maar gaan een kortere iteratietijd gebruiken. De doorlooptijd van een iteratie bij de Agile implementatie loopt van één week tot één maand. Een Agile release bestaat uit meerdere iteraties en een Agile project bestaat uit meerdere releases (zie rechts). De planning gaat slechts per deelniveau gebeuren. Deze manier van plannen staat ook bekend als rolling wave planning, en wordt eveneens beschreven en gebruikt in de PMBok. Figuur 1 Agile Project Life Cycle Verder heeft Agile nog maar weinig gemeen met het klassieke watervalmodel. Eventueel kan er binnen een iteratie wel nog met het watervalmodel gewerkt worden. 4.2 Standpunt van bedrijf Ondanks dat Agile werken een groeiende trend is op de ICT markt, werken we binnen KBC Global Services NV vooral nog via het verouderde V-model, een variant van het klassieke watervalmodel. Tot eind 2009 was het officieel niet toegelaten om binnen de OKP en OSD afdelingen op een Agile manier te werken. Binnen het directoraat was er echter nog een afdeling, OKA, die wel al met een Agile implementatie, Scrum, werkt. Sinds 2010 is de OSD afdeling ook bezig met het introduceren van deze manier van werken. Omwille van enkele succesvolle implementaties binnen OSD zijn er Agile ideeën overgewaaid naar onze afdeling, OKP. Je kunt nu bijvoorbeeld al stand-up meetings waarnemen 's morgens in de wandelgangen. 4.3 Project vs. maintenance omgeving De Agile werking leent zich vooral voor projectwerking. Men kan niet zomaar de principes van sprints, burn charts, velocity, product owners en andere binnen een sterk veranderende maintenance omgeving introduceren. Verder hebben de maintenance taken niet altijd de "high uncertainty" en "volatility" nodig voor Agile. 9 van 22
10 Volgende principes zijn wel eenvoudig toepasbaar binnen een maintenance omgeving: Dagelijkse stand-up meetings Informatieradiatoren Rolling wave planning Op de dagelijkse stand-up meetings wordt de huidige status besproken. De projectleden zeggen kort (elevator pitch) waarmee ze bezig zijn en mogelijke problemen die ze ervaren. De problemen worden pas na de meeting meer diepgaand besproken. Op deze meetings is het hele team aanwezig. Het voordeel van deze dagelijkse meetings is dat het hele team upto-date en betrokken is met de ontwikkelingen van de collega s, een noodzaak bij parallelle ontwikkeling. Duidelijk zichtbaar opgestelde bronnen van informatie bruikbaar voor Management By Walking Around (MBWA). De informatieradiatoren bevatten projectvoortgang informatie, huidige problemen, technische ontwerpen, en hun hoofdfunctie is om in één oogopslag de passant een indruk te geven van het project. Wanneer het niet mogelijk is om de deliverables al op te delen in werkpakketten, kan dit uitgesteld worden tot de details bekend zijn. 5 Nieuwe situatie 5.1 Context Als tijdelijke oplossing rond het probleem van onduidelijkheid rond taken en prioriteiten was er de afspraak ingevoerd dat alle teamleden op het einde van elke werkdag een overzicht van hun taken naar de leiding doorstuurt. In dit overzicht staat er: - Een overzicht van de taken waar ze gewerkt hadden. - Een korte beschrijving wat er precies uitgevoerd was. - De gespendeerde tijd. - De planning voor de volgende dag. Deze manier in combinatie met de microplanning is geen proactieve manier van werken: problemen met het werken aan de verkeerde taken worden pas te laat geïdentificeerd. Verder hebben de teamleden het gevoel dat ze extra (en onnodig) gecontroleerd worden door de leiding en wordt er kostbare tijd verloren op dagelijkse basis bij het opstellen van deze s. Een voordeel van deze werking via dagelijkse s is dan weer dat de teamleden een moment van zelfreflectie hebben over de invulling van de voorbije dag. 5.2 Beschrijving De nieuwe afspraken, gebaseerd op de Agile principes beschreven in "4.3 Project vs. maintenance omgeving", worden in praktijk gebracht op volgende manier: 1. Er wordt een whiteboard gebruikt om de taken per teamlid aan te duiden. 2. Dit takenbord geeft in één oogopslag de stand van zaken en werkverdeling weer. 3. Op dagelijkse stand-up meetings wordt er met het hele team de stand van zaken besproken. 5.3 In de praktijk Aan de hand van een aantal experimenten door continue verbetering wordt een manier van werken uitgewerkt. De nieuwe manier wordt onmiddellijk in gebruik genomen en de theorie wordt getest aan de praktijk. 10 van 22
11 Voor deze aanpak heb je een teamleider nodig die open staat voor nieuwe denk- en werkwijzen, en die ruimte toe laat voor experimenteren Voorstudie Voor we beginnen met onze experimenten, nemen we deel aan een stand-up meeting van de OSD afdeling en krijgen we een theoretische toelichting van de werking Eerdere ervaring Het Provider team had al ervaring met het werken met een informatieradiator (zie figuur). Opzet: - Er is een whiteboard met een overzicht van defects en incidenten per team. - Er is geen indicatie van teamleden of teamsamenstelling. - De hoge prioriteiten staan bovenaan het bord. - De lage prioriteiten staan onderaan het bord en worden in een andere kleur aangeduid. - Er is een aparte zone Done waar de afgewerkte defects en incidenten geplaatst worden. - De ECARs, incidenten en defects worden geplaatst op Post-Its met daarop het referentienummer en een korte uitleg. Werking: - De teamcoördinator plaatst nieuwe defects en incidenten op het whiteboard. - De teamleden pikken ad hoc de defects/incidenten op van het bord. Wanneer het defect/incident van het whiteboard verwijderd zijn, zijn ze in verwerking. - Wanneer de defects/incidenten voltooid zijn, wordt de Post-It door het teamlid in de Done zone gehangen. Voordelen aan deze manier van werken: 1. De prioriteiten van de defects en incidenten zijn duidelijk in gebruik. 11 van 22
12 2. Het is duidelijk hoeveel openstaande defects en incidenten er momenteel zijn. 3. Op elke Post-It kan je lezen wat het defect/incident inhoudt. Nadelen aan deze manier van werken: 1. Er is geen overzicht van de werklast per teamlid. 2. Er is geen manier om ECARs op te volgen. 3. Er is een groot whiteboard dat haast niet gevuld is. 4. Er is geen zichtbare status van voortgang. 5. Post-Its die van het bord gehaald worden, kunnen verloren gaan of vergeten worden. 6. Het principe van de informatieradiator komt hier slechts beperkt tot zijn recht: pas bij ernstige problemen (extreem veel defects/incidenten) zal het whiteboard aandacht trekken. 7. Er is geen betrokkenheid van de teamleden. Wanneer we de nadelen bekijken (en dan vooral 1, 2, 4, 6 en 7), kunnen we al vlug besluiten dat deze manier van werking geen oplossing is voor ons probleem Experiment 1 Tijdens het opstarten van het eerste experiment bevinden we ons midden tijdens de fase van functionele testen (FET). Omwille van problemen met het halen van de streefdatums ligt de focus volledig op defect en incidentwerking. Er wordt uitzonderlijk niet (of verwaarloosbaar) aan ECARs gewerkt. Opzet: - We introduceren een whiteboard met een overzicht van defects per teamlid. - De teamleden sturen nog steeds dagelijkse s naar de leiding. - Elk teamlid krijgt één swim lane. - De hoge prioriteiten staan bovenaan het bord. - De lage prioriteiten staan onderaan het bord en worden in een andere kleur aangeduid. - Er is ongeveer eenmaal per week een stand-up meeting, maar er zit geen regelmaat in. Werking: - De teamcoördinator voegt nieuwe defects toe aan het bord en verwijderd doorstreepte defectnummers. - De teamleden maken zelf een aanduiding van de status: o Doorstreept = gedaan o H = On Hold o W = Waiting - De projectleiders geven aan de teamcoördinator door welke defects prioriteit hebben (naast de prioriteiten in QC). 12 van 22
13 Figuur 2 Whiteboard van experiment 1 Voordelen aan deze manier van werken: 1. De teamleden weten waaraan te werken. 2. De werkverdeling is duidelijk: je ziet wie er overbelast is (zie team AGF) en waar het werk blijft hangen. 3. De prioriteiten van de defects zijn duidelijk in gebruik. Nadelen aan deze manier van werken: 1. Er is weer een tweede manier ontstaan om belangrijke defects aan te duiden, namelijk met een rood uitroepteken. 2. Resources kunnen zonder werk zitten (zie teamlid Petr). 3. Het is niet duidelijk met welke defects de teamleden niet meer verder kunnen. 4. Iedereen past het bord aan wanneer hij wil: er is geen dagelijkse gezamenlijke update. 5. Op dit bord kan je geen ECARs, noch incidenten toevoegen. Dit is blokkerend voor bijvoorbeeld Wim, omdat hij vooral via incidenten werkt. 6. Tijdens de stand-up meetings blijft dat defectnummers niets zeggend zijn: we kunnen het bord niet als hulpmiddel gebruiken en zijn verplicht om een PC of print-out te raadplegen. 7. Er is géén manier voor zelfreflectie van de voorbije dag. Omwille van het grote aantal nadelen is deze manier van werken enkel geschikt als tijdelijke oplossing. Vooral nadeel 5 maakt dat dit bord niet meer gebruikt kan worden na de FET periode. Verder is er niet echt een meerwaarde aan dit bord vol met defects: de lijst van defects, prioriteit, toegewezen teamlid en status kan eenvoudig uit de Quality Center tool getrokken worden. Door de teamleden wordt er dan ook opgemerkt dat er enkel overhead is. Voor de leiding is er echter wel een duidelijk overzicht van de werklast. 13 van 22
14 5.3.4 Experiment 2 Binnen het tweede experiment wordt een nieuwe whiteboard werking geïntroduceerd en starten ook de dagelijkse stand-up meetings. Opzet: - We introduceren een whiteboard met een overzicht van taken per teamlid. - De teamleden sturen nog steeds dagelijkse s naar de leiding. - Elk teamlid krijgt één vak. - De ECARs, incidenten en defects worden geplaatst op Post-Its met daarop het referentienummer en een korte uitleg. - Eventuele prioriteiten worden aangeduid op de Post-Its. - Incidenten worden met een rode titel geschreven. - Herhalende taken worden aangeduid met het recycleersymbool. - Er zijn vier algemene zones toegevoegd: o To Do: taken die nog gedaan moeten worden. o Assessment Needed: taken die nog geschat moeten worden. o Parked: geparkeerde taken. o Done: uitgevoerde taken. - Taken in het vak van een teamlid worden beschouw als Busy. Werking: - De teamcoördinator voegt nieuwe taken toe aan het bord in de zone To Do. - De projectleiders geven aan de teamcoördinator door welke taken prioriteit hebben (naast de prioriteiten in SC en QC). - Op een dagelijkse stand-up meeting wordt het bord overlopen. De teamleden geven hier kort toelichting bij de taken. Eventueel worden er aanpassingen gemaakt aan het whiteboard. Figuur 3 Whiteboard van experiment 2 14 van 22
15 Voordelen aan deze manier van werken: 1. Deze versie van het bord bevat alle taken: ECARs, incidenten en defects. 2. Er is een duidelijk onderscheid tussen To Do, Busy, Assessment Needed, Parked en Done. 3. De teamleden weten waaraan te werken. 4. De werkverdeling is duidelijk: je ziet wie er overbelast is (zie team Davy D.) en waar het werk blijft hangen (Assessment Needed). 5. Er is een manier voor zelfreflectie van de voorbije dag. Nadelen aan deze manier van werken: 1. Het is niet duidelijk wie er taken parkeert (naar Parked verplaatst) en hoe lang deze daar blijven. 2. Het is niet duidelijk wie er taken voltooid (naar Done verplaatst) heeft. 3. Het is niet duidelijk waar iemand precies mee bezig is. 4. Het is niet duidelijk wie er welke Assessements moet maken. 5. Iedereen past het whiteboard aan wanneer hij wil. 6. Er zitten te veel teamleden op dit bord: Davy N. en Bram zitten in projectwerking en zullen altijd maar twee Post-Its hebben. 7. De overhead van de dagelijkse mails wordt nu duidelijk en de teamleden melden dit ook. 8. De betrokkenheid is laag: tijdens de stand-up meeting update de teamcoördinator het bord. De teamleden moeten (te) lang luisteren naar de anderen en die hun taken & problemen. 9. De vakjes voor elk teamlid zijn te klein (zie Davy D.). Deze versie van het whiteboard duidt al beter de verschillende fases van ontwikkeling aan. Verder is er per teamlid een overzicht van de verschillende soorten taken mogelijk. De grootste problemen met dit bord zijn de onduidelijkheid van de taken in de aparte vakken (To Do, Busy, Assessment Needed, Parked en Done) en de lage betrokkenheid. Samen met enkele kernleden van het team en de teamleider wordt het whiteboard van het tweede experiment besproken en worden er verbeteringen aangekaart. Deze verbeteringen worden aangebracht in het derde experiment Experiment 3 Binnen het derde experiment wordt een nieuwe whiteboard werking geïntroduceerd en worden de dagelijkse stand-up meetings verder gezet. De dagelijkse s worden afgeschaft. Opzet: - We introduceren een whiteboard met een overzicht van taken per teamlid en opdeling per fase. - De teamleden sturen géén dagelijkse s meer naar de leiding. - Elk teamlid krijgt één swim lane. - Eventuele prioriteiten worden aangeduid op de Post-Its. - Voor incidenten wordt er met een rode Post-It gewerkt zodat deze meteen opvallen. - Herhalende taken worden aangeduid met het recycleersymbool. - De vier algemene zones zijn er nog, maar enkel de zones To Do en Done worden gebruikt. - Voor assessments wordt er het woord "Ass." op de Post-It geplaatst. - Wanneer beschikbaar wordt er op de Post-Its de totale werklast van de taak geplaatst. - Resources in projectwerking, Bram en Davy N., worden van het bord verwijderd. Werking: - De teamcoördinator voegt nieuwe taken toe aan het bord in de zone To Do. - De projectleiders geven aan de teamcoördinator door welke taken prioriteit hebben (naast de prioriteiten in SC en QC). 15 van 22
16 - Op een dagelijkse stand-up meeting wordt het bord overlopen. De teamleden geven hier kort toelichting bij de taken. Eventueel worden er aanpassingen gemaakt aan het whiteboard. - Tijdens de stand-up meetings worden er streefdatums voor de taken aangeduid. Om meer betrokkenheid te creëren worden bij de ingebruikname van het bord alle teamleden betrokken. Het bord start leeg en ieder teamlid krijgt zijn stapeltje Post-Its uit het vorige experiment. Vervolgens mogen de teamleden elk om de beurt de Post-Its in de juiste ontwikkelingsfase hangen van hun swim lane. Telkens geven ze ook uitleg aan de groep in de vorm van een elevator pitch. Deze manier van werken heeft onmiddellijk succes omdat de teamleden ten eerst zelf inspraak hebben in de nieuwe vorm van het bord en nu op een interactieve manier het bord kunnen opzetten. Figuur 4 Whiteboard van experiment 3 - voor gebruik 16 van 22
17 Figuur 5 Whiteboard van experiment 3 - na de initialisatie meeting Figuur 6 Whiteboard van experiment 3 close-up 17 van 22
18 Figuur 7 Whiteboard van experiment 3 na twee werkweken Voordelen aan deze manier van werken: 1. Er is meer betrokkenheid van het team. 2. De dagelijkse stand-up meetings werken; de teamleden komen er nu zelfs spontaan achter vragen. 3. Deze versie van het bord bevat alle taken: ECARs, incidenten en defects. 4. Er is een duidelijk onderscheid tussen To Do, Busy, Assessment, Parked en Done. 5. De teamleden weten waaraan te werken. 6. De werkverdeling is duidelijk: je ziet wie er overbelast is (zie team Wim) en waar het werk blijft hangen (To Do strook). 7. Er is een manier voor zelfreflectie van de voorbije dag. Nadelen aan deze manier van werken: 1. Er is nog testfase tussen Busy en Done: hierdoor weet je niet welke taken er klaar zijn voor testen. 2. Het whiteboard is te klein aan het worden. 3. De stand-up meetings zijn eerste wat schuift bij dringende problemen. 4. Het is niet duidelijke welke taken bij To Do het dringendste zijn. 5. Het is niet duidelijk wat de prioriteit van de verschillende taken is. Er zitten nog te veel gebreken in de huidige manier van werken zoals nadelen 3, 4 en 5. Qua prioriteiten is er nu nog steeds sturing van de teamcoördinator nodig: deze voegt tijdig nieuwe Post-Its toe aan het whiteboard en bij dringende incidenten worden deze (na overleg met de medewerker) meteen in Busy geplaatst Verdere ontwikkeling We hebben nu al nieuwe manier van werken die de teamleden bevalt en werkt voor de leiding. Nu moet deze werking verder groeien in maturiteit. 18 van 22
19 Na verloop van tijd verwachten we volgende resultaten (in volgorde van groeiende maturiteit): - De stand-up meetings vinden dagelijks plaats. Het tijdstip past zich aan de drukte aan. - De teamleden vullen zelf het bord aan. - De teamleden organiseren en leiden zelf de stand-up meetings. De aanwezigheid en het startsignaal van de teamcoördinator of teamleider is niet meer nodig. - De teamleden stellen zelf hun takenlijst op (na macroplanning van de teamcoördinator). Verder zou ik willen opmerken dat elke vorm van opvolging extra werk introduceert bij de teamleden. De informatie op het bord is altijd beschikbaar in de normale softwarepakketten zoals de microplanning, MisKBC, Service Center en Quality Center. Het extra werk heeft hier echter een meerwaarde waar vooral het menselijke aspect in uitblinkt: - Het schept duidelijkheid voor de leiding (MBWA mogelijk). - De teamleden weten van elkaar wie waar mee bezig is en kunnen elkaar helpen. - Er wordt meer betrokkenheid gecreëerd. - De verantwoordelijkheid wordt bij de teamleden gelegd (team empowerment). 19 van 22
20 6 Evaluatie van het onderzoeksproces Wat kunnen we leren van het gebruikte onderzoeksproces zodat dit in de toekomst beter kan? 1. Aanpak. Tijdens deze studie zijn we te vlug in de Do-fase van het Deming Wheel gegaan: er is te veel gewerkt via trial & error. Er kan tijd gespaard worden door op voorhand het probleem grondig te bestuderen, de root cause(s) vast te leggen, de mogelijkheden uit te werken en het team te betrekken. Ook naar de verschillende types en mogelijkheden van borden kon op voorhand meer onderzoek uitgevoerd worden. 2. Het betrekken van de groep. Het betrekken van de groep in de uitwerking van het laatste bord heeft belangrijke voordelen gehad zoals nieuwe ideeën en meer betrokkenheid. Er moet echter toch opgelet worden dat men niet te zeer democratische beslissingen krijgt. De typische informaticus is schuw ten opzichte van organisatie en administratie, en de oplossing zou te zeer neigen naar een vrijgeleide voor taakindeling. 3. Meten van resultaten. Voor deze studie en experimenten werden er geen metingen gedefinieerd. De evaluatie van de experimenten werd telkens besproken met de leiding en tijdens de poolmeetings. Deze manier van verzamelen van resultaten is sterk subjectief en het interpreteren van impliciete (en soms subversieve) opmerkingen is niet eenvoudig. Het gevaar van de ownership trap loert ook altijd om de hoek en tijdens het uitvoeren van de experimenten is er een waarnemer op afstand nodig. 20 van 22
TFS als perfecte tool voor Scrum
TFS als perfecte tool voor Scrum René van Osnabrugge renevo@delta-n.nl About me René van Osnabrugge Communicate @renevo renevo@delta-n.nl http://osnabrugge.wordpress.com Agenda Wat is Scrum? Wat is ALM
Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil
Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil eagileagileagileagileagileagileagileagi leagileagileagileagileagileagileagileag
End-to-End testen: de laatste horde
End-to-End testen: de laatste horde Dieter Arnouts Agenda Begrip End-to-End testen in het test proces Praktische aanpak End-to-End Test Omgeving Uitdagingen End-to-End testen: De laatste horde 11/10/2010
Kwaliteit in Agile: een gegeven?
QA in Agile: waste? Kwaliteit in Agile: een gegeven? Een praktijkvoorbeeld Arno Balemans senior Quality Assurance consultant Bussum, 29 september 2015 Kwaliteit in Agile 2015 2 Werkzaamheden In mijn opdrachten:
WHITEPAPER IN 5 MINUTEN. 11. Scrum
WHITEPAPER IN 5 MINUTEN A U G U S T U S 2 0 1 4 11. Scrum Deze whitepaper gaat over Scrum. Kort en bondig: Scrum is een software-ontwikkelmethode met vaste sprints van enkele weken waarin steeds een verbeterde
Scrum. Een introductie
Organisatie SYSQA B.V. Pagina 1 van 10 Scrum Een introductie Almere 1999 Proud of it Pagina 1 van 10 Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 Inleiding... 3 2 Scrum... 4 3 Scrum rollen...
WORKSHOP 1W5. De Scrum-projectmethode voor betere groepsresultaten. Rienk van der Ploeg hogeschooldocent Informatica bij IICT-FNT
WORKSHOP 1W5 De Scrum-projectmethode voor betere groepsresultaten Rienk van der Ploeg hogeschooldocent Informatica bij IICT-FNT 11.00-12.00 uur / Expedition Curriculum Vitae Team Lead Software Developers
Software Project Management Plan
Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn inhoud. Het
Bijlage 9. UNI 120621.9 REB GD. Releasebeleid
Releasebeleid Ondanks alle aan de samenstelling van de tekst bestede zorg, kan Newway Retail Solutions bv (Newway) géén enkele aansprakelijkheid aanvaarden voor eventuele directe en/of indirecte schade,
EXIN Agile Scrum Foundation
Voorbeeldexamen EXIN Agile Scrum Foundation Editie april 2014 Copyright 2014 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system
Agile Testen in de praktijk
1 Agenda 2 Agile Testen in de praktijk Summerschool 13 Juli 2011 Introductie Agile de context van agile Testen2.0 de tester in een agile project Waarden en principes DoD, PRA en MTP Testen3.0 in een agile
B.Sc. Informatica Module 4: Data & Informatie
B.Sc. Informatica Module 4: Data & Informatie Djoerd Hiemstra, Klaas Sikkel, Luís Ferreira Pires, Maurice van Keulen, en Jan Kamphuis 1 Inleiding Studenten hebben in modules 1 en 2 geleerd om moeilijke
Agile buiten de IT. Bent u al onbewust bekwaam met agile? Bert Leibbrand bert.leibbrand@itri.nl +31 6 27 74 60 88
Agile buiten de IT Bent u al onbewust bekwaam met agile? Bert Leibbrand bert.leibbrand@itri.nl +31 6 27 74 60 88 Agenda Overzicht Agile: een hype? Agile termen Planningpoker: zelf ervaren Samenvatten Volgende
WHITE PAPER. Agile/Scrum
WHITE PAPER Agile/Scrum Belangrijkste kenmerk van Scrum is de ontwikkeling via een serie van korte - iteraties, in Scrum terminologie sprints genoemd. Introductie Heel in het kort gezegd is Scrum een Agile
Agile Beheer: Mythe of werkelijkheid? Odile Moreau BlinkLane Consulting NIOC 2013 - Arnhem, 5 april 2013
Agile Beheer: Mythe of werkelijkheid? Odile Moreau BlinkLane Consulting NIOC 2013 - Arnhem, 5 april 2013 Achtergrond 2 Agile methoden zijn al een tijd heel populair geworden Zoals Scrum voor software ontwikkeling
Overdracht van project naar beheer. Beheer is ook Agile!
Overdracht van project naar beheer. Beheer is ook Agile! Belangrijkste doelen Project: Binnen tijd en geld een nieuw of aangepast product of dienst aan de klant leveren. Beheer: Het garanderen van continuïteit
De projectmanager. en zelforganiserende teams
De projectmanager en zelforganiserende teams Agenda 16:00 16:30: Inloop 16:30 16:50: Welkomstwoord DUO 16:50 17:00: Welkomstwoord IPMA Noord 17:00 17:30: Oefening zelforganisatie 17:30 18:00: Agile en
Weekstart Keek op de Week
Weekstart Keek op de Week Het WAAROM van de Weekstart? Roll up van de afgelopen week zorgt voor focus op hulpvragen die uit de afgelopen week zijn gekomen en geeft de mogelijkheid de opgeloste hulpvragen
Handleiding helpdesk. Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark
Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark Inhoudsopgave Inhoudsopgave... 2 1. Beheer helpdesk... 3 1.1. Settings... 3 1.2. Applicaties... 4 1.3. Prioriteiten... 5 1.4. Gebruik mailtemplates...
De veranderende rol van de projectleider in een Agile-wereld: Het belang van Agile Leadership
De veranderende rol van de projectleider in een Agile-wereld: Het belang van Agile Leadership 11.45: Ontwikkeling Agile bij ING en de veranderende rol van de projectleider bij ING Jan Gastkemper 12:15:
Agile ervaring Ir.ing. Erik van Daalen
Agile ervaring Ir.ing. Erik van Daalen Eneco Rotterdam 3 december 2013 03-12-2013 Agile Erik van Daalen 1 Hoofdsponsor Sponsors IPMA-N Jaarsponsors 03-12-2013 Agile Erik van Daalen 2 Korte introductie
Workshop verhogen van je persoonlijke effectiviteit. Welkom. Martin Fisch, cc Flickr. UNC Plus Delta alle rechten voorbehouden
Workshop verhogen van je persoonlijke effectiviteit Welkom Martin Fisch, cc Flickr 1 Ik haal altijd mijn deadlines 2 Ik haal altijd mijn deadlines binnen mijn normale werkuren 3 Mijn mailbox is aan het
Riskpoker - Confirmation - Planningpoker. Opfrissing TMap NEXT in scrum en toelichting op de opdracht Leo van der Aalst - Jos Punter - Hans Lantink
Riskpoker - Confirmation - Planningpoker 10-7-2013 Opfrissing TMap NEXT in scrum en toelichting op de opdracht Leo van der Aalst - Jos Punter - Hans Lantink 1 Presentatie (sprint) backlog items 1 2 3 4
T IS AGILE VOOR DE VERANDERING
T IS AGILE VOOR DE VERANDERING Wendbare organisatie, teal, agile, Nieuwe kreten of is er echte verandering op til? Pascal Vanden Bossche pascalvdbossche Wij begeleiden organisaties om succesvol projecten
erbeterdezaak.nl Processen managen Een inleiding erbeterdezaak.nl
Processen managen Een inleiding Proces cultuur De klant komt eerst Zorg dat je altijd waarde toevoegt Moedig eigen initiatief aan Geef medewerkers ruimte Moedig teamwerk aan Beloon team prestaties Werk
het starters lab het Starters Lab starters4communities werkt met jong talent aan maatschappelijke innovatie.
het starters lab In het Starters Lab bouwen jonge talenten in teams sociale ondernemingen. Samen sterker! Jij bent: starters4communities werkt met jong talent aan starters4communities presenteert het Starters
Wanneer ga je Agile? Wat is Agile Project Management?
Wanneer ga je Agile? Agile Project Management 1 past goed in deze tijd. Het is snel, flexibel en leuk. Je kunt het echter niet altijd en overal gebruiken. Het werk en de organisatie moeten geschikt zijn
[ SCRUM. ] Een introductie
[ SCRUM. ] Een introductie [ SCRUM IN HET KORT. ] Scrum is een agile-proces, welke het mogelijk maakt om te focussen op het leveren van het beste resultaat in de kortst mogelijke tijd. Het maakt het mogelijk
Agile Scrum voor Non-IT
whitepaper Agile Scrum voor Non-IT 020 2614 195 1 Inhoud 3 Waarom Agile Scrum 6 Hoe werkt Agile Scrum 8 Over ASG Scrum aanpak voor non-it projecten Scrum is een aanpak waarmee in projecten slimmer kan
Agile : Business & IT act as one
Agile : Business & IT act as one Waar loop je tegen aan als je Business en IT samen Agile wil laten worden? Otto van den Hoven November 2015 1 Managing change : Traditionele waterval Business deliverables
Versie-/Releasebeleid
Versie-/Releasebeleid Ondanks alle aan de samenstelling van de tekst bestede zorg, kan Newway Retail Solutions bv (Newway) géén enkele aansprakelijkheid aanvaarden voor eventuele directe en/of indirecte
Oplossingen voor het testen van objectgeoriënteerde software
Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen
Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken
Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken De business organisatie heeft altijd stijgende verwachtingen van uw IT organisatie. Meer dan ooit is het van
14/11/2010. Voorbeelden van productrisico s. Omschrijving bevindingenanalyse. Productrisicoanalyse (1)
Project- en productrisico s RISICO- ANALYSE & TESTSTRATEGIE No. 24 Project- versus productrisico s No. 25 Voorbeelden van projectrisico s Business Project overschrijding Tijd Budget Slechte testomgeving
APMG-International Webinar. ITIL Editie 2011 Wednesday 16 Mei 2012 / 15:30 CET Presented by Karel Höster
www.apmg-international.com APMG-International Webinar (In samenwerking met Ultracomp Academy) ITIL Editie 2011 Wednesday 16 Mei 2012 / 15:30 CET Presented by Karel Höster www.apmg-international.com ITIL
INNOVATION BY MAKING LEARNING BY DOING
INNOVATION BY MAKING LEARNING BY DOING 1 INNOVATION BY MAKING, LEARNING BY DOING Bij alles wat we doen, hanteren we deze twee principes. Innovation happens by making. The only way to learn innovation is
Software Quality Assurance Plan
FACULTEIT WETENSCHAPPEN Software Quality Assurance Plan Software Engineering groep 3 Jeroen Van den haute Versie Datum Auteur Commentaar 0.1 09/11/2010 Jeroen Van den haute Eerste versie 0.2 12/11/2010
Process & IT: eerst KIEZEN maakt het DOEN daarna zoveel makkelijker
Process & IT: eerst KIEZEN maakt het DOEN daarna zoveel makkelijker Wim Tindemans Manager Business Applications Business and Automation Solutions Egemin NV Agenda Probleemstelling Tegenstelling tussen
Anko Tijman Een agile teststrategie op basis van MoSCoW
Titel, samenvatting en biografie Anko Tijman Een agile teststrategie op basis van MoSCoW Samenvatting: Deze presentatie behandelt de toepassing van de teststrategie vanuit een agile perspectief: welke
MOTUS- APP: De gebruikersgids
MOTUS- APP: De gebruikersgids 1 Hoe de MOTUS- app gebruiken Een gebruikersgids voor de web tool van MOTUS is beschikbaar via de webpagina s http://www.motus.vub.ac.be en www.motusdemo.com. Wat nu volgt
Resultaat gerichter Testen
Resultaat gerichter Testen Verandering van test beleid bij Rabobank International De Rabobank 1 Rabobank International Information Systems &Development IS&D Global Services & IT Risk Management Strategy
LSSN seminar Amsterdam 01-11-2012 Edwin Kippers Master Black Belt. Project Management
Lean Six Sigma Scrum Niet alleen voor software projecten LSSN seminar Amsterdam 01-11-2012 Edwin Kippers Master Black Belt Project Management Project succes survey The Standish Group's report: "CHAOS Summary
Scrum. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.
Scrum Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING... 3 2 SCRUM... 4 3 FASERING... 5 4 KENMERKEN... 6 4.1 DE SCRUM-MEETING...
sturen om tot te komen Rijnconsult Business Review
Je moet behoorlijk sturen om tot zelfsturing te komen 56 Rijnconsult Business Review Het creëren van effectieve autonome teams is geen nieuw onderwerp voor veel organisaties. Maar de dynamiek waarin veel
fysieke beveiliging onder controle Fysieke beveiliging Lean & Agile Thimo Keizer
fysieke beveiliging onder controle Fysieke beveiliging Lean & Agile www.fysiekebeveiliging.nl Thimo Keizer Fysieke beveiliging Lean & Agile 2016 www.fysiekebeveiliging.nl Thimo Keizer Niets uit deze uitgave
Meer grip en betere resultaten
Meer grip en betere resultaten Hand-out Het belang van fasering Voorbereiding Commitment Opdracht fase 1 fase 2 Knip het project op in verschillende tijdseenheden, elk vooraf gedefinieerd met een eindresultaat
Newway Versie- /Releasebeleid
Newway Versie- /Releasebeleid Ondanks alle aan de samenstelling van de tekst bestede zorg, kan Newway Retail Solutions bv (Newway) géén enkele aansprakelijkheid aanvaarden voor eventuele directe en/of
De brug tussen requirement engineer en gebruiker
De brug tussen requirement engineer en gebruiker Gerlof Hoekstra Even kennismaken Senior testconsultant / product manager In de ICT sinds 1985 Sinds 1993 testen/kwaliteitszorg Opdrachtgevers Postbank KPN
ISO 20000 @ CTG Europe
ISO 20000 @ CTG Europe 31/10/2007 mieke.roelens@ctg.com +32 496266725 1 Agenda 31 oktober 2007 Voorstelling Project Business Case: Doel & Scope Projectorganisatie Resultaten assessments en conclusies De
Procesbeheer bij de VLM
CoP Procesbeheer 8 mei 2009 1 Procesbeheer bij de VLM Maarten Stieperaere CoP Procesbeheer 8 mei 2009 2 Procesbeheer bij de VLM Bron: Rosemann & de Bruin CoP Procesbeheer 8 mei 2009 3 Processen bij de
Portfoliomanagement software van Thinking Portfolio
Portfoliomanagement software van Thinking Portfolio Eenvoudig in gebruik Snelle implementatie Betrouwbaar in de cloud Vast maandbedrag Onbeperkt aantal gebruikers PMO Portfoliomanagement Programma s en
Agile Consortium International Agile Master Assessment
Agile Consortium International Agile Master Assessment Agile Master Assessment Info & Criteria Page 1 of 5 Version 1.0 Wat is het Agile Master Certificaat Het Agile Master Certificaat is een bewijs van
EXIN Agile Scrum Foundation
Preparation Guide EXIN Agile Scrum Foundation Editie december 2014 Copyright 2014 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing
Toelichting bij onze werkwijze
Toelichting bij onze werkwijze GMI group Helpdesk Referentie: IDH_20120713_HDP_V2.0 Datum: 23 juli 2015 COLOFON TITEL Een toelichting bij onze werkwijze GMI group Helpdesk UITGEVER GMI group N.V. De Pintelaan
AERIUS II. Mark Wilmot Product Owner AERIUS. Ministerie van EL&I Programma Directie Natura 2000 Programma Stikstof (PAS)
AERIUS II Mark Wilmot Product Owner AERIUS Ministerie van EL&I Programma Directie Natura 2000 Programma Stikstof (PAS) m.j.wilmot@mineleni.nl Inhoud Toelichting AERIUS II Project Demo Agile / Scrum proces
Test rapportage Waarom eigenlijk?
Testrapportage Boodschappers van de koning? Test rapportage Waarom eigenlijk? TestNet voorjaarsevenement 2015 Jurian van de Laar Jurian van de Laar @JurianvdL 30 april 2015 @JurianvdL Jurian van de Laar
SCRUM METHODE.
SCRUM METHODE www.gladwell.nl bel ons 020-240 2244 WAT IS SCRUM? Scrum is een methode om effectief, kostenefficiënt, klant- en resultaatgericht te werken in teams. Met Scrum kunt u de principes van agile
doel bereikt zelfsturing inrichten veiligheid fundament Behoeftepiramide van een "Social Business"
Behoeftepiramide van een "" (Naar analogie piramide van Maslow) Maslow rangschikte de volgens hem universele behoeften van de mens in een hiërarchie. Volgens zijn theorie zou de mens pas streven naar bevrediging
Planning opstellen. Dag van de projectleider 09/10/2014
Planning opstellen Dag van de projectleider 09/10/2014 Intro Eric Duton Programmamanager / Projectleider Ervaring binnen Vlaamse overheid Agenda Soorten planningen Plannen vanuit Planningswijze Resources
1. Work Breakdown Structure en WBS Dictionary
1. Work Breakdown Structure en WBS Dictionary CUSTOMER migratie Management Technische Transitie Meetings Status Reporting Administratie Technisch Upgegrade Systemen (3-tier) Delta Analyse & Functioneel
Testomgevingen beheer
Testomgevingen beheer Testen brengt het verwachte resultaat en de huidige toestand bij elkaar. Het geeft aanknopingspunten om de planning te maken, het product te verbeteren en om zorgen bij belanghebbenden
Leiderschap in een organisatie met technische professionals
Quintor Leiderschap in een organisatie met technische professionals Johan Tillema CEO Quintor Professionele softwareontwikkeling ICT Architectuur Java,.NET en Mobile Informatieanalyse Opgericht in 2005
Factsheet CONTINUOUS VALUE DELIVERY Mirabeau
Factsheet CONTINUOUS VALUE DELIVERY Mirabeau CONTINUOUS VALUE DELIVERY We zorgen ervoor dat u in elke volwassenheidsfase van uw digitale platform snel en continu waarde kunt toevoegen voor eindgebruikers.
Software Project Management Plan
Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem Eerste versie voor klant 1.0 27/11/2010 Brecht Van Laethem Aanbrengen verduidelijkingen + toevoegen
Praktische zaken INFOB3SO
Praktische zaken INFOB3SO Department of Information and Computing Sciences, Universiteit Utrecht November 7, 2014 Welkom bij INFOB3SO Ofwel: Systeemontwikkeling: Methoden en Management Vervolg op MSO,
Een register is een verzameling reglementeringen die hetzelfde doel hebben, nl. veiligheid
Wetgevingsregister Overzicht Wetgevingsregister is een module van het systeem waar gebruikers van Verifield hun conformiteitsprogramma binnen de organisatie kunnen beheren. In Wetgevingsregister vindt
Agile werken: zó doen we dat
Agile werken: zó doen we dat Bij Freshheads werken we graag volgens de Agile aanpak. De voordelen? Verhoogde efficiëntie en flexibiliteit, snellere resultaten en grotere betrokkenheid. Maar hoe gaat het
Testen. Presentatie. Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2
Testen Presentatie Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2 Algemeen Tegenwoordig behoeft het belang van testen nauwelijks nog te worden uitgelegd. Binnen organisaties speelt
Toelichting bij onze werkwijze
Toelichting bij onze werkwijze GMI group Helpdesk Referentie: IDH_20120713_HDP_V2.0 Datum: 15 oktober 2015 COLOFON TITEL Een toelichting bij onze werkwijze GMI group Helpdesk UITGEVER GMI group N.V. De
E-PROCUREMENT GEBRUIKERSBEHEER
E-PROCUREMENT GEBRUIKERSBEHEER HANDLEIDING VOOR AANKOPERS GEBRUIKSVOORWAARDEN Rechten De FOD Personeel en Organisatie behoudt alle rechten (waaronder auteursrechten, merkrechten en octrooien) met betrekking
De juiste requirements juist
De juiste requirements juist Een voorwaarde voor succesvolle applicatie ontwikkeling Arno van Herk Managing partner Synergio B.V. a.van.herk@synergio.nl 2011 Een brug naar onze presentatie Uniface is Compuware's
Continuous Delivery. Sander Aernouts
Continuous Delivery Sander Aernouts Info Support in een notendop Maatwerk softwareontwikkeling van bedrijfskritische kantoorapplicaties Business Intelligence oplossingen Managed IT Services Eigen Kenniscentrum
Enterprise Architectuur. een duur begrip, maar wat kan het betekenen voor mijn gemeente?
Enterprise Architectuur een duur begrip, maar wat kan het betekenen voor mijn gemeente? Wie zijn we? > Frederik Baert Director Professional Services ICT @frederikbaert feb@ferranti.be Werkt aan een Master
ALGEMEEN PROJECT RAPPORT
Evaluatie EVALUATION rapport RAPPORT SENDI PROJECT project ALGEMEEN PROJECT RAPPORT This report contains the evaluation analysis of the filled out questionnaire about the Kick off meeting in Granada Dit
RAPID DEPLOYMENT PLAN IBM MAXIMO SCHEDULER
Voor de implementatie van onze IBM Maximo planning oplossing Scheduler maken wij gebruik van een standaard rapid deployment methode welke ons in staat stelt u snel na aanschaf van uw licenties op weg te
Oplossingen voor het testen van objectgeoriënteerde software. Oplossingen voor het testen van. Overzicht. Pieter van den Hombergh.
Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen
Energiemanagement actieplan. Koninklijke Bammens
Maarssen, 16 februari 2015 Auteur(s): Niels Helmond Geaccordeerd door: Simon Kragtwijk Directievertegenwoordiger Milieu / Manager Productontwikkeling C O L O F O N Het format voor dit document is opgesteld
Software Quality Assurance Plan
Software Quality Assurance Plan GameTrac Versie Datum Auteur(s) Opmerking 1.0 10-12-2010 Bram Bruyninckx Eerste iteratie 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn
Timemanagement Kerngebieden onderscheiden
Timemanagement Als manager heb je veel verschillende werkzaamheden: je geeft leiding aan je medewerkers, maar je hebt ook je eigen taken. Je hebt met je medewerkers te maken, met andere collega s en afdelingen
Ordina VSM Customer Portal
Ordina VSM Customer Portal Waarom gebruik maken van een Customer Portal U wilt de voortgang van uw meldingen (verstoringen / vragen) voor uw beheercontract(en) via een internetportaal kunnen inzien. Eventueel
Communicatieplan m.b.t. CO2
Communicatieplan m.b.t. CO2 Opgesteld door : H. van Roode en Y. van der Vlies Datum : 20 februari 2014 Goedgekeurd door : H. van Roode Datum: 20 februari 2014 Blad 2 van 11 Inhoudsopgave Inleiding... 3
Adding value to test tooling Hoe en waarom DevOps de wereld van performance testen verandert
Hoe en waarom DevOps de wereld van performance testen verandert Najaarsevenement 14 oktober 2015 Inleiding Wie zijn we Marc Koper: Specialist in performancetesten / testautomatisering HenkJaap van den
Business Case. <>
Business Case SYSQA B.V. Almere Versie : Datum : Status : Opgesteld door : Pagina 2 van 8 Inhoudsopgave 1 Inleiding... 1.1 Doel van dit document...
ITIL komt van Mars, Agile van Venus
ITIL komt van Mars, Agile van Venus Frederick Winslow Taylor 2 Scientific Management 3 Werknemers zijn... 4 Denkwerk overlaten aan... 5 Dus Tayloriaans = Standaardisatie van zoveel mogelijk activiteiten
14-9-2015. Scrum in het kort
Les 3 Scrum in het kort Scrum is een agile proces dat het ons mogelijk maakt om de hoogste waarde in de kortste tijd te realiseren. Het maakt het ons mogelijk om snel en regelmatig echt werkende software
Plan van Aanpak. project Tetris Packing
Plan van Aanpak project Tetris Packing Inleiding! 4 Projectomschrijving! 5 Producten! 5 Testplan! 5 Ontwerprapport! 5 Implementatierapport! 5 Testrapport! 5 Systeemdocumentatie! 5 Aanpak! 6 Projectmethodiek!
Stuurgroep ICT innovatie in de ouderenzorg. 12 oktober 2010
Stuurgroep ICT innovatie in de ouderenzorg 12 oktober 2010 Agenda High Level Scope Projectorganisatie en werkingsprincipes Projectplanning en roll-out Projectopvolging Evaluatie diensten Agenda volgende
Agile Testing isn t Risking IT! Bram Bronneberg Test Manager Logica - CGI
Agile Testing isn t Risking IT! Bram Bronneberg Test Manager Logica - CGI B.W.F.P.M. BRONNEBERG TEST MANAGER UIREMENT & QUALITY MANAGEMENT Introductie Q & A Achtergrond Agile Testing isn t Risking IT!
Voorbereiding pilootfase Het Nieuwe Werken
Voorbereiding pilootfase Het Nieuwe Werken Het Nieuwe Werken Het Nieuwe Werken gaat ruimer dan telewerken. Terwijl telewerken beperkt is tot het werken op een andere plaats, gaat het bij het Nieuwe Werken
Succes = Noodzaak x Visie x Draagvlak 2. Case: Implementatie Requirements Lifecycle management bij Rabobank International
Succes = x Visie x Draagvlak 2 Case: Implementatie Requirements Lifecycle management bij Rabobank International dinsdag 3 oktober 2006 Spider Congres Agenda Inventarisatie SPI-knelpunten Implementatie
Kwaliteit en Testen binnen Agile Project Management volgens Scrum bij Planon. David Griffioen 11 april 2006
Kwaliteit en Testen binnen Agile Project Management volgens Scrum bij Planon David Griffioen april 2006 Agenda Planon Agile Scrum Scrum bij Planon Kwaliteit en Testen Planon Planon maakt productsoftware
Tennis Vlaanderen Elit-clubtoepassing / Lid worden 8/12/2014
Tennis Vlaanderen Elit-clubtoepassing / Lid worden 8/12/2014 Louizapoortgalerij 203 bus 3, 1050 Brussel Tel.: 02/548.03.00 Fax: 02/548.03.03 E-mail: info@tennisvlaanderen.be E-mail clubs: elit@tennisvlaanderen.be
Lean management in een paar minuten
management in een paar minuten Introductie De term staat voor slimmer, sneller en slanker alles met de helft doen: slimmer werken, niet harder! is een managementfilosofie en een bedrijfsstrategie Focus
Agile in Projecten minimalisme of strak pak? Richard Weber PMP
Agile in Projecten minimalisme of strak pak? Richard Weber PMP De Spreker Richard Weber Directeur & oprichter Adviseur & coach Projectmanagement Profile Dynamics ICT & Bedrijfskundige achtergrond Trainer
Kickstart Architectuur. Een start maken met architectuur op basis van best practices. Agile/ TOGAF/ ArchiMate
Kickstart Architectuur Een start maken met architectuur op basis van best practices. Agile/ TOGAF/ ArchiMate Context schets Net als met andere capabilities in een organisatie, is architectuur een balans
Requirements Management Werkgroep Traceability
Requirements Management Werkgroep Traceability Plan van Aanpak (1) Doel en definitie van Traceability Traceability heeft tot doel om tijdens het ontwikkelproces status informatie te verschaffen omtrent
Het WAAROM van de Dag Start
De Dag Start Het WAAROM van de Dag Start Kort cyclisch (dagelijks) focus houden op en bijdragen aan organisatiedoelen Het afstemmen van de capaciteiten (mens/machine) op te realiseren productie doelstellingen
enterprise; development; operations; CA Technologies; DevOps; management; agility; software delivery life cycle; SDLC; CA
Asset 1 van 7 De kloof dichten tussen Dev en Ops Gepubliceerd op 12 may 2014 Hoe verbetert u de software delivery life cycle? DevOps wordt gezien als de volgende stap in Agility. In deze paper leest u
Whitepaper ERP Vreemde ogen
Whitepaper ERP Vreemde ogen Citrien Procesconsult Braamweg 77 3768 CE SOEST T 06 14 27 19 97 W www.roaldvanderheide.nl E info@roaldvanderheide.nl Vraagstelling Hoe de kans op een succesvolle ERP-implementatie