Onze werkwijze
Bij Emble ontwerpen en ontwikkelen we websites en webapplicaties maar daarnaast doen we nog een hoop andere zaken. We werken aan losse verbeteringen, voeren onderhoud en updates uit, zetten servers op waarop we websites hosten en voeren audits en toegankelijkheidsanalyses uit.
Om een overzicht te krijgen van hoe we werken, hebben we in kaart gebracht hoe het proces eruit ziet wanneer je bij ons een nieuwe website laat maken. Waar beginnen we? Welke tussenstappen zijn er allemaal? En hoe gaat een website live? Daarnaast hebben we in kaart gebracht hoe dit proces eruit ziet als je nog geen klant bij ons bent maar al wel een Drupal, Laravel of React website hebt die je bij ons wilt onderbrengen.
Inhoud van deze pagina:
Hoe bouwen we een nieuwe website / webapplicatie?
Dit hangt af van de complexiteit van het project en waar het zwaartepunt ligt. Bij Emble creëren we niet alleen complexe webapplicaties maar we ontwerpen en bouwen ook corporate website die als primaire doel hebben om bezoekers te overtuigen en tot een conversie te leiden. Daarnaast ontwikkelen we ook webapplicaties waarbij de vormgeving ondergeschikt is en deze verschillende technische uitdagingen kent. Van zware databases, tot complexe functies en/of koppelingen.
Om bij beide soorten projecten een verkennende fase aan te kunnen bieden hebben we deze opgesplitst in een eerste designsprint of een eerste sprint. Een sprint 0. Beide verkennende fases, de designsprint en een sprint 0 hebben meerdere voordelen. Het biedt onze nieuwe opdrachtgevers de mogelijkheid om ons te leren kennen voordat er een langdurige relatie wordt aangegaan. Daarnaast biedt het voor ons de mogelijkheid om de diepte in te gaan en op een gedegen manier voorbereidingen te treffen voor de uiteindelijke ontwikkeling.
Designsprint als eerste fase
Bij dit projecten waarbij het design een cruciale rol speelt starten we met een eerste designsprint om uit te denken welke doelgroepen de website moet gaan bedienen, hoe we deze doelgroepen soepel door de website leiden en hoe dit alles eruit moet gaan zien in lijn met de huisstijl van de opdrachtgever.
Het designtraject gaan wij als eerste project aan om vanuit daar inschattingen te maken voor het ontwikkelen van de rest van de website. Het vormt als het ware een blauwdruk. Gemiddeld ontwerpen we onze webdesigns in 64 à 96 uur en bieden we deze aan middels een strippenkaart.
Sprint 0 als eerste fase
Bij projecten die complexer van aard zijn en waarbij de techniek de grootste uitdaging vormt starten we ook met een verkennende fase. We noemen dit een Sprint 0. In deze sprint 0 brengen we de te bouwen website of applicatie in kaart. We doen dit door user stories te schrijven. Dit zijn korte beschrijvingen die aangeven welke functionaliteit gewenst is en welke uitwerking verwacht wordt voor een beheerder of gebruiker. Deze user stories beschrijven we aan de hand van onderzoek en sessies met de opdrachtgever met als doel om uit te werken hoe we deze user stories gaan realiseren en welke impact dit heeft qua ontwikkeling. Aan het eind van een Sprint 0 ontstaat hiermee een compleet overzicht van alle wensen en functionaliteiten die nodig zijn om de nieuwe te bouwen website of applicatie te realiseren. Met de inschattingen per user story heeft de opdrachtgever een goed beeld van waar de complexiteiten liggen en is het mogelijk om zelf te bepalen met welke onderdelen we starten, welke onderdelen in een latere fase ontwikkeld kunnen worden of helemaal achterwege blijven. Gemiddeld rekenen we 32 a 64 uur voor een sprint 0 en bieden we deze aan met een via strippenkaart een strippenkaart. Zie ook onze tarieven.
Vervolg
Wanneer de verkennende fase, in de vorm van een designsprint of sprint 0, is afgerond hebben we een compleet beeld van de benodigde uren die nodig zijn voor het creëren van de nieuw te bouwen applicatie of website.
Samen met onze projectmanager wordt gekeken hoe we deze sprints zo optimaal kunnen inplannen. Niet alleen moeten de juiste ontwerpers en ontwikkelaars aanwezig zijn, ook moet er vanuit de opdrachtgever in de vorm van een product owner en stakeholders voldoende ruimte zijn om feedback en sturing te geven.
Omdat de samenwerking nu een vaste vorm krijgt waarin we in meerdere sprints voor een langere periode met elkaar gaan werken bieden we een raamovereenkomst aan, eventueel met een een deelovereenkomst, waarin we vastleggen hoe de samenwerking eruit zal zien, wie waar verantwoordelijk voor is en wat ieder van elkaar mag verwachten. Wil je meer weten over hoe we werken met sprints?
Hoe nemen we een bestaande website / webapplicatie in beheer
Heb je al een Drupal, Laravel of React website / webapplicatie en wil je graag dat we deze overnemen qua beheer dan is dat geen probleem. We bieden specialistische hosting, onderhoudscontracten ( service level agreements ) en kunnen middels strippenkaart, sprints of een raamcontract je website / webapplicatie verder doorontwikkelen.
Als eerste een audit
Bij een audit brengen we de website / webapplicatie in kaart en kijken we hoe de website is ontwikkeld. Welke technieken er gebruikt zijn. Of deze up-to-date zijn. En of er mogelijke zwakke plekken aanwezig zijn. Tijdens de audit noteren we onze bevindingen en delen we deze in een audit rapport. Dit helpt ons een plan op te stellen om de website up-to-date te krijgen en veilig in beheer te nemen. Voor het afnemen van een audit wordt vooraf bepaald hoeveel uur vereist is voor de audit. Hoe complexer een website of applicatie is, des te meer uur hiervoor nodig is. Op basis van deze inschatting bieden wij een strippenkaart aan. Zie ook onze tarieven.
Hosting en onderhoud
Na de audit hebben we een goed beeld van de website en kunnen we een voorstel doen voor de ideale hostingoplossing en een passend service level agreement.
Bij Emble werken uitsluitend met managed private virtual servers. Dit houdt in dat resources zoals geheugen, cpu’s en harddiskruimte gereserveerd worden voor een eigen privé-server die wij beheren en onderhouden. Dit biedt niet alleen de beste performance maar ontzorgt onze opdrachtgevers. Wij gebruiken het datacenter van TransIp waarbinnen wij onze servers opzetten. Dit datacenter staat in Amsterdam, is ISO 27001, 9001, 14001-gecertificeerd en maakt gebruik van windenergie voor haar stroomvoorziening.
Wanneer ons hostingvoorstel akkoord is starten we met het inrichten van de server, de bijbehorende OTAP omgevingen en het overzetten van alle data. Wij en de eigenaar van de website / webapplicatie kunnen deze testen op onze server voordat de website daadwerkelijk live is zodat we er zeker van zijn dat de website / webapplicatie goed werkt.
Bij goedkeuring gaat de website live en nemen wij het onderhoud dat binnen de service level agreement is afgesproken op ons. Dit houdt in dat Emble verantwoordelijk wordt voor het up-to-date houden van de applicatie door het installeren van security updates en staan we paraat bij incidenten waarbij de website of webapplicatie helemaal of gedeeltelijk niet goed functioneert.
Toegankelijkheidsanalyse
De audit die wij uitvoeren richt zich met name op de techniek en voorkomt problemen bij het in beheer nemen van de website. Naast de audit is het ook mogelijk dat Emble een toegankelijksheidsanalyse uitvoert. Zeker gezien aankomende EU wetgeving is het verstandig om voorbereid te zijn en websites zo toegankelijk mogelijk te maken.
Emble ontwerpt en bouwt veel overheidswebsites en heeft op die manier jarenlange ervaring met het ontwerpen en bouwen van websites die aan de strenge toegankelijkheidseisen moeten voldoen. Daarnaast werken we samen met organisaties die zich actief bezighouden met het toegankelijk maken van het web voor slechtzienden en blinden, zoals Bartimeus en Visio.
De WCAG 2.2 AA-standaard is opgedeeld in 50 criteria. Aan alle 50 criteria moeten strikt voldaan worden om aan de WCAG 2.2 specificatie op AA-niveau te voldoen. Onze specialisten onderzoeken de website op deze 50 criteria en in het rapport laten we zien op welke punten de website wel of niet voldoet. Voor de toegankelijkheidsanalyse rekenen we 24 uur.
Doorontwikkeling in de vorm van losse werkzaamheden of sprints
Het kan zijn dat wij naast hosting en onderhoud ook aan de slag moeten met het doorontwikkelen van de website of applicatie. Denk aan een nieuw webdesign ontwerpen zodat de conversie of toegankelijkheid wordt verbeterd of een nieuwe koppeling toevoegen zodat data direct aanwezig is in een administratiesysteem. Maar het kan ook zijn dat we allerhande kleine aanpassingen moeten doorvoeren. We voeren deze werkzaamheden uit op twee manieren: Namelijk gepland in grotere blokken die we sprints noemen, waarbij meestal meerdere designers of developers samen werken aan een verbeterde versie van de website of applicatie. Deze werkwijze wordt ook wel scrum genoemd, wat afkomstig is van het scrum framework waarin allerlei afspraken rondom scrum zijn vastgelegd.
Het kan ook zijn dat er een aanpassing vereist wordt die relatief klein is en waarbij samenwerken in een team of sprint overkill is. Dit kunnen zowel support, design, training, advies of development-werkzaamheden zijn en deze worden los ingepland en vaak specifiek aan één persoon gekoppeld.
Hoe werkt Scrum bij ons in de praktijk?
Sprints zijn ‘ontwikkeletappes’ binnen de SCRUM-methodiek. Dit betekent dat een van tevoren samengesteld team van ontwikkelaars in samenwerking met de klant op vaste dagen binnen een bepaalde cyclus (standaard twee weken) werkt aan een project.
Om een overzicht te houden van alle werkzaamheden, werken we met een projectmanagementsysteem genaamd Jira. Voordat de ontwikkeling in een project van start gaat, wordt in Jira een zogeheten product backlog ingericht. Dit houdt in dat de werkzaamheden binnen het project worden opgesplitst in taken die uitgewerkt worden in kaartjes. De product backlog is eigenlijk de ‘verzamelbak van to-do’s’. Deze product backlog is volgens de SCRUM-methodiek het domein van de 'product owner'. In de praktijk betekent dat dat de opdrachtgever de product backlog vult met taken die moeten leiden tot de realisatie van zijn/haar uiteindelijke product. Hierbij beiden wij, indien gewenst, uiteraard hulp en uitleg.
Voor elke sprint wordt een selectie van kaartjes uit de product backlog gehaald. Deze kaartjes vormen de sprint backlog. Elke sprint kan één of meer sprintdoelen hebben. Aan het einde van de sprint volgt een sprint review. In sommige gevallen kan de product owner belanghebbenden ('stakeholders') erbij halen om samen de oplevering van de sprint te bekijken of te beoordelen. In andere gevallen worden alleen open eindjes van de sprint besproken tussen de product owner en het ontwikkelteam.
Tijdens de daaropvolgende sprint retrospective kijken we samen met de klant nog even naar hoe de sprint is verlopen en stellen we eventuele verbeteringen op voor de volgende sprints. Idealiter volgt na de sprint retrospective meteen de sprintplannning voor de volgende sprint, die ook meteen wordt gestart.
Sprint events
Projecten die in sprints worden uitgevoerd hebben de volgende vaste onderdelen in de planning:
Voorafgaand aan de sprints:
- Samenstelling sprint backlog
- Afstemming tijdstippen en duur sprints
- Samenstelling SCRUM-team
Tijdens de sprints:
- Sprintplanning
- Sprint + daily’s
- Sprint review
- Sprint retrospective
Tips: Focus op de haalbaarheid van sprintdoelen. Het is altijd verstandig om bij alle werkzaamheden in de juiste volgorde van prioriteit te werken, zodat je als eerste krijgt wat je echt wilt of nodig hebt en daarna pas gaat kijken naar nice-to-haves. Ook bij het stellen van sprintdoelen is het verstandig altijd prioriteiten te stellen.
Denk ook aan bijkomende werkzaamheden als het live zetten van het nieuwe product, het inrichten van backups, het instellen van mail en analytics, training, documentatie et cetera. Het is vaak handig om ook dit soort werkzaamheden in de sprints als kaartjes in te voeren.
Sprints en Jira
Jira is een de meest gebruikte project management systemen en is met name geschikt voor het inzichtelijk krijgen en houden van de ontwikkeling voor grotere projecten. Het biedt ontzettend veel mogelijkheden voor opdrachtgevers, product owners, project managers en designers en developers om projecten op te delen in kleinere stukken, deze toe te kennen aan een persoon of een status mee te geven.
In Jira werkt een sprintbord anders dan een bord voor bijvoorbeeld support. Het grootste verschil is dat alleen de kaartjes die onder de actieve sprint valt op het bord staan. De hele lijst met kaartjes (de ‘product backlog’) vind je onder het kopje ‘Backlog’ in de zijbalk.
Uitleg bij kolommen
- Nog doen: Het kaartje staat klaar om opgepakt te worden.
- Actief: Een ontwikkelaar is met het kaartje bezig
- Blocked: Het team kan niet verder met het kaartje, omdat ze nog input nodig hebben van de klant, zoals extra informatie of inloggegevens. Wanneer de benodigde informatie of beslissing er wel is, kan het kaartje terug naar de To Do-kolom. Dit mogen onze klanten zelf doen.
- Review: De werkzaamheden van een ontwikkelaar staan klaar om beoordeeld te worden door een andere ontwikkelaar. Dit betreft vaak een technische review.
- Testing intern: Het kaartje is opgeleverd naar een test- of acceptatieomgeving en wordt gecontroleerd door iemand binnen ons team.
- Testen klant: Het kaartje kan op de test- of acceptatieomgeving door de klant getest worden. Als het kaartje goedgekeurd is kan hij op ‘gereed’. Als het afgekeurd wordt, kan het kaartje terug naar de To Do-kolom en krijgt het kaartje de status 'afgekeurd', waarbij de ontwikkelaar hem met hoge prioriteit oppakt.
- Gereed: De werkzaamheden in het kaartje zijn afgerond.
Tip: Werk van rechts naar links. Je hebt het meest aan zo veel mogelijk afgeronde kaartjes in plaats van te veel kaartjes met losse eindjes. Maak duidelijke afspraken over wanneer je wilt testen. Dan kunnen de ontwikkelaar de testomgeving goed klaarzetten voor dat moment. Probeer zo veel mogelijk één taak in één kaartje te houden. Zo houd je zicht op wat afgerond is en wat niet.
Hoe gaan we om met losse aanpassingen in de praktijk?
Soms heb je kleinere aanpassingen snel nodig aan je website die zich er niet voor lenen om in een sprint met een geheel team op te pakken. Je kunt deze aanpassingen per stuk invoeren in Jira als een issue zodat wij deze gaan uitvoeren.
Issues worden één of meerdere keren per week ingepland. We kijken daarbij naar de beschikbaarheid van de collega’s en proberen daarbij zoveel mogelijk rekening te houden met urgente zaken.
Losse werkzaamheden en Jira
Om een overzicht te houden van alle werkzaamheden, werken we met een projectmanagementsysteem genaamd Jira. Een Jira-bord voor losse issues ziet er anders uit dan een SCRUM-bord, omdat er geen afzonderlijke backlog is waaruit een selectie van issues op het bord terechtkomt. In een strippenkaartbord staan alle kaartjes standaard al op het bord. Wanneer we de issues inplannen komen ze in de kolom ‘Ingepland’ te staan en vermelden we in de issues zelf het verwachte tijdstip wanneer ze opgepakt worden. We werken standaard ‘van rechts naar links’ op het bord, d.w.z. dat we issues die in behandeling zijn (in de ‘testing’- of ‘doing’-kolommen) met voorrang oppakken.
Uitleg bij kolommen:
- Nog doen: Het kaartje staat klaar om opgepakt te worden.
- Gereageerd: Eerste feedback aan de klant waarmee bevestigd wordt dat we de issue gezien hebben en in gaan plannen. Deze feedback kan ook directe tips/acties bevatten naar gelang de aard van de issue.
- Ingepland: De issue staat in de planning voor een collega.
- Doing: Een collega is bezig met het kaartje.
- Blocked: Het team kan niet verder met het kaartje, omdat ze nog input nodig hebben van de klant, zoals extra informatie of inloggegevens. Wanneer de benodigde informatie of beslissing er wel is, kan het kaartje terug naar de backlog. Dit mogen onze klanten zelf doen.
- Review: De werkzaamheden van een ontwikkelaar staan klaar om beoordeeld te worden door een andere ontwikkelaar. Dit betreft vaak een technische review.
- Testing intern: Het kaartje is opgeleverd naar een test- of acceptatieomgeving en wordt gecontroleerd door iemand binnen ons team.
- Testen klant: Het kaartje kan op de test- of acceptatieomgeving door de klant getest worden. Als het kaartje goedgekeurd is kan hij op ‘gereed’. Als het afgekeurd wordt, kan het kaartje terug naar de backlog, waarbij de ontwikkelaar hem met hoge prioriteit oppakt.
- Gereed: De werkzaamheden in het kaartje zijn afgerond.
Tip: Soms is het fijn als je issues aan kunt melden zonder dat ze meteen ingepland hoeven te worden. Dan kun je de issues een label geven: ‘nog-niet-inplannen’. Let wel op dat je het label wel weer verwijdert wanneer het gewenst is dat wij aan de slag gaan met het issue.
Hoe werken onze Service Level Agreements?
Als je een SLA (Support Level Agreement) bij ons hebt bieden wij support bij incidenten. Bij een incident kun je denken aan situaties waarbij de website opeens onbereikbaar is of wanneer plotseling niemand in kan loggen of de mail niet werkt. Dit soort incidenten kun je direct aanmelden via support@emble.nl. Dit zorgt ervoor dat onze collega’s hier een notificatie van krijgen.
Elke vorm van SLA ( Basic, Professional of Enterprise ) heeft een eigen responstijd en binnen de afgesproken responstijd verhelpen we hij het of contact nemen we contact op over de vervolgstappen met een eventuele oplossingsrichting.
Voor incidenten gebruiken we de reguliere borden in Jira, maar met een ander issuetype (‘incident’). Wij verplaatsen zelf de issues die via support@emble.nl binnenkomen naar het juiste Jira-bord, waar je vervolgens ook de voortgang in bij kunt houden.
Wat zijn onze tarieven?
Ons standaard uurtarief is € 100,- ex. Btw. Dit tarief is een blended tarief en geldt voor al onze ontwikkelaars, ontwerpers, projectmanagers, scrum masters en consultants, ongeacht het niveau of het aantal jaar werkervaring.
Contractueel bieden we onze uren aan via:
- Strippenkaarten. In de vorm van 32, 64 en 96 en 128 uur, waarbij de uren altijd geldig blijven. Administratief eenvoudig en ideaal voor wanneer er ad hoc aanpassingen plaats moeten vinden.
- Raamcontract. Voor wanneer er geregeld werkzaamheden plaatsvinden is een raamcontract een prettige oplossing. In dit contract worden werkafspraken vastgelegd en de gemaakte uren worden aan het eind van de maand gefactureerd.
- Deelovereenkomst. Naast het raamcontract is het mogelijk een vast aantal uren af te spreken bijvoorbeeld voor de ontwikkeling van een bepaald project.
Urenverantwoording
Onze specialisten boeken hun uren via het tijdregistratiesysteem Harvest waardoor per kwartier inzichtelijk is waar en door wie aan gewerkt is. Op elk gewenst moment is het mogelijk een export te krijgen van alle gemaakte uren.
Wanneer het gewenst is dat onze experts op locatie werken, bespreken of een training geven dan is dat in overleg mogelijk. We berekenen de reistijd en kosten middels een gehalveerd tarief van € 50,- ex. Btw. Projectmanagement en uren voor de scrum master worden ook geboekt volgens ons standaard uurtarief.