Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Een overzicht van alle publieke databanken die informatie tonen die verzameld werden door onze applicaties.
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Over ons en onze visie op het semantische ecosysteem tussen overheden en burgers
Als team werken we dag in dag uit aan het versterken van onze democratie door burgers en bedrijven actief te informeren en te betrekken bij (lokale) besluitvorming. Daarnaast streven wij ernaar de digitale dienstverlening te vereenvoudigen door informatie efficiënt te onderhouden en te hergebruiken via één digitale invoer.
Lees hier meer over in onderstaand document waarin onze visie en missie worden beschreven, over onze waarden als organisatie:
Of bekijk onderstaand filmpje waarin onze Missie en Visie meer in detail wordt uitgelegd:
De manier waarop we onze producten ontwikkelen en samenwerken is gebaseerd op het Scaled Agile Framework (SAFe) maar aangepast om beter te werken met de ABB Digiteam manier om dingen te doen en het aantal mensen in ons team.
Deze pagina is nog in opbouw. Lees je iets raar? Vraag er even naar! david.suijkerbuijk@vlaanderen.be
Grote uitdagingen worden in kleine, concrete stappen ontwikkeld. Zo ontstaat er een constante flow en zien we het geheel groeien.
Transparant overzicht houden op het werk
Werken in behapbare blokken
Voldoende en flexibel plannen
Verantwoordelijkheden op de juiste plaats
Rollende roadmap die minstens één jaar vooruit kijkt.
Groeispurts van 10 weken eindigend met een Centrale Planningsdag.
Iedere Spurt bestaat uit vier sprints en één IPI.
Het releasen van ontwikkelingen is niet per definitie gekoppeld aan de cadans.
We gebruiken een vrij uitgebreide roadmap. Daarbij vinden we het belangrijk dat we concreet definiëren voor welke doelgroep de desbetreffende functionaliteit meerwaarde oplevert. Deze bijgewerkte roadmap op middellange termijn vind je in onze online-tool die gelinkt is aan de JIRA-tool die het hele productteam gebruikt voor de planning en opvolging van de sprints & spurts in de scaled agile werking.
Het opstellen en bijsturen van de roadmap is een continue gegeven: deze wordt elke groeispurt bijgestuurd in functie van de resultaten en ervaringen van de afgelopen groeispurt en eventuele bijkomende doelen of gewijzigde prioriteiten.
Een groeispurt heeft steeds een duur van 10 weken. Het omvat vier reguliere (ontwikkel)sprints en een Innovatie en Planning Iteratie (IPI). In de laatste week van een groeispurt/ IPI is er een Centrale Planningsdag (CPD) waar de doelen voor de volgende groeispurt wordt vastgelegd.
Door in periodes van 10 weken te werken is er voldoende focus om stappen te zetten maar niet te veel rigiditeit om met een steeds veranderende context om te gaan. Het geeft de ontwikkelteams een duidelijke focus voor 10 weken maar wel de mogelijkheid om met de volgende groeispurt in te spelen op (veranderde) prioriteiten uit de organisatie.
Een sprint is een afgebakende periode van twee weken waarin een productteam aan de slag gaat om een duidelijk sprintdoel te bereiken. Sprints volgen elkaar steeds direct op en hebben een aantal vaste elementen/rituelen:
Sprintplanning
Backlog Refinement Meeting (BRM)
(Daily) stand-up
Sprint demo (review)
Sprintrapportering op Solution Stand-up
Naast het ontwikkelen van functionaliteiten is er ook nood aan andere activiteiten om een product(team) verder te laten groeien. Daarom zijn de laatste twee weken van een groeispurt steeds speciaal omdat het expliciet ruimte biedt voor ...
Innovatie en experimenten
Training
Planningsactiviteiten voor volgende groeispurt
Wanneer? De Innovatie en Planning (IPI) iteratie gebeurt steeds op het einde van een Spurt.
Op deze pagina vind je meer info over het verloop en de praktische invulling van een groeispurt bij Digiteam ABB
Een groeispurt heeft steeds een duur van 10 weken. Het omvat vier ontwikkelsprints en een Innovatie en Planning Iteratie. In de laatste week van de een groeispurt is er een Centrale Planningsdag (CPD) waar de doelen voor de volgende groeispurt wordt vastgelegd.
Door in periodes van 10 weken te werken is er voldoende focus om stappen te zetten maar niet te veel rigiditeit om met een steeds veranderende context om te gaan. Het geeft de ontwikkelteams een duidelijke focus voor 10 weken maar wel de mogelijkheid om met de volgende groeispurt in te spelen op (veranderde) prioriteiten uit de organisatie.
Aan het werken in sprints - als onderdeel van een groeispurt- zijn bij ABB, zoals klassiek in de sprintwerking, een aantal vaste ceremonies verbonden.
In deze rubriek beschrijven we hoe de teams deze ceremonies invullen en wie er aan deel neemt.
De sprintplanning is de eerste ceremonie van een sprint en vindt plaats op de eerste (werk)dag van een nieuwe sprint. Tijdens de sprintplanningsmeeting plant het scrum team samen met de scrum master en de product owner de aankomende sprint door de stories op de backlog (in Jira) te bespreken en in te schatten. Indien nodig licht de product owner items op de product backlog nog toe zodat iedereen deze begrijpt. (let wel: voorafgaandelijke kan er een backlog refinement gebeurd zijn met het team en kan het zijn dat de inhoud van de hoogst geprioriteerde user stories nog fris in het hoofd zit van de deelnemers en dus weinig extra uitleg behoeft).
De leden van het scrum team (designers, analisten, developers) stellen op basis van hun capaciteit en de prestaties in vorige sprints vast welke user stories zij oppakken. De lijst met geselecteerde user stories vormt de sprint backlog. Vervolgens formuleert het scrum team gezamenlijk een definitief sprintdoel dat een duidelijk antwoord geeft op de vraag: voor welke doelstellingen engageren we ons met het team tijdens de komende sprint?
Deelnemers aan de sprintplanning zijn (minimaal) de product owner - (lead) developers - designer - analist- scrum master.
Het doel van de backlog Refinement Meeting is om de hoogste prioriteit items in de product backlog te ontleden in user stories die geschikt zijn voor opname in de volgende sprint. Tijdens deze bijeenkomst neemt het team gezamenlijk de items bovenaan de product backlog en ontleedt ze in ‘goede’ user stories. Tijdens de backlog refinement vergadering bekijkt het team elk item om de beurt en bespreekt of het haalbaar is om in de volgende sprint op te nemen of dat het verder moet worden opgesplitst en/of verfijnd om het uitvoerbaar te maken in de volgende sprint.
Een belangrijke verantwoordelijkheid rust bij de Product Owner en de Scrum Master om als voorbereiding op deze vergadering - de backlog in juiste orde te zetten. Uiteraard kan vanuit het scrum team ook - voorafgaandelijk - backlog items klaargezet worden om te bespreken samen met de items bovenaan de backlog.
Deelnemers aan de backlog refinement meeting zijn - minimaal - de product owner, de (lead) developer(s), de designer en de scrum master.
De stand-up is een korte bijeenkomst (virtueel of fysiek) tijdens de lopende sprint op frequente basis (dagelijks tot enkele keren per sprint) waarin de deelnemers op beknopte wijze een antwoord geven op de volgende 3 vragen:
Wat heb je sinds de vorige stand-up gedaan?
Wat ga je doen tegen de volgende stand-up?
Heb je vragen of problemen bij het uitvoeren je werk tijdens de sprint?
Tijdens de stand-up wordt in Jira het actieve sprintbord gebruikt.
Deelnemers aan de stand-up zijn minimaal de product owner, de (lead)developers, de designer, de analist en de scrum master. Bijkomend is het nuttig dat op bepaalde momenten ook de tester en de product manager deelnemen.
De verschillende product teams van het Digiteam ABB vullen de Daily Stand-up routine momenteel bewust op een andere manier in:
Organisatieportaal: elke dag een stand-up, behalve op vrijdag, van 11:45 - 12:00
Kalliope: elke woensdag en elke eerste vrijdag van de sprint is er een stand-up van 30 minuten
Loket, Gelinkt Notuleren, Architectuurteam: de stand-up wordt samen met de backlog refinement gehouden op de eerste vrijdag van de sprint
Elke eerste maandag van een sprint rapporteert de product owner/ product manager over het verloop van de vorige sprint op de Solution Stand-up. De rapportering wordt gedaan aan de hand van een status slide in een bepaalde template. Er wordt gerapporteerd over:
is het sprintdoel gerealiseerd?
zijn we nog on track om het groeispurt doel te realiseren?
welke belangrijke inhoudelijke realisaties zijn er in de voorbije sprint (afgewerkt en begonnen maar niet afgewerkt)
hoe zag de sprint burndown eruit en hoeveel story points werden gerealiseerd versus hoeveel waren er gepland?
zijn er bepaalde issues of risico's waar de collega PM's en de Solution Stand-Up van op de hoogte moeten zijn?
De rapportering op de Solution Stand-up wordt in een plenaire sessie gedaan om iedereen zoveel mogelijk geinformeerd te houden. Meer en meer producten dragen samen bij aan een of meerdere waardestromen en de informatie uitwisseling tijdens een sprintrapportering is hier een belangrijke drijvende factor in.
Hoe?
De sprint review of sprint demo meeting aan het einde van elke sprint gehouden. Deze informele bijeenkomst is bedoeld om terug te kijken op wat er behaald is en waar nodig de Product Backlog aan te passen. Bij deze meeting zijn ook alle belanghebbenden van het project aanwezig, die hier de kans hebben om feedback te geven. De sprint demo wordt elke laatste vrijdagnamiddag van de sprint gehouden en dit per product. De organisatie en moderatie is in handen van de scrum master.
Deelnemers aan de sprint demo zijn in essentie iedereen die bij de ontwikkeling van het product - als onderdeel van een of meerdere oplossingen - betrokken is. Dit betekent dus niet alleen de leden van het scrum team (developers, designer, analist, product owner en product manager, scrum master) maar ook product managers en product owners van andere producten, gebruikers van het product, business stakeholders, leden van het architectuurteam welkom zijn op de tweewekelijkse sprintdemo.
De techniek van Impact mapping helpt de productteams bij Digiteam ABB en hun belanghebbenden niet alleen om de product roadmaps te visualiseren, maar ook om uit te leggen hoe ‘deliverables’ aansluiten op de behoeften van gebruikers, en om te communiceren hoe gebruikersresultaten zich verhouden tot oplossingen op hoger niveau en waardeketens.
Voor deze oefening gebruiken we een techniek van impact maping, beschreven door Neuri Consulting LLP. Bij het maken en bijwerken van de impactmappings van een waardeketens denken de teams na over gedragsveranderingen die een grote impact zouden hebben op de gebruikers van de in de waardeketen betrokken product of producten. Vervolgens schrijven we ze op in de impactmap en groeperen we de impacts op actoren, persona's of gebruikerscategorieën met behulp van vertakkingen. Vervolgens voegen we per tak (impact per groep) deliverables toe die die gedragsveranderingen kunnen ondersteunen en streefdata die we nastreven om de impact te realiseren. Vervolgens nemen we de organisatiedoelen die door die impacts worden ondersteund op in de mindmap.
De impact mapping wordt minstens 1 keer per groeispurt gedaan en ten laatste tijdens de IPI. Het is een interactieve manier om voor een bepaalde waardeketens de meest impactvolle en dus belangrijkste product prioriteiten voor de volgende groeispurt te bepalen. Deelnemers aan de impact mapping zijn het product team (PM, PO, architect, developer, designer, tester) en een breed publiek aan betrokken stakeholders. De eigenaar van de waardeketen leidt de sessie.
Onze impact mappings worden gemaakt en bijgewerkt in Miro. Ze worden traditioneel bijgewerkt tijdens de tweede week van de IPI (Innovatie en Planning Iteratie) en zijn te vinden op het CPD-bord onder Solution. Impact mappings van voorbije groeispurten worden doorgaans mee gearchiveerd en zijn bereikbaar via het overzicht naar de voorbije groeispurten als een van de eerste frames van het CPD-bord onder Solution.
Vertrek steeds vanuit een meetbare doelstelling voor de creatie van waarde. Vertak vervolgens naar de actoren die we moeten bereiken (en beinvloeden) om de doelstelling te realiseren. Schrijf vervolgens per actor op aparte vertakkingen uit welke impact we precies moeten bereiken om onze doelstelling te halen. Tenslotte bepalen we per impact concrete 'deliverables' die we moeten realiseren om de impact ook effectief te kunnen realiseren.
Naast het ontwikkelen van functionaliteiten is er ook nood aan andere activiteiten om een product(team) verder te laten groeien. Daarom zijn de laatste twee weken van een groeispurt steeds speciaal omdat het expliciet ruimte biedt voor ...
Innovatie en experimenten
Training
Planningsactiviteiten voor volgende groeispurt
Wanneer? De Innovatie en Planning (IPI) iteratie gebeurt steeds op het einde van een Spurt.
Om de activiteiten die typisch in de IPI plaatsvinden te kunnen organiseren werd een kalender opgemaakt waarin elk van de noodzakelijke activiteiten een plaats kreeg. Bij het uitzetten van de activiteiten hebben we rekening gehouden met enkele voorkeuren van het team met betrekking tot vergaderdagen en hebben we geprobeerd de innovatie-activiteiten als één blok te groeperen om focusverschuiving tussen innovatie en planningsvergaderingen te voorkomen. Deze kalender wordt gebruikt om bij de betrokken teams placeholders in de agenda te zetten zodat de nodige tijd wordt gevrijwaard in elke IPI.
Voorbeeldactiviteiten: testen nieuwe technologieën, breder delen van nieuwe functionaliteiten, kennisoverdracht, scoping sessies & brainstormen, retrospectieves, manier van werken herbekijken, ...
Deze kalender ziet er momenteel zo uit:
WEEK 1 IPI: FOCUS op sprintplanning IPI - Innovatie - Inspect and adapt
WEEK 2 IPI: Focus op Groeispurtplanning - Retrospectieve en Sprintdemo IPI
De capaciteit van de IPI mag niet worden ingecalculeerd voor het halen van de Spurt-doelen. Het is niet gewoon een 'extra' sprint.
De centrale planningsdag is een essentieel terugblikmoment om terug te kijken naar de Groeispurt die eindigt en te plannen voor de volgende Groeispurt. Daarom vindt deze plaats tussen twee groeispurten in.
Het geeft tijd aan alle actoren in onze agile productontwikkeling om ...
Delen van gerealiseerde oplossingen a.h.v. demo’s in een plenaire sessie.
Plannen van de volgende Spurt o.b.v. de voorbereiding die vooraf gemaakt werd tijdens de IPI. Epics (productfunctionaliteiten) worden gepland om uit te voeren. Hun implementatie draagt uiteindelijk bij tot oplossingen waaraan ze gelinkt zijn.
Afstemming tussen verschillende producten om tot gedeelde oplossingen te komen
Het programma van een CPD is gebaseerd op de onderdelen van het standaardprogramma dat binnen het Scaled Agile Framework wordt beschreven maar de activiteiten worden doorheen de volledige IPI verspreid. De belangrijkste finale afstemming gebeurt op een één dag.
Wanneer? De Centrale Planningsdag (CPD) gebeurt steeds tijdens de IPI op laatste donderdag van een Spurt.
Wat? | Doel | Aanwezigen | |
---|---|---|---|
Day/Part
Maandag
Dinsdag
Woensdag
Donderdag
Vrijdag
AM
Sprintplanning IPI
Innovation
Innovation
Innovation
Inspect and Adapt
AM
(Retrospectieve)
Capacity check DEV + Design
PM
Innovation
Innovation
Innovation
Innovation
Inspect and Adapt
PM
(Retrospective)
Dag/Deel
Maandag
Dinsdag
Woensdag
Donderdag
Vrijdag
AM
Impact Mapping
Impact Mapping
Story Mapping
CPD
Retrospective
AM
Story Mapping
Story Mapping
Impact Mapping
PM
Impact Mapping
Impact Mapping
Capacity Check PM's ifv planning
CPD
Sprintdemo IPI
PM
Story Mapping
Story Mapping
Prepare backlog for sprint 1
Vooraf
Impactmapping per waardestroom
Overzicht van mogelijke deliverables
PM's & PO's,
Solution niveau
Designers
Business Analisten
Business-personen
Vooraf
Retrospectieve per productteam
Terugkijken en leren op het ontwikkelproces
Alle teamleden van een productteam
Vooraf
Voorbereiding CPD per productteam
Bekijken wat realistisch is om in de volgende groeispurt op te nemen. - Storymapping - Planning op CPD-bord
PM en PO
Development leads
Vooraf
Capaciteitsinschatting - sync met dev's en designers
Vraag naar dev's en designers in overeenstemming brengen met beschikbaarheid
RedPencil
Hannes
Veronique
Vooraf
Capaciteitsinschatting - sync met PO's en PM's
Feedback aan PM's en PO's over beschikbaarheid dev's en designers voor hun producten voor de volgende groeispurt
PO's
PM's
Veronique
9h00 - 9h15
Introductie door
IT-directeur (en Manager Digitale Oplossingen)
Verwelkoming
PM's & PO's
Productteams
Business-personen
Solution niveau
9h15 - 10h30
Demo's gekoppeld aan de waardestromen
Tonen wat er in de voorbije groeispurt werd ontwikkeld per waardestroom.
PM's & PO's
Productteams
Business-personen
Solution niveau
10h30 - 15h00
Break-outsessies per waardestroom
Finaal overlopen van de planning voor die waardestroom over de producten heen.
PM's & PO's
Relevante productteams
Business-personen
15h00 - 15h30
Planning finaliseren per product
Moment voor de PM's en PO's om hun planning af te werken vooraleer te presenteren op de plenaire sessie.
PM's & PO's
15h30-16h30
Presentatie van sprintplanning en sprintdoelen per product
Presentatie eindresultaten van de planning per productteam. De presentatie van de planning houdt een 'impliciete confidence vote' in van de betrokken teams.
PM's & PO's
Productteams
Business-personen
Solution niveau
Een user story mapping helpt je om user stories te ordenen in een zinvol model of patroon en om zodoende de functionaliteit van een systeem te begrijpen, en eventuele gebreken in de product functionaliteiten/ product backlog te achterhalen en daarna effectief releases te plannen die op het moment van release de best mogelijke waarde opleveren voor gebruikers. Het is met andere woorden een slimme techniek om hoofd-van bijzaak te onderscheiden in de productlog en op het juiste moment het best mogelijk in te spelen op gebruikersnoden.
User Story Mapping is de voorbije jaren een populaire techniek geworden voor het beheren van user stories dankzij de inspanningen van pionier Jeff Patton. Met de techniek kan je meerdere niveaus en dimensies voor een product backlog vastleggen ondermeer door de gebruikersbehoeften uit te splitsen als (gebruikersactiviteiten, gebruikerstaken), epics en user stories. Bij ABB wordt user story mapping doorgaans toegepast na de impact mapping en in voorbereiding van de planning op de Centrale Planningsdag. Het moet helpen om - binnen de beschikbare capaciteit voor de groeispurt en sprints - de meest waardevolle dingen te bouwen.
De story mapping wordt minstens 1 keer per groeispurt gedaan, ten laatste tijdens de IPI als voorbereiding van de volgende groeispurt en na de impact mapping. Deelnemers aan de story mapping zijn de product teams (PM, PO, Architect, Developer, Designer). Geinteresseerde business stakeholders zijn ook uitgenodigd om deel te nemen. De PM of PO (volgens afspraak in het product team) leidt de sessie.
De capaciteitscheck(s) die tijdens het IPI worden uitgevoerd, zijn een moment om informatie te verzamelen over de beschikbaarheid van teamleden tijdens de komende groeispurt. De check is nodig om te voorkomen dat teamleden "overgepland" worden in één of meerdere productteams waardoor frustratie ontstaat en uiteindelijk sprintdoelen niet worden gehaald. Een capaciteitscheck met de ontwikkelaars, ontwerpers en analisten wordt gevolgd door een capaciteitscheck met Product Managers en Product Owners op de dag voor de CPD. De uitkomst van de check is een overzicht van de beschikbare mandagen per teamlid per sprint. Deze info wordt vervolgens gebruikt om werkzaamheden te plannen tijdens de planningssessie van de CPD.
Voor de capaciteitscheck - georganiseerd door het solution niveau van Digiteam - bellen de PM's en/of PO's in om te overleggen met leden van het solution niveau. Zij deden voorafgaand met alle leveranciers (ontwikkelaars, designers, testers, ...) een check op beschikbaarheid/ budget voor de volgende groeispurt.
Een van de pijlers van de SAFe Lean-Agile Mindset is innovatie, maar het kan moeilijk zijn om tijd te vinden voor ideeën en verandering te midden van de drukte in de reguliere sprints. Daarom gebruiken we bij Digiteam - zoals veel organisaties die de SAFe structuur volgen - IP-iteraties voor onderzoeks- en ontwerpactiviteiten zoals hackathons. Er zijn twee eenvoudige regels voor hackathons: we werken bij voorkeur aan eenzelfde thema met verschillende groepen samengesteld uit leden van verschillende teams (cross-team). De teams demonstreren hun werk aan anderen aan het einde van de hackathon.
De Inspect and Adapt workshop uit de Scaled agile methode is voor het ABB Digiteam momenteel een nieuwe, nog niet toegepaste, manier om de kwaliteit van de toepassing op het moment van de workshop te evalueren met de teams die betrokken zijn bij de 'release' van de toepassing. Volgens het Scaled Agile Framework bestaat het Inspect and Adapt evenement uit 3 delen:
PI-systeemdemo
Kwantitatieve en kwalitatieve meting
Retrospectieve en probleemoplossende workshop
Het uiteindelijke doel van de Inspect and Adapt workshop is om een routine aan te kweken waarbij de belangrijkste gebreken aan de toepassing via een verbeterstory de weg vinden naar de backlog voor de volgende groeispurt(s).
Er zijn verschillende rollen in de SAFe-werking van het projectteam. Op deze pagina vind je de beschrijvingen van de meeste rollen.
Deze pagina is nog in opbouw. Lees je iets raar? Vraag er even naar! david.suijkerbuijk@vlaanderen.be
Alle rollen binnen de SAFe-werking binnen het projectteam staan zo dicht mogelijk bij de eindklant(en). De focus verschilt wel afhankelijk van het stadium waar een oplossing zich in bevindt. Iedereen moet zijn/haar focus kunnen houden om zo goed en snel mogelijk oplossingen en dus waarde te kunnen leveren.
Een Product team bestaat uit een Product Owner, Scrum Master en ontwikkelteam. Op basis van Scrum worden door de product teams nieuwe functionaliteiten en oplossingen opgeleverd in de ontwikkelcadans.
Product teams hebben alle benodigde vaardigheden om elke Sprint waarde te creëren. Ze zijn dus multidisciplinair. Daarnaast is het Scrum Team zelfsturend en bepalen ze dus onderling wie wat opneemt.
De Product Owner vertaalt de visie voor de klanten op het product naar functionele acties met als doel samen met inhoudelijke business experten en IT-technische collega’s te komen tot processen, diensten en toepassingen die beantwoorden aan de noden en zo waarde te leveren binnen de waardestromen van ABB. Dit gebeurt volgens de overeengekomen normen in termen van tijd, kwaliteit en kosten.
vormt een tandem met de Product Manager;
vertaalt de visie op het product naar functionele acties om zo de doelstellingen te garanderen;
stimuleert het team om kwaliteitsvolle stories te definiëren en de backlog te prioriteren;
maximaliseert samen met het productteam de waarde die gecreëerd wordt voor belanghebbenden;
zorgt ervoor dat wat wordt opgeleverd voldoet aan de behoeften van de belanghebbenden;
haalt waardevolle informatie op binnen en buiten de organisatie en bouwt daarvoor stabiele interne en externe netwerken op;
past de technieken van agile product management en business analyse toe volgens de vooropgestelde kwaliteitsvereisten en procedures;
Het ontwikkelteam is multidisciplinair en bestaat dus niet enkel uit ontwikkelaars, ook designers, analisten, testers en architecten kunnen er deel van uitmaken. Deze zijn bij ABB vaak niet exclusief voor één product.
De Product Manager definieert op een strategisch niveau de visie voor de klanten op een product met als doel deze visie te vertalen naar een roadmap voor het product en oplossingen. Dit gebeurt in lijn met de overeengekomen normen in termen van tijd, kwaliteit en kosten.
werkt nauw samen met een breed scala aan mensen om de behoeften van belanghebbenden te identificeren en de oplossingscontext te begrijpen;
stimuleert en organiseert de samenwerking binnen het team zodat het product waarde creëert voor de belanghebbenden;
ontwikkelt visie op het product, stelt een roadmap op en vertaalt deze in oplossingen waar het team verder aan werkt;
toont aan hoe een oplossing een positief effect heeft op een waardestroom en dus waarde kan bieden voor interne en externe klanten;
boort nieuwe domeinen aan waarvoor het product waarde kan leveren;
identificeert en contacteert potentiële gebruikers en integratie-partners;
werkt in tandem samen met de Product Owner die de visie vertaalt naar concrete Epics en stories voor het productteam
(optioneel) een PM kan ook verantwoordelijk zijn voor een oplossing waar zelf meer dan zijn/haar product bij betrokken is.
De product manager kan de oplossingen op de product roadmap niet op zijn of haar eentje uitwerken en bepalen. Hij of zij kan hiervoor beroep doen op een business analist, die de beste business oplossing samen met anderen (designers, architecten, product owner) uitwerkt en hiervoor gebruik maakt van een methodiek en een set aan tools.
De business analist helpt dus mee om de high level oplossing te vertalen naar epics waarin de best mogelijke invulling van de oplossing op de product roadmap wordt uitgewerkt zodat ze kan worden uitgevoerd en - na oplevering - ook de vooropgestelde waarde realiseert.
Zodra de 'business probleemstelling' goed is begrepen en de best passende oplossing is gedocumenteerd, biedt de business analist verdere ondersteuning bieden tijdens het schrijven en bijwerken van de epics zodat ze (technisch) kunnen worden geimplementeerd en nadien de verwachte doelstellingen mee inlossen.
Om kennisdeling over en consistentie in, bijvoorbeeld, gebruikte technieken te stimuleren worden er door de Treinbegeleider periodiek Communities of Practises georganiseerd. Een COP vind plaats rond een bepaalde rol in de werking of specifieke competenties. Tijdens deze bijeenkomsten worden voorbeelden gedeeld, nieuwe technieken aangeleerd of zelfs nieuwe praktijken ontwikkeld.
Bewaakt de effectieve waarderealisatie uit oplossingen door
potentieel van oplossingen te verduidelijken o.b.v. input van andere stakeholders. Bijvoorbeeld door gebruik te maken van waardefiches, oplossingenfiches & impactmaps;
stimuleren en ondersteunen van contact tussen projectteam en (eind)gebruikers;
lanceren van oplossingen binnen en buiten ABB.
De treinbegeleider zorgt ervoor dat de nodige procesmatige en technische afstemming (tussen producten) gebeurt en jaagt dit zelfs aan. Hiervoor start die idealiter vanuit de roadmap en de waardestromen. Daarnaast begeleidt de treinbegeleider het leren en continue verbeteren van de SAFe-werking. Dit zowel binnen het Project Team als ruimer in heel ABB.
werkt nauw samen met de Product Owners en Product Managers om afstemming te stimuleren en begeleiden;
zorgt dat de waardestromen en roadmap up-to-date en gekend zijn;
organiseert en faciliteert belangrijke overlegmomenten (Centrale Planningsdag, Communities of Practises, Solution Stand-ups);
organiseert periodieke retrospectieves en zorgt dat verbeteringen o.b.v. de inzichten tot stand komen;
ondersteuning en eerste hulp bieden rond Agile werken van product- tot solution-niveau.
De manager Digitale Oplossingen incorporeert oplossingen in Solution Roadmap. Coördineert informatie, middelen en capaciteit zodat oplossingen ontwikkeld kunnen worden.
De ICT architect bepaalt de architecturale roadmap en technologiestrategie. Binnen dit kader bewaakt die de beste fit van oplossing met technologie.
De ICT directeur brengt mogelijke waardevragen uit de organisatie in en bewaakt de strategische alineëring.
De sprint retrospective is een terugkerende bijeenkomst aan het einde van een Groeispurt en wordt gebruikt om te bespreken wat er goed en/of fout ging tijdens de vorige Groeispurt-cyclus en wat er verbeterd kan worden in de volgende Groeispurt. De sprint retrospective is een essentieel onderdeel van de (scaled) agile manier van werken. Bij Digiteam ABB hebben we afgesproken om een retrospective te doen aan het einde van vier sprints en niet aan het einde van elke sprint. Problemen die tijdens de sprint ontstaan en die een (zware) impact hebben op de samenwerking van de productteams of op hun efficiëntie worden uiteraard direct opgepakt door het team en de scrummaster(s) en wachten niet tot de retrospective bij de einde van de Groeispurt. Bijgevolg is ad hoc retrospective mogelijk.
Stap 1: "Set the stage". Een retrospectieve is het meest effectief als iedereen in het team eerlijk is over wat goed ging en ook wat niet. Maak duidelijk waar de terugblik over gaat en hoe de retrospective praktisch zal verlopen.
(Stap 2: Opwarmen). Gebruik een kleine oefening om ervoor te zorgen dat iedereen minstens één ding zegt om op te warmen. bijv. Vertel wat je als ontbijt hebt gehad Vertel wat je favoriete vakantiebestemming is Beschrijf de laatste iteratie in slechts 3 woorden Stap 2: Verzamel gegevens via een sjabloon. Er zijn veel retrospectieve sjablonen beschikbaar op internet. Kies er een om de gegevensverzameling te structureren. bijv.
Vervolgens krijgt elke deelnemer de tijd om virtueel of fysiek post its te schrijven en op te plakken. We doen dit in real time zodat anderen kunnen zien wat er geplakt werd. Zo raken mensen met weinig inspiratie wellicht toch geinspireerd om gedachten te formuleren. Elk idee of elke gedachte is een post-it.
Stap 3: Inzichten genereren met de hele groep is de volgende stap. Begin met het identificeren van groepen en duplicaten, praat over wat er naar voren komt en wat kan helpen om het te verbeteren of te verhelpen.
Stap 4: Bepaal wat je moet doen door een korte lijst te maken met dingen om in gedachten te houden tijdens hun volgende sprint.
Waardeketens zijn de opeenvolging van activiteiten (end to end) die nodig zijn om, als organisatie, een product of dienst aan een klant te leveren . De waardeketens van ABB waar het Digiteam nu aan gepland heeft om bij te dragen zijn:
Met gelinkte sjablonen maken lokale besturen kwaliteitsvolle besluiten met authentieke herbruikbare gegevens
Gelinkt publiceren en melden zorgt voor doorzoekbare besluitinformatie
Gestroomlijnd communiceren tussen Vlaanderen en lokale besturen
Vereenvoudigde en interactieve toegankelijkheidsinformatie leidt tot meer data en een groter inclusiviteitsbewustzijn
Het duurzaam, betrouwbaar en herbruikbaar open stellen van (contact)gegevens van lokale besturen
Het beleid rond geloofsgemeenschappen steunt op duurzame, betrouwbare en herbruikbare informatie
Kennisgedreven digitale end-to-end dossierbehandeling
Ondersteunende waardeketens
De IT-dienstverlening wordt op een duurzame, kwaliteitsvolle en efficiënte manier ontwikkeld en ondersteund
Een nieuw idee voor oplossing past altijd in een bestaande of nieuwe waardeketen.
Waardeketens worden op Solution-niveau opgevolgd en afgestemd. Een waardeketen heeft ten minste 1 eigenaar. Voor de huidige waardeketens zijn de eigenaars hieronder weergegeven.
Idealiter heeft iedere waardeketen een duidelijke beschrijving.
Een oplossing is de manier waarop het Digiteam bijdraagt tot het verbeteren of mogelijk maken van een waardeketen. Iedere oplossing die binnen het Digiteam wordt gebouwd moet bijdragen tot een waardeketen.
Oplossingen worden op Solution-niveau bedacht, verduidelijkt, opgevolgd en afgestemd.
Er zijn twee mogelijkheden rond wie verantwoordelijk is om een oplossing op te volgen.
Een dedicated persoon die het opvolgt op Solution niveau.
Een PM die het opvolgt omdat het het meeste aansluit bij zijn/haar product.
Iedere oplossing staat kort en krachtig beschreven een oplossingenfiche.
Deze pagina is nog in opbouw. Lees je iets raar? Vraag er even naar!
Waardeketen | Eigenaar(s) |
---|
Een oplossing kan ontwikkeling in één of meerdere producten vergen. Als er meerdere producten betrokken zijn, is de afstemming des te belangrijker om de oplossing op te kunnen leveren in de .
Een oplossing kan over verschillende ontwikkeld en opgeleverd worden.
Om helder te krijgen wat er dan functioneel moet kunnen in de betrokken producten maken we gebruik van Epics. Een Epic is een beschrijving van een functioneel blok dat, eens gebouwd en beschikbaar gemaakt in het product voor eindgebruikers, voor de business eigenaar een bepaalde waarde zal opleveren. De tijd nodig om een Epic te realiseren is doorgaans langer dan een sprint. Bij ABB proberen we Epics wel zo te dimensioneren dat ze in 1 kunnen worden opgeleverd. Dit doen we omdat de planningsfocus op een centrale in principe niet verder reikt dan 1 .
All information on how we use Jira at ABB can be found in located in the Tooling Space of the ABB Gitbook (members only).
Met gelinkte sjablonen maken lokale besturen kwaliteitsvolle besluiten met authentieke herbruikbare gegevens | Pieter Van Maldegem |
Gelinkt publiceren en melden zorgt voor doorzoekbare besluitinformatie | Katrien Desmet |
Gestroomlijnd communiceren tussen Vlaanderen en lokale besturen | Pieter Van Hastel |
Vereenvoudigde en interactieve toegankelijkheidsinformatie leidt tot meer data en een groter inclusiviteitsbewustzijn | Ingvar Van Haelst |
Het duurzaam, betrouwbaar en herbruikbaar open stellen van (contact)gegevens van lokale besturen | Sofie Merciny |
Het beleid rond geloofsgemeenschappen steunt op duurzame, betrouwbare en herbruikbare informatie | Yassin Boullauazan |
Kennisgedreven digitale end-to-end dossierbehandeling | Bart Vangeebergen? Pieter Van Hastel? |
De IT-dienstverlening wordt op een duurzame, kwaliteitsvolle en efficiënte manier ontwikkeld en ondersteund | Patrick Kyei ? Pieter Lenaerts ? |
Overzicht van de groeispurts bij Digiteam ABB
Groeispurt 28: 20/11/23 - 26/01/24
Sprint 4: 2/01/24 - 12/01/24
Sprint 5 - IPI: 15/01/24 - 26/01/24 - (CPD op donderdag 25/01/24)
Groeispurt 29: 29/01/24 - 5/04/24
Sprint 1: 29/01/24 - 9/02/24
Sprint 2: 12/02/24 - 23/02/24
Sprint 3: 26/02/24 - 8/03/24
Sprint 4: 11/03/24 - 22/03/24
Sprint 5: 25/03/24 - 5/04/24 (CPD op donderdag 4/04/24)
Groeispurt 30: 8/04/24 - 14/06/24
Sprint 1: 8/04/24 - 19/04/24
Sprint 2: 22/04/24 - 3/05/24
Sprint 3: 6/05/24 - 17/05/24
Sprint 4: 20/05/24 - 31/05/24
Sprint 5: 3/06/24 - 14/06/24 (CPD op donderdag 13/06/24)
Groeispurt 31: 17/06/24 - 23/08/24
Sprint 1: 17/06/24 - 28/06/24
Sprint 2: 1/07/24 - 12/07/24
Sprint 3: 15/07/24 - 26/07/24
Sprint 4: 29/07/24 - 9/08/24
Sprint 5: 12/08/24 - 23/08/24 (CPD op donderdag 22/08/24)
Groeispurt 32: 26/08/24 - 1/11/24
Sprint 1: 26/08/24 - 6/09/24
Sprint 2: 9/09/24 - 20/09/24
Sprint 3: 23/09/24 - 4/10/24
Sprint 4: 7/10/24 - 18/10/24
Sprint 5: 21/10/24 - 1/11/24 (CPD op donderdag 31/10/24)
Groeispurt 33: 4/11/24 - 10/01/25
Sprint 1: 4/11/24 - 15/11/24
Sprint 2: 18/11/24 - 29/11/24
Sprint 3: 2/12/24 - 13/12/24
Sprint 4: 16/12/24 - 27/12/24
Sprint 5: 30/12/24 - 10/01/25 (CPD op donderdag 9/01/25)
Groeispurt 23: 05/12/22 – 10/02/23
Sprint 1: 05/12/22 – 16/12/22
Sprint 2: 19/12/22 – 30/12/22
Sprint 3: 2/01/23 - 13/01/23
Sprint 4: 16/01/23 - 27/01/23
Sprint 5 - IPI: 30/01/23 - 10/02/23 - (CPD op donderdag 9/02/23)
Groeispurt 24: 13/02/23 - 21/04/23
Sprint 1: 13/02/23 - 24/02/23
Sprint 2: 27/02/23 - 10/03/23
Sprint 3: 13/03/23 - 24/03/23
Sprint 4: 27/03/23 - 7/04/23
Sprint 5 - IPI: 10/04/23 - 21/04/23 - (CPD op donderdag 20/04/23)
Groeispurt 25: 24/04/23 - 30/06/23
Sprint 1: 24/04/23 - 5/05/23
Sprint 2: 8/05/23 - 19/05/23
Sprint 3: 22/05/23 - 2/06/23
Sprint 4: 5/06/23 - 16/06/23
Sprint 5 - IPI: 19/06/23 - 30/06/23 - (CPD op donderdag 29/06/23)
Groeispurt 26: 3/07/23 - 8/09/23
Sprint 1: 3/07/23 - 14/07/23
Sprint 2: 17/07/23 - 28/07/23
Sprint 3: 31/07/23 - 11/08/23
Sprint 4: 14/08/23 - 25/08/23
Sprint 5 - IPI: 28/08/23 - 8/09/23 - (CPD op donderdag 7/09/23)
Groeispurt 27: 11/09/23 - 17/11/23
Sprint 1: 11/09/23 - 22/09/23
Sprint 2: 25/09/23 - 6/10/23
Sprint 3: 9/10/23 - 20/10/23
Sprint 4: 23/10/23 - 3/11/23
Sprint 5 - IPI: 6/11/23 - 17/11/23 - (CPD op donderdag 16/11/23)
Groeispurt 28: 20/11/23 - 26/01/24
Sprint 1: 20/11/23 - 1/12/23
Sprint 2: 4/12/23 - 15/12/23
Sprint 3: 18/12/23 - 29/12/23
Sprint 4: 2/01/24 - 12/01/24
Sprint 5 - IPI: 15/01/24 - 26/01/24 - (CPD op donderdag 25/01/24)
Groeispurt 18: 20/12/21 – 25/02/2022
Sprint 1: 20/12 – 31/12
Sprint 2: 03/01 – 14/01
Sprint 3: 17/01 – 28/01
Sprint 4 : 31/01 – 11/02
Sprint 5: 14/02 – 25/02
CPD: 24/02
Groeispurt 19: 28/02/22 – 06/05/22
Sprint 1: 28/02 – 11/03
Sprint 2: 14/03 – 25/03
Sprint 3: 28/03 – 08/04
Sprint 4: 11/04 – 22/04
Sprint 5: 25/04 – 06/05
CPD: 05/05
Feestdagen:
18/04: Paasmaandag
Groeispurt 20: 09/05/22 – 15/07/22
Sprint 1: 09/05 – 20/05
Sprint 2: 23/05 – 03/06
Sprint 3: 06/06 – 17/06
Sprint 4: 20/06 – 01/07
Sprint 5: 04/07 – 15/07
CPD: 14/07
Feestdagen:
26/05: OLH Hemelvaart,
06/06: Pinkstermaandag
11/07: Dag van de Vlaamse Gemeenschap
Groeispurt 21: 18/07/22 – 23/09/22
Sprint 1: 18/07 – 29/07
Sprint 2 : 01/08 – 12/08
Sprint 3: 15/08 – 26/08
Sprint 4: 29/08 – 09/09
Sprint 5: 12/09 – 23/09
CPD: 22/09
Feestdagen:
21/07: Nationale Feestdag
15/08: OLV Hemelvaart
Groeispurt 22: 26/09/22 – 02/12/22
Sprint 1: 26/09 – 07/10
Sprint 2: 10/10 – 21/10
Sprint 3: 24/10 – 04/11
Sprint 4: 07/11 – 18/11
Sprint 5: 21/11 – 02/12
CPD: 01/12
Feestdagen:
01/11: Allerheiligen
02/11: Allerzielen
11/11: Wapenstilstand
15/11: Dag van de Dynastie
Groeispurt 23: 05/12/22 – 10/02/23
Sprint 1: 05/12 – 16/12
Sprint 2: 19/12 – 30/12
Groeispurt 13: 04/01/21 – 12/03/21
Sprint 1: 04/01 – 15/01
Sprint 2: 18/01 – 29/01
Sprint 3: 01/02 - 12/02
Sprint 4: 15/02 – 26/02
Sprint 5: 01/03 – 12/03
CPD 11/03
Groeispurt 14: 15/03/21 –21/05/21
Sprint 1: 15/03 – 26/03
Sprint 2: 29/03 – 09/04
Sprint 3: 12/04 – 23/04
Sprint 4: 26/04 – 07/05
Sprint 5: 10/05 – 21/05
CPD: 20/05
Feestdagen:
05/04: paasmaandag,
13/05: OLH Hemelvaart
Groeispurt 15: 24/05/21 – 30/07/21
Sprint 1: 24/05 – 04/06
Sprint 2: 07/06 – 18/06
Sprint 3: 21/06 – 02/07
Sprint 4: 05/07 – 16/07
Sprint 5: 19/07 – 30/07
CPD: 29/07
Feestdagen:
24/05: Pinkstermaandag,
21/07: Nationale Feestdag
Groeispurt 16: 02/08/21 – 08/10/21
Sprint 1: 02/08 – 13/08
Sprint 2: 16/08 – 27/08
Sprint 3: 30/08 – 10/09
Sprint 4: 13/09 – 24/09
Sprint 5: 27/09 – 08/10
CPD: 07/10
Groeispurt 17: 11/10/21 – 17/12/21
Sprint 1: 11/10 – 22/10
Sprint 2: 25/10 – 05/11
Sprint 3: 08/11 – 19/11
Sprint 4: 22/11 – 03/12
Sprint 5: 06/12 – 17/12
CPD: 16/12
Feestdagen:
01/11: Allerheiligen
02/11: Allerzielen
11/11: Wapenstilstand
15/11: dag van de Dynastie
Groeispurt 18: 20/12/21 – 25/02/2022
Sprint 1: 20/12 – 31/12
Binnen het productteam werken we - meer nog dan vóór de de pandemie - heel efficiënt en effectief (samen) op afstand. Alle sprint- en spurtrituelen die horen bij onze resultaatgerichte SAFE-werking, gaan digitaal door. Binnen en buiten vergaderingen is er ook voldoende ruimte en vertrouwen voor sociale interactie. Werktijd is ook nog nooit een issue geweest: iedereen is er op de momenten die nodig zijn of heeft afspraken gemaakt om eventuele afwezigheid op te vangen.
Hoewel er dus weinig of geen werkinhoud is die dit vereist, geven verschillende teamleden aan dat het wenselijk is om elkaar terug wat meer fysiek zien, bv. om samen te lunchen of koffie te drinken, elkaar eens in een andere omgeving echt spreken,... Alleen blijkt dat het niet evident is om elkaar te ontmoeten als iedereen op andere momenten op de werkvloer aanwezig. Bovendien zijn we sterk gegroeid waardoor een volledige terugkeer naar de vroegere situatie praktisch niet helemaal haalbaar is.
Om ervoor te zorgen dat we elkaar toch makkelijker tegen komen, proberen we volgende afspraken uit:
We proberen zoveel als mogelijk op maandagen in Brussel te zijn en op vrijdagen in Gent.
Minstens op de maandag van de tweewekelijkse rapportering blokkeren we ruimte in de agenda om samen te eten of samen een koffie te drinken.
In eerste instantie testen we dit vooral met de product managers en -owners, analisten, de leden van het solution team en andere collega's die over de producten heen werken. Wanneer ontwikkelaars, designers en testers nood hebben aan fysieke aanwezigheid en interactie, zijn zij uiteraard ook welkom. Uiteraard staat dit bijkomende regelingen binnen elk productteam niet in de weg.
We beseffen dat mensen minder productief kunnen zijn op dagen dat ze onderweg zijn. We hebben oog voor de impact die dat heeft op resultaten en stressniveau van individuele collega's. Open feedback is een belangrijke waarde binnen ons team en dat geldt hier ook: erover praten helpt om wederzijdse verwachtingen scherp te houden.
Gelinkt Notuleren geeft lokale besturen de kans om besluiten gelinkt te publiceren en melden – ook als ze geen softwareleverancier hebben, of met een softwareleverancier werken die niet kan voldoen aan de decretale verplichting om open standaarden te gebruiken.
Gelinkt notuleren toont ook aan softwareleveranciers hoe aan de decretale verplichtingen te voldoen.
Bekijk de functionaliteiten: https://gelinkt-notuleren.vlaanderen.be/login
Handleiding: https://abb-vlaanderen.gitbook.io/gelinkt-notuleren-handleiding/
Ondersteuning Gelinkte Besluitvorming Gelinkt Notuleren wil besluitvorming ondersteunen, maar bestaat niet om de markt te verstoren. De functionaliteiten die we aanbieden bestaan om gelinkte besluitvorming mogelijk te maken.
Gelinkt Notuleren is een webapplicatie die helpt met het opmaken en publiceren van agenda's, notulen en besluiten voor Lokale Besturen. De bedoeling van Gelinkt Notuleren is niet om rechtstreeks te concurreren met bestaande notulering-pakketten. Het doel van de applicatie is om te tonen dat notulen opstellen die verrijkt worden met linked open data mogelijk is, en om lokale besturen zonder notuleringpakket uit de nood te helpen.
Ontdek hoe we onze applicaties ontwikkelen onder ONTWIKKELING > Architectuur.
Gelinkt Notuleren bestaat uit modulaire bouwblokken die hergebruikt kunnen worden in andere applicaties.
Alle informatie over onze plugins is beschikbaar via https://github.com/lblod/frontend-embeddable-notule-editor?tab=readme-ov-file#managing-plugins
Gelinkt Notuleren verzamelt kennis uit besluiten die lokale besturen maken. Deze kennis wordt vervolgens weer ter beschikking gesteld om te hergebruiken.
Een lokaal bestuur bereidt agendapunten – ook dossiers of ontwerpbesluiten genoemd – apart voor. Dat gebeurt door de bevoegde dienst(en) binnen dat lokaal bestuur. Het gebeurt ook dat medewerkers van de secretarie agendapunten die geen specifieke kennis vereisten voorbereiden, zoals de goedkeuring van de notulen van de vorige zitting.
[Hulp nodig: kloppen de mensen die betrokken zijn?]
De agendapunten worden voor verschillende bestuursorganen voorbereid. In de applicatie log je in als medewerker van een Gemeente, OCMW of Provincie. [Hulp nodig: district ook? missen er organen of eenheden?]
Gemeente
Gemeenteraad
College Burgemeester & Schepenen (CBS)
Burgemeester
Autonoom Gemeentebedrijf (AGB)
OCMW
Bijzonder comité
Vast Bureau
Provincie
Provincieraad
Deputatie
Autonoom Provinciebedrijf (APB)
Bekijk hoe het werkt in Gelinkt Notuleren [Hulp nodig: aparte pagina aanmaken?]
Lezer
kan alle agendapunten bekijken.
Schrijver
kan alle agendapunten bekijken en bewerken.
In Gelinkt Notuleren kunnen dossiers voorbereid worden in de tab Agendapunten. Het is ook mogelijk om rechtstreeks een zitting aan te maken en daar agendapunten toe te voegen – maar dat is minder flexibel.
Agendapunten die verdaagd werden kunnen gekopieerd worden, zodat ze niet opnieuw opgebouwd moeten worden.
Er zijn 3 statussen
Concept
Het agendapunt is in voorbereiding, maar werd nog niet aan een zitting gekoppeld. Het agendapunt kan ten allen tijde aangepast worden.
Geagendeerd
Het agendapunt werd in een voorbereiding van een zitting opgenomen. De agenda kan nog veranderen, en het agendapunt kan nog aangepast worden.
Gepubliceerd
Het agendapunt werd gekoppeld aan een zitting, en deze werd gepubliceerd. Het agendapunt kan niet meer aangepast worden.
In deze fase is enkel Concept
van toepassing.
Wanneer je start met een nieuw agendapunt, start je met een van de 2 generieke sjablonen aan: besluiten (met een stemming) en vrije tekst. Voorbeelden van agendapunten:
Besluiten
Goedkeuren van notulen
Reglementen
Verordeningen
Mededelingen [Hulp nodig: of vrije tekst?]
Vrije tekst
Discussiepunten
Varia
We bieden 2 stijlen aan voor besluiten:
Nieuwe stijl: gebruikt rubrieken om bevoegdheden, juridische context en motivering te scheiden. Sommige besturen gebruiken nog extra rubrieken, maar wij maken hier geen verder onderscheid.
Klassieke stijl: gebruiken "gelet op" en "overwegende dat" om juridische context en motivering te scheiden.
Feature passports bestaan om informatie die in mensen hun hoofden verscholen zit zichtbaar te maken, en om ervoor te zorgen dat we de open source community ondersteunen om bij te dragen.
Om succesvolle producten te bouwen met een team, heb je vanuit ieders expertise input nodig om in te schatten wat gebouwd moet worden, waarom en hoe dat iets gebouwd moet worden – op een realistische en duurzame manier.
Feature passports zijn een manier voor ons om dat te doen.
Feature passports bestaan om een documentatiecultuur te ondersteunen, dat aangemoedigd wordt wanneer we open source applicaties maken – zodat iedereen kan bijdragen wanneer ze kunnen en willen.
Een feature passport bestaat om te communiceren onder teamleden over het gedeelde begrip en status van een feature die geïmplementeerd wordt, geïmplementeerd zal worden of verbeterd wordt.
Om te weten hoe ver je kan springen en waar je naartoe gaat, heb je een gedeeld begrip nodig over het doel van hetgeen we bouwen en wat de limitaties en opportuniteiten zijn binnen een team.
Het feature passport beschrijft:
Waarom bouwen we dit? Waarom is dit waardevol? Wie zijn de stakeholders? Een gedeelde fundering om samen gepaste oplossingen te bouwen. De agenda’s naast elkaar leggen.
Wat is de beste oplossing voor ons doelpubliek, dat ons team kan bouwen? Ambitieus zijn als team vanuit aanwezige expertise, onrealistische verwachtingen en verwarring vermijden.
Dubbel werk & Frictie vermijden
In sterk groeiende teams
Bij een verscheiden aantal producten
Remote werken
Overhead aan meetings
Kennis delen & Bruggen bouwen
Bij elk product, idee, ding waar een team aan zal samenwerken kan een feature passport helpen om elkaar en het doel beter te begrijpen.
Er wordt verwacht dat op feature een licht geworpen wordt vanuit ieders expertise en ervaring om een waardevol product te bouwen.
Wie start een feature passport? Iedereen kan een feature passport starten en gebruiken. In overleg en met samenwerking groeit de feature passport.
Wie werkt er aan? Iedereen kan aan een feature passport werken; op elk moment. Het is niet de bedoeling dat dit afgeschermd wordt, of waterfallgewijs mensen pas betrokken worden nadat een fase is afgewerkt. Afhankelijk van de inhoud moet er bepaald worden wie er aan werkt en op welk moment.
Niet elk teamlid is op elk moment voor elke feature passport nodig.
Wie is de eigenaar? Idealiter iemand die het finale aanspreekpunt is, maar gedragen door het team. Dat is afhankelijk van project, feature, team! Ownership ≠ Verantwoordelijkheid Deel verantwoordelijkheid! Om inzichten te verzamelen of bepaalde delen af te werken kan de eigenaar iemand verantwoordelijkheid geven (in stories) en zorgen dat de fakkel tijdig doorgegeven wordt.
Voor product bouwers Om ervoor te zorgen dat iedereen weet wat we gaan doen, wat ze gaan bouwen en waarom, en wat de status is.
Kennis die in mensen hun hoofden verscholen zit neer te schrijven;
discussies op te starten en feedback te geven;
als "bron van waarheid" voor uitvoering (maar hou punt 2 in gedachten, dit staat niet muurvast);
nieuwe teamleden en teamleden up-to-date te brengen.
Voor product managers en project managers
Teamleden op dezelfde lijn krijgen
Haalbaarheid in te schatten
Vinger aan de pols houden op feature niveau: impact van een feature in het oog houden
Vogelperspectief op product niveau: gaan we de juiste richting uit, halen we onze doelen (impact map)
Houdt de doelen die bepaald werden in een impact map in check (een milestone kan meerdere feature passports bevatten). Vooraf: Zijn de doelen haalbaar? Tijdens: Zijn we goed op weg? Achteraf: Werden de doelen behaald?
Beschrijft het verhaal of de verhalen binnen een epic, iets waarde oplevert, waarin de stories zorgen dat het verhaal of de verhalen werkelijkheid worden. Hoe zorgen deze taken dat het doel behaald wordt? Welke taken nemen we nog niet mee, en waarom niet? Afhankelijk van welk stadium kan je een feature passport gebruiken als story, epic of als iets om een idee mee op te werpen.
Fungeert als neerslag voor scoping sessies en meeting minutes – waar iedereen aan kan. Vermijdt calls en mails zoals “Hoe zat dit weer…? Ah, maar ik had het zo begrepen! Alles op een plek.”
Dient als ondersteuning voor backlog refinements Zijn we klaar om hier aan te starten?
Vereenvoudigt demo’s aan het einde van de sprint en centrale planningsdagen Opvolgen wat er klaar is en wat niet, screens staan klaar!
Communicatietool: wat is haalbaar om dit doel te bereiken (impact map)?
Overzicht op product bewaren: evolutie, wie werkt er aan wat?
Lifecycle van een feature opvolgen: impact meten, deadlines
Demo’s geven, release notes, rapportering & status updates (intern en extern).
Nieuwe mensen eenvoudiger briefen en laten inwerken
Wat moet ik testen?
Waar moet ik testen?
Waar heeft deze feature invloed op?
Hoe test ik deze feature?
Wat is er belangrijk en wat is secundair?
“Waarom, voor wie?” als barometer voor gepaste oplossing.
Minder verrassingen: Wat nu wel, wat later? Wat nooit? (feature creep voorkomen)
Communicatietool: Brug tussen idee en realiteit, feedback geven.
Dubbel werk vermijden, informatie sneller vinden: inzichten vergaren, track record.
Nieuwe mensen eenvoudiger briefen en laten inwerken
Het is belangrijk dat elke dienst en alle medewerkers van de secretarie hier de rol Schrijver
hebben. Dit wordt ingesteld op het (ACM-IDM), meestal door de IT dienst van het lokaal bestuur.
Onderdeel | Informatie | Gelinkte informatie | Wordt gepubliceerd in |
Openbare titel (in agendapunt zelf) | Deze titel wordt gebruikt bij het publiceren van het de uittreksels, notulen en besluitenlijsten. | Ja | Uittreksels, notulen, besluitenlijst |
Korte openbare beschrijving (in agendapunt zelf) | Kan meer informatie geven over het besluit. Niet elk bestuur doet dit, sommigen kopiëren de titel. Wordt gebruikt bij het publiceren van de uittreksels, notulen en besluitenlijsten | Ja | Uittreksels, notulen, besluitenlijst |
Bestuursorgaan | Over welk bestuursorgaan gaat dit? | Nee | Notulen |
Bevoegdheid | Via de citatenplugin geeft het bestuur de rechtsgrond in die bepaalt dat het orgaan bevoegd is. | Ja | Notulen, uittreksels |
Juridische context | Via de citatenplugin geeft het bestuur de juridische contexten in die gerelateerd zijn. | Ja | Notulen, uittreksels |
Motivering | Het bestuur geeft de motiveringen in. | Neen | Notulen, uittreksels |
Beslissing | De beslissing bestaat uit een of meerdere artikel(s). | Ja | Notulen, uittreksels |
Artikels | Een artikel bestaat uit een artikelnummer en de inhoud. | Ja | Notulen, uittreksels |
Artikel nummer | Opeenvolgende cijfers. | Ja | Notulen, uittreksels |
Artikel inhoud | Inhoud. | Ja | Notulen, uittreksels |
Medewerkers van de secretarie Verrichten administratief werk voor de publieke organisatie, zoals de gemeente of het openbaar centrum voor maatschappelijk welzijn.
Algemeen directeur De algemeen directeur staat in voor de algemene en coördinerende leiding van de diensten van de gemeente en van het openbaar centrum voor maatschappelijk welzijn. De algemeen directeur realiseert samen met zijn medewerkers de decretale en wettelijk voorgeschreven taken en beleidsobjectieven.
Agendapunt in concept / ontwerpbesluit Een (mogelijks nog aan te vullen of aan te passen) ontwerp voor het besluit dat uit dit agendapunt zou voortkomen.
Interne agenda Een agenda (mogelijks nog aan te vullen of aan te passen), die intern kan worden nagekeken.
Ontwerpagenda Een agenda (mogelijks nog aan te vullen of aan te passen), die voor de zitting gepubliceerd wordt naar zowel de raad als naar de burger.
Aanvullende agenda De ontwerpagenda kan na publicatie nog herzien worden. Na herziening wordt deze opnieuw gepubliceerd als aanvullende agenda. Ook deze kan nog aangevuld worden.
Spoedeisende agenda Agenda met punten aangebracht door de raad tot net voor de zitting.
Nadat de agendapunten werden voorbereid worden deze bezorgd aan de secretarie om te agenderen. De agenda wordt over het algemeen voorbereid door een medewerker van de secretarie en/of de algemeen directeur. Daarna wordt deze nagekeken en aangevuld door de algemeen directeur.
*Dit is geen officiële term. Deze term wordt hier gebruikt om het proces te duiden.
De ontwerpagenda wordt voor de zitting gecommuniceerd naar de raad en gepubliceerd naar voor de burger. Deze agenda kan nog aangepast of aangevuld worden.
De raadsleden kunnen nog agendapunten aanbrengen tot enkele dagen voor de zitting. Deze wordt dan opnieuw gecommuniceerd en gepubliceerd als aanvullende agenda.
Tot net voor de zitting kunnen de raadsleden nog agendapunten aanbrengen. De spoedeisende agenda wordt ook gecommuniceerd en gepubliceerd als aanvullende agenda.
De ontwerpagenda, aanvullende agenda en spoedeisende agenda [Hulp nodig; wordt de spoedeisende altijd op voorhand nog gecommuniceerd, of is dat optioneel?] worden gecommuniceerd naar de raadsleden. Dit gebeurt over het algemeen door een medewerker van de secretarie of algemeen directeur, via het softwarepakket of per mail. Digitale communicatie wordt aangemoedigd.
De ontwerpagenda, aanvullende agenda en spoedeisende agenda worden gelinkt gepubliceerd via de softwareleverancier (zoals bijvoorbeeld Gelinkt Notuleren) en worden op de website gezet. Wanneer er gepubliceerd wordt via GN, komt deze op een publicatieomgeving terecht zoals die van Gelinkt Notuleren. Besturen kunnen vanuit hun website linken naar deze pagina.
Bekijk hoe het werkt in Gelinkt Notuleren
Voor het agenderen heb je de rol schrijver
nodig.
Via Gelinkt Notuleren kunnen de mensen die geen schrijfrechten nodig hebben, maar wel de agenda nakijken, met de rol lezer
de geagendeerde agendapunten bekijken.
Binnen Gelinkt Notuleren maak je een agenda aan binnen een zitting – dus deze moet eerst aangemaakt worden. Je vult de informatie in van de zitting die je op voorhand ter beschikking hebt:
Vervolgens worden de agendapunten die werden voorbereid toegevoegd aan de zitting.
Eerst wordt het agendapunt gelinkt aan de zitting. Vervolgens wordt er een titel en een beschrijving (optioneel) toegevoegd aan de zitting voor dat agendapunt. Deze titel en beschrijving worden gebruikt bij het publiceren van de agenda's. Deze titel en beschrijving mogen verschillen van de titel en beschrijving van het agendapunt zelf. De titel in het agendapunt zelf worden gebruikt bij de besluitenlijst, de notulen en de uittreksels.
Openbaarheid
Vanaf het moment dat een agendapunt geagendeerd wordt en gekoppeld aan een zitting, wordt de status geagendeerd
toegevoegd aan het agendapunt, en kan je het aan geen andere zitting meer toevoegen.
Hoe verloopt een zitting, en hoe ondersteunen wij dat?
Zowel de agenda, besluitenlijst, notulen als uittreksels dienen ondertekend te worden.
Men kan digitaal ondertekenen via Gelinkt Notuleren. De ondertekening verloopt op basis van de identiteit van de bevoegde personen. Deze personen loggen in via ACM-IDM, en kunnen dan eenvoudigweg ondertekend worden door op "onderteken" te klikken.
Bepaalde documenten moeten verplicht gepubliceerd en/of gemeld worden: https://lokaalbestuur.vlaanderen.be/werking-bestuur/bekendmakingsplicht
Per document lopen hier verschillende termijnen:
Agenda: publicatie 8 dagen voor de zitting
Besluitenlijst: publicatie en melding 10 dagen na de zitting
Notulen: publicatie en melding na goedkeuren op de volgende zitting
Afhankelijk van het besluittype worden er nog andere agendapunten apart gepubliceerd en gemeld. Deze hebben verschillende termijnen.
[Hulp nodig: termijnen]
Men kan publiceren en melden zonder ondertekenen. Het is belangrijk dat het bestuur wel een ondertekende versie ter beschikking heeft om juridisch in orde te zijn.
De ontwerpagenda, aanvullende agenda en spoedeisende agenda worden gelinkt gepubliceerd via de softwareleverancier (zoals bijvoorbeeld Gelinkt Notuleren) en worden op de website gezet [Hulp nodig; wordt de spoedeisende altijd op voorhand nog gepubliceerd, of is dat optioneel?] . Wanneer er gepubliceerd wordt via GN, komt deze op de publicatieomgeving terecht. Besturen kunnen linken naar deze pagina.
Melden kan automatisch gebeuren via een leverancier, semi-automatisch via Gelinkt Notuleren (met nazicht) of manueel via het loket:
In de volgende zitting worden de notulen van de vorige zitting goedgekeurd (of de zitting erna, indien er nog aanpassingen dienen te gebeuren).
Er zijn bepaalde documenten, zoals omgevingsvergunningen, die nog voor het goedkeuren van de notulen aan bepaalde partijen bezorgd kunnen worden. Het is mogelijk om deze apart te ondertekenen, publiceren en te melden.
Hier kan men ook expliciet een print van maken in Gelinkt Notuleren.
Notulen worden over het algemeen niet aangevuld tijdens de zitting, maar asynchroon verwerkt.
De context waarin de agendapunten behandeld worden kan nu meegegeven worden.
[hulp nodig: in deze context secretaris of algemeen directeur?]
Vervolgens worden per agendapunt aanwezigen, stemmingen en het besluit ingegeven worden. Er kunnen meerdere stemmingen per agendapunt gehouden worden.
Bekijk hoe het werkt in Gelinkt Notuleren
Het is belangrijk dat elke dienst en alle medewerkers van de secretarie hier de rol Schrijver
hebben. Dit wordt ingesteld op het Gebruikersbeheer (ACM-IDM), meestal door de IT dienst van het lokaal bestuur.
Lezer
kan alle agendapunten bekijken.
Schrijver
kan alle agendapunten bekijken en bewerken.
In Gelinkt Notuleren kunnen dossiers voorbereid worden in de tab Agendapunten. Het is ook mogelijk om rechtstreeks een zitting aan te maken en daar agendapunten toe te voegen – maar dat is minder flexibel.
Vanaf het moment dat een een zitting gepubliceerd wordt, kan je het niet meer van de zitting ontkoppelen, en krijgt het agendapunt de statusgepubliceerd
.
Agendapunten die verdaagd werden kunnen gekopieerd worden, zodat ze niet opnieuw opgebouwd moeten worden.
Onderdeel
Informatie
Gelinkte informatie
Wordt gepubliceerd in
Orgaan
Voor welk orgaan werd deze zitting gepland
Ja
Agenda
Geplande datum
De dag waarop de zitting gepland wordt.
Ja
Agenda
Gepland uur
Wanneer de zitting gepland werd om te starten.
Ja
Agenda
Locatie
Waar gaat de zitting door.
Nog niet
/
Onderdeel
Informatie
Gelinkte informatie
Wordt gepubliceerd in
Openbare titel (in de zitting, voor agenda)
Deze titel wordt gebruikt bij het publiceren van de agenda.
Ja
Agenda
Korte openbare beschrijving (in de zitting, voor agenda)
Kan meer informatie geven over het besluit. Niet elk bestuur doet dit, sommigen kopiëren de titel. Wordt gebruikt bij het publiceren van de agenda
Ja
Agenda
Geplande openbaarheid
De verwachting waarop het agendapunt behandeld zal worden: openbaar of besloten.
Ja
Agenda
Onderdeel
Informatie
Gelinkte informatie
Wordt gepubliceerd in
Startdatum
De dag waarop de zitting doorging.
Ja
Notulen, uittreksels
Startuur
Wanneer de zitting gestart werd door de voorzitter.
Ja
Notulen, besluitenlijst, uittreksels
Aanwezigen zitting
Wie er aanwezig was bij de start van de zitting.
Ja
Notulen, besluitenlijst, uittreksels
Afwezigen zitting
Wie er afwezig was bij de start van de zitting.
Ja
Notulen, besluitenlijst, uittreksels
Voorzitter (of vervanging)
Wie de rol van voorzitter van de raad op zich nam.
Ja
Notulen, besluitenlijst, uittreksels
Secretaris (of vervanging)
Wie de rol van secretaris van de raad op zich nam.
Ja
Notulen, besluitenlijst, uittreksels
Onderdeel
Informatie
Gelinkte informatie
Wordt gepubliceerd in
Aanwezigen agendapunt
Wie er aanwezig was bij het agendapunt.
Ja
Notulen, uittreksels
Afwezigen agendapunt
Wie er afwezig was bij het agendapunt.
Ja
Notulen, uittreksels
Openbaarheid agendapunt
De werkelijke behandeling van het agendapunt: openbaar of besloten.
Ja
Notulen, uittreksels
Onderwerp stemming
Waar gaat de stemming over
Ja
Notulen, besluitenlijst uittreksels
Type stemming
Geheim of open
Ja
Notulen, besluitenlijst uittreksels
Voorstanders
Aantal voorstanders: enkel cijfers indien geheim, naam aanwezige ook indien open.
Ja
Notulen, besluitenlijst uittreksels
Tegenstanders
Aantal tegenstanders: enkel cijfers indien geheim, naam aanwezige ook indien open.
Ja
Notulen, besluitenlijst uittreksels
Onthouders
Aantal onthouders: enkel cijfers indien geheim, naam aanwezige ook indien open.
Ja
Notulen, besluitenlijst uittreksels
Gevolg stemming
Wat is het gevolg van deze stemming.
Ja
Notulen, besluitenlijst uittreksels
Sluiting zitting
Wanneer de voorzitter de zitting sluit.
Ja
Notulen
Melden van publicatie van besluiten en overzichtslijsten (op hun webtoepassing). In kader van Bestuurlijk Toezicht.
Hoe het werkt: https://abb-vlaanderen.gitbook.io/handleiding-loket/modules/toezicht
Opgelegd voor Decreet Lokaal Bestuur; verplicht via LLB (BVR Communicatie).
Lokale besturen hebben verschillende beslissingsorganen, die besluiten nemen zoals budgetten, belastingreglementen en rechtspositieregelingen. Er zijn ook besluitenlijsten. Bepaalde besluiten (de lijst wordt hier bijgehouden: https://lokaalbestuur.vlaanderen.be/loket-lokaal-bestuur-module-toezicht) moeten samen met de besluitenlijst, afhankelijk van het type document, binnen een bepaalde termijn gepubliceerd worden op hun website, en aan ABB bezorgd worden. De bezorging gebeurt via het loket voor lokale besturen – niet meer per post.
De toezichthouder keurt de besluiten binnen een bepaalde termijn goed of af via de interne toepassing "Databank Toezicht", en gaan naar het dossieropvolgingsysteem Kalliope.
Elke burger kan binnen een bepaalde termijn klacht indienen tegen en item op de besluitenlijst; dat wordt dan ook gekoppeld aan Kalliope en wordt gecommuniceerd naar de besturen via het loket voor lokale besturen in de module berichtencentrum.
Om ervoor te zorgen dat informatie op zo weinig mogelijk plaatsen tegelijk bezorgd moeten worden, zorgen we ook voor integraties. Zo kunnen lokale besturen nu ook gebruik maken van het loket om gegevens te bezorgen aan Vlabel (Extra velden voor belastingsreglementen: MAR-code, bedrag opcentiem, ..) en het Vlaams Huis Verkeersveiligheid / MOW (Categorie "reglementen en verordeningen"). Deze worden dan ook doorgestuurd naar de interne besluitendatabank Toezicht.
Het uiteindelijke doel is dat besturen de besluiten en besluitenlijsten automatisch doorsturen na publicatie via hun softwarepakket, en niet meer via het de module toezicht in het loket moeten gaan om iets te bezorgen aan ABB – enkel om iets na te kijken, om andere modules te gebruiken of voor de tweewegscommunicatie. Door dat automatisch te laten verlopen, willen we de foutenmarge verkleinen.
Gemeente, OCMW, Disctrict, Provincie, AGB, APB, OCMW-verenigingen, IGS’en, HVZ & PZ
Interne databank Toezicht & Kalliope.
Opsturen van opvragingen en kennisnames (ikv Bestuurlijk Toezicht) via Kalliope.
Hoe het werkt: https://abb-vlaanderen.gitbook.io/handleiding-loket/modules/berichtencentrum
Opgelegd voor Decreet Lokaal Bestuur; verplicht via LLB (BVR Communicatie)
Gemeente, OCMW Disctrict, Provincie, AGB, APB, OCMW-verenigingen, IGS’en, HVZ & PZ
Kalliope
Toesturen van digitale financiële documenten uit de boekhoudpakketten die horen bij bepaalde besluiten. Moet de toezichthouder in staat stellen budgetten, jaarrekeningen en meerjarenplannen goed te keuren.
Hoe het werkt: https://abb-vlaanderen.gitbook.io/handleiding-loket/modules/bbc-dr
Opgelegd voor Decreet Lokaal Bestuur; verplicht via LLB (BVR Communicatie).
Gemeente, OCMW (wordt geleidelijk aan opgenomen in gemeente), Disctrict, Provincie, AGB, APB, OCMW-verenigingen, IGS’en (sommige)
Qlikview via Management File Transfer
Ingeven en beheren van mandaten bij besturen
Hoe het werkt: https://abb-vlaanderen.gitbook.io/handleiding-loket/modules/mandatenbeheer
Opgelegd voor Decreet Lokaal Bestuur.
Gemeente, OCMW, Disctrict, Provincie
Ingeven en beheren leidinggevende functies
Hoe het werkt: https://abb-vlaanderen.gitbook.io/handleiding-loket/modules/leidinggevendenbeheer
Opgelegd voor Decreet Lokaal Bestuur; verplicht via LLB (BVR Communicatie)
Gemeente, OCMW Disctrict, Provincie, AGB, APB, OCMW-verenigingen, IGS’en,
Beheren van personeelsgegevens: aantal werknemers en voltijds equivalenten.
Hoe het werkt: https://abb-vlaanderen.gitbook.io/handleiding-loket/modules/personeelsbeheer
Gegevens nodig voor beleid (Comite C1).
Gemeente
Enkel intern gebruik
Volg aanvragen voor subsidiemaatregelen op.
Hoe het werkt: https://abb-vlaanderen.gitbook.io/handleiding-loket/modules/subsidiebeheer
/
Gemeenten, later meer.
Voorlopig enkel intern gebruik.
Volg wijzigingen van de bedienaar van de eredienst op.
Hoe het werkt: https://www.vlaanderen.be/lokaal-bestuur/loket-voor-lokale-besturen/bedienarenbeheer
/
Besturen van de eredienst
Organisatieportaal, Kalliope, voor intern gebruik.
Volg wijzigingen van de bestuursleden van de eredienst op.
Hoe het werkt: https://www.vlaanderen.be/lokaal-bestuur/loket-voor-lokale-besturen/mandatenbeheer-erediensten
/
Besturen van de eredienst
Organisatieportaal, Kalliope, voor intern gebruik.
Een open-source tekstverwerker die specifieke informatie uit notulen verrijkt met data, op een gestructureerde manier, zodat we achteraf die informatie kunnen extraheren en hergebruiken.
De Embeddable is een bouwsteen van Gelinkt Notuleren. Het is een slimme, open-source tekstverwerker die specifieke informatie uit notulen verrijkt met data, op een gestructureerde manier, zodat we achteraf die informatie kunnen extraheren en hergebruiken.
Externe notuleringpakketten die lokale besturen helpen met het opstellen van notulen, kunnen deze embeddable ook hergebruiken in hun software pakket om de data te extraheren.
We bieden deze tekstverwerker aan als embeddable (eenvoudig inplugbaar) voor die besturen of hun software leveranciers kunnen gebruiken in hun notuleringpakketten. We stellen deze embeddable ook open onder de naam van Say Editor voor eender wie die hun tekstverwerking willen verrijken met kennis.
De embeddable bestaat uit verschillende bouwblokken die gelinkt notuleren mogelijk maken.
Wij gebruiken meerdere gegevensbronnen om notulen en besluiten te verrijken:
De Vlaamse Codex – verwijzingen naar de rechtsgronden in beslissingen.
Mandaten – om aanwezigen bij te houden, te benoemen en te ontslaan.
Leidinggevenden – om aanwezigen bij te houden.
We hebben aparte kleine apps gemaakt die in de teksteditor kunnen worden gestopt:
Toolbar: basisfuncties voor tekstbewerking.
Sjablonen: om het makkelijker te maken om te beginnen met noteren.
In de toekomst zullen we ook een sjablonenbouwer maken, waar besturen en overheden zelf hun sjablonen kunnen samenstellen.
Citaten plugin: maakt gebruik van de Vlaamse Codex – om te verwijzen naar juridische gronden in beslissingen.
Stemming: stem over beslissingen.
Aanwezigen: volg wie deel uitmaakte van de vergadering, en deel uitmaakt van bepaalde beslissingen.
Import – export: beslissingen kunnen geïmporteerd en geëxporteerd worden (in uitvoering).
Annotaties: annoteer tekst met specifieke gekoppelde informatie, zoals mandaten.
Ondertekenen: ondertekenen van notulen, uittreksels, agenda's, besluitenlijsten.
Anonimiseren: verwijder persoonlijke informatie voor publieke weergave.
Voeg zelf de slimme tekstverwerker toe aan je ember applicatie:
Om meer gedetailleerde informatie over Say editor te vinden, bezoek .
Technische informatie en hoe deze te integreren in je webtoepassing, zie:
Authenticatie: inloggen via (ACM-IDM).
Lees de documenten van Say Editor om te zien hoe ze worden opgezet: .
Al onze applicaties worden op dezelfde manier opgebouwd. Lees eerst de pagina voor je start met deze repositories.
Het Agentschap Binnenlands Bestuur werkt nauw samen met het department (MOW) en het Agentschap Wegen en Verkeer (AWV). Samen bouwen ze het Register van Maatregelen voor borden en markeringen, een algemeen register dat tot doel heeft de duidelijkheid, deelbaarheid en herbruikbaarheid van (juridische) gegevens en documenten voor gebruikers in lokale gemeenten te verbeteren door het gebruik van Linked Open Data.
Ontdek hoe we onze applicaties ontwikkelen onder .
Lokale besturen zijn sinds 1 januari 2019 verplicht om bepaalde besluiten, lijsten en stukken te publiceren op hun webtoepassing en te melden aan de toezichthoudende overheid, via het loket voor lokale besturen. Gelinkt publiceren kan via de applicatie Gelinkt Notuleren, of via een software pakket dat voldoet aan de standaarden.
Meer informatie op https://lokaalbestuur.vlaanderen.be/gelinkt-publiceren-melden.
Bekijk de video's onderaan om te ontdekken hoe je kan melden.
Het loket voor lokale besturen is een digitale manier voor communicatie tussen Lokale Besturen in Vlaanderen en het Agentschap Binnenlands Bestuur.
Om dat mogelijk te maken, bouwen we het loket zo op:
De communicatie wordt opgebouwd als een beveiligde zending (vaststelling tijdstip van verzending en aflevering van communicatie) – volgens het BVR 20/04/2018
Het loket werd modulair opgebouwd, per type communicatie, om eenvoudig onderscheid te maken en toegang te geven.
Werd gebaseerd op semantische formulieren – die het mogelijk maakt om data open en gelinkt te delen.
Digitale gegevensuitwisseling tussen lokale besturen enerzijds en de bredere centrale (Vlaamse) overheid anderzijds.
Gemakkelijke gegevensdeling vanuit de lokale besturen door open data uit lokale besluiten (LBLOD) – met als doel efficientiëwinst voor lokale besturen.
Informatie op een gebruiksvriendelijke manier ter beschikking stellen aan (Vlaamse) overheidsinstanties zodat zij deze makkelijk kunnen verwerken/behandelen.
Gemeente
OCMW
Autonoom Gemeentebedrijf (AGB)
OCMW-vereniging (welzijnsvereniging)
Intergemeentelijke Samenwerkingsverbanden (IGS) Intercommunale, Dienstverlenende Vereniging, Opdrachthoudende Vereniging, Projectvereniging
Districten
Provincie Autonoom Provinciebedrijf (APB)
Hulpverleningszone (HVZ)
Politiezone (PV)
Erediensten
Watering & Polders
Een uitgebreide handleiding vindt u up https://abb-vlaanderen.gitbook.io/handleiding-loket/.
Ontdek hoe we onze applicaties ontwikkelen onder ONTWIKKELING > Architectuur.
Bovenstaande handleiding zal deze vervangen: Handleiding https://loket.lokaalbestuur.vlaanderen.be/handleiding/ Code https://github.com/lblod/handleiding-digitaal-loket
Module
Mogelijkheden
Bezorg besluiten en overzichtslijsten aan de toezichthoudende overheid.
Bekijk en reageer op de berichten van de toezichthoudende overheid.
Bezorg de digitale rapporten aan de Vlaamse Regering over de beleids- en beheerscyclus.
Hou de mandaten binnen de gemeenten, OCMW’s, districten en provincies bij.
Hou hier de leidinggevende functies voor uw bestuur bij.
Hou hier de personeelsaantallen voor uw bestuur bij: aantal werknemers en voltijds equivalenten.
Volg hier uw aanvragen voor subsidiemaatregelen op.
De besturen van de eredienst moeten sinds februari 2023 de wijzigingen van de bedienaar van de eredienst bijhouden in module bedienarenbeheer van het Loket voor Lokale Besturen. Voor sommige besturen van de eredienst neemt het representatief orgaan deze taak op zich.
De besturen van de eredienst moeten sinds februari 2023 de wijzigingen van bestuursleden bijhouden met de module “mandatenbeheer erediensten” van het Loket voor lokale besturen.
Nieuwe besturen hebben een goedkeuring nodig van ABB, toegang tot het gebruikersbeheer van het facilitair bedrijf en het loket, en een connectie met Kalliope zodat tweewegscommunicatie kan gebeuren en ABB dossieropvolging kan doen.
Om dat te laten gebeuren, doen we het volgende:
We verwachten een goedkeuringsbeslissing van het Agentschap Binnenlands Bestuur over het nieuwe lokale bestuur.
ABB verwittigt het loket voor Lokale Besturen.
Dan kan het bestuur toegang vragen via het Gebruikersbeheer aan het Facilitair Bedrijf
ABB, de product manager van het loket, geeft verificatie en vraagt de OVO aan. Dit wordt teruggekoppeld, samen met de typering.
Hierna wordt connectie gemaakt met het KBO
Er wordt een unieke code aangemaakt om het bestuur mee te identificeren, die we een URI noemen (Unique Resource Identifier)
Die wordt zowel gebruikt voor het Loket als in Kalliope, om dossieropvolging en tweewegscommunicatie mogelijk te maken.
Lokale besturen krijgen toegang door eenmalig toegang te vragen via het Toegangs- (ACM) en Gebruikersbeheer (IDM) van de Vlaamse overheid. Meer informatie over ACM-IDM.
Het gebruikersrecht dat gebruikt wordt om in te loggen voor het Loket voor Lokale Besturen is "Loket Lokaal Bestuur Gebruiker".
Per gebruiker kan ingesteld worden welke modules ze zien. De keuze bestaat momenteel uit: Toezicht, berichtencentrum, leidinggevenden, mandatenbeheer, personeelsbeheer, BBC-DR, subsidies. Dit kan later nog uitgebreid worden.
Er bestaan drie gebruikersbeheren per doelgroep:
Vlaamse Overheid
Economische actoren
Lokale Besturen. De doelgroepverantwoordelijke voor Lokale Besturen is ABB.
De Form Builder werd aanvankelijk gebouwd als proof-of-concept tijdens een Innovatie sprint.
Voorbeelden van velden die je op dit moment standaard kan invoegen in een formulier:
De Formbuilder POC evolueerde in 2023 van een alpha versie naar een eerste volwaardige productversie waarmee talrijke formulieren werden gebouwd. Om de formbuilder als product of technische component verder te ontwikkelen werd een apart product team samengesteld. Het team werkt momenteel aan een tweede versie van de Formbuilder.
Het loket is modulair opgebouwd, met herbruikbare componenten. Dat doen we ook voor de formulieren die we bouwen; zo generiek en standaard mogelijk. De form-builder is een manier om te visualiseren wat voor standaard formulieren je kunt maken voor de verschillende modules in Loket, zoals en .
Bekijk de mandaten in een bestuur. Deze data komt in deze databank terecht via
Andere notuleringspakketten die de lokale besturen aankopen via leveranciers, die gebruik maken van de open standaarden voor notuleren.
Ontdek hoe we onze applicaties ontwikkelen onder ONTWIKKELING > Architectuur.
Via het Loket voor Lokale Besturen kunnen lokale besturen klachten zien die ingediend werden door burgers. Via de website https://lokaalbestuur.vlaanderen.be/digitaal-klachtenformulier kunnen burgers een klacht indienen tegen een lokaal bestuur. Deze wordt onderzocht, en daarna teruggekoppeld naar het bestuur via het loket.
Bekijk de leidinggevenden in een bestuur.
Deze informatie komt momenteel uit:
[later] Gelink Notuleren
[later] Andere notuleringspakketten die de lokale besturen aankopen via leveranciers, die gebruik maken van de open standaarden voor notuleren.
Ontdek hoe we onze applicaties ontwikkelen onder ONTWIKKELING > Architectuur.
Zoek naar gelinkte en gepubliceerde agenda's, besluiten en notulen van een bestuur:
Deze informatie komt momenteel uit:
Het is verplicht voor lokale besturen om bepaalde informatie in notulen gelinkt te publiceren. Meer informatie over de richtlijnen.
De applicatie Gelinkt Notuleren maakt het mogelijk om dat te doen, en publiceert de informatie hier. Lokale besturen kunnen op hun website linken naar deze pagina.
Ontdek hoe we onze applicaties ontwikkelen onder ONTWIKKELING > Architectuur.
Geraardsbergen en 9 andere Vlaamse gemeentes willen samen tien processen van dienstverlening aan burgers, verenigingen en ondernemers optimaliseren en digitaliseren, zowel op niveau van frontoffice als backoffice. Daarmee willen ze de verwerking van die processen effectiever en efficiënter maken, met oog voor klantvriendelijkheid, transparantie en het only once-principe. Deze GZG- projectindieners willen dat doen door middel van co-creatieve procesoptimalisatie en -automatisering met behulp van Vlaamse Bouwstenen zoals MAGDA en Mijn Burgerprofiel, en integratie met andere softwarepakketten. De generieke processen die uit deze oefening voortkomen, worden opgenomen in het Open Proceshuis van het Agentschap Binnenlands Bestuur.
De realisatie van het Open Proceshuis past volledig binnen de missie en de visie van het Agentschap Binnenlands Bestuur, namelijk lokale besturen instrumenten aanreiken om samen te werken, kennis te delen en hiermee ook herbruikbare oplossingen te realiseren. Concreet betekent dit in het geval van het Open Proceshuis dat de inspanning die een of meerdere gemeentes leveren om een proces te analyseren, te optimaliseren en te documenteren makkelijk kan gedeeld worden met andere gemeentes die het geoptimaliseerde proces of stappen eruit meteen kunnen hergebruiken, en vice versa.
Lokaal Beslist is een online tool die agendapunten van Vlaamse lokale besturen samenbrengt op 1 centrale plek. Dat maakt het voor de burger gemakkelijk om te begrijpen waar lokale besturen mee bezig zijn en welke beslissingen ze nemen. Lokaal Beslist maakt de lokale besluitvorming transparanter en vergroot de betrokkenheid van burgers. Als lokale mandataris kan je met Lokaal Beslist ontdekken hoe andere gemeenten uitdagingen aanpakken en innovatieve oplossingen implementeren.
De informatie in de applicatie is niet altijd even volledig. In de komende maanden en jaren zullen we nauw samenwerken met lokale besturen en hun leveranciers om meer en betere informatie beschikbaar te stellen. We willen samen met burgers en lokale besturen de functionaliteit en bruikbaarheid van Lokaal Beslist optimaliseren. Zo zal de applicatie steeds beter aan alle behoeften voldoen. Programma's als Gemeente Zonder Gemeentehuis en Lokaal Beslist helpen alvast aanzienlijk om de kwaliteit en de maturiteit van gegevensuitwisseling tussen overheden te verbeteren. De oefening moet nog even vol gehouden worden om de vruchten ervan te kunnen plukken.
Met de Module Toezicht doelen we op de interne besluitendatabank Toezicht voor medewerkers van het Agentschap Binnenlands Bestuur. Via deze databank zijn alle besluiten terug te vinden die door de lokale besturen gemeld of ingezonden werden via het Loket voor Lokale Besturen.
Deze databank bestaat om gegevensdeling binnen de Vlaamse overheid te versoepelen. Zo worden er ook connecties gelegd met Vlabel en Vlaams Huis Verkeersveiligheid (MOW).
Ontdek hoe we onze applicaties ontwikkelen onder ONTWIKKELING > Architectuur.
⚠️Voor Toegankelijk Vlaanderen wordt er geen gebruik gemaakt van ACM-IDM, het gebruikersbeheer.
Het organisatieportaal is de toegangspoort tot informatie over organisaties en personen die ABB contacteert. Via het organisatieportaal kan je verschillende authentieke databronnen met betrekking tot organisatiegegevens van lokale besturen aanspreken – allemaal op één plek. Het platform maakt connectie naar interne producten en applicaties, om de informatiestromen beter in de hand te houden.
ABB-gebruikers van toepassingen gekoppeld aan het Organisatieportaal
Lokale besturen die via het Loket Lokale Besturen hun contactgegevens kunnen beheren
Bedienaren van erediensten
Andere overheidsagentschappen - zoals bijvoorbeeld Agentschap Digitaal Vlaanderen - die hun toepassingen koppelen aan het Organisatieportaal voor het uitwisselen van contactgegevens
We hebben op dit moment twee manieren om gegevens te exploreren, opgedeeld in twee onderdelen: organisaties en personen. De volgende cases werden toegepast op erediensten.
Al de informatie die leeft rond erediensten werd als een eerste pilootproject gezien voor het organisatieportaal. Deze nieuwe dienst start op 1 september, en zal de eerste basisversie van het organisatieportaal worden.
Deze bestaan uit publieke organisaties zoals bestuurseenheden, bestuursorganen, formele organisaties en algemene organisaties.
Voorbeelden voor informatie omtrent lokale besturen en meer specifiek erediensten:
Publieke organisaties, zoals Bestuurseenheden: Autonoom gemeentebedrijf, Autonoom provinciebedrijf, Bestuur van de eredienst, Centraal bestuur van de eredienst, Dienstverlenende vereniging, District Gemeente, Hulpverleningszone, OCMW, OCMW vereniging, Opdrachthoudende vereniging, Polders, Politiezone, Projectvereniging, Provincie, Watering, Welzijnsvereniging
Bestuursorganen: Gemeenteraad, College van Burgemeesters en Schepenen, Provincieraad, Raad van Bestuur, Centraal Bestuursorgaan, Eredienstenbestuursorgaan, ...
Formele organisaties, zoals Geregistreerde organisaties: Ondernemingen (Vennootschappen, Verenigingen, Stichtingen), Representatief Orgaan, ...
Algemene organisaties: Feitelijke verenigingen, zonder winstuitkering, ...
U kan de posities van een persoon binnen de verschillende organisaties terugvinden, zoals leidinggevenden, mandatarissen, bedienaren, ...
Voorbeelden voor informatie omtrent lokale besturen en meer specifiek erediensten:
Posities binnen verschillende organisaties: Penningmeester, Secretaris, Bedienaar, Expert, Vertegenwoordiger van rechtswege, …
Leidinggevenden: Algemeen directeur, Adjunct algemeen directeur, Financieel directeur, Adjunct financieel directeur, Leidend ambtenaar, Griffier, Financieel beheerder …
Mandatarissen: Burgemeester, Aangewezen burgemeester, Schepen, Toegevoegde schepen, Voorzitter Bestuurslid …
Het organisatieportaal heeft een aantal basisgegevens, core gegevens, die elke organisatie en persoon heeft, bijvoorbeeld:
Personen: kerngegevens (naam, geboortedatum, ...), posities bij organisaties, contactgegevens per positie
Organisaties: kerngegevens (naam, type, status, ...), vestigingen, veranderingsgebeurtenissen, verbonden organisaties, leidinggevenden, mandatarissen, ..
Naargelang de noden voor de contactgegevens die nodig is per organisatie en workflow, kunnen er zowel verschillende types organisaties en gegevens gekoppeld worden.
Bijvoorbeeld, in kader van erediensten werden volgende organisaties gekoppeld: Bestuur van de eredienst Centraal bestuur van de eredienst, betrokken bestuursorganen, representatieve organen.
Draag hier bij aan onze applicaties, en bekijk onze datamodellen [EN]:
Het traject erediensten bestaat om het informatiebeleid rond erediensten op een duurzame, betrouwbare en herbruikbare manier op te bouwen. Er is een eenvoudige toegang nodig tot alle informatie die de verschillende afdelingen ontvangen in het kader van erediensten. Deze informatie zit nu zowel in lijsten in Sharepoint, als verspreid over verschillende Sharepoint mappen. Verder is er een nood bij de actoren in het veld om vlot aan hun decretale verplichtingen te voldoen.
Dit wordt gerealiseerd door het gebruik van het organisatieportaal (bekijk voor afbeeldingen en voorbeelden), het loket voor lokale besturen, het intern dossierbehandelingssysteem (Kalliope) en oplossingen van de derdepartij softwareleveranciers (bv. ReligioPoint van Vanden Broele).
Het bestuur van de eredienst is een lokale bestuurseenheid (het is een openbare instelling met rechtspersoonlijkheid) die bevoegd is voor de zorg voor de materiële voorwaarden die de uitoefening van de eredienst in de geloofsgemeenschap en het behoud van de waardigheid ervan mogelijk maken. Het bestuur is ook belast met het onderhoud en de bewaring van het gebouw of de gebouwen van de eredienst van de geloofsgemeenschap en met het beheer van de goederen en de gelden die eigendom zijn van de geloofsgemeenschap of die bestemd zijn voor de uitoefening van de eredienst in de geloofsgemeenschap.
Het Centraal bestuur van de eredienst is een lokale bestuurseenheid (het is een openbare instelling met rechtspersoonlijkheid) die in een gemeente of provincie voorkomt als er in die gemeente of provincie een decretaal bepaald aantal besturen (bvb parochies) van de desbetreffende eredienst erkend zijn met hoofdgebouw van de eredienst op dat grondgebied. De Vlaamse regering kan toestaan dat er bij een lager aantal dan decretaal bepaald toch een centraal kerkbestuur wordt ingericht of dat er bij een veel groter aantal twee of meer centrale (rooms-katholieke) kerkbesturen worden ingericht.
Het overkoepelend orgaan dat erkend werd door de federale overheid om (centrale) besturen van de eredienst te vertegenwoordigen.
De gemeente of provincie die de rol van toezichthouder op zich neemt betreffende een bestuur of centraal bestuur. Dit is tevens de overheid die de tekorten van exploitatie bijpast en bijdraagt in de investeringen in de gebouwen van de eredienst conform het decreet van 7 mei 2004.
Staan in voor administratieve aangelegenheden betreffende erediensten
Dossierbehandeling eredienstendossiers (Samenvoegingen, erkenningen etc.)
Opvolgen notulen en verkiezingen
Beantwoorden adviesvragen
Klachten
Deze dienst is in oprichting
Doet onderzoek indien nodig (verschillende types van onderzoek - ad-hoc, generiek etc)
Behandelen financiële aspecten van eredienstendossiers. Dit omvat onder andere de goedkeuring van de jaarrekeningen en de beroepsprocedures.
Draag hier bij aan onze applicaties [EN]:
OrganisatiePortaal beheert gegevens van erediensten
Loket voor Lokale Besturen voorziet een loket voor erediensten
Kalliope waar ABB dossiers behandelt betreffende erediensten en communiceren naar besturen
Publieke data betreffende erediensten is raadpleegbaar op de Centrale Vindplaats
Databank Toezicht Erediensten
Deze oplossing is in aanbouw
Ontdek hoe we onze applicaties ontwikkelen onder ONTWIKKELING > Architectuur.
Versie 2 van de Formbuilder Toepassing
We willen ontwikkelaars een instrument aanreiken waarmee ze efficient en snel 'slimme formulieren' - dit wil zeggen formulieren die eens ingevuld correcte Linked Open Data genereren - kunnen samenstellen.
Ontwikkelaars in product teams (van Agentschap Binnenlands Bestuur en bij uitbreiding in andere Vlaamse agentschappen) die veelvuldig formulieren voor toepassingen bouwen of onderhouden.
De visie en de ambitie sluit nog steeds aan bij de initiele gedachte achter de Proof of Concept die destijds met het product team van het Loket Lokale Besturen werd gerealiseerd, namelijk formulieren modulair opbouwen uit herbruikbare componenten om de bouw en het onderhoud van talloze formulieren te vergemakkelijken.
Op het tabblad Code Builder vindt een gebruiker aan de rechterkant de code die achter een bepaald formulier zit. Aan de linkerzijde van de tab ziet hij of zij de visuele weergave van deze code. Dit tabblad wordt voornamelijk gebruikt door de ontwikkelaars. Zij kunnen de code hierop aanpassen.
Op dit tabblad kan de gebruiker (die geen ontwikkelaar is) formulieren maken door het volgende toe te voegen: 1. Secties , 2.Velden (met verschillende veldtypes: invoer, tekstgebied, numeriek, data, url,...) 3. Tabellen en 4. Lijsten.
Dit onderdeel wordt gebruikt om validaties op formulieronderdelen te beheren. Het wordt zowel door ontwikkelaars als 'gewone' gebruikers van de Formbuilder gebruikt.
Afmelden of wisselen van bestuurseenheid* kan u door rechtsboven op uw bestuurseenheid te klikken.
*Wisselen van bestuurseenheid kan enkel voor specifieke applicaties, en enkel indien u toegang heeft tot meerdere bestuurseenheden.
Wanneer u klikt op "Wissel van bestuurseenheid" krijgt u opnieuw de pop-up te zien waar u eerst selecteert dat u zich wil aanmelden voor een lokaal of provinciaal bestuur. Zorg ervoor dat uw browser deze pop-up ook toestaat. Bekijk hoe u popups toestaat.
Vervolgens kiest u de juiste bestuurseenheid.
Om toegang te krijgen tot onze applicaties, moet u als gebruiker gekend zijn bij Gebruikersbeheer Vlaanderen. Onze applicaties zijn voorzien om u veilig aan te melden via Gebruikersbeheer Vlaanderen.
Bekijk hier hoe aanmelden, afmelden en wisselen van bestuurseenheid in elkaar zit:
Krijg je geen toegang? Kijk of je gebruikersrechten goed zitten.
De lokale beheerder die in elk bestuur aanwezig is kan u hier toegang tot geven. Meestal is dit de secretaris/algemeen directeur, griffier of iemand die door de organisatie werd aangeduid. U gaat dus best bij hen ten rade als u niet weet wie uw lokale beheerder is. Meer informatie over gebruikersbeheer.
Om optimaal gebruik te maken van onze applicaties, gebruikt u best Firefox of Chrome.
Het kan echter dat bepaalde functionaliteiten niet werken zoals het hoort. Mocht u dit opmerken, kunt u ons dit altijd laten weten via: DigitaalABB@vlaanderen.be.
Aanmelden verloopt via het gekende gebruikersbeheer Vlaanderen.
Al onze applicaties hebben op hun landingspagina een blauwe knop met "Meld u aan" staan. Klik op deze knop om verder te gaan. Bekijk alle webapplicaties van het Agentschap Binnenlands Bestuur.
Vervolgens verschijnt er een pop-up, die u enkele veilige opties voorstelt om u mee aan te melden.
Indien u toegang heeft tot meerdere bestuurseenheden, krijgt u in de pop-up de optie om een bestuurseenheid te kiezen.
Indien u een foutmelding krijgt, met de boodschap: "U beschikt niet over de rechten om aant e melden op deze toepassing."
Zorg dat de instellingen van uw browser goed staan.
Firefox
Bezoek deze link https://support.mozilla.org/nl/kb/instellingen-pop-upblokkering-uitzonderingen-probleemoplossing en kies Pop-upblokkeringsinstellingen.
Chrome
Bezoek deze link https://support.google.com/chrome/answer/95472?co=GENIE.Platform%3DDesktop&hl=nl en zoek naar Pop-ups van een specifieke site blokkeren of toestaan. Klik daarna op Pop-ups van een bepaalde site toestaan.
Krijgt u geen toegang tot de applicatie? Ga naar Gebruikersbeheer voor meer informatie.
Na het kiezen van een bestuurseenheid, bent u ingelogd. U krijgt nu toegang tot de modules waar u voor gekend staat bij het Gebruikersbeheer.
Het streefdoel van digitalisering is om niet te printen. We begrijpen echter dat in de overgang naar verdere digitalisering sommige pagina's toch geprint moeten worden.
Onze toepassing is geoptimaliseerd voor de browsers Chrome en Firefox. Wij raden dan ook aan een van deze browsers te gebruiken.
U kan informatie op webapplicaties printen naar een fysieke printer en/of een .pdf document.
Gebruik de printfunctionaliteit van uw browser. Een voorbeeld van chrome:
Klik op de drie puntjes om de dropdown te zien verschijnen.
Kies afdrukken
Sla het document op als PDF of print het document. U kan ook bij "meer instellingen" de titels en de densiteit van het document aanpassen.
Geraak op snelheid in de architectuur van onze toepassingen.
In dit introductiefilmpje leer je hoe de kennisgedreven semantische webtoepassingen bij ABB helpen om de missie en de visie van het Agentschap Binnenlands Bestuur in praktijk om te zetten.
Onderstaande presentatie geeft in vogelvlucht een beeld op de linked data gebaseerde, kennisgedreven toepassingen bij ABB.
An application framework to build web applications that run on linked data, aware of micro services.
User facing microservices
Deploy with Docker
Single page apps with Ember.js
Standard requirements: HTTP, JSON, SPARQL
Bootstrap een mu.semte.ch microservices omgeving in drie eenvoudige stappen.
Geen video beschikbaar voor de gevorderde concepten mu-authorization, delta-notifier, mu-search en yggdrasil – neem contact op om hier meer over te ontdekken.
Bekijk hier tot welke producten en diensten u toegang heeft:
Vervolgens verschijnt er een pop-up, die u enkele veilige opties voorstelt om u mee aan te melden op het gebruikersbeheer.
Zorg dat de instellingen van uw browser goed staan.
Firefox
Bezoek deze link https://support.mozilla.org/nl/kb/instellingen-pop-upblokkering-uitzonderingen-probleemoplossing en kies Pop-upblokkeringsinstellingen.
Chrome
Bezoek deze link https://support.google.com/chrome/answer/95472?co=GENIE.Platform%3DDesktop&hl=nl en zoek naar Pop-ups van een specifieke site blokkeren of toestaan. Klik daarna op Pop-ups van een bepaalde site toestaan.
Krijgt u geen toegang tot de applicatie? Ga naar Gebruikersbeheer voor meer informatie.
Je kiest voor de optie 'een entiteit van de Vlaamse overheid'.
In de sectie 'Mijn gebruikersrechten' vind je in het tabblad "Werkrelatie" een overzicht met al je gebruiksrechten voor verschillende toepassingen". Wens je toegang tot een toepassing contacteer dan één van de Hoofd Lokale beheerders van ABB.
In het tabblad 'Mijn Lokale Beheerders' vind je de contactgegevens van de collega's van ABB die je toegang kunnen geven tot een toepassing binnen de VO.
Staan uw gebruikersrechten goed, maar kan u zich niet aanmelden, of heeft u geen toegang tot bepaalde onderdelen? Neem contact op met uw lokale beheerder.
Staan uw gebruikersrechten niet goed? Neem contact op met uw lokale beheerder – deze persoon kan u toegang verlenen tot de producten en diensten van ABB.
Dit kan door lokale beheerders gebeuren.
Om toegang te krijgen tot de meeste applicaties van ABB, moet u de nodige toegangsrechten gekregen hebben via het gebruikers- en toegangsbeheer.
Toegangsrechten worden toegekend door de lokale beheerder die in elk bestuur aanwezig is. Meestal is dit de secretaris/algemeen directeur, griffier of iemand die door de organisatie werd aangeduid. U gaat dus best bij hen ten rade als u niet weet wie uw lokale beheerder is.
Om als lokale beheerder rechten toe te kennen aan gebruikers, surft u naar https://vo-gebruikersbeheer.vlaanderen.be. Meer informatie op https://overheid.vlaanderen.be/ict/ict-diensten/gebruikersbeheer.
Meld u aan met uw favoriete aanmeldingssysteem:
Kies vervolgens de juiste doelgroep, en het bestuur waar u zich voor wil aanmelden.
Klik op snel rechten toekennen om te starten.
U krijgt een overzicht te zien, waar u kan zoeken naar de juiste persoon.
Vervolgens kan u voor de geselecteerde persoon de juiste rechten zoeken. Afhankelijk van de applicatie waar u voor kiest, is dat een ander recht.
Gelinkt Notuleren: kies Gelinkt Notuleren
Loket Lokaal Bestuur: kies Loket voor Lokale Besturen
Organisatieportaal: kies ABB OrganisatiePortaal Gebruiker
Afhankelijk van de applicatie die u koos kan u nu rollen of contexten toekennen aan de persoon die u toegang verleende.
U kan een gebruikers het recht geven om bepaalde acties al dan niet uit te voeren op basis van rollen.
Een gebruiker kan rechten krijgen voor meerdere rollen.
Lezer;
ondertekenaar (handtekenbevoegdheid);
publiceerder;
schrijver.
Beheerder
Editeerder
Lezer
U kan een gebruiker tot bepaalde onderdelen van de applicatie toegang verlenen of ontkennen aan de hand van contexten.
Eens een gebruiker toegang heeft tot een bepaalde context, kan deze gebruiker alle acties uitvoeren voor de bijbehorende onderdelen. Een gebruiker kan rechten krijgen voor meerdere contexten.
Voorbeeld van 7 contexten voor Loket Lokaal Bestuur:
Context Gebruiker Mijn Toezicht: recht op onderdeel toezicht.
Context Gebruiker Berichtencentrum: recht op onderdeel berichtencentrum.
Context Gebruiker BBC DR: recht op onderdeel BBC-DR.
Context Gebruiker Mandatenbeheer: recht op onderdeel mandatenbeheer.
Context Gebruiker Leidinggevendenbeheer: recht op onderdeel leidinggevendenbeheer.
Context Gebruiker Personeelsbeheer: recht op onderdeel personeelsbeheer.
Context Gebruiker Subsidies: recht op onderdeel subsidiebeheer.
Geef ook een reden op om het recht toe te kennen.
U wordt gevraagd om het toekennen van rechten te bevestigen, waarna een boodschap verschijnt indien het proces met succes voltooid werd.
De persoon kan zich nu aanmelden met de toegekende rollen of contexten voor de gekozen applicatie.
Er is een vertraging van 5 à 10 minuten tussen het toekennen/afnemen van het recht en de effectieve toegang voor de gebruiker.
Lees meer over om te begrijpen waarom we deze technologie gebruiken!
Onze applicaties gebruiken Ember.js als Javascript framework.
Een goede leidraad kan je vinden op https://guides.emberjs.com/release/ – maar as je graag een boek ter hand neemt is https://balinterdi.com/rock-and-roll-with-emberjs/ een goede bron.
We gebruiken momenteel octane met glimmer components. Dit is de nieuwe versie.
De meeste componenten zijn al gemigreerd naar octane & glimmer, maar soms kom je nog oude syntax tegen die je zeker mag updaten.
Hier zie je hoe dat er uit ziet, en hoe je dat kan omzetten:
Hier kan je testen:
We bouwen onze applicaties op linked open data modellen. Vind ze hier:
Voorbeelden die we gebruiken:
De meeste van onze applicaties werden gebouwd met het Toegangs-(ACM) en Gebruikersbeheer (IDM) van de Vlaamse overheid. Dit wordt voorzien door Het Facilitair Bedrijf.
Het Facilitair Bedrijf vraagt eenmalig toegang via contract. Daarna maken ze het bestuur aan en geven ze rechten aan Lokale Beheerder in IDM. Daarna kunnen de lokale besturen inloggen via ADM (inloggen).
Aanmaken nieuwe gebruikers (intern of extern) + werkrelatie met bestuurseenheid
Toekennen gebruikersrechten (= toegang tot toepassing) en contexten (= wat mag/kan je doen binnen toepassing)
Toegang beperken in tijd of verwijderen
Eerste/hoofd Lokale Beheerder kan collega Lokale Beheerders aanduiden
De Appuniversum basis bestaat enkel uit HTML en CSS. Iedereen kan deze basiselementen (HTML elementen waar geen javascript voor nodig is) dus gebruiken in hun applicaties, los van de technologische keuzes die ze gemaakt hebben op vlak van Javascript bibliotheken. Lees meer over de richtlijnen op de documentatiesite.
Onze applicaties gebruiken Ember.js als Javascript framework. Enkel Kalliope gebruikt een ander platform, dat aangeboden wordt als softwarepakket van een leverancier.
Om die reden bouwen we onze webcomponenten in Ember. Deze kunnen niet gemakkelijk uitgewisseld worden met andere applicatiebouwers binnen de VO, maar ze mogen altijd onze code hergebruiken. Webuniversum gebruikt Vue.js.
Draag hier bij: https://github.com/appuniversum/
De Mijlpalen zijn WIP.
TODO chronologisch rangschikken + taken/risico's + effort
Implementatie van de pipeline: Het opzetten van een geautomatiseerde pipeline voor het uitvoeren van testen op schema. Taken:
Bepaal een scope per project ( Smoke - Regressie - E2E - Integratie - Performance - Security - DataDriven - UI - Headless - Unit )
Maak een pipeline per Projectscope: [Serge - docker - multipipeline voor het ophalen en builden]
Geschatte Effort:
Pipelineconfiguratie definiëren:
Maak de configuratiebestanden voor je CI/CD-tool om de stappen in de pipeline te definiëren, zoals het ophalen van de broncode, het opzetten van de testomgeving, het uitvoeren van tests, en het genereren van rapporten.
Build/Teststappen configureren
Integratie rapportage
Documentatie bijwerken
Notificaties instellen
Beveiligingsoverwegingen
(Monitoring / Logging - prestaties pipeline)
(Parallelle uitvoering)
(Automatische deployments)
Risico's:
Integratiecomplexiteit / Toolcompabiliteit
Automatiseringsduur
Gegevensbeheer
Beveiligingsuitdagingen
Teamtraining
Geschatte effort:
Volledige rapportage zonder menselijke interactie: Als we rapportages genereren zonder menselijke tussenkomst en deze automatisch naar Teams verzenden. Taken:
Risico's:
Geschatte Effort:
Onderhoudsproces opzetten: Aangezien er regelmatig onderhoud nodig is, kan het opzetten van een eenvoudig en gestructureerd onderhoudsproces een mijlpaal zijn. Taken:
Risico's:
Geschatte Effort:
Toevoegen van LPDC als 4e project: Het integreren van LPDC als een nieuw project in het automation framework. Taken:
Risico's:
Geschatte Effort:
Implementatie van API-testen:
Taken:
framework analyse / POC / training
Verwachte resultaten verzamelen [ eg expected response/data format/status code/error handling/ (performance/ security measures) .. ]
Automatisering / rapportering
Risico's:
Geschatte Effort:
Invoering van Performantie-testen:
Taken:
framework analyse / POC / training
Performantie-indicatoren [ eg response tijden, systeemstabiliteit onder belasting..]
Automatisering / rapportering
Risico's:
Geschatte Effort:
..?
EINDDOEL - Integratie in een CI/CD pipeline.
Uitbreiding van de test scope: Het liefst nemen we dit mee op het planningsniveau van de spurt.
Verbeteringen in snelheid en betrouwbaarheid: Als de code aanzienlijk sneller en betrouwbaarder is geworden, kan dit worden beschouwd als een mijlpaal in de prestatieverbetering van het automatiseringsframework.
Onderhoud: x
Training en capaciteitsopbouw:
Bied training aan het team voor het gebruik van het automation framework, API-testen en performantietesten.
Bouw capaciteit op binnen het team om deze technieken zelfstandig te beheren.
Zorg ervoor dat deze mijlpalen specifiek, meetbaar, haalbaar, relevant en tijdgebonden (SMART-criteria) zijn, zodat je duidelijk kunt meten wanneer ze zijn bereikt.
De diagram is een Work in Progress.
Automatisering van de 3 bestaande projecten: de overgang van de oude software naar Playwright is voltooid. ---
Vind meer informatie over ember op de architectuur pagina ember.js.
Het testing team bij ABB ondersteunt de verschillende product teams in het testen van hun producten naar aanleiding van releases of bij incidenten.
De testen die het test team uitvoert in opdracht van de product teams kunnen ingedeeld worden in een aantal soorten:
manuele, functionele testen waarbij specifieke delen van de toepassing getest worden.
manuele end-to-end testen waarbij bepaalde flows getest worden binnen toepassingen of bij integraties tussen verschillende toepassingen
manuele regressietesten, meestal in samenwerking met key users/ gebruikers van bepaalde toepassingen. Typisch worden deze testen uitgevoerd bij de lancering van nieuwe features.
automatisch testen
De praktische samenwerking met het test team verloopt in hoofdzaak door gebruik te maken van Jira ticket flow. In de Jira gebruikershandleiding van ABB wordt deze praktische samenwerking verder toegelicht. Door gebruik te maken van Jira tickets, ticket workflows en borden kan snel, efficient en ad hoc worden gewerkt.
Momenteel biedt het test team van ABB de volgende soorten testen niet aan:
automatische load testen
automatische stress testen
automatische performantie testen
usability testen
toegankelijkheidstesten
Een teststrategie voor UI, API en prestatietests bepaalt de aanpak voor het waarborgen van de kwaliteit in specifieke gebieden van softwareontwikkeling.
Het identificeert testdoelstellingen voor de gebruikersinterface (UI), applicatieprogrammeerinterfaces (API's) en prestatie-aspecten.
De strategie specificeert de testmethoden, zoals handmatige UI-tests, geautomatiseerde API-tests en prestatietests om de respons- en schaalbaarheidskenmerken te evalueren.
Testniveaus, zoals systeemtests voor UI en API-integratietests, worden vastgesteld.
De strategie omvat ook de selectie van geschikte testmiddelen, zoals testframeworks en tools voor prestatietests.
Door deze bepalingen wordt een gestructureerde aanpak mogelijk gemaakt, waarbij het testen van UI, API en prestaties effectief wordt geïntegreerd in het ontwikkelingsproces.
https://miro.com/app/board/o9J_kpGeOXs=/
https://miro.com/app/board/o9J_l9uYRTY=/
Taak
Geschatte effort
Maken van de test specificatie
Schrijven van testcases: Tussen een half uur tot enkele uren per testcase afhakelijk van de complexiteit en beschikbaredocumentatie.
Onderhoud
Continu
Test Executie
Test Executie, Opvolging/Onderhoud en Rapportage: Enkele dagen tot weken, afhankelijk van projectgrootte.
Test Opvolging en Rapportering
Het doel is om deze taak uiteindelijk gedeeltelijk geautomatiseerd uit te voeren.
Deze handleiding zal uitleggen hoe analisten/developers/product managers/... feedback kunnen geven op mockups via comments op Figma.
Met een muis: Om te navigeren tussen de verschillen schermen moet je spatie en rechter muisknop tegelijk ingedrukt houden en je muis bewegen.
Met een trackpad: Als je een trackpad hebt, kan je heel makkelijk door de schermen in Figma navigeren, door met je vingers te slepen.
Om in te zoomen naar een scherm, kan je + of - op je toetsenbord gebruiken (dit kan verschillen per toetsenbord). Je kan ook rechts boven zoom opties vinden met verschillende toetsenbord sneltoetsen terug vinden.
Als je een trackpad hebt, kan je ook makkelijk in- en uitzoomen door je twee vingers van of naar elkaar te slepen.
Feedback geven via Figma doe je door comments te laten op schermen.
Een designer bezorgt een Figma link naar mockups. Om comments te kunnen schrijven, moet je eerst een account aanmaken.
Eens je een Figma account hebt aangemaakt, kan je comments laten op specifieke plekken op de schermen.
Om in comment modus te gaan, moet je op het tekst ballonetje linke boven klikken. Je muis zal dan in een pin veranderen. Deze kan je eender waar in het document plaatsen. Wanneer je dit doet, maak je een comment aan. Dan mag je daar relevante feedback schrijven.
Als je per ongeluk op de verkeerde plaats een pin zet, kan je op Cancel drukken, of ergens anders op de scherm klikken met je muis. Dit zorgt ervoor dat de pin verdwijnt.
Eens je je feedback geschreven hebt, mag je op "post" drukken. Dit maakt je comment zichtbaar voor iedereen die toegang heeft tot de Figma link. Je kan een lijst van alle comments zien op de rechter kant van je scherm, wanneer je in "comment modus" bent. Je kan ook reageren op comments en discussies starten.
How to conduct user interviews and tests online.
Since 2020 we have been conducting remote, online, user tests and interviews. We have found a pretty flexible way to perform that testing. Below you can find a suggestion of how to conduct those user interviews and tests, but make sure you adjust the tools according to your needs!
scope
Decide with your team members what you are going to test and why. This will dictate what questions you'll ask, what type of test you'll conduct and who you will contact.
What
Which assumptions do you know you have, and which ones do you want to test?
What answers are you looking for?
What do you know you don't know yet?
Who
Who can answer these questions for you? Who will work with the application? Who do you need to convince to get the entire team to work with your app?
How
How you're going to test is going to depend on what you are testing. If you are testing raw ideas, you'll probably share wireframes (via screen sharing for example). If you are testing an application, you'll need a dev environment ready and you'll probably want people to share their screen with you.
Why
What do you want to do with these answers afterwards? Do you want to make sure you know what new features to develop, or which ones to improve? Or would you want to set up webinars afterwards to get people to use it? Many options.
inhoud test
Define the structure of your meeting.
Will it have an interview part? Will you send the questions up front?
Will you test with wireframes, mockups, a prototype or something else?
Which parts are there to your test?
Conclusions
For drawing conclusions overall, after each session, we already add conclusion tabs to the template, per interview- and test section. These conclusion tabs you can already prepare up front; because they help you define up front what you want to know. Sometimes you need multiple questions to gather one insight.
timing
Allocate time to the different parts of your test and interview. Allocate the most time to what is important. Make sure you have some time to run out; you don't want your meeting to be stuffed to the brim. Things will go wrong.
No clue how to time it? Do an internal pre-test with some colleagues to give yourself a better idea.
name
, type of participant
, organisation
, type of organisation
, contact person
, tag
Get an overview of who you need to talk to to get the relevant information for your project – and what steps you can undertake if you cannot find those people right away.
Usually the product manager sets up the meetings via personal contacts, or partnerships that are relevant to the product or via the client (VVSG – Vereniging van Vlaamse Steden en Gemeenten, Inter, Klankbordgroep Gent).
Fill out their name
, type of participant
(think of which type of people you need to see to get a good grasp on your answers, broad and diverse enough), organisation
and type of organisation
(also relevant for your end results) and who the contact person
is (probably your product manager; this is helpful during the introduction or when someone does not show up). The tag
can help you to anonymise information later on, but is optional.
date
, time
, location
Before anyone starts contacting interviewees, make sure you block out enough placeholder time ahead with the appointed team members; so the product manager can align agenda's with the interviewees.
Make sure you have a bit more time allocated to the meeting than you planned for in the interview / test (because things will go wrong).
Location: make sure everyone knows up front where the meeting will take place. Add them to the document to make sure you can switch easily.
interviewer
, notulist
, specialist
Appoint an interviewer
, and someone that takes notes (notulist
). If they switch, it'll be different every session; just make sure everyone knows up front.
Sometimes it's helpful to have a specialist
on board (like a jurist) to answer specific questions about the topic you're dealing with. Try answering these questions at the end of the session, because it's easy to get lost in details and go off-topic.
More than 2 people can be overwhelming to the test subject, so find out what's the best for the outcome.
Consider turning off camera's for people that are not taking the interview, but do involve everyone in the introduction (smile & wave) and when saying goodbye.
The goal of the introduction is to make people feel at home and set expectations.
The interviewer takes te lead and lets everyone (including the notetaker, specialist, ...) introduce themselves briefly. Mention the contact person (see attendees) if needed to make sure everyone knows why they are here.
A virtual round of the table is hard; you don't know who's next to you. The interviewer calls out everyone one by one to introduce themselves.
The interviewer goes over the setup.
What can they expect, what do you expect
Explain what is going to happen and why; what you want people to focus on.
Explain the structure of the meeting before they start – so they know what's coming.
GDPR: Explain what happens to the notes, and what their rights are.
Sometimes interviewees think they have to elaborate, do things differently than usual or "do a good job" (most of us want to!) . Try to debunk that.
If something goes wrong, that's excellent.
Make sure everyone knows it's okay to make mistakes, be confused and have questions – and that it is valuable information. We are testing the application (or service or idea or...), not their skillset.
Honesty is key to get value out of these sessions.
The interviewees should know that they can't insult (or compliment!) anyone in the room.
Their lead
The interviewees don't need to be extra elaborate or extra fast – they can just act the way they would as if they're at home or in the office.
Think out loud
Urge your test subjects to think out loud (and show their frustration) to help the interviewer and notetaker understand what is going on.
Leave room for questions!
To understand the feedback you're getting from your interviewees, you need some context. The interviewer and the interviewee are mostly speaking. As little intervention as possible from is expected others. If the notetaker missed something, it's okay to speak up.
Ask targeted questions if there are multiple people in the room, don't leave it open-ended (in a remote situation this usually causes silence)
Only ask one question at a time.
This is easier to answer
You'll most likely get an answer
It's easier to note down.
Think of what you need to know, and what to leave out. This depends from test to test.
Some examples:
Demography & Job
– ask about their function, and what they do on a daily base. This can frame how often they would be interact with your product (or service or..).
Digital skills
– if you have little knowledge about your interviewees, it will be helpful to know what their digital skillset is. If they spend a lot of time using their computer during their job, chances are high they'll onboard your application much quicker than someone that only uses their ipad during the weekend; and they might need more guidance.
Applications
– if they use similar or other applications to complete the job you're interested in, you know which patterns they might be used to or what quality they expect.
Previous use
- it's possible people have already used your application. You might want to figure out what they think about your application now; and see if it's different after they've seen your new features or adapted features.
These questions will also help you to create archetypes (persona's) later on, that can guide you when building features.
Add as many rows as needed to keep an overview.
If you are interviewing multiple people at the same time (depending on your situation this can happen, even if it is not always ideal) add initials or tag of the person that is giving an answer or to the information you are writing down.
If multiple people are editing, make sure you're not overriding what they just wrote down.
Decide when and how you're going to ask these questions:
Up front (via mail)
Reduces meeting time; which everyone likes.
If it's a lot of questions, it can feel like an annoying assignment – chances of it getting completed get lower with every question. This is especially the case with busy people.
You can ask "why" or elaborate during the meeting.
During the test
Elongates meeting time.
No "homework" feeling.
Easier to ask questions and go deeper when they are filling it out.
Can take long when doing this together.
The interviewer and the interviewee are mostly speaking. As little intervention as possible from is expected others. If the notetaker missed something, it's okay to speak up.
Ask targeted questions if there are multiple people in the room, don't leave it open-ended (in a remote situation this usually causes silence)
Only ask one question at a time.
This is easier to answer
You'll most likely get an answer
It's easier to note down.
Make sure you have a separate, stabile test-environment – where anyone can safely add test-data. Warn the developers not to deploy when you are testing!
Make sure people can share their screen if needed.
Have a back-up scenario available that allows you to to share your screen and perform the tasks they want to complete, just in case it doesn't work out. Make sure you don't steer or influence especially in this case.
If you are testing raw ideas, you'll probably share wireframes (via screen sharing for example).
Make sure people can see the relevant applications on your screen.
Turn off notifications to not be disturbed.
Make sure people don't have to see a cluttered background, irrelevant information or irrelevant tabs pass by.
Take it easy. Don't make people motion-sick. Give them time to inspect.
Your testing questions will depend on which type of test it will be. The main setup is giving someone an assignment, see how they complete it, and ask them nudging questions to discover what is going on in their mind.
When you have a clickable prototype:
"Create a new file"
"Fill out the form"
When you have a concept in a wireframe or mock-up
"If you would want to create a new file, how would you go about it?"
Refrain from giving people answers. If they ask you "is it this button?", you can ask them to try it out, and discover it together. Assure them nothing can go wrong.
Add as many rows as needed to keep an overview.
If you are interviewing multiple people at the same time (depending on your situation this can happen, even if it is not always ideal) add initials or tag of the person that is completing the task/answering a question or to the information you are writing down.
If multiple people are editing, make sure you're not overriding what they just wrote down.
What to fill out
Opdracht gelukt
Did they succeed?
Think of a system up front like "yes / no / almost"
This will help you when draw conclusions faster in the end
Omschrijving interactie
How did it go?
Where did they get stuck?
What went well?
Add rows if needed
Opmerkingen
If you have anything to add, like thoughts or suggestions (from anyone in the room), you can add it to the comments field.
To make sure you know what's happening inside people's minds, and why they make certain decisions, you can help them think out loud by asking questions:
What do you see here?
What can you do here?
Did this button meet your expectations?
The interviewer and the interviewee are mostly speaking. As little intervention as possible from is expected others. If the notetaker missed something, it's okay to speak up.
If you decide to do a guided test, and want to teach people how to work with your application (or service or..) more than discover what to improve, you can show them or help them complete a task. Then give them time to try it themselves. After a while you can ask them how it went.
How did it go for you? Did it work out?
If they don't give you a lot of details, you can ask what went well and what did not, and get into a conversation if needed.
The one question that you probably want an answer to is "Would you use this application/service/...?" You can ask any variety on this, but this will probably give you the best insight.
Ask for feedback on your test as well, see if there is room for any improvement.
This is also a great time to ask if you can contact them again in the future to be part of other tests or even enter your customer advisory board.
Tell people what is going to happen.
Will you send them an e-mail with follow-up? When?
When will they be able to see something? Do you want to keep them up-to-date?
Do you want them to participate in other tests?
Ask them if they want to!
When you're done with all the interviews, you can start drawing conclusions. This is will be different for each set-up. Up front, you can however define which conclusions you know you already want to draw – but you don't know what you don't know, so this will change. See Scope & Overview.
After all the user tests are over, you can review the questions and see which issues and questions arise. This is a wonderful time to prioritise and review how you're going to approach your roadmap in the near future.
To make it easier to decide what to fix first (regardless of effort and time – that's to be decided by the team), we can divide them into 3 priorities:
Blocking problems These are the types of features and issues that keep our target audience from completing the goals they and we have in mind – that our solution needs to provide. These are crucial and need to be estimated and planned first. Us: "Can they reach their goal?" Them: "I can only use it if..."
Improvements These features make our solution easier to use, will make sure our target audience can reach their goals in a better way and make sure the business is closer to their goals as well. We'd like to plan these in the near future; to make sure we don't frustrate anyone – which will keep them from being happy advocates for us.
Us: "What is frustrating?" Them: "I'd recommend this to my colleagues if..."
Nice to have & Future Nice to have: the cherries on top that will make our target audience happy. Future: Features that we have in mind but they are not on our roadmap in the near future. Us: "What other goals we have in the future, that align our target audience and business?" Them: "I'd love it if..."
Depending on how you see your solution, what your product management style is and how you approach things – you can adapt these priorities!
You can use questions you need answers to that you defined in Scope & Overview, to group your topics as well ("vraag" and "antwoord").
You can also label the features and issues with tags to see what your improvements are mostly about; for example UX/UI
, bug
or new functionality
.
Take this information to the team; and get their expert view on what the future might hold. Reprioritise together, and turn it into Jira tickets.
Ontwerpers bij ABB werken op verschillende gebieden en overlappen ook met mensen in andere disciplines (front-end, analyse, ...). Het is aan jou om te bepalen op welke gebieden je wilt bijdragen. Enkele voorbeelden van wat we doen:
Conceptualisering
Analyse
Interviews afnemen
Wireframing & schetsen
High-fidelity mockups tekenen
HTML & CSS
Testen met klanten
Branding
Presentaties
Momenteel bestaat de design team uit:
Smooth Sailing: Agency
Er zijn ook specifieke richtlijnen voor de digitale huisstijl, die lichtjes verschillen van de algemene richtlijnen.
Header: Om vlot te integreren met onze codebase en snelheid te verhogen, hebben we de header nagemaakt in Ember. Deze verschijnt altijd en overal.
Footer: De footer werd ook nagemaakt. Deze gebruiken we enkel op log-in pagina's, omdat onze applicatiepatronen anders in elkaar zitten.
We maken momenteel gebruik van een mix van klikbare prototypes in Figma, en echte prototypes in HTML en CSS. We werken ook samen met andere departementen om hier een degelijke componenten bibliotheek aan te leggen, zowel in vectoren (Figma) en HTML en CSS.
We gebruiken Figma, maar we hebben nog geen licentie.
De Vlaamse Overheid heeft een webcomponentenblibiotheek gebouwd. We maken daar momenteel geen gebruik van:
In haar huidige vorm, de 3.0 versie, is deze bibliotheek beschikbaar wanneer we gebruik maken van hun Webplatform. Binnen onze applicatiearchitectuur maken we geen gebruik van dat Webplatform, en kunnen we dus ook geen gebruik maken van de webcomponentenbibliotheek.
De 3.0 versie is niet open source. Wij maken open source applicaties, en hebben dus nood aan open source oplossing.
Om onze applicaties mee te bouwen, hebben we een open source componentenbibliotheek gebouwd.
Deze componenten bibliotheek bestaat momenteel uit twee delen: Appuniversum & Ember-Appuniversum.
Dit Design systeem is zover gegroeid dat het een project op zich is geworden. We werken eraan om de communicatie tussen de verschillende partijen en bewegende delen te optimaliseren.
Appuniversum is niet alleen voor developers, of designers die prototypes in HTML & CSS bouwen. We bieden ook een open-source Figma library, waar designers, analisten, project managers,... eigen wireframes en mock-ups kunnen bouwen, gebruik makend van vooraf gedefinieerde onderdelen.
Deze bibliotheek bootst Ember-Appuniversum na.*
*Dit werk is nog in uitvoering en er kunnen nog kleine discrepanties in bestaan.
Designers gebruiken de bovenstaande skillset om aan alle LBLOD projecten te werken die vermeld staan in
: Freelance
Wij zijn verplicht de huisstijl van de Vlaamse overheid te volgen. Zij hebben uitgebreide en transparante richtlijnen (kleuren, logo, lettertypes, ...). We gebruiken deze richtlijnen om ons eigen open-source Design systeem, , te maken. Deze is gebaseerd op, en volgt, de richtlijnen van .
Al de applicaties en websites die we publiceren, moeten toegankelijk zijn, volgens de [EN].
De bibliotheek is gebaseerd op de oude webcomponenten van de Vlaamse Overheid, . Hier bouwden we onze applicaties mee in het begin, toen deze versie nog open source gepubliceerd werd. Om ervoor te zorgen dat we bugs konden oplossen, de bibliotheek konden uitbreiden voor specifieke applicatie componenten en onze applicaties open source konden publiceren, riepen we Appuniversum in het leven. Iedereen die gebruik wil maken van deze bibliotheek, meer specifiek in kader van projecten voor de Vlaamse Overheid, mag hier aan meewerken.
De Vlaamse Overheid heeft een webcomponentenblibiotheek gebouwd. We maken daar momenteel geen gebruik van:
In haar huidige vorm, de 3.0 versie, is deze bibliotheek beschikbaar wanneer we gebruik maken van hun Webplatform. Binnen onze applicatiearchitectuur maken we geen gebruik van dat Webplatform, en kunnen we dus ook geen gebruik maken van de webcomponentenbibliotheek.
De 3.0 versie is niet open source. Wij maken open source applicaties, en hebben dus nood aan open source oplossing.
Om onze applicaties mee te bouwen, hebben we een open source componentenbibliotheek gebouwd.
De bibliotheek is gebaseerd op de oude webcomponenten van de Vlaamse Overheid, versie 2.0. Hier bouwden we onze applicaties mee in het begin, toen deze versie nog open source gepubliceerd werd. Om ervoor te zorgen dat we bugs konden oplossen, de bibliotheek konden uitbreiden voor specifieke applicatie componenten en onze applicaties open source konden publiceren, riepen we Appuniversum in het leven. Iedereen die gebruik wil maken van deze bibliotheek, meer specifiek in kader van projecten voor de Vlaamse Overheid, mag hier aan meewerken.
Deze componentenbibliotheek bestaat momenteel uit twee delen: Appuniversum & Ember-Appuniversum.
Er zijn ook andere organisaties op zoek naar manieren om hier open source en meer gericht op applicaties mee om te gaan.
Zo is Kaleidos ook bezig met een bibliotheek, waar we op zoek zijn naar een manier om dichter naar elkaar te groeien: http://development.kaleidos-prototype.mono.digital/styleguide/auk-tabs.html
Het Agentschap Binnenlands Bestuur bouwt mee aan duurzaam en democratisch samenleven in diversiteit. Dat doen we door burgers en bestuur te verbinden en te versterken.
Lokale besturen
Steden
Brussel
Gelijke Kansen
Integratie en inburgering
Vlaamse Rand
Meer informatie over ABB: https://www.vlaanderen.be/agentschap-binnenlands-bestuur
Binnen deze domeinen werken we aan:
goed functionerende lokale besturen;
sterke en duurzame steden;
de ondersteuning van de Vlaamse aanwezigheid in Brussel en de banden tussen Brussel en Vlaanderen;
gelijke kansen voor elke Vlaming;
het dichten van de herkomstkloof in onze samenleving;
de ondersteuning van het Vlaamse en groene karakter in de Vlaamse Rand.
Het Agentschap Binnenlands Bestuur bouwt mee aan duurzaam en democratisch samenleven in diversiteit door burgers en bestuur te verbinden en te versterken.
Het Agentschap Binnenlands Bestuur is een wendbare organisatie die het beleid inspireert en antwoorden aanreikt voor de bestuurlijke en maatschappelijke uitdagingen van vandaag en morgen.
Door het verder uitbouwen en aanwenden van onze kennis, onze expertise en ons netwerk willen we de referentie zijn voor burgers en bestuur.
Wij verbinden en versterken burgers en bestuur door:
het bevorderen van gelijke kansen en het samenleven van burgers in diversiteit.
een beleidskader en instrumenten aan te reiken die de relatie tussen burgers en bestuur bevorderen.
in te zetten op de versterking van de bestuurskracht van lokale besturen, zodat taken op het meest burgernabije niveau kunnen worden uitgevoerd.
Samenwerking en wendbaarheid We vinden samen oplossingen, geloven in de kracht van samenwerking en staan open voor nieuwe uitdagingen.
Vertrouwen & Integriteit We geven en verdienen vertrouwen en bevorderen integriteit.
Openheid We geven duidelijke informatie, delen onze kennis en werken met transparantie.
Besluitvaardigheid We zeggen wat we doen en doen wat we zeggen.
Meer dan 300 lokale besturen in Vlaanderen schrijven elke dag beslissingen die waardevolle informatie bevatten. Wij willen ervoor zorgen dat zij, door gebruik te maken van linked open data, hun informatie en (juridische) documenten rechtstreeks kunnen publiceren, en directe gegevensuitwisseling mogelijk maken. We zorgen voor herbruikbare bronnen, zodat informatie kan doorstromen naar andere overheden & diensten, burgers, organisaties en bedrijven.
ABB biedt ondersteuning voor kwaliteit & efficiëntie, om die lokale overheden te versterken.
Om die waarde tot leven te brengen, bouwen we diverse digitale oplossingen.
We ondersteunen lokale besturen bij het creëren van herbruikbare informatie via LBLOD-oplossingen:
We hebben samen met de lokale overheden een Linked Open Data Standard gecreëerd: een standaard manier om gegevens te delen tussen de betrokken partijen.
We valideren software leveranciers die notuleren voor lokale overheden ondersteunen; en zorgen ervoor dat ze hun gegevens op een correcte manier uitwisselen en publiceren.
We bouwen aan Gelinkte Notuleren: gelimiteerde, gratis besluitvormingssoftware voor lokale overheden zonder softwareleverancier - om gelinkte gegevens te ondersteunen.
We bouwen aan een innovatieve open source linked data tekst editor die eindgebruikers ‘zonder inspanningen’ machineleesbare informatie laat creëren. We hergebruiken deze editor in onze eigen toepassingen en zorgen ervoor dat externe partijen deze ook eenvoudig kunnen hergebruiken.
Deze informatie wordt doorgegeven via het Loket voor Lokale besturen - een platform voor gegevensuitwisseling en communicatie tussen lokale besturen en ABB.
We stellen op onze beurt deze gegevens ter beschikking van andere overheden en diensten en particuliere hergebruikers via kwaliteitsvolle databronnen, zoals de decretale publieke databanken, het organisatieportaal en het Verenigingenregister. Eind 2023 lanceerden we de toepassing lokaalbeslist.be waarop elke burger de gepubliceerde agendapunten en bijhorende besluiten van zijn of haar gemeente kan raadplegen. De toepassing toont - hergebruikt dus - de gelinkte informatie die de lokale overheden en hun softwareleveranciers sinds de totstandkoming van de Linked Open Datastandaard voor besluiten, hebben gepubliceerd. Binnen ABB gaan ook interne tools, zoals het case managementsysteem Kalliope, ermee aan de slag zodat de medewerkers van ABB optimaal kunnen werken.
ABB biedt ondersteuning via hun helpdesk, geeft opleidingen en ontwikkelt relevante functionaliteiten die lokale besturen nodig hebben om efficiënt te communiceren en gegevens uit te wisselen met allerlei actoren.
Ontdek het ecosysteem, de oplossingen en de applicaties die burgers en bestuur verbinden [klik om te vergroten]
Al onze code is open-source, in lijn met onze visie en waarden, en kan je vinden op https://github.com/lblod.
Lokale Besluiten als geLinkte Open Data (LBLOD) is een programma. Het omvat alle ABB-projecten in kader van lokale besluitvoering, en gelinkte data (linked data).
Linked data is een digitale methode om informatie te structureren en te publiceren, zodat mensen en (zoek)machines het kunnen raadplegen op internet.
Om ervoor te zorgen dat deze informatie open en gelinkt beschikbaar gesteld kan worden, hebben de partijen in het ecosysteem verschillende oplossingen bedacht en daar applicaties voor ontwikkeld.
Lokale besluiten bevatten waardevolle authentieke gegevens voor iedereen.
Als burger wil ik weten wanneer mijn straat ontoegankelijk is door werken.
Als ondernemer wil ik weten aan welke verplichtingen ik moet voldoen.
Als vereniging wil ik weten of en hoeveel subsidies ik kan krijgen.
Als middenveld wil ik weten hoe lokale besturen hun cultuurbeleid vormgeven.
Door de gegevens in lokale besluiten gelinkt te publiceren, kunnen organisaties die gegevens gemakkelijker hergebruiken. Gelinkte gegevens zijn gestandaardiseerd, waardoor machines ze eenvoudig kunnen vinden en verwerken. Iedereen kan met de informatie in de lokale besluiten aan de slag dankzij LBLOD.
Een concreet voorbeeld: agentschappen en departementen van de Vlaamse overheid kunnen zelf de informatie die zij nodig hebben uit de gepubliceerde besluiten halen. Lokale besturen hoeven die niet telkens opnieuw op te sturen of aan te leveren.
De producten en diensten binnen ABB worden gebouwd met Linked Open Data als basis. Publieke data, geen privacy-gevoelige data, worden op zo'n manier verzameld en beschikbaar gesteld dat mensen binnen en buiten de overheid die informatie kunnen verwerken, hergebruiken en verrijken.
Meer over open source: https://opensource.pleio.nl/
Microsoft Teams wordt gebruikt als het centrale communicatiemiddel voor online communicatie. Alle klassieke agile scrum 'ceremonies' worden gehouden met behulp van Microsoft Teams (o.a. sprintplanning, stand-up, Backlog Refinement, Sprint demo's) evenals de Groeispurt Voorbereidingsactiviteiten zoals Impact- en Story Mapping, Spurt Planning en Spurt Retrospectives.
Verder gebruiken een aantal producten Teams Channels om efficiënt te communiceren over bepaalde relevante onderwerpen met betrekking tot het bouwen, testen, vrijgeven en bedienen van de applicatie(s).
Vragen? Contacteer Serge serge.gillebeert@vlaanderen.be
Sharepoint wordt gebruikt om administratieve zaken van de werking en documenten die persoonsinformatie bevatten goed en veilig te capteren. Bijvoorbeeld de aanwezigheidskalender en contracten worden op deze manier bijgehouden.
Vragen? Contacteer Sarah Macquoy sarah.macquoy@vlaanderen.be
Wij gebruiken Miro voor verschillende doeleinden. Productteams houden zich op verschillende momenten bezig met Impact Mappings en Story Mappings. Tijdens de Centrale Planningsdag stellen we de productplanning op Spurt-niveau op met behulp van een Miro-bord voor elk product. Tijdens de IPI wordt Miro ook gebruikt om Spurt retrospectives uit te voeren waar nodig.
Sommige productteams maken nog meer gebruik van Miro en bereiden ook productroadmaps en productreleases voor in Miro.
Vandaag zijn er online toepassingen die in de browser werken en bestanden kunnen openen van of opslaan naar jouw computer.
Gemakkelijkste en gratis tools zijn https://app.diagrams.net voor algemene diagrammen, met zeer veel templates en toolboxes en https://demo.bpmn.io voor specifiek BPMN, CMMN of DMN.
Deel diagrammen van deze tools altijd met collega's via Sharepoint of versiecontrolesysteem.
Vermijd aub diagrammen in Visio. Visio is een dure licentie die ABB bovenop de standaard software paketten moet betalen.
De prototypetool Figma wordt gebruikt voor het ontwerpen van gebruikersinterfaces en gebruikerservaringen. Het stelt de productteams in staat om in realtime samen te werken aan gebruikersinterfaces: het helpt ons om relevante schermen voor gebruikers te ontwerpen en het helpt ons om zo goed mogelijk te beschrijven hoe de schermen moeten werken voor het scrum (dev) team dat de pagina's gaat bouwen . Vervolgens helpt het het testteam om de relevante informatie te krijgen over wat te testen zonder lange documenten te hoeven lezen die de gebruikersinterface en gebruikerservaring beschrijven.
Het platform Gitbook wordt door het Digiteam ABB gebruikt voor het beheren en delen van relevante informatie voor externe partners van het team die mee werken aan de bouw en het gebruik van het semantische ecosysteem van toepassingen en data. Het bevat technische en functionele informatie over de verschillende toepassingen en producten met als doel de instap voor externe partners zo laag mogelijk te maken en de zelfredzaamheid van deze partijen zo hoog mogelijk te maken.
Naast bovenstaande informatie bevat het Gitbook platform ook nog relevante informatie over de werking van het Digiteam om nieuwe (externe) mederwerkers vlot operationeel en in het team geintegreerd te krijgen.
Een Feature Passport bevat alle informatie om een bepaalde functionaliteit van een product te berschrijven. Zo zorgen we ervoor dat iedereen begrijpt wat we gaan bouwen en wat de status daarvan is.
De subsidiedatabank verzamelt alle info rond ingediende subsidieaanvragen (via het loket lokale besturen), zodat inhoudelijke afdelingen makkelijk kunnen opvolgen wie wanneer wat indient.
Elk bestuur of organisatie die voor haar werking een subsidie wil aanvragen uitgereikt door het Agentschap Binnenlands Bestuur. In de praktijk kunnen dit lokale overheden zijn (bijvoorbeeld subsidies voor de aanleg of verbetering van fietsinfrastructuur, subsdies voor de bouw van nooddorpen voor Oekrainse vluchtelingen, ...) of verenigingen op Vlaams grondgebied.
Een lijst met alle relevante links voor elk product is hier te vinden, om productoverschrijdend werken makkelijker te maken.
Een lijst met alle relevante links voor elk product is hier te vinden, om productoverschrijdend werken makkelijker te maken.
Elk product en elke dienst heeft zijn eigen handleiding, maar het aanmelden en het gebruikersbeheer is voor de meeste producten hetzelfde. Er is een aparte handleiding die uitlegt hoe u gebruikers aanmeldt en beheert.
U kunt productmanagers vragen hoe zij toegang krijgen tot ontwikkelingsomgevingen.
Front-end https://github.com/lblod/frontend-gelinkt-notuleren
Gebruikerssessies: https://gebruikerssessie.gelinkt-notuleren.lblod.info/login Development: https://dev.gelinkt-notuleren.lblod.info/login
Citatenplugin (link naar de Vlaamse Codex in notulen) https://github.com/lblod/ember-rdfa-editor-citaten-plugin
Gebruikerssessies: https://publicatie.gebruikerssessie.gelinkt-notuleren.lblod.info/ Development: https://publicatie.dev.gelinkt-notuleren.lblod.info/
De editor die in Gelinkt Notuleren ingeladen wordt https://github.com/lblod/ember-rdfa-editor
Front-end https://github.com/lblod/frontend-loket
Back-end https://github.com/lblod/app-toezicht-abb Front-end https://github.com/lblod/frontend-toezicht-abb
Quality Assurance https://qa.toegankelijk.vlaanderen.be/ Quality Assurance intern: https://qa.toevla.org/ Development: https://dev.toevla.org/
Development: https://dev.organisaties.abb.lblod.info Quality Assurance: https://organisaties.abb.lblod.info
Front-end: https://github.com/lblod/frontend-organization-portal Back-end: https://github.com/lblod/app-organization-portal More information: https://abb-vlaanderen.gitbook.io/doc-organisatieportaal/code
Front-end https://github.com/lblod/frontend-mandatendatabank
Front-end https://github.com/lblod/frontend-leidinggevenden-databank