Tag Archives: ontwikkelen

Het belang van een proeflapje

In een vorige blogpost wees ik op het belang van het omgaan met risico’s. Een hele begrijpelijke reactie vond ik: “Boris, hoe ga ik dan om met risico’s in de technologie?”.


Risico  

Stel, je hebt een technisch risico geïdentificeerd in een project. Laten we als uitgangspunt nemen dat je in het project een combinatie hebt van vertrouwde technologie en een technologie die je nog niet goed kent. Hoe ga je dan om met het laatste risico? Een belangrijke techniek die je kunt gebruiken is het proeflapje!

Proeflapje

Met een proeflapje weet je hoeveel wol
je nodig hebt.Foto van Arne Heggestad, ga naar foto 

Proeflapjes maken doe je zo 
Voor mensen die veel breien is een proeflapje een bekend begrip, maar voor de meeste mensen zal een uitleg op zijn plaats zijn. In het breipatroon staat aangegeven hoeveel pennen en steken je moet gebruiken om bijvoorbeeld een wollen trui met een bepaalde maat te maken – in mijn geval zou dat al snel lengtemaat XXL zijn. Maar de één maakt net wat lossere steken bij het breien dan de ander. En wol is een natuurlijk materiaal, dus de elasticiteit verschilt wel eens. Het aantal pennen en steken in een patroon is een gemiddelde. Daarom maak je eerst een proeflapje, om uit te proberen hoe je het precies moet doen. Als je weet hoe het moet, haal je het proeflapje gewoon weer uit. De wol kan dan worden hergebruikt.

Teveel geitenwollen sokken?  
Misschien spreekt deze analogie je niet zo aan. Dan is hier een militaire versie, want in gevechtssituaties doen ze net zoiets: daar sturen ze een verkenner voor de troepen uit. Bij Arendsoog was dat Witte Veder, in de Golfoorlog gebruikte Stormin’ Norman SEAL’s met Hummers. De verkenner bepaalt de beste route, geeft schattingen over de reistijd en geeft aan of er hindernissen moeten worden overwonnen. En dan kunnen de troepen aan de slag.

Het throw-away prototype
Ook in IT-projecten is het mogelijk op deze manier om te gaan met technische risico’s. Het proeflapje heet daar dan een throw-away prototype. Laat een ontwikkelaar (de verkenner) een versie maken die alleen maar aantoont hoe je met de technologie werkt. Hierbij worden de functies beperkt tot het absolute minimum. De code hoeft voor deze keer niet netjes of onderhoudbaar in elkaar te zitten en er zit geen foutafhandeling en logging in.

Verkenner3

Kies een goede verkenner

Foto van Cpl. James L.
Yarboro, U.S. Marine Corps 

 

 

 

Kies de goede verkenner
Uiteraard kies je een goede ontwikkelaar voor deze klus. De geschiedenis zit vol met voorbeelden van de rampzalige gevolgen van ontbrekende of verkeerde informatie van verkenners. Zo verloren de Romeinen in de slag om het Teutoberger Woud drie complete legioenen mede door ontbreken van verkenners en verloor Napoleon de slag bij Waterloo mede door verkeerde informatie van de verkenners. Xerxes en zijn Perzen daarentegen wonnen juist de slag bij Thermopylae van de Spartanen door goede informatie van verkenners.

Gooi het throw-away prototype weg
Als het prototype klaar is, gebruik je de inzichten die het maken heeft opgeleverd. De inzichten van het prototype worden verwerkt in het ontwerp en urenschattingen, het team kan nu worden opgeschaald en er kan worden begonnen met het bouwen van de echte versie in een schone omgeving. Het throw-away prototype zelf wordt na afloop weggegooid, zoals de naam al aangeeft. De verleiding is misschien groot om door te willen bouwen op het prototype, maar trap niet in die valkuil. Het prototype is niet geschikt als fundament; het was een bewuste keus om het prototype quick & dirty te realiseren. In je urenschatting ga je er vanuit dat je geen hergebruik kunt doen van het throw-away prototype in het echte product.

Pijpinspecties
Een mooi praktijkvoorbeeld van de inzet van een throw-away prototype komt van de ontwikkeling van EngeMOVI’s nieuwe device voor pijplijninspectie, of Pipe Inspection Gauge (PIG). Een pijplijninspectie-device wordt in een olie- of gaspijplijn ingebracht om de staat van de leiding te inspecteren. Bij de ontwikkeling identificeerden de ontwerpers het geolocatie algoritme als hun grootste technische risico. Hun throw-away prototype bestond uit een basale versie van meetapparatuur, bevestigd met tie-wrap op een fiets. Dit prototype stelde hen in staat hun algoritme te testen en te verfijnen, mede omdat een fiets bij benadering de gewenste snelheid heeft. Na de tests werd het prototype weer gedemonteerd.

Risicomitigatie
Als je een technisch risico hebt geïdentificeerd, dan is het gebruik van een throw-away prototype een goede manier om dit technisch risico aan te pakken of op zijn minst de impact te beperken (het risico te mitigeren). Een throw-away prototype kun je in iedere ontwikkelmethode gebruiken (waterval, scrum, jbf etc).  Dus: bepaal het risico van het project en pak het aan! Maak een proeflapje of stuur een kundige verkenner vooruit. Met deze onmisbare informatie kun jij de (wed)strijd winnen: het project op tijd en binnen budget succesvol afronden.

LinkedInFacebookTwitterDeel deze blogpost
Posted in Developer, Projecten | Tags: , , , , | Plaats een reactie

Duidelijk toch? Toch maar even vastleggen!

Ik zie het vaak gebeuren en misschien is het wel herkenbaar: er is hard (over)gewerkt om een nieuwe app of website op tijd op te leveren, maar de opdrachtgever is niet eens blij! Bij oplevering blijkt dat er iets heel anders werd verwacht. Dat is vervelend voor de maker en voor de opdrachtgever, maar is er iets te doen om dit een volgende keer te voorkomen?

Misschien is het duidelijk wat er gemaakt moet worden, maar dan is het vast ook niet moeilijk om dat op te schrijven.

Misschien is het duidelijk wat er gemaakt moet
worden, maar dan is het vast ook niet moeilijk om
dat op te schrijven.

Verwachtingen managen
Het voor de hand liggende antwoord is dat je de verwachtingen vooraf moet managen – verwachtingen over tijd, geld en inhoud. In deze blogpost wil ik stilstaan bij het managen van de verwachtingen over de inhoud, hier gebruiken we in de IT meestal requirements voor.

Geanimeerd voorgesprek
Soms hoor ik weleens dat het niet nodig is om de requirements vast te leggen. “Het is toch duidelijk wat je moet maken?”, wordt dan gezegd. Misschien is het inderdaad helemaal duidelijk, maar dan kan het vast ook niet moeilijk zijn om de inhoud even op te schrijven, toch? Vaak genoeg heb ik meegemaakt dat bleek dat we elkaar in dat geanimeerde voorgesprek toch niet helemaal goed hadden begrepen. Vergeet niet dat de kosten van het oplossen van fouten steeds hoger worden, naarmate je verder komt in het ontwikkelproces. Een fout in de requirements is zo aangepast, maar het wordt snel vele malen duurder om dezelfde fout op te lossen als je er pas achter komt bij het testen.

requirements-opschrijven1

Een fout wordt snel vele malen duurder om op te
lossen als je er pas achter komt bij het testen.

Kwaliteit als eis
Inhoud kent nog een andere dimensie. Performance kan bij GIS-systemen door de hoeveelheid data een aandachtspunt zijn, reden om het hier vooraf eens over te hebben. Dit zijn de kwaliteitseisen, ook wel non-functional requirements genoemd. Hoe lang mag het openen van deze kaartlaag duren bij deze extent en op dit schaalniveau? Soms wordt er gemakkelijk vanuit gegaan dat security een verantwoordelijkheid is van de IT-afdeling, maar het is verstandig er op zijn minst eens over te hebben met wat voor user id de gebruikers moeten inloggen. Het klopt, dit zijn vaak moeilijk grijpbare onderwerpen. Maar als bij oplevering blijkt dat de opdrachtgever niet tevreden is met de kwaliteit (performance, security, usability, etc), dan heb je vaak een probleem dat zich veel moeilijker laat oplossen dan een bug in een functie.

Eenvoudig beginnen
Mijn advies is om eenvoudig te beginnen. Kijk wat werkt voor het soort projecten dat u doet. Een ding is zeker: als bij uw volgende project de requirements worden vastgelegd, dan hebben u en uw opdrachtgever alvast een verrassing minder bij de oplevering.

Posted in ArcGIS, Developer | Tags: , , , | 1 Comment

Ontwikkelen is als chocolaatjes proeven

Afgelopen week was Londen dé plek voor ambitieuze Geospatial App Developers. Ik ben er ook zo een. De tweede Europese Esri Developer Summit wist maar liefst 389 deelnemers uit 28 landen bij elkaar te brengen. Dat gaf het evenement een interessante dimensie.

dev-summit-europe

MapAttack is een real-time on
location based game.

Hackathon
Op zondag werden de deelnemers uitgenodigd door Esri UK voor de MapAction Hackathon. MapAction is een onafhankelijk organisatie die draait op de inzet van fantastische vrijwilligers. Zij komen in actie tijdens de allereerste en meest kritieke fase van natuur- en andere humanitaire rampen. Daarbij zetten ze hun professionele GIS-competenties in om snel de situatie en noden letterlijk in kaart te brengen. Hoe bijzonder is het dat de winnende app de volgende dag al kan worden ingezet in het door de tyfoon Haiyan getroffen gebied van in de Filipijnen?

Hot topics
Dat tijdens de plenaire sessie van een DevSummit alle hot topics gedemonstreerd worden, werd nu onbedoeld wel erg letterlijk genomen. Dit vanwege een verplichte evacuatie na een brandmelding. Gelukkig konden we de coole demo’s en nieuwe mogelijkheden van het platform later in een mooie presentatie aanschouwen. Keynote-spreker was Amber Case van het nieuwe Esri R&D Center in Portland. Zij daagde ons uit om tijdens de pauze MapAttack te spelen. Een coole urban game waarin de nieuwste technologie voor geofencing (via GPS een gebied virtueel afbakenen) en geotriggers (de geofencing een bepaalde actie laten uitvoeren) is verwerkt.

Speedgeeking
Een belangrijk aspect, naast goede lunches, is tijdens zo’n bijeenkomst kennis uitwisselen en elkaar ontmoeten. Dit kan in ruime mate tijdens de technische sessies, Lightning Talks, User Demo’s en de Dev Lounce. Ik heb interessante gesprekken gevoerd met allerlei ontwikkelaars, bijvoorbeeld met de R&D-developer die aan het product CityEngine werkt. Zo’n Dev Summit is de ideale kans om de mensen achter de schermen op ontspannen wijze te ontmoeten. Heel inspirerend!

dev-summit-europe1

Welke smaak je ook ontwikkelt,
iedereen kan een fijnproever zijn.

Chocolaatjes proeven
Extra spannend wordt het natuurlijk als je zelf met een andere internationale Esri-collega een presentatie mag geven. Hoe maak je een sessie interactief aan het einde van de dag als iedereen al zoveel informatie op heeft moeten nemen? ‘Let’s throw them chocolates’ was de ludieke actie die ook nog eens paste bij het onderwerp ‘communicatie met het ArcGIS-platform’. Ongeacht in welke smaak je ontwikkelt, iedereen kan een fijnproever zijn. Wat heerlijk om een Advanced Topics te mogen presenteren met een echte Pro. Uit de directe feedback heb ik begrepen dat de bezoekers de Europese Esri Developer Summit goed wisten te waarderen en daar gaat het natuurlijk om.

Coderen is sociaal, weet u het nog? Een waardevolle investering voor alle bezoekers. En volgend jaar? Wir sehen uns in #Berlin.

Posted in Achter de schermen, ArcGIS, Developer | Tags: , , , , , , , , , | Plaats een reactie

Vuurdoop: Startup Weekend Groningen

Ontwikkelaars, managers, marketeers, creatievelingen en andere enthousiaste mensen gingen afgelopen weekend aan de slag om hun idee te delen, vervolgens een team te vormen, een product te ontwikkelen. Spannend, want misschien is het idee het waard een eigen bedrijfje te lanceren. Het 54 uur durende Startup Weekend-evenement is een fantastische broedplaats. Dit weekend was mijn vuurdoop. Mijn conclusie: deze eerste kennismaking smaakt naar meer!

In een minuut je idee 'verkopen'. Foto: Joost Nuijten

In een minuut je idee ‘verkopen’. Foto: Joost Nuijten

Wereldkundig
Op vrijdagavond startte het weekend met de pitches. De deelnemers krijgen een minuut de tijd om hun briljante idee te ‘verkopen’. Voor sommigen toch spannend om voor een grote zaal te spreken, maar vooral om jouw idee, je kindje wereldkundig te maken. Stel je voor dat je wordt afgewezen? Droom kwijt, ervaring rijker?

Groepsvorming en fun
De beste ideeën hebben geen enkele moeite om teamleden te verzamelen. Dit is grote stap in de goede richting. Nadat het pitchen van de ideeën en het vormen van de teams, begint het echte werk. De eerste minuten verlopen moeizaam. Hoeveel ego’s zitten er in een groep? Wie neemt de leiding? “Wij doen alleen mee als het fun is.” Kortom: er vindt een groepsbindingsproces plaats. Even later dreigt de groep uit elkaar te vallen, maar als iedereen dan open en eerlijk alle kaarten op tafel gooit, ontstaat er iets moois, de tegenstanders worden medestanders en omarmen het gezamenlijke idee en doel. Tijd om te gaan slapen!

Op zondagavond moet het idee 'af' zijn.
Op zondagavond moet het idee ‘af’ zijn.

 

Enthousiasme
Gedurende de nachtrust gaat het creatieve proces natuurlijk gewoon door en als op zaterdagochtend iedereen zich weer bij de groep meldt, loopt het als een zonnetje. Er staat een gemotiveerde groep met mensen klaar, de rollen worden verdeeld. De marketeers gaan op onderzoek uit, de developers gaan ontwikkelen, de vormgevers creëren en de managers zien toe dat het proces in goede banen verloopt. Om de paar uur worden de resultaten gedeeld en wordt er bijgestuurd. De club wordt steeds enthousiaster, maar de zondagavond is
dichtbij, dit is de keiharde deadline waarop alles
klaar moet zijn.

Prijzen
Twee teams hebben het Esri-platform gebruikt voor hun app. City Crush, een locatiegebaseerd smartphone-spel om de jeugd buiten aan het spelen te krijgen, gaat er met de derde prijs vandoor. Team Hawkseye, een Social Rapid Response, ontvangen golden tickets voor TEDxBinnenhof. De prijzen zijn verdeeld. Het was een mooi weekend van hard werkende gemotiveerde mensen. Blijft het hierbij of zijn de eerste stappen gezet voor the next Twitter, Facebook of Candy Crush-onderneming? Ik denk het laatste, maar enkel de toekomst zal het ons leren.

Een geweldig idee maakt pas echt kans van slagen als je het deelt en een daarmee een ECHTE kans geeft. Esri Nederland gelooft hierin en wil daarom vanaf nu volop meewerken aan dit soort initiatieven.

Posted in ArcGIS, Developer | Tags: , , , , , | Plaats een reactie