Leestijd 7 min

Jan Eerdekens

In deze technische blogpost wil ik het hebben over hoe je eenvoudige en flexibele ETL-gebaseerde anonimisering kunt opzetten. Waarom? Wel, ik had onlangs de gelegenheid om een klein proof of concept uit te voeren voor een klant. De klant wilde weten welke opties beschikbaar waren om interne gegevens te nemen, alle persoonlijk identificeerbare informatie (PII) te verwijderen of anonimiseren en deze op een eenvoudige manier en vorm beschikbaar te maken voor externe partijen. Na het verzamelen van verdere vereisten werd de context voor dit proof of concept als volgt gedefinieerd: Welke oplossing dan ook, het moet in staat zijn om gegevens te extraheren uit een on premise Oracle database . Het eindresultaat moet een set CSV-bestanden zijn in een Amazon S3-bucket . Tussen het ophalen van de Oracle-gegevens en het dumpen ervan in CSV-vorm op S3, moet er iets zijn dat PII-gegevens verwijdert/anonimiseert. Indien mogelijk moet de gekozen oplossing cloud native zijn. In deze 3-delige blogreeks leg ik uit hoe je eenvoudige en flexibele ETL-gebaseerde anonimisering opzet: Het onderzoek naar producten die gebruikt zouden kunnen worden om het probleem op te lossen. Controleer ook hoe geschikt ze zijn voor wat de proof of concept moet bereiken. Hoe het gekozen product gebruikt kan worden om een ETL pipeline te maken die aan de eisen voldoet. Daarnaast, hoe je een lokale Oracle database opzet in Docker die gebruikt kan worden als databron voor het data ingestion deel van het proof of concept (gewoon omdat dit zo'n PITA was om te doen). En of dit op een cloud native manier kan worden gedaan. Onderzoek Het onderzoeksdeel van het proof of concept bestaat uit 2 delen: Hoe haal je data uit een Oracle database, anonimiseer je het op de een of andere manier en sla je het op als een stel CSV bestanden in een S3 bucket aka het ETL gedeelte. Uitzoeken wat de beste manier is om de anonimisering uit te voeren. De gegevens extraheren, transformeren en opslaan Het probleem van de klant klonk meteen al opmerkelijk als iets dat je zou kunnen oplossen met een ETL-product: Extract Transform Load . Het onderzoeksgedeelte voor dit deel van het proof of concept zou zich dus concentreren op dit type product. Ik kreeg ook wat input van iemand in mijn team om eens te kijken naar singer.io , omdat dat iets was dat ze in het verleden met succes hadden gebruikt voor dit soort problemen. Als je naar de homepage van Singer kijkt, vallen een aantal dingen meteen op: Singer maakt gegevensextractie en -consolidatie mogelijk voor alle tools van je organisatie. De open-source standaard voor het schrijven van scripts die gegevens verplaatsen. Unix-geïnspireerd: Singer taps en targets zijn eenvoudige applicaties samengesteld met pipes. JSON-gebaseerd: Singer-toepassingen communiceren met JSON, waardoor ze eenvoudig te gebruiken en te implementeren zijn in elke programmeertaal. Singer is dus gewoon een specificatie, zij het geen officiële. Het is een eenvoudig, op JSON gebaseerd dataformaat en je kunt iets in dit formaat produceren (een tap in Singer terminologie) of het formaat consumeren (een target ). Je kunt deze taps en targets aan elkaar koppelen om gegevens van de ene locatie te halen en op een andere locatie op te slaan. Singer wordt standaard geleverd met een heleboel taps (meer dan 100) en targets (10). Deze taps en targets zijn geschreven in Python. Omdat het centrale punt van het systeem slechts een gegevensformaat is, is het vrij eenvoudig om er zelf een te schrijven of een bestaand formaat aan te passen. Bij het controleren van de taps zou de standaard Oracle-tap het Extract-gedeelte van ons proof of concept moeten dekken. Hetzelfde lijkt echter niet het geval te zijn voor het Load gedeelte als we kijken naar de standaard targets. Er is een CSV target , maar deze slaat de resultaten lokaal op, niet in een S3 bucket. Er is een optie om gewoon dit doel te gebruiken en de S3 upload zelf te doen nadat de ETL pijplijn is voltooid. Een andere optie zou zijn om het bestaande CSV target aan te passen en de bestandsopslag te veranderen naar S3. Even Googelen levert een door de gemeenschap gemaakt S3 CSV Singer doel op. Volgens de documentatie zou dit target precies moeten doen wat we willen. Oeps, Singer transformeert niet Met de Extract en Load delen gedekt, blijft alleen het Transform deel van de ETL pijplijn over om uit te zoeken... en dit is waar het een beetje vreemd wordt. Ook al is Singer geclassificeerd als een ETL tool, het lijkt geen ondersteuning te hebben voor het transformatie gedeelte? Toen ik hier verder naar keek, kwam ik deze onheilspellend getitelde post tegen: Why our ETL tool does not do transformations . Als ik dit lees, lijkt het erop dat ze hun JSON specificatie/gegevensformaat beschouwen als het transformatiegedeelte. Dus ze ondersteunen transformatie naar ruwe gegevens en het opslaan ervan, maar ondersteunen geen andere soorten transformaties. Dat deel mag je zelf doen nadat het ergens is opgeslagen door een Singer-doel. Het blijkt dus dat Singer meer lijkt op het EL deel van een ELT product dan op een "old school" ETL product . Op dit punt zou Singer in ieder geval voldoende moeten zijn om de gegevens uit een Oracle database te halen en in CSV-formaat in een S3 bucket te zetten. En omdat Singer vrij eenvoudig, open en uitbreidbaar is, laat ik het hier voorlopig bij. Laten we verder kijken naar de anonimiseringsopties die in deze Singer-context zouden kunnen passen. Gegevens anonimiseren Net als bij het ETL-gedeelte, kreeg ik ook voor dit gedeelte wat input die me wees op Microsoft Presidio . Op de homepage kunnen we het volgende lezen: Het biedt snelle identificatie- en anonimiseringsmodules voor privé-entiteiten in tekst en afbeeldingen , zoals creditcardnummers, namen en meer. Het faciliteert zowel volledig geautomatiseerde als semi-geautomatiseerde PII de-identificatiestromen op meerdere platforms. Aanpasbaarheid in PII-identificatie en -anonimisering. Er staan dus veel veelbelovende dingen in die me zouden kunnen helpen bij het oplossen van mijn anonimiseringsbehoeften. Bij nader onderzoek lijkt het erop dat ik dit product evalueer tijdens een grote transformatie (snap je? 😉 ) van V1 naar V2. V1 bevatte wat ETL-achtige dingen zoals het ophalen van gegevens uit bronnen (hoewel Oracle-ondersteuning in de roadmap nooit lijkt te zijn gerealiseerd ) en het opslaan van geanonimiseerde resultaten in een aantal vormen/locaties. V2 heeft deze aanpak echter volledig losgelaten en concentreert zich puur op het detecteren en vervangen van PII-gegevens. In de kern is Presidio V2 een op Python gebaseerd systeem dat bovenop een AI-model is gebouwd. Dit stelt het in staat om automatisch PII-gegevens te ontdekken in tekst en afbeeldingen en deze te vervangen volgens de regels die je definieert. Ik heb wat tests gedaan met behulp van hun online testtool en het werkt min of meer, maar voor onze specifieke context moet het zeker worden aangepast. Als we kijken naar de meegeleverde testgegevens, lijkt het erop dat het vooral eenvoudige en korte gegevens zijn, maar geen grote tekstblokken of afbeeldingen. Dit roept de vraag op: zelfs als we Presidio kunnen configureren om te doen wat we willen, slaan we misschien kleine spijkers met een grote hamer? Is Presidio te veel? Laten we hier nog eens over nadenken. Als we gemakkelijk kunnen weten en definiëren welke eenvoudige kolommen in welke tabellen moeten worden geanonimiseerd en wanneer gewoon nulling of hashing van de kolomwaarden voldoende is, dan hebben we het autodetectie deel van Presidio niet nodig. We hebben ook geen Presidio-ondersteuning nodig voor volledige tekst of afbeeldingen en we hebben ook geen fancy substitutie-ondersteuning nodig. Presidio zou een krachtige bibliotheek kunnen zijn om een automatische anonimiseringsstap te maken voor onze Singer-gebaseerde pijplijn. Het helpt ook dat Presidio gebaseerd is op Python. Maar mijn gevoel zegt dat ik misschien eerst moet proberen om een iets eenvoudigere oplossing te vinden. Ik begon te zoeken naar iets dat een eenvoudige PII-vervanging kan doen en dat werkt in een Singer tap/target context. Ik vond deze Github repository: pipelinewise-transform-field . In de documentatie staat "Transformatiecomponent tussen Singer taps en targets". Klinkt verdacht veel als het " T " deel dat Singer als een ETL miste! Verderop in de configuratiesectie lezen we zelfs: "Je moet definiëren welke kolommen door welke methode moeten worden getransformeerd en in welke conditie de transformatie moet worden toegepast." en de mogelijke transformatietypes zijn: SET-NULL : transformeert elke invoer naar NULL HASH : transformeert stringinvoer naar hash HASH-SKIP-FIRST-n : Transformeert stringinvoer naar hash waarbij de eerste n tekens worden overgeslagen, bijv. HASH-SKIP-FIRST-2 MASK-DATE : Vervangt de maand- en dagdelen van datumkolommen door 1 jan. MASK-NUMBER : Zet elke numerieke waarde om in nul. MASK-HIDDEN : verandert een willekeurige tekenreeks in 'verborgen'. Dit lijkt volledig te voldoen aan onze eenvoudige anonimiseringseisen! We kunnen zelfs zien hoe we het moeten gebruiken in de context van Singer: some-singer-tap | transform-field --config [config.json] | some-singer-target Standaard Conclusie We hebben nu alle stukjes van de puzzel voor het opzetten van eenvoudige en flexibele ETL-gebaseerde anonimisering. In de volgende blogpost laten we zien hoe ze in elkaar passen en of ze de resultaten opleveren die de klant zoekt.

Leestijd 8 min

Dorien Jorissen

Bij de ontwikkeling van software kunnen aannames ernstige gevolgen hebben en we moeten altijd op onze hoede zijn. In deze blogpost bespreken we hoe je omgaat met aannames bij het ontwikkelen van software. Stel je voor... je rijdt naar een bepaalde plaats Een plek waar je al 5 jaar lang elke dag naartoe rijdt, dezelfde route neemt, langs dezelfde verlaten straat rijdt, waar je nog nooit een andere auto hebt gezien. Langzamerhand begin je je vertrouwd te voelen met deze route en ga je ervan uit dat je zoals altijd de enige auto op deze weg zult zijn. Maar op een gegeven moment duikt er een auto vlak voor je op... er was al die tijd al een zijstraat, maar je had hem nooit opgemerkt, of misschien was je hem helemaal vergeten. Je trapt op de rem en komt gelukkig net op tijd tot stilstand. Aannames werden je bijna fataal. Gelukkig zijn de veronderstellingen die we in ons werk maken nooit zo gevaarlijk voor ons leven als de veronderstellingen die we in het verkeer maken. Toch kunnen veronderstellingen ernstige gevolgen hebben en moeten we altijd op onze hoede zijn. Stel je voor... je maakt websites Je laatste klant is op zoek naar een nieuwe site voor zijn bejaardentehuis omdat zijn huidige site verouderd en niet zo fancy is. Dus u bouwt een fancy nieuwe website in de veronderstelling dat fancy betekent: modern ontwerp, sociale functies, dynamische inhoud. De site is niet het succes dat hij had verwacht ... vreemd ... je hebt precies gebouwd wat je klant wil. Maar heeft u gebouwd wat de bezoekers van de site willen? De gemiddelde gebruiker is tussen de 50 - 65 jaar oud, op zoek naar een nieuw huis voor hun vader en moeder. Ze zijn geen digital natives en voelen zich misschien niet thuis op een mooie, dynamische website vol twitterfeeds en sociale knoppen. Het enige wat ze willen is een goede indruk krijgen van het bejaardentehuis en gerustgesteld worden over het feit dat er goed voor hun ouders zal worden gezorgd. Hoe meer ervaring je krijgt, hoe harder je moet oppassen geen aannames te doen en dubbel te checken met je klant EN de doelgroep . Een ander bekend gevaar van ervaring is " de vloek van de kennis ". Hoewel het klinkt als de volgende Pirates of the Caribbean sequel, is de vloek van kennis een cognitieve bias die bijna iedereen met expertkennis in een specifieke sector overheerst. Het betekent dat beter geïnformeerde partijen het extreem moeilijk vinden om over problemen na te denken vanuit het perspectief van minder goed geïnformeerde partijen. Je kunt je afvragen waarom economen er niet altijd in slagen om de juiste beursvoorspellingen te doen. Iedereen die wat geld over heeft, kan aandelen kopen. Je hoeft geen expert te zijn of zelfs maar verstand te hebben van economie. En dat is de belangrijkste reden waarom economen er vaak naast zitten. Omdat ze expertkennis hebben, kunnen ze niet voorbij deze expertise kijken en kunnen ze zich moeilijk voorstellen hoe minder geïnformeerde mensen zullen reageren op veranderingen in de markt. Hetzelfde geldt voor IT. Daarom moeten we altijd een oogje in het zeil houden en blijven we in de huid kruipen van onze klanten. Inzicht krijgen in hun ervaring en standpunt is de sleutel tot het creëren van de perfecte oplossing voor de eindgebruiker. Dus hoe pakken we aannames aan ...? Ik zou graag zeggen "Eenvoudig" en je een prachtige oneliner geven ... maar zoals gewoonlijk ... is eenvoudig nooit het juiste antwoord. Om de drang om over te schakelen op de automatische piloot en de vloek van de kennis te laten werken, hebben we een methodologie ontwikkeld op basis van verschillende Agile-principes die ons dwingt om onze eindgebruiker te betrekken bij elke fase van het project, te beginnen wanneer onze klanten nadenken over een project, maar de oplossing nog niet hebben gedefinieerd. En eindigt... nou eigenlijk nooit. De eindgebruiker zal nieuwe inzichten opdoen door met uw oplossing te werken, wat kan leiden tot nieuwe verbeteringen. In de watervalmethode wordt aan het begin van een project een analyse gemaakt door een business analist. Soms wordt de gebruiker betrokken bij deze voorafgaande analyse, maar dit is niet altijd het geval. Dan maakt een conclaaf van ontwikkelaars iets in eenzaamheid en na de witte rook ... begint het gebruikersacceptatietesten (UAT) . Het moet pijnlijk voor ze zijn om zich na deze tests te realiseren dat het product dat ze zorgvuldig hebben gemaakt niet de oplossing is die de gebruikers ervan verwachtten. Het is te laat om ingrijpende veranderingen door te voeren zonder dat daar veel meer tijd en budget voor nodig is. Met een Agile projectmethodologie kom je een heel eind. Door elke 2 tot 3 weken testbare versies uit te brengen, kunnen gebruikers geleidelijk functionaliteit testen en hun feedback geven tijdens de ontwikkeling van het project. Deze aanpak houdt rekening met de inzichten van de gebruiker, die tijdens het project zijn opgedaan, en garandeert een betere match tussen de behoeften van de gebruiker en de oplossing die je voor hun behoeften creëert. Agile beoefenaars zijn voorstander van 'continuous deployment'; een praktijk waarbij nieuw ontwikkelde functies onmiddellijk worden uitgerold naar een productieomgeving in plaats van in batches om de 2 tot 3 weken. Dit stelt ons in staat om het systeem (en in essentie de aannames) in het wild te valideren, waardevolle feedback van echte gebruikers te krijgen en gerichte experimenten uit te voeren om te valideren welke aanpak het beste werkt. Door onze methodologie te combineren met constante betrokkenheid van gebruikers, elimineer je de ergste aanname in IT: we weten hoe de werknemers hun werk doen en wat ze nodig hebben ... het gevaar van ervaring! Elimineren we altijd aannames? Laat me het iets ingewikkelder maken: Nogmaals... stel je voor: je gaat al 10 jaar naar dezelfde supermarkt, het is vrij veilig om aan te nemen dat de cornflakes nog steeds in hetzelfde gangpad liggen, zelfs op hetzelfde schap als gisteren. Als je niet meer zou aannemen waar de cornflakes liggen... dan zou je enorm veel tijd verliezen door de hele winkel door te lopen. Niet één keer, maar steeds opnieuw. Hetzelfde geldt voor ons werk. Als we ons werk zouden doen zonder te vertrouwen op onze ervaring, zouden we geen inschattingen kunnen maken over budget en tijd. Elke schatting is gebaseerd op aannames. Hoe meer ervaring je hebt, hoe nauwkeuriger deze aannames worden. Maar leiden ze ook tot goede en betrouwbare schattingen? Niet noodzakelijk ... Terug naar mijn metafoor ... We nemen elke dag dezelfde weg naar het werk. Op basis van ervaring kan ik inschatten dat ik er 30 minuten over zal doen om naar mijn werk te rijden. Maar wat als ze files aankondigen op de radio en ik de aankondiging niet heb gehoord ... dan is mijn schatting niet juist. Bij ACA Group gebruiken we een aantal belangrijke werkwijzen bij het maken van schattingen. Ten eerste is het een teamsport. We maken nooit schattingen in ons eentje en hoewel schatten een serieuze zaak is, doen we het terwijl we een spelletje spelen: Planningspoker. Laat me je dit uitleggen; planning poker is gebaseerd op het principe dat we beter kunnen inschatten in een groep. Dus we lezen het verhaal (stuk functionaliteit) hardop voor, iedereen pakt een kaart (die een indicatie geeft van de complexiteit) en legt deze open op tafel. Als iedereen een kaart heeft gekozen, worden ze allemaal tegelijk omgedraaid. Als er verschillende getallen worden getoond, ontstaat er een discussie over het waarom en hoe. Veronderstellingen die de basis vormen voor iemands schatting komen naar boven en worden besproken en gevalideerd. Er volgt nog een schattingsronde en het proces gaat door tot er consensus is bereikt. Het eindresultaat: een betere schatting en een grondig begrip van de aannames die aan de schatting ten grondslag liggen. Deze expliciete aannames zijn er om gevalideerd te worden door onze belanghebbenden; een geweldig eerste hulpmiddel om ons begrip van de scope te valideren.Dus elimineren we altijd aannames? Nou, dat zou bijna onmogelijk zijn, maar door aannames expliciet te maken elimineren we een hoop verspilling. Wil je meer weten over deze Agile Estimation? Bekijk dan dit boek van Mike Cohn . Hé, dit is een tegenstrijdigheid... Hoe zit het dan met die aannames? Moeten we ze proberen te vermijden? Of moeten we erop vertrouwen? Als je ervan uitgaat dat je alles weet... zul je nooit meer verbazing ervaren. Zoals Aristoteles al zei: "Het was hun verwondering, verbazing, die de mensen ertoe bracht om te filosoferen". Welnu, een proces dat de gemaakte veronderstellingen valideert door middel van goed uitgevoerde experimenten en snelle feedback heeft bewezen geweldige resultaten op te leveren. Dus in essentie zal het goed beheren van je aannames prachtige dingen opleveren. Wees je er wel van bewust dat de vloek van kennis om de hoek loert, wachtend op een onbewaakt moment om het over te nemen. Geïnteresseerd in deelname aan ons team? Wil je een van onze teamleden ontmoeten? Geïnteresseerd om deel uit te maken van ons team? We zijn altijd op zoek naar nieuwe gemotiveerde professionals om het ACA-team te versterken! {% module_block module "widget_3ad3ade5-e860-4db4-8d00-d7df4f7343a4" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"View career opportunities"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":{"content_id":229022099665,"href":"https://25145356.hs-sites-eu1.com/en/jobs","href_with_scheme":null,"type":"CONTENT"},"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}

Leestijd 4 min

Dorien Jorissen

ACA doet veel projecten. In het laatste kwartaal van 2017 deden we een vrij klein project voor een klant in de financiële sector. De deadline voor het project was eind november en onze klant werd eind september ongerust. We hadden er echter alle vertrouwen in dat we de klus op tijd konden klaren en besloten een experiment uit te proberen. We brachten het team samen in één kamer en begonnen met mob-programmering . Maffia wat? We hadden een artikel gelezen waarin het concept van mob programming werd uitgelegd. In het kort komt mob programming erop neer dat het hele team samen in één ruimte zit en aan één user story tegelijk werkt. Eén persoon is de 'bestuurder' en doet het coderen voor een bepaalde tijd. Als die tijd voorbij is, gaat het toetsenbord over naar een ander teamlid. We probeerden het experiment met de volgende opzet: Ons team was relatief klein en had slechts 4 teamleden. Omdat het project waaraan we werkten relatief klein was, konden we maar 4 mensen aannemen. De user stories die we behandelden waren slechts een deel van het project. Omdat dit een experiment was, wilden we niet dat het project - zo klein als het was - volledig zou worden overspoeld. Daarom kozen we één specifieke epic en implementeerden we die user stories in de mob. We werkten niet op dezelfde computer. We hadden elk een aparte laptop en checkten onze code in op een centraal versiebeheersysteem in plaats van het toetsenbord te verwisselen. Dit was niet echt een keuze die we maakten, gewoon iets dat gebeurde. We wisselden elke 20 minuten. Het artikel waarnaar we verwezen heeft het over 12, maar we vonden dat te kort en besloten om in plaats daarvan 20 minuten te nemen. Klaar, af, af! We brachten meer dan een week door in een vergaderruimte waar we om de beurt onze laptops konden aansluiten op één groot scherm. De eerste dag van het experiment ontwierpen we. Urenlang stonden we achter het whiteboard om te beslissen over de architectuur van de component die we gingen bouwen. Op dezelfde dag begon onze groep met de implementatie van het eerste verhaal. We gingen er echt vandoor! We vlogen door de user story en riepen naar onze klantproxy als sommige vereisten niet duidelijk waren. Tegen het einde van de dag waren we uitgeput. Ons experiment was nog maar net begonnen en het was al zo intens. De volgende dagen gingen we verder met het implementeren van de user stories. In minder dan een week hadden we werkende software die we aan onze klant konden laten zien. Hoewel het nog niet perfect was en niet alle vereisten dekte, was onze software al na 3 dagen in staat om een volledige, gelukkige path flow uit te voeren. Twee dagen later implementeerden we verbeteringen en uitzonderingsgevallen die via andere user stories waren besproken. Er was nog maar een week verstreken sinds onze klant zich zorgen begon te maken en we hadden al zoveel geïmplementeerd dat we hem konden laten zien. De laatste hand leggen Tegen het einde van het project moesten we alleen nog wat technische zaken regelen. Een daarvan was het agnostisch maken van onze nieuw gebouwde softwareomgeving. Als we deze user story hadden afgewerkt met pair programming, zou één paar alle technische details van de software kennen. Met pair programming hoefden we het niet aan de rest van het team te laten zien. Het team wist het al. Omdat we laptops gebruikten in plaats van toetsenborden, had iedereen de setup op zijn eigen machine gedaan. Iedereen kende de commando's en de configuratie. Het was kennis delen op zijn best! Andere technische aspecten waren het correct configureren van onze software. Dit bleek een saaie taak te zijn voor de meeste navigators. Op dit punt besloten we dat het maffia-experiment ver genoeg was gegaan. We hadden het gevoel dat het niet de bedoeling was om dit soort taken met 4 mensen tegelijk te doen. Tenminste, dat is onze mening. Vlak voordat de groep uiteenviel, planden we een evaluatiebijeenkomst. We waren enthousiast en wilden dit opnieuw doen, misschien zelfs op grotere schaal. Onze ervaring met mob-programmering Het resultaat van ons experiment was erg positief. We ervoeren kennisdeling op verschillende niveaus. Alle betrokkenen kenden de volledige functionaliteit van de applicatie en we kenden allemaal de details van de implementatie. We waren in staat om snel een nieuw teamlid te integreren wanneer dat nodig was, terwijl we toch op een constante snelheid bleven werken. We hadden al gezegd dat we erg enthousiast waren voor, tijdens en na het experiment. Dit had een positieve invloed op onze teamgeest. We waren allemaal meer betrokken bij het project. Het nadeel was dat we mob-programmeren als vermoeiender ervoeren. We voelden ons uitgeput na een dag samenzijn, zij het op een goede manier! Volgende stappen Andere collega's zagen ons in onze vergaderruimte programmeren op een groot scherm. Er ontstonden gesprekken over het experiment. Onze opwinding werkte aanstekelijk: mensen waren meteen geïnteresseerd. We begonnen te praten over meer experimenten. Misschien zouden we mob-programmering kunnen doen in verschillende teams op verschillende projecten. En zo begint het... Heb jij ooit al eens mob-programmering geprobeerd? Of sta je te popelen om het te proberen? Laten we tips of trucs uitwisselen! We horen graag van je !