Overzicht van ontwikkelingsproces en procedures

Dit document geeft een overzicht van de ontwikkelingsprocessen en -procedures van Leading2Lean. Dit proces beschrijft de verantwoordelijkheden, beleidsregels en procedures die Leading2Lean moet volgen bij het aanbrengen van wijzigingen in de productieservice en -infrastructuur. Alle medewerkers zijn verplicht dit beleid te volgen.

Het technologieteam van Leading2Lean heeft als taak een stabiele en betrouwbare IT-infrastructuur voor onze klanten te bieden. Het doel van het ontwikkelingsproces is het minimaliseren van serviceonderbrekingen in onze datacenteromgeving en het bevorderen van systeembeschikbaarheid en -integriteit. De Chief Technical Officer (CTO) is verantwoordelijk voor het onderhouden en indien nodig bijwerken van het ontwikkelingsproces en de procedures. Dit proces wordt verder geregeld door organisatorische controles die zijn gedefinieerd als onderdeel van ons AICPA SOC 2 Type 2-complianceprogramma. Deze controles worden jaarlijks door onze externe auditor gecontroleerd.

Het ontwikkelingsproces begint met een ontwikkelaar die het ticket beoordeelt, met collega's over architectuur en ontwerp overlegt, code schrijft, feedback ontvangt van het QA-team en uiteindelijk de software aan klanten uitbrengt. 

Reikwijdte

Dit document definieert de levenscyclus van functieverzoeken en fouten. Het beschrijft ook de processen en procedures die worden gebruikt om ervoor te zorgen dat voor elke release de juiste tests en validatie plaatsvinden. Dit document beschrijft niet het wijzigingsbeheerproces zoals gedefinieerd in ons Overzicht van het beleid voor wijzigingsbeheer.

Definities

Achterstand: Een verzameling fouten en functies waarvan de ontwikkeling nog niet is begonnen. De achterstand is de plaats waar alle tickets met een lagere prioriteit staan. 

Fout: Een functie die niet werkt zoals bedoeld. Fouten kunnen variëren van niet-ernstig tot extreem ernstig. De foutenlijst is de plaats waar alle fouten met een lagere prioriteit staan. Tickets worden tijdens de triagevergadering op de foutenlijst geplaatst. Tickets worden vanuit de foutenlijst toegewezen aan leden van het ontwikkelingsteam.

Functie of verbetering: Gedrag dat nog niet voor de software is ontwikkeld. Dit kan een wijziging van bestaande functionaliteit of het creëren van nieuwe functionaliteit zijn.

Project of epic: Een verzameling fouten en functies. Projecten worden beheerd op de roadmap. 

Roadmap: Een verzameling projecten. De roadmap is het planningsbord voor grotere projecten. De roadmap stuurt de ontwikkeling van nieuwe functies, groot en klein. 

Triage: Verzameling van nieuwe tickets. De Triage-lijst is waar alle nieuwe tickets worden aangemaakt. Het Triage-team plaatst tickets vervolgens in de lijst Bugs, Roadmap of Backlog.

Overzicht

Er zijn 3 hoofdfasen voor elk ontwikkelingsticket: 1. Planning, 2. Ontwikkeling en 3. Kwaliteitstesten. Elke fase wordt hieronder besproken.

Planning

We hanteren een multidisciplinaire triageaanpak voor het planningsproces. Onze Support-, Ontwikkelings- en Kwaliteitsteams komen regelmatig bijeen voor een Triage-bijeenkomst om nieuwe problemen, functieverzoeken en verbeteringen te beoordelen. Op basis van de ernst kunnen deze problemen een geëscaleerde break/fix-responscyclus in gang zetten om de dienstverlening te herstellen bij items met hoge prioriteit of wanneer de dienstverlening achteruitgaat. Anders krijgen ze een initiële prioriteit en worden ze doorgegeven aan ons Productteam voor verdere planning, prioritering en inroostering.

Functies worden doorgaans gepland met de inbreng van een klein aantal mensen.  Dit kunnen leden van het Productteam, inhoudelijke experts, klanten enzovoort zijn. Dit wordt aangestuurd door ons productmanagementteam.

Het merendeel van de functieverzoeken wordt besproken tijdens de Roadmap-planningsbijeenkomst. Tijdens deze bijeenkomst worden projecten en geëscaleerde functieverzoeken besproken. Projecten worden geprioriteerd ten opzichte van andere projecten, en functieverzoeken worden beoordeeld en naar de backlog verplaatst. Functieverzoeken kunnen worden gekoppeld aan een project op de roadmap.

Ontwikkeling

Zodra het planningsproces is voltooid, wordt dit werk toegewezen aan Development. Het Developmentteam beschikt over een eigen set ontwikkelomgevingen die een spiegelbeeld zijn van onze productieomgeving. Dit is een essentieel onderdeel van ons kwaliteitsprogramma. In elke stap van onze ontwikkelingslevenscyclus (Dev, QA, Staging en Productie) onderhouden we een afzonderlijke infrastructuur om ervoor te zorgen dat al het voltooide werk goed wordt getest en geverifieerd voordat het in onze productieomgeving terechtkomt.

We maken gebruik van een volledige set industriestandaard ontwikkelingstools die zijn ontworpen voor versiebeheer, geautomatiseerd testen, statische codeanalyse en codekwaliteit. Deze tools geven de ontwikkelaar vroegtijdige en frequente feedback om de best mogelijke codekwaliteit te waarborgen. Ze helpen ook bij het handhaven van een goede scheiding tussen ontwikkelingsbranches om kruisbesmetting te voorkomen tussen ontwikkelaars die aan verschillende projecten, taken en onderdelen van de codebase werken. Deze tools bieden een gestandaardiseerde methode voor collegiale codebeoordelingen en goedkeuringsprocessen, zodat alle code die klaar is voor Quality Assurance Testing alle geautomatiseerde test- en validatiecontroles heeft doorstaan.

Onze ontwikkelaars communiceren rechtstreeks met het supportteam, het productteam of andere ontwikkelaars wanneer er vragen ontstaan over de implementatie van een ticket. Voor alle UI-wijzigingen is goedkeuring van het productteam vereist. Omdat UI-wijzigingen van invloed zijn op klanten en mogelijk training vereisen, werken we samen met klanten, support en het productteam om ervoor te zorgen dat er zorgvuldig wordt omgegaan met het ontwerpen van UI-wijzigingen, zodat de impact op klanten tot een minimum wordt beperkt. Alle UI-wijzigingen worden tijdens de Quality Assurance Testing-fase ook door ons supportteam beoordeeld om te valideren dat de juiste functionaliteit aanwezig is en dat klanten de juiste meldingen en training krijgen.

Ontwikkelaars zijn verplicht om onze geautomatiseerde testsuite succesvol uit te voeren voor alle wijzigingen als onderdeel van hun normale werkprocedures. Zodra het ticket deze geautomatiseerde tests heeft doorstaan, kan het worden beoordeeld door iemand anders dan de ontwikkelaar. Hierdoor weten belangrijke teamleden dat het tijd is voor feedback en wordt aangegeven dat het ticket dichter bij een release komt.

Alle code wordt door een andere ontwikkelaar collegiaal beoordeeld voordat deze aan het QA-team wordt overgedragen. Dit helpt ervoor te zorgen dat meer dan één persoon weet en begrijpt wat er wordt gewijzigd en waarom. Het doel van een codebeoordeling moet zijn om na te denken over het overkoepelende doel van de wijzigingen, de code te controleren op eenvoudige fouten, de code te scannen op inefficiënties, om verduidelijking te vragen wanneer iets niet juist lijkt en te proberen consistent te blijven met de coderingsstandaarden en best practices. Soms zal de oorspronkelijke ontwikkelaar de code refactoren vanwege feedback tijdens de testfase. Als dit leidt tot een aanzienlijke hoeveelheid codewijzigingen, wordt een aanvullende beoordeling uitgevoerd. Wanneer de consensus over de codebeoordeling is vastgelegd en gedocumenteerd, is de code klaar om aan het QA-team te worden vrijgegeven

Quality Assurance Testing

Zodra de geautomatiseerde testsuite succesvol en zonder fouten is voltooid en de codebeoordeling succesvol is afgerond, kan het QA-team beginnen met het Quality Assurance Testing-proces.

De twee belangrijkste activiteiten die bij het testproces betrokken zijn, zijn het uitvoeren van geautomatiseerde testscripts en handmatig testen. L2L beschikt over een reeks UI- en unittests die vanaf de opdrachtregel worden uitgevoerd. Er is ook een lintingproces dat op de code wordt uitgevoerd om basale programmeerfouten te controleren. Alle ontwikkelaars moeten zowel de testsuite als het lintingproces uitvoeren voordat ze hun code ter beoordeling indienen. Het QA-team voert een eigen beoordeling uit van de resultaten van de geautomatiseerde testsuite nadat de code naar de QA-testomgeving is uitgerold. Dit zorgt ervoor dat we een schone testomgeving hebben om te beoordelen of de code-update functioneert zoals ontworpen en volgens onze kwaliteitsnorm.

Het QA-team coördineert het handmatig testen van code om aanvullende kwaliteit te waarborgen. Feedback van het QA-team wordt toegevoegd aan het ontwikkelingsticket. Vaak moet code worden geherstructureerd en bijgewerkt voordat QA goedkeuring geeft. QA geeft aan dat de code klaar is om te worden samengevoegd door het pull request goed te keuren. QA voegt de code toe aan de hoofdcodebase zodra alles is goedgekeurd. Dit zorgt ervoor dat ontwikkelaars geen code kunnen samenvoegen met onze hoofdcodebase en het QA-proces kunnen omzeilen.

Tijdens de kwaliteitsborgingstestfase zal het QA-team ook teamleden van support en de klant inzetten om gebruikersacceptatietests uit te voeren. Deze tests zijn essentieel om ervoor te zorgen dat de codewijzigingen bruikbaar zijn, voldoen aan de behoeften van de klant en in overeenstemming zijn met eventuele regelgeving en vereisten binnen de branche.

Wijzigingsbeheerproces en implementatie in Productie

Om ervoor te zorgen dat wijzigingen in onze productieomgeving een standaardproces volgen, hebben we een wijzigingsbeheerproces geïmplementeerd zoals gedefinieerd in ons Overzicht van het beleid voor wijzigingsbeheer. Dit zorgt ervoor dat we binnen de organisatie over de juiste controles en waarborgen beschikken om de kwaliteit, beveiliging en beschikbaarheid van de productieomgeving te waarborgen. Zie de bovenstaande link voor meer informatie over dit proces.

Het is belangrijk om op te merken dat L2L als onderdeel van het wijzigingsbeheerproces een geautomatiseerd implementatiescript gebruikt om software vanuit de coderepository naar klantservers uit te rollen. Werknemers werken de productieomgeving nooit handmatig bij. Dit geautomatiseerde systeem maakt voor elke nieuwe release/implementatie een audittrail aan en controleert of de juiste goedkeuringen aanwezig zijn. Zodra dit is voltooid, mogen de releasescripts de productieservers bijwerken. Dit geautomatiseerde script zorgt ook voor interne bedrijfsnotificatie van de implementaties. Zodra de implementatie is voltooid, voert dit geautomatiseerde systeem ook "smoke tests" uit om te valideren dat de implementatie succesvol was en dat de productieomgeving correct functioneert.

Retrospectieve vergadering

In het geval dat vrijgegeven code een oud probleem opnieuw veroorzaakt of ervoor zorgt dat het systeem een melding genereert, zal er een retrospectieve vergadering, ook wel een post-mortem genoemd, plaatsvinden. Het doel van de vergadering is om de feiten met betrekking tot het vrijgeven van de foutieve code te verzamelen, manieren te bespreken om soortgelijke gebeurtenissen in de toekomst te voorkomen, taken toe te wijzen met betrekking tot het voorkomen van toekomstige gebeurtenissen en het team over het incident te informeren. Deze vergaderingen moeten binnen 36 uur na de gebeurtenis plaatsvinden en er moeten zoveel mogelijk ontwikkelaars en leden van het kwaliteitsborgingsteam bij betrokken zijn voor analyse van de hoofdoorzaak en trainingsdoeleinden. 

Klantmelding

Klantmeldingen kunnen op meerdere momenten tijdens dit proces plaatsvinden. Klanten worden vaak geraadpleegd tijdens de plannings-, ontwikkelings- en QA-fasen, evenals nadat de code is vrijgegeven. De klant wordt op de volgende manieren geïnformeerd:

• Persoonlijk contact / geplande vergaderingen. Klanten die betrokken zijn bij specifieke ontwikkelingsprojecten kunnen worden uitgenodigd om deel te nemen aan regelmatige updatevergaderingen om plannen, ontwerpen en de projectstatus te beoordelen.
• Persoonlijke e-mail aan klanten. Alle oorspronkelijke supporttickets worden bijgewerkt met de mededeling dat de wijziging is vrijgegeven voor productieservers, waarna het ticket wordt gesloten. Als er geen supportticket is aangemaakt, kan een supportmedewerker rechtstreeks contact opnemen met de klant. Als slechts één klant door een wijziging is getroffen, worden mogelijk geen andere meldingsmethoden gebruikt.
• Wijzigingslogboek. Alle wijzigingen die gevolgen hebben voor klanten bevatten een wijzigingslogboek. Dit omvat bugfixes, kleine updates en functieverzoeken. Wanneer een wijziging slechts gevolgen had voor één klant en de impact gering was, en als er rechtstreeks contact met een klant is opgenomen, wordt mogelijk geen wijzigingslogboek toegevoegd. Klanten kunnen het wijzigingslogboek openen via het menu Support in de applicatie.
• Massamail. Bij alle grote wijzigingen aan de app wordt een e-mail naar alle beheerders gestuurd. Massamails worden voornamelijk gebruikt voor productaankondigingen en grote UI-verbeteringen, maar kunnen ook voor andere scenario's worden gebruikt.
• Meldingen in de app kunnen worden gebruikt voor wijzigingen met gevolgen.