Team Topologies is een framework dat is gebaseerd op het idee dat verschillende soorten teams nodig zijn om verschillende soorten problemen bij softwareontwikkeling aan te pakken.

Op een hoger abstractie niveau gaat Team Topologies over: fast flow, snelle feedback, team interactie, evolutie van de organisatie, team cognitive load en omgaan met de huidige belemmeringen in de organisatie.

De bedenkers beschrijven Team Topologies als volgt: Vier fundamentele teamtypen en drie kernteam interactiemodi combineren met bewustzijn van de wet van Conway, cognitieve belasting van het team en responsieve organisatie-evolutie om een ​​no-nonsense, teamvriendelijke, humanistische benadering te definiëren voor het bouwen en gebruiken van softwaresystemen.

Laten we dit eens verder uitwerken. In dit artikel ligt de focus op typologieën, interactiemodi en gedrag.

Het boek Team Topologies

Het boek ‘Team Topologies, Organizing business and technology for fast flow’ van Matthew Skelton en Manuel Pais biedt een raamwerk voor het ontwerpen en beheren van teams in organisaties om softwarelevering te verbeteren. Het helpt organisaties bij het ontwerpen en beheren van hun teams op een manier die snellere en effectievere softwarelevering ondersteunt.

Het boek benadrukt het belang van het hebben van de juiste teams om verschillende soorten problemen aan te pakken en bespreekt vier team topologies (hoofd teamtypes): Stream-aligned teams, Enabling teams, Complicated Subsystem teams en Platform-teams.

Skelton en Pais beschrijven dat teams moeten worden ontworpen rondom de interacties die ze hebben met andere teams en systemen in de organisatie, in plaats van simpelweg te worden toegewezen aan een specifiek project of product. Hoe organisaties de structuur van hun teams kunnen optimaliseren en hoe ze de teams kunnen ondersteunen met de juiste tools, processen en culturele veranderingen.

Uitdagingen

Het boek behandelt ook de uitdagingen die vaak voorkomen bij teams, zoals silo’s, overbelasting van teams, onvoldoende samenwerking en te veel beheersing. Het biedt praktische oplossingen om deze problemen aan te pakken, zoals het invoeren van een ’team-first’ cultuur, het bevorderen van samenwerking en communicatie, het vereenvoudigen van de technologie stack en het bieden van ondersteuning en hulpmiddelen voor teams.

Het boek richt zich ook op de noodzaak van een agile en DevOps-cultuur om teams te ondersteunen bij het sneller en beter leveren van software. Het beschrijft hoe teams kunnen samenwerken met andere teams en belanghebbenden, hoe teams de feedback-lus kunnen sluiten om de software continu te verbeteren en hoe teams hun prestaties kunnen meten en verbeteren. In het artikel DevOps lees je meer over DevOps.

Ten slotte biedt het boek praktische tips voor het implementeren van de Team Topologies-benadering in een organisatie, zoals het identificeren van het huidige teamontwerp, het definiëren van de gewenste teamstructuur, het ontwikkelen van nieuwe teamvaardigheden en het meten van de prestaties van teams.

‘Ontwerp een organisatie architectuur om de juiste software architectuur te produceren.’

Matthew Skelton en Manuel Pais

Evolutie van Team Topologies

De evolutie van Team Topologies is gestart met de observatie dat de traditionele manier van werken in silo’s binnen een organisatie niet meer goed werkte in de steeds complexer wordende technologische wereld. In het begin richtte Team Topologies zich voornamelijk op de opzet en inrichting van teams binnen een organisatie om deze complexiteit te kunnen beheersen.

Gaandeweg is Team Topologies verder geëvolueerd naar een meer holistische benadering, waarbij niet alleen gekeken wordt naar de inrichting van teams, maar ook naar de interactie tussen teams en de manier waarop informatie en kennis wordt gedeeld binnen een organisatie. Dit heeft geleid tot meer aandacht voor het belang van een goede architectuur en tooling, die teams in staat stelt om efficiënter en effectiever te werken.

Een andere belangrijke evolutie van Team Topologies is de focus op het beheersen van cognitieve belasting bij teams. Dit is een belangrijk aspect van het werken in complexe omgevingen en kan bijdragen aan het succes van een organisatie.

Ten slotte heeft Team Topologies ook aandacht besteed aan de evolutie van organisaties zelf, van traditionele hiërarchische structuren naar meer platte en wendbare organisaties.

Dit heeft geleid tot aanbevelingen voor het opzetten van teams die meer autonomie hebben en meer beslissingsbevoegdheid, maar ook meer verantwoordelijkheid dragen voor het realiseren van bedrijfsdoelen.

Kortom, de evolutie van Team Topologies heeft geleid tot een meer holistische benadering van het werken in complexe technologische omgevingen, waarbij niet alleen gekeken wordt naar de inrichting van teams, maar ook naar de interactie tussen teams, de architectuur en tooling, en het beheersen van cognitieve belasting bij teams. En deze evolutie is een mooi voorbeeld van Agile werken.

There is no single ‘right’ team topology, but several ‘bad’ topologies for any one organisation.

Matthew Skelton

Het basisidee van Team Topologies

Het basisidee is vrij eenvoudig te verwoorden: richt je op het team en optimaliseer, want high performing teams zijn uiterst effectief. Gebruik daarbij de wet van Conway, hanteer de 4 typologieën, kies de juiste interactiemodus, ontwikkel de topologie door en bekijk de verandering vanuit een (business) organisatie perspectief.

In gewone taal: begin met het team, identificeer de stromen, bepaal het dunst levensvatbare platform, identificeer de mogelijke capaciteitsissues en oefen de teaminteracties.

Onderstaande afbeelding toont de 7 elementen van Team Topologies. Al deze 7 elementen zal je dienen aan te passen of toepassen om belemmeringen om te zetten naar fast flow.

Van belemmeringen naar fast flow

In dit artikel worden niet alle onderdelen uitgebreid beschreven. Van de 7 onderdelen ligt de focus in dit artikel op typologieën, interactiemodi en gedrag. Elke stap zal nu wel kort belicht worden. Zie onderstaande afbeelding.

Deze 7 elementen zijn belangrijk zijn, maar het vereist een separaat artikel om alle mogelijke varianten uit te leggen. Het is m.i. interessanter om het concept te verdiepen vanuit (type) teams, gedrag en interactiemodi. We beginnen met Cognitieve belasting.

Cognitive Load

Team Topologies besteedt veel aandacht aan het beheersen van de cognitieve belasting bij teams. Cognitieve belasting verwijst naar de mentale inspanning die nodig is om een bepaalde taak uit te voeren en kan worden beïnvloed door factoren zoals de complexiteit van de taak, de beschikbare informatie en de ervaring van de persoon.

De mentale inspanning kan worden beschreven als: intrinsic en extraneous en germane cognitive load. In het artikel Wat is de Cognitive load theorie? lees je hier alles over, hieronder zijn de effecten voor Team Topologies beschreven.

Skelton en Pais stellen dat teams die te veel cognitieve belasting ervaren, minder effectief zijn in het leveren van waarde en vaak minder tevreden zijn met hun werk. Daarom raden ze aan om teams te structureren op basis van de complexiteit van het werk dat ze doen en om de cognitieve belasting te beheersen door onder andere:

• Het beperken van de omvang en reikwijdte van elk team, zodat elk team zich kan concentreren op een specifieke set taken en verantwoordelijkheden.
• Het hebben van een duidelijke en gedeelde visie en doelstellingen voor elk team, zodat alle leden weten wat er van hen wordt verwacht en hoe hun werk bijdraagt aan de organisatiedoelen.
• Het verminderen van de hoeveelheid onzekerheid en complexiteit die elk team moet beheren, bijvoorbeeld door het gebruik van een duidelijke architectuur en tooling.
• Het zorgen voor de juiste mate van autonomie en besluitvorming voor elk team, zodat ze de verantwoordelijkheid en vrijheid hebben om hun werk op de meest effectieve manier uit te voeren.
• Het hebben van duidelijke communicatielijnen tussen teams, zodat iedereen weet wie verantwoordelijk is voor welke taak en er niet te veel overlap is.

Door deze aanbevelingen te volgen, kunnen teams hun cognitieve belasting beheersen en effectiever en efficiënter werken.

4 Team Topologies

Team Topologies identificeert vier hoofd teamtypes die organisaties kunnen gebruiken om hun softwarelevering te verbeteren: Stream-aligned teams, Enabling teams, Complicated-subsystem team en Platform-teams.

Elk van deze teamtypes heeft zijn eigen doel en verantwoordelijkheden en is ontworpen om een specifieke bijdrage te leveren aan de softwarelevering in de organisatie. Door de juiste mix van teams te gebruiken, kunnen organisaties sneller en efficiënter software leveren die aan de behoeften van de klant voldoet.

Je zult meerdere beschrijvingen op internet tegenkomen m.b.t. deze type teams.

1. Stream-aligned teams

Stream-aligned team: afgestemd op een werkstroom van (meestal) een segment van het bedrijfsdomein

Dit type team is verantwoordelijk voor het leveren van functies en services met betrekking tot een bepaalde werkstroom of product. Ze hebben end-to-end eigendom van de software die ze leveren en zijn verantwoordelijk voor het handhaven van de kwaliteit van de code.

Stream-aligned teams zijn teams die verantwoordelijk zijn voor het leveren van software aan een specifieke klant, gebruikersgroep of productlijn. Deze teams zijn gericht op het leveren van waarde aan de klant door het continu leveren van kleine hoeveelheden software die functioneel zijn en voldoen aan de vereisten van de klant. Deze teams zijn ook verantwoordelijk voor het ontwikkelen en onderhouden van technische expertise en best practices voor hun specifieke gebied.

2. Enabling teams

Enabling team: helpt een Stream-aligned team om obstakels te overwinnen. Detecteert ook ontbrekende mogelijkheden.

Dit type team is verantwoordelijk voor het leveren van ondersteuning en tools aan stream-gerichte teams. Ze helpen om standaardisatie te creëren en herbruikbare oplossingen te ontwikkelen.

Enabling teams zijn teams die ondersteuning bieden aan Stream-aligned teams en andere teams in de organisatie. Deze teams zorgen voor een goede werking van de ontwikkelingsprocessen en de infrastructuur, en bieden ook ondersteuning op het gebied van compliance, beveiliging en kwaliteit. Enabling teams helpen bij het ontwerpen van processen en tools die nodig zijn om softwarelevering te versnellen en kwaliteit te waarborgen.

3. Complicated subsystem teams

Gecompliceerd subsysteemteam: waar aanzienlijke wiskunde/berekening/technische expertise nodig is.

Dit type team richt zich op het aanpakken van complexe technische uitdagingen. Ze werken aan problemen die te groot zijn om door een enkel stream-gericht team te worden opgelost.

Complicated Subsystem teams zijn teams die zich richten op het oplossen van complexe problemen die niet kunnen worden opgelost door Stream-aligned teams. Deze teams hebben een hoge mate van autonomie en zijn verantwoordelijk voor het ontwikkelen van nieuwe technologieën en best practices die nodig zijn om de organisatie te helpen innoveren en concurrerend te blijven. Complicated Subsystem teams zijn vaak multidisciplinair en werken samen met andere teams in de organisatie om hun doelen te bereiken.

4. Platform-teams

Platformteam: een groep andere teamtypen die een overtuigend intern product bieden om de levering door Stream-aligned teams te versnellen.

Dit team richt zich op het ontwikkelen en onderhouden van platforms en infrastructuur. Ze bieden de basis voor andere teams om op te bouwen en te leveren.

Platform-teams zijn teams die verantwoordelijk zijn voor het ontwikkelen en onderhouden van de technologieplatforms die door andere teams in de organisatie worden gebruikt. Deze teams zorgen voor een gestandaardiseerde en geautomatiseerde manier van werken en zorgen ervoor dat andere teams efficiënter kunnen werken door het delen van infrastructuur en best practices. Platform-teams zijn verantwoordelijk voor het leveren van een stabiele en veilige omgeving die andere teams kunnen gebruiken om software te bouwen, testen en implementeren.

Interessant is om dan verder te gaan kijken hoe de teams interacteren. Zoals beschreven zijn daar 3 vormen voor: faciliteren, X-as-a-Service en samenwerken. In de afbeelding is dit al samengevat, maar hoe krijg je dat nu goed op elkaar ingespeeld?

Samenwerking tussen de verschillende type teams

In “Team Topologies” wordt benadrukt dat de samenwerking tussen teams van cruciaal belang is om succesvolle softwarelevering te realiseren. Elk teamtype heeft zijn eigen verantwoordelijkheden en taken, maar ze werken allemaal samen om software te leveren die aan de behoeften van de klant voldoet. In bovenstaande afbeelding worden de geadviseerde vormen van samenwerking getoond, maar teams hebben vaak meerdere samenwerkingen, deze worden hieronder beschreven.

1. Stream-aligned teams

Stream-aligned teams zijn gericht op het leveren van software aan een specifieke klant of productlijn. Ze werken samen met andere teams om de benodigde infrastructuur en ondersteunende systemen te bouwen en te onderhouden. Ze hebben ook nauwe banden met Enabling teams om ervoor te zorgen dat hun processen, tools en technologieën goed werken. Complicated Subsystem teams kunnen soms worden ingezet om Stream-aligned teams te ondersteunen bij het oplossen van complexe technische uitdagingen.

2. Enabling teams

Enabling teams zijn gericht op het ondersteunen van andere teams in de organisatie. Ze werken samen met Stream-aligned teams om hen te helpen efficiënter te werken en betere software te leveren. Ze werken ook samen met Complicated Subsystem teams om te helpen bij het ontwikkelen en implementeren van nieuwe processen, tools en technologieën.

3. Complicated subsystem teams

Complicated subsystem teams werken vaak aan strategische projecten en nemen deel aan innovatieprogramma’s om de organisatie te helpen concurrerend te blijven. Ze hebben vaak nauwe banden met Platform-teams om ervoor te zorgen dat hun innovaties kunnen worden geïntegreerd in de bredere systemen en architectuur van de organisatie.

4. Platform-teams

Platform-teams zijn gericht op het leveren van een stabiele en veilige technologische basis voor de hele organisatie. Ze werken nauw samen met andere teams om te zorgen dat hun infrastructuur en tools goed werken en efficiënt worden gebruikt. Ze kunnen ook werken aan strategische projecten die gericht zijn op het verbeteren van de technologische basis van de organisatie.

‘Evolve different team topologies for different parts of the organisation at different times to match the team purpose and context. ‘

Matthew Skelton

De onderlinge verhoudingen tussen teams zijn afhankelijk van de specifieke organisatie en haar behoeften. “Team Topologies” benadrukt echter het belang van een duidelijke taakverdeling tussen teams en een duidelijke communicatie om ervoor te zorgen dat iedereen op één lijn zit. Het is ook belangrijk dat teams samenwerken aan gedeelde doelen en dat ze open staan voor feedback en verbetering.

Verschillen en overeenkomsten in gedrag per team

Als we naar de verschillende teams vanuit een gedragskant bekijken, kunnen we enkele overeenkomsten en verschillen identificeren.

Overeenkomsten

• Een belangrijke overeenkomst tussen de teams is dat ze allemaal gericht zijn op het leveren van waarde aan de klant. Elk teamtype heeft zijn eigen verantwoordelijkheden en taken, maar ze werken allemaal samen om software te leveren die aan de behoeften van de klant voldoet. Dit betekent dat alle teams een sterke focus hebben op klantgerichtheid en het leveren van waarde.
• Een ander gemeenschappelijk gedrag van deze teams is hun focus op samenwerking. Elk teamtype werkt samen met andere teams in de organisatie om hun doelen te bereiken. Dit betekent dat effectieve communicatie en samenwerking essentieel zijn om de doelen van de organisatie te bereiken.

Verschillen

Er zijn echter ook enkele verschillen tussen de teams vanuit een gedragskant.

• Stream-aligned teams zijn bijvoorbeeld gericht op het leveren van software aan een specifieke klant of productlijn, waardoor ze een zeer klantgerichte focus hebben.
• Enabling teams daarentegen zijn gericht op het ondersteunen van andere teams in de organisatie, wat betekent dat ze een sterk focus hebben op samenwerking en ondersteuning.
• Complicated subsystem teams hebben vaak een sterke focus op innovatie en het ontwikkelen van nieuwe technologieën en processen. Dit betekent dat ze vaak een meer risicovolle benadering hebben en bereid zijn om nieuwe ideeën uit te proberen.
• Platform-teams hebben ten slotte een sterke focus op stabiliteit en veiligheid. Ze zorgen ervoor dat de technologische basis van de organisatie stabiel is en efficiënt wordt gebruikt. Dit betekent dat ze vaak meer nadruk leggen op controle en veiligheid dan andere teams.

Kortom, terwijl alle teams in “Team Topologies” zich richten op het leveren van waarde aan de klant en samenwerking tussen teams, hebben ze elk hun eigen unieke kenmerken en gedragingen die hen onderscheiden van andere teams in de organisatie.

Effectief samenwerken? Vier interactiemodi!

In “Team Topologies” worden drie interactiemodi beschreven die teams kunnen gebruiken om effectief samen te werken. Hier zijn de drie interactiemodi:

1. Collaboration- samenwerken

Dit is een interactiemodus waarbij teamleden actief samenwerken om gemeenschappelijke doelen te bereiken. Dit omvat co-creatie, coördinatie en communicatie. Teamleden zijn actief betrokken bij elkaars werkzaamheden en werken samen om betere resultaten te behalen. Deze interactiemodus kan effectief zijn voor Development Teams en Platform Teams die samenwerken aan de ontwikkeling en implementatie van softwareoplossingen.

2. X-as-a-Service

Dit is een interactiemodus waarbij teams hun diensten aanbieden als een product aan andere teams binnen het bedrijf. Het omvat interne dienstverlening en self-service. Teams die diensten aanbieden, zorgen voor gestandaardiseerde interfaces en documentatie om andere teams in staat te stellen hun eigen werkzaamheden uit te voeren.

Deze interactiemodus kan effectief zijn voor Platform Teams die services aanbieden aan Development Teams en andere teams binnen het bedrijf.

3. Facilitation – faciliteren

Dit is een interactiemodus waarbij een team of individu verantwoordelijk is voor het faciliteren van de samenwerking tussen andere teams. Dit omvat ook coaching en mentoring. Het faciliterende team werkt als een brug tussen verschillende teams en zorgt ervoor dat de samenwerking soepel verloopt. Deze interactiemodus kan effectief zijn voor een team dat verantwoordelijk is voor de architectuur van een systeem en die andere teams helpt bij het begrijpen van de architectuur en bij het nemen van technische beslissingen.

In “Team Topologies” wordt benadrukt dat het belangrijk is om de juiste interactiemodi te kiezen op basis van de context en de doelstellingen van het project en dat teams flexibel moeten zijn om van interactiemodus te veranderen als dat nodig is. Dat betekent o.a. open staan voor nieuwe ideeën en om regelmatig feedback te geven en te ontvangen om de samenwerking tussen teams te verbeteren.

Team Topologies, agile en DevOps

Interessant is wellicht de vraag hoe Team Topologies zich verhoudt tot andere agile en DevOps-methoden.

Team Topologies richt zich op het ontwerpen van teams en hoe deze teams effectief kunnen samenwerken om software op een snelle en betrouwbare manier te leveren. Andere agile methoden, zoals Scrum en Kanban, leggen de nadruk op het plannen, monitoren en beheren van werk om de productiviteit en kwaliteit te verbeteren.

DevOps is een bredere filosofie en cultuur die gericht is op het integreren van de ontwikkeling, het testen en het inzetten van software om de time-to-market te versnellen en de kwaliteit van de software te verbeteren. Team Topologies past binnen DevOps omdat het zich richt op het ontwerpen van teams die samenwerken om deze doelen te bereiken.

In de praktijk worden deze methoden vaak gecombineerd en aangepast om te voldoen aan de specifieke behoeften van een organisatie. Het belangrijkste is om te begrijpen wat elk van deze methoden te bieden heeft en hoe ze kunnen worden toegepast om de effectiviteit en efficiëntie van softwareontwikkeling te verbeteren

Impact op organisatie

Team Topologies kan een aanzienlijke impact hebben op de cultuur en structuur van een organisatie, vooral als de implementatie ervan leidt tot veranderingen in de manier waarop teams samenwerken en communiceren.

Een van de belangrijkste voordelen van Team Topologies is dat het kan leiden tot meer focus en duidelijkheid binnen teams. Door het definiëren van duidelijke verantwoordelijkheden en communicatiekanalen kunnen teams zich beter concentreren op hun werk en betere resultaten behalen.

Daarnaast kan Team Topologies ook helpen bij het stimuleren van innovatie binnen organisaties. Door het creëren van meer flexibele teams en het aanmoedigen van samenwerking en uitwisseling van kennis en ideeën, kunnen organisaties nieuwe oplossingen en manieren van werken ontdekken.

Aan de andere kant kan de implementatie van Team Topologies ook weerstand oproepen bij medewerkers die zich comfortabel voelen met de huidige manier van werken. Het kan ook tijd en middelen kosten om de nieuwe teams en structuren op te zetten en in te bedden in de organisatie.

Tot slot

In Team Topologies wordt benadrukt dat het belangrijk is om niet alleen te focussen op één enkele methodologie of model, maar om verschillende methodologieën en modellen te combineren om de beste resultaten te behalen. Team Topologies benadrukt het belang van flexibiliteit en aanpassingsvermogen bij het organiseren en werken van teams.

Team Topologies die op zichzelf staat zal geen effectieve software systemen laten ontstaan. Want daarnaast is er ook nodig: een ondernemende can-do cultuur, goede engineering, gezonde financiële modellen en een duidelijke visie op de business.

Soms onderschat men het belang van de business insteek, maar veiliger en snellere verandering van software systemen is een vorm van Business Agility. En zoals je weet is Business Agility het vermogen om snel (in een paar uur) te reageren op veranderde interne en externe condities.

In een VUCA wereld is het belangrijk om het operating model te optimaliseren voor een ‘fast flow of value’. Dit doe je door jezelf te organiseren rondom een ‘loosely coupled value streams’. Teams dienen zich te focussen op gebruikersbehoeften en UX EN de omgeving waar te nemen om snel de koers te kunnen veranderen.

Want dat is Team Topologies op een hoger abstractie niveau: fast flow, snelle feedback, team interactie, evolutie van de organisatie, team cognitive load en omgaan met de huidige belemmeringen in de organisatie.

Het bericht Wat is Team Topologies? verscheen eerst op agile4all.

DevOps is een methodologie en framework die door gestructureerd samenwerken, van IT-ontwikkeling en operatie, meerwaarde voor de klant brengt.

De term DevOps een combinatie van twee woorden: Development en Operations. Van DevOps zijn veel verschillende beschrijvingen, waarbij de meeste varianten beschrijven dat DevOps staat voor bedrijfsinnovatie en continue verbeteren van processen. Uit alle varianten zijn drie verschillende en elkaar aanvullende beschrijvingen gekozen.

Volgens Wikipedia is DevOps een gebruik en een praktijk binnen softwareontwikkeling die tot doel heeft softwareontwikkeling (Dev) en softwareoperaties (Ops) samen te voegen.

Een andere willekeurig gekozen beschrijving werkt deze verder uit: DevOps is een reeks software ontwikkelingspraktijken die softwareontwikkeling (Dev) en IT-operaties (Ops) combineert om de levenscyclus van systeemontwikkeling te verkorten en tegelijkertijd frequent functies, fixes en updates te leveren in nauwe afstemming met bedrijfsdoelstellingen.

Zoals je hebt kunnen lezen zou de voorgaande benadering als ‘vrij technisch’ gezien kunnen worden. Begrijpelijk, want DevOps is ontstaan in de IT wereld. Voor de derde beschrijving is gekozen voor een meer agile benadering van DevOps. Dan is het verstandig om DASA te citeren:

Voor ons, is DevOps niet een ding. Het is geen product, standaard, specificatie, raamwerk of functietitel. DevOps gaat over ervaringen, ideeën en cultuur om goed presterende IT-organisaties te creëren.

Devops Agile Skill Association

Met deze drie benaderingen heb je een goede eerste indruk van wat DevOps is. In dit artikel is zal worden getracht om het uitgebreide DevOps jargon te beperken, zodat ook non IT-ers de filosofie en het framework kunnen begrijpen.

Waarom DevOPs?

In de overload aan beschikbare technische informatie is het noodzaak om de hoogste prioriteit van DevOps te kennen: sneller aan de behoefte van de klant te kunnen voldoen, met name door de doorlooptijd van veranderingen te verkorten!

De 3 hoofdredenen waarom Devops tot stand is gekomen:

• De organisatie verlangt snellere en continue levering voor de klant.
• Traditionele IT-opleveringen zijn uiterst moeizaam.
• Ogenschijnlijke tegenstrijdigheden leveren problemen op. Men doelt dan op een wens van snelle ontwikkeling versus de stabiliteit van een IT omgeving. Dev versus Ops.

Interessant is dat het probleem tussen ontwikkeling (Dev) en operatie (OPS)is beschreven als:

‘the wall of confusion’.

Een mooie bewoording van een situatie die je ook in andere omgevingen waarneemt. Wat neem je dan bijvoorbeeld waar: silo’s, verschillende gereedschappen, mindset, omgevingen, processen die niet lopen, matige feedback tot en met de ‘blame game’.

The wall of confusion resulteert in een neerwaartse spiraal. Iedereen krijgt het drukker, alles kost meer tijd, communicatie gaat trager en het werk vertraagd uiteindelijk. Dat vraagt weer om meer communicatie, coördinatie, toestemmingen. Kortom gekibbel over vrijwel alles, waarbij de oplevering steeds trager wordt.

De oplossing om de muur tussen Dev en Ops omlaag te halen is: het creëren van kleine teams die onafhankelijk hun features kunnen valideren in productie achtige omgevingen. Dan kunnen ze hun code snel, veilig en secuur in productie brengen. (bron: The DevOps Handbook, Gene Kim, Jez Humble, Patrick Debois and John Willis.)

Korte introductie DevOps

DevOps is ruim 20 jaar geleden ontstaan om websites met veel traffic overeind te houden. In 2009 vond de eerste presentatie plaats door medewerkers van Flickr. In hetzelfde jaar werd de eerste DevOps dag gehouden in België. Vervolgens werden in de opvolgende jaren frameworks en open source tools ontwikkelt. Deze ontwikkeling zet zich nog steeds voort.

DevOps heeft als primair doel snellere levering van waarde voor de klant. Dat lijkt heel eenvoudig, maar de wens om dit steeds sneller te verrichten, met de juiste kwaliteit, maakt het een complexe aangelegenheid. Want dan is opeens de gehele organisatie betrokken. Denk daarbij aan allerlei eisen zoals beveiliging, administratie, compliance etc.

Het meest herkenbare van DevOps zijn de technische voorbeelden, zoals updates, releases en het toevoegen van functies of foutherstelling (bug fixes) etc. Hoewel dit herkenbare voorbeelden zijn van wat DevOps ook is, is DevOps pas compleet als de filosofie en framework worden toegepast.

DevOps heeft als filosofie om de levenscyclus van de systeemontwikkeling te verkorten en tegelijkertijd regelmatig functies, fixes en updates te leveren volledig in lijn met de bedrijfsdoelstellingen.

Het DevOps framework bestaat uit verschillende fasen, zoals continu ontwikkelen, continu integreren, continu testen, continue implementatie en continue monitoring.

Zowel de filosofie en het framework dienen te worden toegepast om DevOps succesvol te laten zijn.

Huidige ontwikkelingen DevOps

Dat DevOps zich nog steeds ontwikkelt blijkt wel uit de vele varianten die er inmiddels zijn. Voorbeelden hiervan zijn: DevSecOps, DevOps 2.0, GitOps, NoOps en nog veel meer!

Alle varianten zijn gericht op een specifieke toepassing of toevoeging, maar altijd vanuit dezelfde filosofie: een gestructureerd samenbrengen van ontwikkeling en operatie.

De huidige ontwikkeling van DevOps richt zich met name op vergaande automatisering van het ontwikkelproces en op de uitdaging van de toenemende complexiteit. Dit laatste vult men in door zich te (willen) gedragen als een Lean Startup. Lees hiervoor het artikel: Wat is de Lean Startup Methode?

Net als andere agile methodieken is er een sterke focus op het opknippen van grote delen in kleine stukjes en het testen/meten op alle niveaus in de pijplijn en dit proces te automatiseren. Lean programming is een vertrouwd fenomeen binnen IT, maar de wijze waarop deze nu ingericht wordt is beduidend meer agile ingericht.

In DevOps 2.0 heeft men naast technische procesverbeteringen als doel gesteld om de volledige organisatie te betrekken en daarbij de communicatie tussen alle betrokkenen in software ontwikkeling te verbeteren. Het gaat hierbij dus nog steeds om Flow!

Binnen DevOps kun je tegenwoordig naast Product (stream) Teams ook Platform Teams tegenkomen. Het grote verschil tussen deze teams is dat men zich steeds meer richt op het bouwen van een feature door één team, die expert kunnen worden in het toegewezen gebied. Het andere team houdt zich meer bezig met specifieke platform kennis.

Daarmee verlaagd men de hoeveelheid informatie die men nodig heeft om een goed product af te kunnen leveren. Toch blijven de product teams end-of-end verantwoordelijk, platform teams brengen een nieuwe specifieke vaardigheid in en gaan daarna door naar waar hun specifieke vaardigheid nodig is. Men tracht met deze methode een oplossing te vinden om flow te verbeteren.

De uitdaging is cultuur!

Als je voorgaande alinea’s samenvat kun je DevOps in vijf categorieën indelen: een ontwikkelcultuur door automatisering, lean te werken en metrics en informatie te delen, waarbij specifieke DevOps-tools worden ingezet. In het Engels hanteert men hiervoor regelmatig de term CALMS (Culture, Automation, Lean, Metrics en Sharing).

Een andere manier om naar DevOps te kijken is vanuit 3 elementen: mensen, proces en technologie.

Wat je dan waarneemt is dat processen en de bijbehorende technologieën veel aandacht krijgen: ‘Want daar komen de nieuwe mogelijkheden en oplossingen vandaan’. Dat zou zo maar waar kunnen zijn, maar de grootste uitdaging voor organisaties is en blijft cultuur. Nieuwe instrumenten zijn fijn, maar als het leiderschap geen richting geeft, de gewenste agile cultuur niet tot stand komt en de resultaten uitblijven is het snel bergafwaarts, ook met DevOps.

Een mooi uitdagend voorbeeld is scaling. Ook in DevOps is scaling een veel besproken fenomeen, maar welke agile methode je ook hanteert: scaling is en blijft uitdagend. De reden hiervoor is eenvoudig, meer deelnemers staat synoniem aan meer interactie. Echter realiseert men zich veelal niet voldoende dat bij het toevoegen van slechts een paar mensen het aantal contacten exceptioneel toeneemt, lees hiertoe het artikel: Wat is Brooks law?.

Dan blijkt dat je aanvullende technische methoden dient te hanteren, want gedeelde centrale informatie is bij het ontwikkelen van software noodzakelijk. Het bekendste voorbeeld is het tegelijkertijd door meerdere mensen werken aan dezelfde software. Als je dit niet goed regelt heb je voordat je het weet meerdere softwareversies. Een garantie voor versie conflicten en bijbehorende bugs.

DevOps lost dit op door automation van het proces. Het is een noodzaak om iedereen aangesloten en ‘on track’ te houden. Zeker als men ook nog remote werkt. Momenteel is automatisering van het totale proces datgene waar DevOps zich snelst in ontwikkelt.

Uit welke componenten bestaat DevOps?

DevOps bestaat uit 4 herkenbare componenten: principes, concepten, praktijken en mensen. Laten we deze samenhang eens bekijken.

1. Principes

DevOps basisprincipes die je minimaal moet kennen: flow, feedback en continu leren i.c.m. verbeteren.

Van bovenstaande principes is het vooral handig om het begrip flow binnen DevOps te begrijpen. Flow is de snelle stroom van Dev naar Ops naar klant. Een aantal kenmerken zijn: visuele borden, WIP-limits, Slicen (opknippen in kleine stukjes), beperken van handovers, impediments aanpakken en focus op toevoegen van waarde.

Feedback en een lerende organisatie zijn bekende agile principes.

2. Concepten

Aan de principes zijn de concepten verbonden, zoals: product, waardenstroom, los verbonden architectuur en autonome teams.

Denk hierbij aan het concept van een Minimum Viable Product (MVP), maar ook aan thema’s, Epics, features en in de Sprints de User Stories. Geprioritiseerd volgens de waardestroom (value stream en value stream mapping) en passend bij MVP.

3. Praktijken

Dan krijg je de praktijken, zoals Continious Integration, Continious testen, Continious Delivery, Continious Deployment, meten en feedback. Deze worden in de volgende paragraaf beschreven. Zie voor de eerste indruk de onderstaande afbeelding.

4. Mensen

Hoewel in veel literatuur de focus ligt op de technische gereedschappen en/of praktijken, is de mens veelal de doorslaggevende factor. Zie onderstaande afbeelding.

Hiermee beschrijf je eigenlijk ook de cross functionele autonome teams, deze bestaan bijvoorbeeld uit Product Owner, Operations Engineer, Developer, QA/tester, Release Manager en InfoSec.

In dit artikel gaan we nu verder met het uitwerken van de DevOps praktijken. Vanuit een agile perspectief lijken de technische termen wellicht minder interessant, het gaat je mogelijk slechts om de filosofie van DevOps. Toch dien je deze termen wel te kennen, simpelweg om de filosofie van DevOps beter te begrijpen.

DevOps Praktijken

DevOps praktijken gaat over flexibiliteit van ontwikkeling door het automatiseren van verschillende processen, bijvoorbeeld het geautomatiseerd testen van software.

De processtroom (flow) richt zich op de aansturing van de productie waarbij ontwikkeling voortdurend in overleg is met het operationele team. Daar gebruikt men in DevOps meerdere begrippen voor: Continious Integration, Continious Delivery (CD), Continious Feedback, Continious Delivery en Continious Deployment. Deze worden nu achtereenvolgens beschreven.

1. Continious Integration  (CI)

Continue Integratie of CI is een proces waarbij ontwikkelaars hun kleine aangepaste codes kunnen updaten in een centrale plaats (repository) die gedeeld wordt met het hele projectteam. Dit vindt meerdere keren per dag plaats.

Hier wordt de toegevoegde code automatisch getest en gevalideerd. Deze repository helpt om vertragingen te verminderen omdat elk teamlid op elk moment de meest up-to-date en gevalideerde versie van de code kan vinden.

De ultieme toets van het fail-fast principe.

2. Continuous Delivery (CD)

CD is de logische stap na CI. Want deze stap staat voor het automatisch bouwen, testen en verpakken van de wijzigingen in de code die bij CI hebben plaatsgevonden.

Zojuist las je het woord ‘automatisch’, jazeker dat is ook hier het sleutelwoord, net als bij CI wordt het leveringsproces grotendeels geautomatiseerd. Het doel is vanzelfsprekend snellere en betere releases. 

3. Continuous Feedback

Met continuous feedback vat men het hele proces van het opsporen van fouten in het systeem samen. Hier bedoelt men ook de tools die het operationele team hanteert om (real time) het ontwikkelingsteam te informeren. Dit proces verhoogd de betrouwbaarheid van de software. 

4. Continuous Deployment

Dit is de meest verwarrende beschrijving in de terminologie. Zowel vanuit een Nederlandse vertaling, alsook in het Engels. In het Nederlands betekent dit Continue Implementatie, maar dat is verwarrend omdat je dit zou kunnen afkorten naar CI. In het Engels is het ook niet echt handig geregeld, want CD staat al voor Continuous Delivery!

Het belangrijkste verschil met Continuous Delivery is dat bij Continuous Deployment een proces plaatsvindt, waarbij geen menselijke tussenkomst vereist is. Dit doen tools die, na automatisch testen, de code vrijgeven zodra het de verandering in de code detecteert.

Wat je waarneemt is dat beide begrippen door en naast elkaar gehanteerd worden. Ook zie je vaker een combinatie tot stand komen, waarbij ze beiden in dezelfde zin worden genoemd. Mede veroorzaakt door de verdere automatisering, waardoor er in meerdere stappen van het proces geen menselijke tussenkomst meer is.

Continuous Deployment versnelt de feedbackloop. Wist je overigens dat je daardoor ook geen release data meer hoeft te plannen?

Controle

Ben je met voornoemde 4 DevOps praktijken er dan? Nou eigenlijk niet, want dan komt ‘controle’ om de hoek kijken. Dit is echter niet het vijfde component, want controle is geïntegreerd in de vier praktijken. Controle staat voor verandermanagement, informatie beveiliging en taak/functie scheiding.

Bij verandermanagement kan je dan denken aan pair programming, TDD, of peer review. Voor beveiliging kan je dan denken aan het integreren van veiligheid in elke functie als dagelijkse routine, maar ook controles op de repository, in de pijplijn, in de omgeving etc.

Bij taak/functie scheiding dien je vooral te denken aan moderne vormen, want traditionele vormen remmen af. Je kunt bijvoorbeeld voor controle: inspectie, code check-ins, code review en pair programming inzetten.

DevOps Cycle

Als je bovenstaande combineert met meten en feedback, soepelere, continue communicatie, samenwerking, integratie, zichtbaarheid en transparantie. Dan heb je DevOps-cyclus!

Bovenstaande afbeelding toont de initiële softwareplanning tot de code-, build-, test- en releasefasen en tot en met de implementatie, activiteiten en continue monitoring.

Het oneindig symbool staat symbool voor continue terugkoppeling naar klanten voor verdere verbetering, ontwikkeling, testen en implementatie.

Het doel blijft natuurlijk dat oneindig vernieuwingen, wijzigingen of toevoegingen sneller en op continu basis te laten plaatsvinden.

Voor het bovenstaande geldt dat de 6 DevOps principes gehanteerd worden.

Zes DevOps principes

De Devops Agile Skill Assocation (DASA) hanteert 6 principes van DevOps. In onderstaande afbeelding zijn deze beschreven.

Van bovenstaande principes behoeft met name de zesde ‘automatiseer’ een korte aanvullende toelichting. De reden hiervoor is dat met name dit hier momenteel de grootste technologische ontwikkeling plaatsvindt.

Hoewel het wat technisch klinkt is men hier bezig met ‘cloudplatforms die op containers gebaseerd zijn’, waardoor ‘infrastuctuur als code’ gezien kan worden. Want dat geeft teams een vergaande flexibiliteit.

‘Infrastructuur als code’ kom je in veel artikelen tegen. Het is dus handig om te weten waar men mee bezig is, maar op de inhoud hiervan gaan we in dit artikel niet verder in.

Samenvatting

Zoals beloofd zou dit artikel niet al te technisch worden. Een mooie manier om DevOps als filosofie op een agile manier samen te vatten is om het acroniem CALMS te hanteren.

Cultuur: bestaande uit de huidige waarden, overtuigingen en houdingen. Die de bedrijfsomgeving rondom en ter ondersteuning van ontwikkeling, operaties en kwaliteit aanduiden.

DevOps: focus op mensen en omarm verandering en het experimenteren.

Automatisering: alles kan effectief kan worden geautomatiseerd om processen te verbeteren en fouten te verminderen.

DevOps: Continious Delivery en ‘infrastucture as code’

Lean: Dit staat synoniem voor het reduceren van verspilling. Met als doel de waarde voor de klant te maximaliseren. Voorbeelden hiervan zijn teamgrootte, vergaderfrequentie en aantal tools.

DevOps: focus op het produceren van waarde voor de eindgebruiker en hanteer kleine batch grootte.

Meten: Dit verwijst naar het meten van alles. Daarvoor dien je te zorgen voor ingebouwde mechanismen om zichtbaarheid te bieden. Dit betreft dan alle systemen en gebeurtenissen. Veelal hanteert men een dashboard.

DevOps: meet alles en toon de verbetering

Delen (sharing): goede communicatie tussen ontwikkeling en operations, voor een effectieve integratie.

DevOps: open informatie delen, samenwerken en communicatie

CALMS is bedacht door Willis en Edwards en dit is later verder beschreven door Humble, zij wilden de filosofie van DevOps beschrijven.

DevOps is dus een filosofie als een framework, de meeste aandacht gaat veelal uit naar de tools. Want door goed gereedschap kan men sneller bouwen, maar cultuur bepalend is voor het uiteindelijke succes.

In later te verschijnen artikelen zullen de diverse DevOps componenten uitgebreid worden beschreven.

Het bericht Wat is DevOps? Een filosofie en framework! verscheen eerst op agile4all.

Natural Language Processing (NLP) is de technologie die wordt gebruikt om computers te helpen de natuurlijke taal van de mens te begrijpen.

De vertaling in Nederlands is: computationele taalkunde of computerlinguïstiek, alleen gebruikt vrijwel niemand deze vertalingen. Overigens wordt Natural Language Processing ook niet zo vaak gebruikt. Zodra men het woord ‘chatbox’ gebruikt, begrijpt opeens iedereen waar het overgaat. NLP is echter veel meer dan een chatbox.  

De meeste artikelen op deze site gaan over agile werken, dit artikel zou dus ook over het andere NLP (Neuro Linguïstisch Programmeren) kunnen gaan. Dit artikel gaat echter over verandering, want NLP is een mooi voorbeeld van grote veranderingen door technologische ontwikkelingen.

Dit artikel is voor velen nog ‘nice to know’, maar afhankelijk van je omgeving al ‘need to know’. Of je techniek nu interessant vindt of niet, voor agile werkenden is het noodzakelijk om veranderingen te herkennen om tijdig te kunnen handelen! In dit artikel zal zoveel mogelijk getracht worden om technisch taalgebruik te vermijden.

Want een ding is inmiddels al duidelijk: het begrijpen van de menselijke taal is niet meer alleen voorbehouden aan de mens.

NLP en Artificial Intelligence

Natural Language Processing is een van de takken van sport in Artificial Intelligence (kunstmatige intelligentiesystemen). NLP houdt zich bezig met de interactie tussen computers en mensen met behulp van mensentaal.

Het doel van NLP is het lezen, ontcijferen, begrijpen en zinnig maken van menselijke taal. Dat dit doel waarde dient te hebben is vanzelfsprekend, dat deze stap gerealiseerd gaat worden ook.

De basisgedachte van NLP is heel simpel. Machinaal leren wordt ingezet om de menselijke talen te leren.

Hoe werkt Natural Language Processing?

Daarvoor past men in de programmering van NLP algoritmes, artificial intelligence en deep learning toe. NLP is een toepassing om ongestructureerde gegevens om te kunnen zetten naar een vorm die een machine begrijpt.

De meeste mensen denken dat NLP m.b.v. statistische methodes werkt, maar statistische methoden bleken te beperkt. In de afgelopen 10 jaar is NLP van statische methodes overgestapt naar neurale netwerken voor machinaal leren. De snelheid waarin dit zich verder ontwikkelt is zeer hoog te noemen.

Het makkelijkste om dit eenvoudig uit te leggen is dat je door het toevoegen van een natuurlijke taalregel een machine deze kan toepassen. Dit is echter niet voldoende, slechts door ontelbare keren te vertalen en een menselijke correctie te ontvangen kan een machine leren. Door te leren, verbetert de machine zich constant. Daardoor is een machine uiteindelijk in staat om de betekenis van een zin te ‘begrijpen’  en de benodigde gegevens er uit te halen.

Straks volgen 9 toepassingen van Natural Language Processing, maar nu eerst een voorbeeld hoe jij helpt om NLP te verbeteren. Wanneer je iets laat vertalen door een machine krijg je soms een verrassende vertaling aangeboden, maar jij begrijpt al snel wanneer de vertaling niet helemaal klopt en gaat op zoek naar alternatieve begrippen in de aangeboden woordenlijst. Door deze woorden aan te klikken, krijg jezelf een betere vertaling en leert de machine. Na ontelbare keren zal de machine steeds betere vertalingen leveren.

Je kunt stellen dat er turbulente ontwikkelingen zijn in AI en NLP. Het lijkt er immers op dat machines de stap naar de taal goed leren te begrijpen maken, begrijpen straks taal net als wij dat doen. Hoe werkt dat nu in grote lijnen?

De stappen in de interactie

Het proces van NLP is vrij eenvoudig te beschrijven. Het is immers een interactieproces, met als verschil dat één van beide partijen een machine is. Simplistisch beschouwt zijn er 6 stappen: 

• Een mens ‘praat of schrijft’ met een machine.
• De machine vangt de audio of tekst op.
• Conversie (van audio) naar ‘taal’ vindt plaats.
• Verwerking van de gegevens naar context.
• Omzetting van context naar een antwoord via audio of tekst.
• De machine reageert door het teruggeven van een tekst of door audio.

Dit is gemakkelijk om te realiseren als er altijd exact dezelfde vraag wordt gesteld. Maar mensen zijn niet zo gemakkelijk te begrijpen. We kennen meerdere talen, elke taal kent meerdere niveaus, bijv. hoog of laag, abstract of niet abstract, emotioneel en/of hanteren allerlei taalvormen (bijvoorbeeld sarcasme). Derhalve hanteert NLP een scala aan technieken, deze zijn echter terug te brengen naar 2 hoofdcategorieën.

De technieken van Natural Language Processing

De hoofdcategorieën van NLP bestaan uit syntactische en semantische analyse. Syntax gaat over de rangschikking van woorden in een zin. Semantiek gaat over de betekenis die overgebracht wordt.

• Voor syntax hanteert men grammaticale regels. Het toepassen van regels past goed bij machinetaal, dus is men hier al heel ver mee.
• Semantiek is de uitdaging die nu voor ligt. Met computeralgoritmes probeert men de betekenis van woorden om zinnen te begrijpen.

Binnen NLP is er een hele wereld aan begrippen ontstaan. Die elk een deel van taal proberen te tackelen.

Omdat beloofd is om in dit artikel niet met complexe termen te komen, volgen nu slechts een aantal voorbeelden van technieken die onder de hoofdindeling passen: speech recognition, grammatical tagging, named entity recognition en parsing.

Een goede eigenschap is dat men nieuwsgierig en onderzoekend is, deze AC beleefd veel plezier aan het met dit soort onderwerpen bezig te zijn. Derhalve is vorig jaar o.a. de techniek van Watson Assistent van IBM verkend, een chatbot voor klantenservice in AI omgevingen.

Wat is op dit moment de NLP uitdaging?

De uitdaging is semantiek, want deze ligt in de combinatie van de gebruikte woorden, de verbinding van deze woorden en de beoogde boodschap.

Feitelijk zijn natuurlijke talen niet eenduidig. We gebruiken dubbelzinnigheden, taalregels die weinigen begrijpen, allerlei uitzonderingen op de taalregels, variaties in zinsbouw en daar komen de verschillende betekenissen per woord(combinatie) nog overheen.

Mensen vangen al een deel van de taal op in de moederschoot en hebben daarna jaren nodig om zelfs in hun moedertaal op hoog niveau te kunnen communiceren. Mensen kunnen vrij goed een tweede of derde taal daarnaast beheersen. Zou jij het handig vinden als tijdens een gesprek met een anderstalige taal direct een vertaling zou plaatsvinden?

Machines gebruikten, tot voor kort, programmeertaal. De mens moest in precieze taal communiceren met de machine. Een natuurlijke taal bestaat echter ook uit dubbelzinnigheid en onnauwkeurigheid en dit maakt het uitdagend voor machines om een natuurlijke taal te leren. 

NLP ontleedt menselijke tekst en spraak op diverse manieren. NLP is eigenlijk een complexe combinatie van computerwetenschap, kunstmatige intelligentie en computationele linguïstiek.

Binnen NLP is er een hele wereld aan begrippen ontstaan. Die elk een apart deel van taal proberen te tackelen. Omdat beloofd is om in dit artikel het niet te complex te beschrijven, volgen nu slechts een aantal technieken, zonder verdere toelichting: speech recognition, grammatical tagging, named entity recognition en parsing.

Wellicht is het handiger om je voorbeelden van toepassingen aan te reiken.

9 toepassingen van Natural Language Processing

Welke toepassingen zijn er en wat merk je er vandaag al van? De huidige status van NLP ervaar je elke dag. Wellicht heb je niet zo vaak door dat NLP al volop wordt ingezet. Laten we direct starten met de persoonlijke assistenten: Siri, Ok Google of Alexa, maar laten we ook de andere mogelijkheden noemen.

1. Taalcontrole

Hoe vaak laat jij je teksten controleren? Vermoedelijk staat je autocontrole standaard aan. Het detecteren en corrigeren van spelfouten vinden we al heel gewoon.

2. Automatisch vertalen

We gebruiken allemaal de diverse automatische vertaalmachines. Denk maar aan Google Translate of Deepl. Deze vertalingen worden in rap tempo beter. Als je twijfelt of een vertaling juist is, dan is de volgende tip wellicht handig. Laat de vertaalde tekst eens ‘terugvertalen’, gebruik daar eventueel een andere vertaalmachine voor.

Vertaalmachines worden steeds nauwkeuriger en steeds meer talen kunnen vertaald worden. Zelfs dialecten worden al meegenomen.

Interessant is dat Google recentelijk heeft aangegeven om ook talen die aan het verdwijnen zijn te vast willen vastleggen. Taal is immers een onderdeel van de cultuur en elke taal bevat verhalen en inzichten die in overlevering worden doorgegeven.

Het is jammer dat talen verloren gaan, maar een mooi voorbeeld hiervan is Latijns. Eigenlijk ‘een dode taal’, want deze wordt niet meer gesproken, maar nog wel steeds gebruikt. Als men een taal uit het verleden kent heeft men beter begrip van die periode in de geschiedenis.

3. Spam

Je staat er vermoedelijk niet bij stil dat als je spamberichten ontvangt, een NLP algoritme deze spam helaas nog niet heeft kunnen tegenhouden.

Want wist je al dat de betere spamfilters detectietechnologieën van NLP gebruiken om e-mails te scannen op taal die vaak wijst op spam of phishing? Men controleert dan o.a. op slechte grammatica, onlogische urgentie, bedrijfsnamen die niet juist zijn gespeld of bepaald taalgebruik.

Spam is echter een kat en muis spel geworden tussen aanvallers en verdedigers. Spam zal dus blijven binnenkomen, maar NLP-deskundigen beschouwen spam als zijnde opgelost binnen NLP. Daar mag je het best mee oneens zijn, maar zij stellen dat ook voor spam de NLP algoritmes steeds beter zullen worden.

4. Chatbots

Chatbots zie je eigenlijk al continue op allerlei websites. Zij gaan uit van getypte tekst in een passend vakje. Maar wist je al dat een aantal chatbots al context (semantiek) gebruiken om tot een beter resultaat te komen? Door het gebruiken van deep learning zijn sommige al zover, dat jij kunt worden verrast door de relevantie van het gegeven antwoord. De antwoorden maken al gebruik van ‘eigen’ taal.

5. Samenvatten van teksten

Er komt steeds meer digitale tekst beschikbaar, al deze tekst kan worden verwerkt. Bijvoorbeeld om samenvattingen, indexaties en databases te maken. Hetzelfde geldt natuurlijk voor beeldmateriaal.

Wat NLP en AI trachten te bereiken is het bieden van relevantie. Want daardoor kunnen mensen veel tijd besparen. Ze hoeven niet alles meer te lezen of bekijken, voordat ze vinden wat ze nodig hebben.

Maar wist je al dat NLP ook al wordt ingezet om geautomatiseerd context toe te voegen en conclusies te trekken?

6. Text to speech

Een tekst kan getransformeerd worden naar gesproken taal. Dit helpt o.a. visueel gehandicapten.

7. Virtuele assistenten

Het tegenovergestelde van text to speech is spraakherkenning. De bekendste virtuele assistenten zijn Siri, Alexa en Google Assistent. Deze assistenten proberen patronen in spraakopdrachten te herkennen. Ze reageren met een actie of commentaar op jouw spraakopdracht in natuurlijke taal. Het uitspreken van tekst noemt men spraaksynthese.

8. Sentimenten van sociale media.

Het meten van de sentimenten van sociale media maakt nog steeds veel los. NLP maakt verborgen gegevensinzichten inzichtelijk door enorme hoeveelheden data te analyseren.

Wat er feitelijk gebeurt is dat NLP wordt ingezet om berichten, reacties, reviews en allerlei houdingen en emoties te beoordelen op basis van gehanteerde taal. Deze inzichten kunnen dan weer worden gebruikt voor tal van doeleinden.

9. Het voorspellen van trends

Naast het bepalen van sentimenten in sociale media, kan men NLP ook richten op specifieke onderwerpen.

Door het scannen van relevante sites, blogs, documenten en beeldmateriaal kan men informatie ophalen en deze classificeren. Daarbij kan NLP bijvoorbeeld ook bepalen of er op het onderwerp positief of negatief wordt gereageerd. Waardoor men uiteindelijk beter kan voorspellen.

Voorbeelden hiervan zijn toepassingen in de wetenschap of door overheidsinstanties t.b.v. de nationale veiligheid.

Welke impact heeft NLP op jou?

Alle voorgaande voorbeelden van een steeds betere NLP stellen jou in staat om anders naar jouw persoonlijke omstandigheden te kijken.

Het gemak waarmee deze systemen ingezet kunnen worden voor persoonlijke doeleinden zal het jou gemakkelijker maken om doelen te bereiken. We vinden het al heel normaal om een computer aan de lijn te krijgen of thuis vragen te stellen aan een speaker met ‘Alexa’.

Naast het gemak, zullen uit de NLP ontwikkeling ook aandachtspunten ontstaan. Een belangrijk aandachtspunt is wat NLP kan betekenen voor jouw organisatie en jouw rol? Om het je gemakkelijk te maken: als jouw taak is om de telefoon op te nemen en simpele antwoorden te geven, dan is het tijd om je verder te gaan ontwikkelen.

Ontwikkeling is nodig, want eenvoudig werk zal door AI en NLP als eerste kunnen worden vervangen. Is dit erg? In veel gevallen niet, want het complexe en interessante werk blijft nog nodig. Maar, dan moet je nu in actie komen om dat interessante werk straks wel te beheersen. Het kan echter ook zijn dat je nu al moet gaan nadenken over een carrière switch.

Tot slot

NLP richt zich op het taalaspect binnen Artificial Intelligence. NLP ontwikkelt zich razendsnel. Je hebt gegarandeerd al te maken gehad met NLP.

Met elkaar verbinden is nodig, men heeft een gedeelde taal nodig om elkaar beter te begrijpen. Zelfs als het begrijpen van de taal van een ander komt door een machine, is het kunnen verbinden belangrijker.

Vraag je eens af wat Natural Language Processing voor jou kan gaan betekenen. In je werk, voor jouw toekomst en gewoon voor fun. Wellicht raak je hierdoor ook geïnteresseerd in Artificial Intelligence en robotisering.

Wil je meer weten over NLP dan is de Engelstalige Wikipedia als vervolgstap interessant.

Het bericht Wat is Natural Language Processing? verscheen eerst op agile4all.

De Mikado-methode is een framework om veranderingen aan te brengen in een complexe code door software ontwikkelaars. Een goede eerste indicatie van waar Mikado voor staat is dat de bedenkers het een Naïeve Aanpak noemen.

De bedenkers zijn Ola Ellnestam en Daniel Brolund. Zij beschrijven de Mikado-methode als een framework hoe om te gaan met complexe veranderingen wanneer code (t.b.v. een it-systeem) herschreven dient te worden. Maar wat als de ontwikkelaars het risico van aanpassen te groot vinden of het gewoonweg  niet aandurven vanwege de mogelijke consequenties? 

Zoals je vermoedelijk wel weet is Mikado ook een spel waarbij je stokjes weghaalt zonder dat je de andere stokjes laat bewegen. Net als het spel is het veranderen (het weghalen van een stokje) bij kleine veranderingen vaak nog goed te overzien.

Naarmate je verder komt in het spel zijn er steeds meer onderlinge afhankelijkheden. Dit wordt in deze methode als volgt beschreven: op een willekeurig gegeven moment zullen grote of kleine veranderingen in eerder geschreven code plaats dienen te vinden.

Mikado richt zich met name op grote veranderingen, waarbij het handig is om een framework of methodiek te hanteren. Het hoofddoel van de Mikado-methode is overzicht te houden tijdens de verandering, waardoor de kans op fouten in de code afneemt.

Het Mikado-model is beschreven in het boek The Mikado Method. Het boek is in Nederland bij de bekende verkooppunten verkrijgbaar, maar is nu (deels) vrijgegeven op manning.com en daar in te zien.

Dit artikel zal met name software ontwikkelaars aanspreken, toch is het ook interessant voor Scrum Masters en Agile Coaches. De Mikado-methode hanteert namelijk een andere benadering dan veelal gebruikelijk en bouwt voort op agile processen zoals refactoring, TDD en snelle feedback.

De 4 basisbegrippen van de Mikado-methode

De Mikado-methode wordt ook wel het Mikado framework genoemd. De methode hanteert 4 basisbegrippen. Deze 4 basisbegrippen zijn eenvoudig te begrijpen:

• Stel een doel
• Experimenteer
• Visualiseer en
• Maak ongedaan.

Kortom, geen ‘rocket science’, maar waarom is het dan anders? Het ‘anders zijn’ ligt in het specifieker kijken naar wat het onderliggende probleem is.

Wat is het onderliggende probleem?

De auteurs beschrijven dat alle softwareontwikkelaars ooit een grasmat zullen moeten betreden waar ze liever niet op willen spelen. Dit wordt beschreven als volgt: de code was ooit vers groen gras, maar inmiddels is het een bruin veld (brown fields) waar men liever niet meer komt. Simpelweg omdat het veranderen van de code teveel organisatie of persoonlijke risico’s met zich meebrengt.

Door velen medewerkers in de organisatie is het niet mogelijk of gewenst om de wedstrijd op of met het bruine gras aan te gaan vanwege de voornoemde risico’s, maar het voortbestaan van een organisatie is veelal mede afhankelijk van verse code. Een organisatie heeft vers groen gras nodig om het concurrentiespel goed te kunnen spelen. Aan de ontwikkelaars de taak om een omgeving te creëren waarmee de organisatie de concurrentiestrijd aan kan gaan.

En als je als ontwikkelaar dat bruine veld dan toch moet betreden is het Mikado-model met 9 processtappen volgens de auteurs een zeer geschikt middel: ‘het werkt heel goed samen met Extreme Programming, Scrum en Kanban.’

De 9 processtappen van de Mikado-methode.

De 9 processtappen van de Mikado-methode worden kort toegelicht. De afbeelding toont het framework.

Stap 1: Teken het originele Mikado doel.

Schrijf een User Story voor het Mikado doel. Schrijf het Mikado doel op een stuk papier, trek er een dubbele cirkel eromheen.

De dubbele cirkel is er om gedurende alle processtappen het oorspronkelijke doel aan te geven. Het doel waar men zich aan gecommitteerd heeft wat dus behaald dient te worden. Je creëert focus en alles wat je doet moet gericht zijn op het behalen van het doel.

Het doel draagt zorg voor 2 belangrijke voorwaarden:

• Is het gekozen doel het startpunt voor verandering?
• Zonder doel weet je niet of je succesvol bent.

Het belangrijkste van het doel is echter dat het je doet bewegen tot het doen van een experiment. Zie stap 2.

Stap 2: Voer het doel naïef uit

Ga direct experimenteren,  analyseer vooraf de mogelijke gevolgen niet, implementeer en leer. Dit heet de Naïeve Aanpak, want je creëert een experiment om te leren. De gedachte erachter is dat er regelmatig veel tijd besteed wordt aan analyseren en te interpreteren, terwijl de wijziging direct doorvoeren direct de juiste inzichten verstrekt.

Zodra je gaat experimenteren gaan er dingen ook fout, hiervan leer je en kan je diverse variabelen valideren en/of voorbereidingen treffen.

In sommige organisaties ontstaan dan de eerste spanningen, want leren door fouten te maken past goed binnen agile denken. Maar niet alle organisaties zijn gecharmeerd van deze gedachtegang, daar mogen fouten niet of beperkt worden gemaakt. Dat is tevens een van de redenen waarom de verouderde systemen niet graag door de ontwikkelaars worden aangepakt.

Stap 3: Zoek eventuele fouten

Ontdek je fouten, belemmeringen en/of problemen dan ga je door naar stap vier. Dat is echter geen procesfout of verloren tijd, je hebt inzicht gekregen in de afhankelijkheden die het bereiken van jouw doel belemmeren.

Zijn er geen fouten dan ga je door naar stap 8 of 7. Zie afbeelding.

Stap 4: Kom met directe oplossingen voor de fouten

Fouten dienen opgelost te worden, over-analyseer deze fouten echter niet. Kom met directe oplossingen, het maakt volgens de methodiek niet uit waar deze gevonden worden. Kom dus snel met een oplossing in de volgende iteratie.

Vaak is er sprake van diverse afhankelijkheden en deze dienen opgelost te worden voor implementatie. Dit doe je door voortdurende iteraties, waarbij het geleerde wordt meegenomen naar de toekomstige iteratie.

Stap 5: Teken de directe oplossingen als nieuwe voorwaarden

Het visueel maken is een heel bekende agile werkwijze. De oplossing wordt opgeschreven en verwijst met een pijl naar het doel. De oplossing noemt men daaropvolgend een voorwaarde voor het oorspronkelijke doel.

Dit is een leerproces op zichzelf, de ene keer is de oplossing geschikt voor meerdere fouten en kan je deze met 1 pijl aangeven de andere keer wordt je geconfronteerd met  veel meer oplossingen voor veel verschillende problemen.

Soms heb je geen oplossing, hanteer dan een ‘placeholder’ waar ‘de fout’ op staat. Deze komt later in de rebound.

Stap 6: Zet de code terug in de oorspronkelijke staat als er fouten zijn gemaakt.

De zesde stap van de Mikado-methode is in menig organisatie een issue. Want eindelijk is er iets opgeleverd, maar dan blijken er alsnog fouten in de code naar voren te komen. Een veelvoorkomende reactie is dan om datgene dat werkt te behouden en alleen de fout(en) te herstellen.

In de Mikado-methode is dit het lastigste onderwerp, de werkwijze die men dan hanteert is het volledig ongedaan maken van de oplevering of te wel de gedane wijziging terugbrengen in de oorspronkelijke staat! Volgens velen is dit het vernietigen van gedaan werk!

Dit is volgens de bedenkers de grootste en belangrijkste drempel bij het toepassen van deze methode.

De Naïeve Aanpak

Volgens de auteurs is er echter slechts één juiste methode. Blijf de Naïeve Aanpak hanteren! Stap 1 tot en met 5 geven het al aan, in deze zesde stap is het credo:

Ga altijd terug naar de laatst werkende situatie, voordat je verdere wijzigingen doorvoert.

Het vermijden van fout op fout stapeling is essentieel voor herhaalbaarheid en voorspelbaarheid.

Het achterliggende idee is heel eenvoudig, je zult fouten moeten maken om te kunnen leren. Het leren gaat met horten en stoten en wordt in een aantal organisaties helaas gezien als verspilling. Dat is het volgens de auteurs echter niet, het is in hun visie de belangrijkste manier om te leren.

Ze stellen zelfs dat het niet terug kunnen gaan na een eerder werkende versie berust op een misvatting. Het gaat immers niet alleen om het opleveren van werkende code. Een systeemontwikkeling dient zich volgens hen te richten op het leren over het systeem, het domein, de taal en de gebruikte technologie.

Het maken van de veranderingen is slechts een fragment van de totale ontwikkeltijd en de grote waarde van de Naïeve Aanpak is wat je leert over het systeem. Het stelt je in staat om te zien wat je eigenlijk in de weg staat.

Het overwinnen van de angst om terug te keren is een belangrijke stap voorwaarts in de Mikado-methode

Stap 7: Herhaal het proces voor elk van de directe oplossingen

Herhaal voor elk van de voorwaarden, één voor één, de voorgaande stappen, beginnend met stap 2. Dit betekent dat voor elk van de voorwaarden, begin met een schoon werkend systeem en probeer de voorwaarde naïef te implementeren. Zoek de fouten (indien aanwezig), bedenk oplossingen voor de fouten, noteer ze als voorwaarde, draai de wijzigingen terug en ga dan verder met de volgende voorwaarde.

Stap 8: Controleer of er geen fouten zijn

Als er verder geen fouten zijn dan is de verandering geslaagd, dit geef je aan met een vinkje bij de oplossing. Je kan dan overgaan tot het overdragen van de code. Veelal hanteert met hiertoe een aantal voorwaarden:

• De code wordt gecompileerd.
• De testen worden uitgevoerd.
• Het product is goed.
• De veranderingen zijn zinvol om in te checken.

Wellicht zullen er nog wat veranderingen moeten worden doorgevoerd en ga je door met de volgende iteratie en een nieuwe voorwaarde. Je start weer bij stap 2.

Als de wijzigingen niet helemaal zinvol zijn, kijk dan naar de afbeelding en kijk of ze vergezeld moeten gaan van een paar extra wijzigingen om een verstandige oplevering te maken. Je kunt eventueel het controleren van de voorwaarden uitstellen, totdat je de code incheckt.

Ga verder met het selecteren van een nieuwe voorwaarde om mee te werken als volgende iteratie, en herhaal het proces vanaf stap 2.

Stap 9: Als het Mikado doel is bereikt, ben je klaar!

Het doel is bereikt, alle voorwaarden zijn vervuld de code is ingecheckt. Tijd voor een feestje en weer door!

Samenvatting

De Mikado-methode is een andere kijk op software ontwikkeling. Dit artikel geeft inzicht in hoofdlijnen van het proces. Wellicht is de Mikado Methode niet geheel nieuw voor je, maar het is interessant om je nog eens verder te verdiepen in deze methode.

Hiervoor verwijs ik je naar het boek of manning.com waar veel dieper op dit framework wordt ingegaan. 

Het bericht Wat is de Mikado-methode? verscheen eerst op agile4all.

UX staat voor User Experience (gebruikerservaring). UX zijn alle interacties die een persoon kan hebben met een product, website, platform of service. Door deze interacties ontstaan emoties, ervaringen en een houding bij de ‘gebruiker’ van jouw product. Veelal een systeem, website, platform of service.

Met het inzetten van ‘User Experience’ in het ontwikkelproces ga je op een gestructureerde wijze op zoek naar een ontwerp dat resulteert in een optimale gebruikerservaring.

Het UX proces bestaat uit een aantal stappen. Om het direct duidelijk te maken: je stapt in de schoenen van de gebruiker en denkend en handelend vanuit de gebruiker gaat men het functioneren van jouw website, dienst of product beoordelen. Om daarna verbeteringen aan te brengen.

User Experience is in de praktijk:

• Het identificeren en weghalen van barrières.
• Het de gebruiker gemakkelijk maken om bepaalde taken te voltooien.
• Een platform snel de wensen van de bezoeker laten vervullen.
• Hoe sneller de gebruiker zijn doel bereikt, hoe beter het UX design is.

Dit artikel over User Experience beschrijft een simpel stappenplan met een uitgebreid voorbeeld.

Ontwikkeling van UX

Het begrip User Experience is al vrij lang in gebruik. In marketing is het al decennia lang een eis om een goed inzicht te hebben in de wensen van een prospect of klant en daar producten of diensten goed op aan te laten sluiten.

De driver achter de huidige ontwikkeling in User Experience is de versnelling in de mens & machine benadering, zoals bijvoorbeeld computer technologieën en website design.

1. Computer technologieën

Voorbeelden hiervan zijn mobiel, sociale platforms en robotisering. De gebruiker ervaart een steeds hoger niveau. Als jouw ‘product’ geen goede gebruikerservaring biedt zijn er voldoende alternatieven. Switchen naar een andere aanbieder is slechts 1 click!

2. Website design

Van ‘techniek’ naar een interactieve omgeving. Waarbij de totale beleving en interactie van de gebruiker met de website bepalend is voor het resultaat. Hiervoor komen o.a. marketing, branding, design en ontwerpers samen voor slechts één doel: een optimale klantbeleving voor een optimaal resultaat.

Beschrijving van User Experience

User Experience lijkt in eerste instantie best lastig te ondervangen, want het gaat over emoties en een totale gebruikerservaring van een product, dienst of service. De toepassing is veelal gericht op interactie van één persoon met een website, maar het kan dus voor meer doeleinden gebruikt worden.

Maar hoe meet je nu percepties? Hoe kijk je naar systeemaspecten zoals nut, gebruiksgemak en efficiëntie? Terwijl de perceptie en het gedrag van de gebruiker continue veranderd.

Daarbij spelen ervaringen van buitenaf ook een belangrijke rol. Een gebruiker leest wellicht slecht nieuws, hoort meningen van vrienden, leest opinies en ziet wellicht milieuaspecten. Al deze bronnen kunnen een een grote impact hebben op de beleving van jouw merk en de gebruikerservaring.

Je wilt de gebruiker begrijpen om hem/haar een optimale gebruikerservaring aan te bieden.

Als voorbeeld neem ik een website. Veel medewerkers van een website kennen hun eigen website van A tot Z. In het verleden heeft de site allemaal logische keuzes gemaakt, maar is dit nu ook nog zo? De gedachtegang die bij de ontwikkeling is gevolgd is wellicht voor de huidige gebruiker helemaal niet gewenst.

Voor vrijwel iedereen is dit een heel herkenbare situatie. Welke sites bezoek je eigenlijk niet meer? Heeft een bepaalde site jouw voorkeur? Zonder dat je het weet is de reden vaak een UX-design, waarbij ‘jouw’ wensen en gedragingen zijn meegenomen in het ontwerp. Bij het ontwerpen of aanpassen van een site gebruikt men vaak UX scenario’s.

Wat is een UX scenario?

In de inleiding staat al dat je in de schoenen van de gebruiker stapt. Daartoe hanteert men binnen User Experience een scenario.

Een scenario is een (visueel) verhaal voor één persoon. Deze persoon staat vaak synoniem voor het gebruikersgedrag van meerdere gebruikers. Per scenario is er één specifiek doel dat moet worden bereikt. Dit wordt vaak aangeduid met persona. Als er meerdere persona’s zijn zullen deze separaat besproken worden.

Het doel van UX is het denken en handelen van de gebruiker centraal te stellen in de ontwikkeling van mogelijke oplossingen. Het hanteren van Scenario’s maakt het mogelijk om de stappen die de gebruiker neemt te visualiseren.

Scenario’s zijn snel te gebruiken en hebben een sterke focus op het verkrijgen van inzicht van de gebruikersacties. Scenario’s is de eenvoudigste manier om de verbeelding te prikkelen en begrijpelijk te maken wat er precies de gebruikerservaring is. Daartoe volgt later in de tekst een uitgewerkt voorbeeld.

Soorten Scenario’s

Scenario’s zijn op meerdere niveaus mogelijk. Een vaak gebruikte indeling is op het niveau van de gevisualiseerde informatie en de diepte van de benodigde inzichten door het team.

• Heeft het team voldoende aan het begrijpen van het gebruikers doel en de genomen stappen door de gebruiker?
• Heeft het team ook suggesties nodig om de stappen te verbeteren?
• Wilt het team een gedetailleerd inzicht in alle te ondernemen stappen om de gebruikerservaring te verbeteren?

Bovenstaande scenario’s gaan van simpel naar complexe onderzoekstrajecten.

Het toepassen van Scenarios

Hoe kan je nu scenario’s toepassen om het gedrag van de gebruiker te koppelen aan de lay-out van een website? Dat doe je in een aantal stappen, deze staan hieronder beschreven:

1. Voorbereiding (plan)

Het doel van een UX sessie is dat de gebruikerservaring van de persona wordt besproken. Denk daarbij aan de mogelijke scenario’s, persona en functies die mogelijk besproken gaan worden. Maar denk ook aan het regelen van een ruimte incl. de benodigde materialen: post-its, sharpies, brown paper of white board.

Stel bij voorkeur een multidisciplinair team samen. Bijvoorbeeld een sessie met UX-onderzoekers, ontwerpers en testers. Let wel op de grootte van het team. Denk aan een teamgrootte van 5 tot max. 8 personen.

Vaak nodig je de deelnemers uit met een toelichting waar de sessie over gaat. Het dient duidelijk te zijn voor de teamleden wat het onderwerp is en wat er besproken gaat worden.

Wellicht kan je van te voren inschatten of er meer dan één sessie nodig is om alle geplande doelen te behandelen. Het komt regelmatig voor dat er meerdere persona’s besproken moeten worden.

2. Start een sessie (do)

De facilitator brengt de eerste persona die in het scenario zal worden gebruikt naar voren.

Persona: Dave is 23 jaar oud, studeert rechten en winkelt graag online. De redenen hiervoor zijn: tijd besparen, groter aanbod en meer variëteiten.

Doel: Koop een betaalbaar en uniek cadeau voor een vriendin.

Er zijn meerdere mogelijkheden om de sessie te starten:

• De facilitator start met de introductie van de sessie en de doelen die tijdens de sessie worden besproken. Deze sessie kan strak begeleid worden of juist niet.

• Een andere mogelijkheid is dat het team de belangrijkste bespreekpunten binnen het onderwerp bepaald. Zie het artikel: Wat is lean coffee?

3. Visualiseer de stappen van de gebruiker

Eindelijk het team gaat aan de slag.

Op post-its worden alle de stappen beschreven die de persona moet doorlopen om het doel te bereiken.

Eerst worden deze stappen verder uitgewerkt, denk hierbij aan reacties van het team op de stap. Observaties, eerdere inzichten of feedback van klanten. Maak hierbij onderscheid tussen feiten, vragen en aannames. Toon de kenmerken, zoals hoe de producten zijn afgebeeld en waar deze te vinden zijn.

Daarna volgen de ideeën en suggesties die deze stap kunnen verbeteren. Herhaal de stappen voor alle functies die van toepassing zijn. Dus elk doel en elk personage wordt apart behandeld.

De sessie met post-its van de UX – User Experience – Scenario’s ziet er dan als volgt uit:

Bekijk bovenstaande afbeelding, dan begrijp je hoe het stappenplan werkt.

Met het nemen van foto’s leg je deze sessie vast. Deel de foto’s met de teamleden. Stakeholders die niet bij deze sessie aanwezig waren ontvangen deze foto’s ook.

4. Feedback (check)

Feedback vragen en krijgen geeft extra inzichten. Belanghebbenden krijgen de ruimte om feedback te geven. Voor snelle feedback is het mogelijke om belanghebbenden direct na de sessie uit te nodigen om het increment te laten zien. Toesturen van de gemaakte foto’s met verzoek voor feedback kan natuurlijk ook. Een feedback sessie, zoals de ik-ik-jij feedback methode is in dit geval niet gebruikelijk.

5. Bouwen! (act)

Na het ontvangen van de feedback is er een sessie om de verkregen feedback mee te nemen in het scenario. Daarna bouwt en implementeert men de definitieve versie.

Samenvattend

Scenario’s is een eenvoudige en efficiënte tool in het UX-onderzoek. Door gebruikerservaring te visualiseren krijg je een beter inzicht in het gebruikersgedrag en de stappen die nodig zijn om elke taak uit te voeren.

Het gevisualiseerde scenario, met suggesties en opmerkingen voor elke stap, maakt verbeteren gemakkelijk.

Een scenario is ook een goed startpunt voor een ontwerp- en ontwikkelteam om snel te komen tot een functioneel en doordacht ontwerp.

In een ander jasje en voor een ander gebruiksdoel ingezet. Scenario’s lijkt veel op: Plan, Do, Check en Act! De PDCA kwaliteitscirkel van Deming!

Het bericht Wat is UX? User Experience! verscheen eerst op agile4all.

Wat is blockchain?

“The blockchain is an incorruptible digital ledger of economic transactions that can be programmed to record not just financial transactions but virtually everything of value.” Don & Alex Tapscott, authors Blockchain Revolution (2016).

Wat is een distributed ledger?

Een ledger is een consensus van gerepliceerde, gedeelde en gesynchroniseerde digitale gegevens die geografisch verspreid zijn over meerdere sites, landen of instellingen. Een soort grootboek waarvan alle aangesloten partijen over een deel van de informatie beslissen. Bron: https://en.wikipedia.org/wiki/Distributed_ledger

Inleiding

Eerst twee definities, een inleiding en ook nog Blockchain op een site over Agile werken! Waarom? Om 2 redenen, de belangrijkste reden is dat het een technologische ontwikkeling is waarvan je minimaal ‘the basics’ mag weten.

De tweede reden is dat de tijd rijp is om over de mogelijkheden binnen jouw organisatie na te denken.

De blockchain droom:

Zou het niet mooi zijn als elke transactie gegarandeerd gevalideerd is, doordat de transactie niet alleen is vastgelegd in een centraal register, maar in een verbonden gedistribueerd systeem van registers, die allemaal met elkaar verbonden zijn door een veilig validatie mechanisme?

Dit is inmiddels geen droom meer, het is een harde realiteit.

Nu vraag je je wellicht af, waar gaat dit over? Maar denk eens aan de Bitcoin. Een saldo en een transactie wordt (h)erkent en gevalideerd door meerdere registers. Ik heb het in dit artikel echter niet over Bitcoin. Waar ik het o.a. wel over ga hebben is de mogelijkheid om van grondstof tot eindgebruiker de totale keten inzichtelijk te krijgen.

De mogelijkheden van blockchain reiken namelijk veel verder dan Bitcoin, het is een revolutionaire ontwikkeling die business op dit moment snoeihard veranderd. De vraag is natuurlijk waarom?

Tijdsbesparing, lagere kosten, dalend risico en meer vertrouwen. Een ook nog voorsprong op de concurrent. Dat is bijna te mooi om waar te zijn. Dus kom ik met een korte schets van een ‘probleem’, waardoor je direct de business uitdaging herkent.

Business uitdaging

Stel je eens voor dat je een contract aan het schrijven bent. Je hebt meerdere mensen nodig die een bijdrage leveren. Voorheen gebeurde dat door stukken door te sturen en de andere persoon revisies op dit stuk te laten doen. Dan wacht je totdat het stuk retour is voordat het naar de volgende gaat etc. etc. Hiervoor is een (deel)oplossing gevonden door bijvoorbeeld Google docs te gebruiken. Er is één document waar meer mensen tegelijkertijd aan kunnen werken.

De echte uitdaging komt echter als je externe partijen uitnodigt om aan hetzelfde document te werken, helemaal als er financiële consequenties uit voort kunnen vloeien. Niet echt werkbaar.

Bij (complexe) transacties zullen stukken, contracten en afspraken meerdere keren over en weer gaan en/of gewijzigd worden. Hoe complexer, hoe minutieuzer en tijdrovender deze activiteiten zijn. Hoe hoger de kosten zijn. Maar vooral wie heeft er nog (totaal) overzicht?

De basis van blockchain is de Ledger!

Een ledger is DE systematiek van vastlegging van een transactie en contract. Gebaseerd op een set afspraken: zoals de wijze van vastlegging en de vastgelegde records.

Ik kom met een simpel voorbeeld van het belang van de shared ledger: de aan- en verkoop van een fiets op afstand.

Piet koopt op een veilingsite een fiets van Klaas. Hij weet niet dat Klaas de eigenaar is. Van Klaas is vooraf al bepaald dat hij de rechtmatige verkoper is. Bij Piet is vooraf geaccordeerd dat hij het geld heeft om te kopen. Bij verkrijging van ‘hoogste bod’ door Piet is de transactie rond. De bank krijgt uit de veilingsite de transactie door. De bank gaat direct tot afschrijving over bij Piet (transactie). Piet heeft daar geen probleem mee. In de wetenschap dat het geld geblokkeerd blijft staan, totdat hij akkoord geeft direct na ontvangst van de fiets. Stel: De fiets is overeenkomstig de verkoopbeschrijving: er zijn dus geen belemmeringen. Het geld gaat door naar Klaas (contract).

Een andere mogelijkheid is dat er een probleem is: de fiets is geleverd zonder trappers. Dan meldt Piet dat er een probleem is. Het geld gaat nog niet over naar Klaas (contract). De afhandeling van deze ledger kan dan bijvoorbeeld worden beoordeeld door een onpartijdige derde. De afspraak binnen het netwerk kan dan zijn dat onpartijdige derde een (bindend) voorstel doet.

Transacties zijn vaak niet uniek

Zoals in het voorgaande voorbeeld valt te lezen is er een set van afspraken w.o. de transactie, de vastlegging en naleving van het contract. Waar in dit voorbeeld veel winst te behalen valt is deze afspraken set van toepassing te verklaren op alle fietstransacties binnen dit business netwerk. In concreto: de afspraken set behorend bij de verkoop van de fiets van Piet naar Klaas, geldt dan ook voor alle andere fiets aankoop/verkoop transacties. Vanzelfsprekend wordt er dan ook verder gebouwd aan meer  mogelijkheden binnen de transactie en contract.

Nu is dit slechts een simpel voorbeeld, maar je begrijpt ook dat complexe transacties uniek lijken, maar dit vaak niet zijn. Uniek omdat het voor de aan- en verkooppartijen een eenmalige transactie is, maar deze transactie niet uniek is voor de tussenpersonen (e.g. banken). Vragen zoals: wat is de herkomst, waar zijn op welk moment de goederen, wie is op welk moment eigenaar, bij overdracht direct overboeken etc. etc. zijn universele vragen.

En zelfs als de transacties nog complexer zijn, zullen ze later wellicht vaker gaan plaatsvinden. I.p.v. elke keer het wiel opnieuw uitvinden. Bouwt het business netwerk steeds aan nieuwe vormen binnen blockchain. Er zijn dus meerdere ledgers binnen een business netwerk.

Maar ook zullen de partijen toetreden tot meerdere business netwerken, omdat ook andere type dienstverleners van andere type ledgers nodig zijn.

4 soorten blockchains

Hoewel dit artikel gaat over business blockchains kan ik niet voorbij gaan aan 4 verschillende type blockchains;

• simpele vormen
  • gecentraliseerd
  • gedecentraliseerd
• distributed ledgers
  • anoniem
  • niet anoniem

Daar ga ik in dit artikel niet verder op in, maar is wel alvast handig om te weten.

Waar moet een business blockchain aan voldoen?

Een business blockchain kan pas tot stand komen als er voldaan is aan 4 vereisten: shared ledger, smart contract, privacy en trust.

Shared ledger:

• Deelnemers zien alleen een deel van de transacties, terwijl alle informatie van alle partijen is opgenomen in de ledger
• De afgesproken en benodigde informatie wordt gedeeld door deelnemers overeenkomstig het raamwerk van afspraken.
• Deelnemers hebben een kopie, het werkelijke bewijs ligt in de vastlegging in de blockchain.

Smart Contract

Het slimme contract is vanzelfsprekend. Volgens afspraken gaat de afhandeling via de blockchain. De business regels worden dus vastgelegd in het contract, ingebed in de blockchain en uitgevoerd met de transactie. Het contract is gevalideerd en getekend en in programmeertaal.

Privacy

Een belangrijke peiler. Het gaat om geld, het verdienmodel en transacties. Men wil soms niet weten wie de voorgaande eigenaar is en vaak geen openbaarheid gewenst over wie, tegen welke prijs, de nieuwe eigenaar is.

De ledger is gedeeld, maar deelnemers willen privacy. Dit betekent dat de algemene informatie en toestemmingen van betrokken partijen in netwerk wel te zien zijn, maar dat bijvoorbeeld de ‘eigen onderlinge afspraken’ niet worden gedeeld.

Deelnemers willen namelijk dat de juiste vertrouwelijkheid bewaakt blijft en dat identiteit niet gelinked is aan een transactie. Overigens moeten de transacties vanzelfsprekend worden geverifieerd en wordt het proces beveiligd door cryptografie.

Trust

Een netwerk blijft alleen bestaan als er vertrouwen is tussen de partijen. Dit wordt bereikt door middel van consensus, de herkomst, onveranderlijkheid en finaliteit. Kortom, eenmaal plaatsgevonden? Dan kan niet meer gewijzigd worden.

De ledger is een vertrouwde bron van informatie, waarbij de deelnemers de transacties onderschrijven.

• Het netwerk beslist wie de transacties onderschrijven, onderschreven transacties worden toegevoegd aan de ledger met de juiste vertrouwelijkheid.
• Assets hebben een verifieerbare controle mogelijkheid.
• Transacties kunnen niet worden gewijzigd, toegevoegd en/of verwijderd.

Waarom is blockchain belangrijk?

Tijd, kosten, risico en vertrouwen.

Het bespaart tijd. Een transactietijd terug gebracht tot seconden in het netwerk.

Het bespaart kosten: Overhead en kosten tussenpersonen.

Risico daalt: fraude en cybercrime.

Vertrouwen: door gedeelde processen en vastlegging transacties.

Maar vooral NU niet te vergeten: toegevoegde waarde door een voorsprong in serviceniveau!

Wie zijn de belangrijkste spelers?

Regulator (e.g. overheid)

Een organisatie die de spelregels bepaald, zoals de overheid. Het is begrijpelijk dat een overheid geïnteresseerd is, want alles is goed te volgen en te controleren. Een goed voorbeeld hiervan zou jouw identiteit kunnen zijn. Een belastingdienst die boeken wil controleren, een ledger waar al jouw ID-informatie of medische gegevens op staat. Maar dan begrijp je ook meteen de zorgen: het is nieuwe technologie, data wordt op meerdere plekken vastgelegd en hoe zit het dan met veiligheid?

Industriegroep

Grote industriegroepen herkenen direct de kostenbesparingen en de beheersbaarheid van het proces. Een aantal organisaties zijn al volop onderweg, zoals….

Een willekeurig voorbeeld zou kunnen zijn de autoindustrie. Waarvan van elk boutje in een auto bekend is, exact bekend is wat de auto allemaal heeft meegemaakt en dat de handel in 2^e hands auto’s betrouwbaar is, omdat de gehele geschiedenis bekend is.

De regulators en industriegroepen zullen in eerste instantie vooral vanuit beheersing en kostenreductie (schoorvoetend) in blockchain stappen.

Market Maker

Dit is een organisatie die innoveert en die een nieuwe dienst / product bedenkt. Hier gaat het echt gebeuren en hier ontstaan nieuwe wereldspelers. High tech, grote behoefte, nieuwe producten en diensten. Kortom, hier voorspel ik de nieuwe giganten. Zoals voorheen e.g. Apple, Google, eBay, Alibaba etc..

Is blockchain bewezen?

Ik heb een kritisch Engelstalig artikel van Merltech.org voor je gevonden, zij geven aan dat de bewijsvoering van succesvolle blockchain technologie toepassingen wellicht nog niet toereikend is.

Zonder een oordeel te willen vellen over voor- en tegenstanders van blockchain meen ik dat je bij alle nieuwe technologieën de bewijslast in de startfase niet altijd direct helder is.

Voor een kritische noot m.b.t. ‘het geleverde bewijs’ verwijs ik je naar een Engelstalig artikel op merltech.org.

Mijn voorlopige antwoord op ‘bewijs leveren’ is: zoek naar je eigen blockchain toepassingsmogelijkheden en valideer deze voordat je start. Daarna kies je voor een continue ontwikkelproces (in kleine stappen) en hou je voortdurend de vinger aan de pols.

Tot slot:

Heb je nog 19 minuten tijd. Dan heb ik een super interessante video voor je gevonden.

Het bericht Blockchain verscheen eerst op agile4all.

Wat is Artificial Intelligence (AI/A.I.) 

Wat doet Artificial Intelligence nu op een Agile website? Dat is simpel, het is één van de voorbeelden van technologische ontwikkelingen waar je in de nabije toekomst mee te maken krijgt.

Er zijn diverse definities, maar Alan Turing (uitvinder computer) noemde het :

‘AI is the science and engineering of making intelligent machines, especially intelligent computer programs’

Wat ik gemakshalve voor jou heb gedaan is het gezamenlijke uitgangspunt bepalen van alle definities. In tegenstelling tot wat vaak wordt gedacht is het eigenlijk vrij simpel om een helikopterview te hebben.

Alle definities gaan uit van:

• kunnen plannen
• redenatie en leren
• waarneming
• het bouwen van een soort van begrip van kennis
• communicatie in natuurlijke taal.

En dat noemt men vaak: big data, reasoning, learning en problem solving.

Twee hoofdcategorieën van A.I.

AI valt in twee hoofdcategorieën in te delen:

Narrow AI: specifiek algoritme. Een voorbeeld is een Schaakprogramma.

General AI: leert en lost alle problemen op. (Dit is eigenlijk het doel waar iedereen naar streeft)

Subcategorieën A.I.

In plaats van de hoofdcategorieën hoor je veel vaker over: machine learning, cognitive systems, robotics en smart machines. Deze termen worden vaak gebruikt in samenhang met AI, soms als synoniem. Omdat ik het zelf super interessant vind is de kans groot dat ik later in andere artikel(en) er dieper op in ga, maar nu zal ik in vogelvlucht deze termen behandelen.

Machine Learning 

 Machines leren door Algoritmes patronen te herkennen. Eigenlijk wordt een machine geleerd om de patronen te herkennen door herhaalde training. De machine begrijpt niet wat het doet en leert er dus niet van, dit is dus geen A.I.

Cognitive Analytics

Trekt informatie uit ongestructureerde data door concepten en relaties in een kennisbase te plaatsen en te zoeken. Zoekt dus het antwoord.

Robotics

Hardware en intelligente software & data verrichten een taak waarvoor een bepaalde mate van intelligentie noodzakelijk is.

Smart Machines

Tot een bepaalde hoogte neemt een smart machine zelf beslissingen. Dus een vorm van autonomie. Een cognitief systeem kan met elkaar gaan communiceren en daardoor beter worden.

Fundamentele AI technieken:

• Heuristics (vaak herkenbaar als trail and error methodes)
• Support vector machines (bijv. wel of geen spam)
• Artificial neural network (nabouwen hersenen, maar nog met veel minder verbindingen)
• Markov decision process ( framework om tot beslissingen te komen)
• Natural language processing (taalherkening)

Het gaat nu te ver om dit verder te behandelen, maar dit zijn technieken die je vaak hoort i.c.m. A.I.

A.I. Applicaties

Voor sommige taken is een machine beter/meer geschikt dan een mens! En het gaat hard! Bijvoorbeeld Siri (Apple), Alexa (Google).

Deze applicaties zijn onder andere:

• Spraak herkenning (speech recognition)
• Beeld-/gezichtsherkenning (image recognition)
• Vertaling (translation)
• Vraag en antwoord (question & answering, Q&A)
• Games en oplossingen (game – solver)

In de nabije toekomst zijn deze applicaties in staat mensen te vervangen, bijv. gezichtsherkenning voor security doeleinden.

Technologie trend

• Cloud
• Big Data
• API’s (out of the box oplossingen, bijv. gezichtsherkenning)
• Open Source
• Internet of things (IoT) en standaardisatie.

Samenvatting

• Cloud is het platform en API’s zijn de ‘bouwstenen’.
• Steeds meer ongestructureerde data, AI technologie heeft antwoorden.
• Data is te trainen.
• Open source AI technologieën, instapdrempel daalt.
• Eerder gemaakte modellen zijn gemakkelijk aan te passen (open source)
• Wijsheid van de groep is beschikbaar.
• Internet of Things (IoT) zorgt voor nog meer data.

Start your engines! Zijn er AI cases mogelijk in jouw organisatie? Agile denken en handelen helpt met deze vraag.

p.s. Denk dus voortaan niet alleen aan een robot bij A.I!

Tot slot

Artificial Intelligence komt goed tot zijn recht bij wat in het Cynefin framework van Snowden het ingewikkeld domein wordt genoemd.

Het bericht Artificial Intelligence verscheen eerst op agile4all.