Delta-NDevOps is een must binnen HBO ICT-opleidingen

Maak studenten ICT bekend met de DevOps cultuur
en de juiste tools

In dit on-demand tijdperk moet nieuwe software zo snel mogelijk en zo goed mogelijk opgeleverd worden tegen acceptabele kosten. Deze paradox vraagt om een radicaal andere manier van samenwerkenDevOps. Alle koplopers in softwareontwikkeling beantwoorden aan de moderne marktvraag dankzij cross-functionele DevOps-teams. Het is nu aan de HBO-opleidingen ICT om studenten klaar te stomen met de juiste mindset, tools en vaardigheden. 

DevOps

Voldoet een app niet meer of mis je handige functionaliteiten? Dan stap je toch over op een andere! Snelle software-introductie en aanpassingen zijn belangrijk om klanttevredenheid op peil te houden en marktaandeel te behouden of te vergrotenTraditioneel was een oplossing pas beschikbaar als deze helemaal af was en werd goedgekeurd via talloze checks door verschillende interne afdelingen. Blijkt achteraf een (deel van de) oplossing achterhaald? Dan was het terug naar de tekentafel en begon het hele proces weer opnieuw. Dit proces is tijdrovend en de verantwoordelijkheid is versnipperd;  organisatieonderdelen vinden namelijk alleen hún onderdeel belangrijk. Het uiteindelijk resultaat, een werkende oplossing en klanttevredenheid, raakt hierdoor ondergesneeuwd.

DevOps: het alles-in-één team  

Om mee te draaien in deze dynamische wereld, moeten organisaties sneller kernfunctionaliteiten live zetten die meteen aan de klantvraag voldoen. Dit vraagt om snellere releases. Dit lukt beter met teams waarin verschillende disciplines samenkomen en die hecht samenwerken van ontwikkeling tot en met de uitrol en het beheer. Agile softwareontwikkeling bracht de testerde developer en de architect al samen in het team. DevOps (een samentrekking van de termen ‘development’ en ‘operations’) voegt er ook nauwe samenwerking met de beheerorganisatie aan toe. 

Sneller waarde leveren 

DevOps brengt softwareontwikkeling, architectuur, testen, technisch beheer, infrastructuur en security samen. In plaats van één ontwikkelcyclus heb je nu een groot aantal korte ontwikkelcycli. Hierdoor kan het team op basis van interne feedback en nieuwe eisen van de klant al tijdens het ontwikkelproces veranderingen doorvoeren. Het resultaat: een product dat sneller én efficiënter live staat en beter aansluit op de veranderende klantwens. DevOps is een bedrijfscultuur die sneller waarde levert. 

Cultuuromslag leidt tot betere software 

devops team

DevOps vereist een nauwe, transparante samenwerking tussen disciplines, duidelijke gezamenlijke doelen en veel communicatie. Het maakt een einde aan over de schutting gedrag en sloopt de fysieke, culturele en budgettaire muren binnen bedrijven. DevOps werken is vooral een cultuurverandering waarin afdelingen die eerst voor zichzelf en eigen KPIs werkten echt samenwerken aan het eindresultaat. Omdat alle toonaangevende softwareontwikkelaars zo werken, spreekt het voor zich dat HBO’s ICT ook modules DevOps aanbieden.

Bereid studenten voor op DevOps

Delta-N verzorgt al enkele jaren een zeer succesvolle leergang DevOps op De Haagse Hogeschool. Hierin leren studenten niet alleen de manier van samenwerken, maar ook de methoden en tools die ze daarin hanteren. Samenwerken via een (virtueel) kanban-bord en automatisering zijn daar een belangrijk onderdeel van. In het ontwikkelproces kan kwaliteitscontrole van de geschreven code en integratie ervan tot en met de uitrol worden geautomatiseerd. Eerder kostte dit veel herhalend handwerk, dat bovendien erg foutgevoelig is. De techniek is een belangrijke motor om DevOps-werken te ondersteunen. Lees hier meer over de leergang DevOps bij de Haagse Hogeschool.

De technische motor achter DevOps 

Microsoft Azure DevOps is een geïntegreerde cloudoplossing die alle stappen van softwareontwikkeling ondersteuntVan ontwikkeling tot versiebeheer, het plannen en traceren van projecten en automatische deployments, je kunt de toolset overal en altijd benaderenHet platform is gratis tot 5 gebruikers en zij kunnen vanwege de gebruiksvriendelijkheid van het systeem binnen een minuut aan de slag in een nieuwe projectomgeving. Je haakt ook gemakkelijk externe gebruikers aan. 

Azure DevOps Git

In 10 minuten uitrollen 

In deze suite integreren alle onderdelen naadloos. Van de Azure Boards met de agile tools als de kanban-borden tot en met beheer via repositories, Git en geautomatiseerde uitrol via Azure Pipelines. Vanwege het open karakter integreert het niet alleen gemakkelijk met Azure, maar ook met andere cloudplatformen. Het werkt simpel en intuïtief, als je de requirements en code klaar hebt staan heb je binnen 10 minuten je nieuwe oplossing uitgerold. 

Continu nieuwe mogelijkheden 

Over snelheid gesproken: elke 3 weken zijn nieuwe features beschikbaar die taken in de projectomgeving gestroomlijnder of gemakkelijker makenVan een automatische notification feed in plaats van e-mails tot en met ondersteuning voor het updaten van websites zonder onderbreking in de dienstverlening dankzij zero downtime deployment. Sluit je studenten aan op dé nieuwe manier van softwareontwikkeling en start met DevOps met Microsoft Azure DevOps als projectomgeving.

Wil je weten hoe? Neem dan contact met ons op via onderstaand formulier. 

 

  • DevOps-program-banner
  • Neem contact met ons op

    Contactverzoek

    • Dit veld is bedoeld voor validatiedoeleinden en moet niet worden gewijzigd.
  • Miquel Asmus

    Account Manager

      • LinkedIn
      • Mail
      • Telefoon
      • 085 – 487 52 20
        miquela@delta-n.nl
        Connect met Miquel
        invisible box
  • In steeds meer bedrijven wordt een vorm van Scrum gebruikt. Ik schrijf bewust een vorm, omdat veel bedrijven aanpassingen doorvoeren die ze goed uitkomen. Ik ben niet tegen aanpassen van Scrum. Zelfs in de Scrum guide staat dat je best zaken aan mag passen. Helaas zijn veel aanpassingen juist zaken die het leveren van waarde tegenwerken.

    5 ideeën, die je tegenhouden in je verbetering

    In dit blog ga ik in op 5 verschillende zaken die ik in praktijk tegengekomen ben, die Scrum of agile werken juist tegenwerken in het leveren van meer waarde naar je klanten.

    Je kunt alleen aan het einde van de sprint een release naar productie brengen

    Dit is niet waar, maar ik snap waar het vandaan komt. Volgens de Scrum guide moet je aan het einde van je sprint een “working increment” hebben. Daarnaast zijn we als we net begonnen zijn met Scrum nog gewend aan die grote projecten, die 3 maanden of langer duurden. Dus 2-4 weken is al best snel.

    Scrum verbiedt echter niet dat je meerdere keren per sprint nieuwe functionaliteit naar productie zet. Sterker nog, het Agile manifesto zegt zelfs:”Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Je kunt dus zelfs elke user story (product backlog item in Scrum) direct als je er klaar mee bent naar productie brengen, als je er klaar mee bent.

    Het is toch mooi om tijdens de sprint review te kunnen vertellen dat de functionaliteit al op productie staat. En wat de eindgebruikers er van vinden.

    Iedereen moet alles kunnen binnen het Scrum team

    Teams moeten cross-functioneel en zelf-organiserend zijn. Dit zorgt ervoor, dat het team meer betrokken is bij het product dat ze opleveren en dat risico in continuïteit verminderd wordt.

    Dit is door veel organisaties geïnterpreteerd als: iedereen moet alles kunnen (en soms zelfs overal expert in zijn). Dus als er ontwikkeld wordt in meerdere talen, dan moet iedereen dat kunnen. En dat geldt ook voor bijvoorbeeld testen, de verschillende testtools, ontwerp en documentatie.

    Is het handig, dat mensen meerdere skills binnen het team hebben? Jazeker. Is het handig, dat elke skill door verschillende mensen bezit wordt? Jazeker. Moet iedereen alles kunnen? Zeker niet! Het t-shaped model, of pi-shape model geven heel mooi aan hoe je om kunt gaan met een of twee skills, die je erg goed kan en de rest heb je op zijn best een basis kennis van.

    Het is dus niet nodig, dat iedereen alles kan, het is wel zeker nodig, dat alles gedaan kan worden door minimaal twee teamleden, zodat je niet afhankelijk bent van één persoon.

    De techniek dicteert de manier van werken

    Dit is niet perse een bewuste keuze, maar ik zie dit wel vaak onbewust gebeuren binnen bedrijven.

    Binnen de organisatie is ooit begonnen met de aanschaf van apparatuur; specifieke servers, infrastructuur en werkstations. Dat is allemaal gedaan met het idee om het beste te kunnen werken in die specifieke omgeving.

    Wat ik heb zien gebeuren, is dat binnen de organisatie begonnen wordt met Scrum en dat het team maar op die nieuwe manier moet gaan werken. Het team moet op een andere manier werken, die meer op zou moeten leveren dan de oude manier van werken. Het probleem is dat alle ondersteuning daarvan, en dan vooral de techniek, is afgestemd op die oude manier. We proberen dus een nieuwe mindset en een nieuwe manier van werken in te voeren en passen dan maar de zaken aan in het team die niet kunnen. Denk daarbij aan bijvoorbeeld het aantal beslispunten waar je langs moet voordat iets naar productie gezet kan worden.

    De techniek is ooit ingesteld om de processen van dat moment te ondersteunen. Nu moeten ze aangepast worden naar de nieuwe processen. Dit hoeft niet in één keer, dat kan ook niet altijd, maar in het proces van continue verbeteren kan ook de omslag naar de nieuwe manier van werken meegenomen worden voor de ondersteunende zaken.

    Velocity is een goed meetinstrument voor voortgang

    Zoek in Google op velocity bij scrum, dan wordt duidelijk waarom het vaak niet juist gebruikt wordt. Velocity is niet meer dan een inschatting van wat het team denkt te kunnen doen in een sprint. Dit is geen belofte of een verplichting, dit is puur een inschatting vooraf. Het sleutelbegrip in deze zin is: het team. Het team bepaalt hoeveel werk ze denken te kunnen doen op basis van de informatie die ze hebben (bijvoorbeeld met ervaring met vorige sprints, diepte van de user stories).

    Wat te veel gebeurt, is dat het team afgerekend wordt op lagere velocity en waarom ze minder hebben gedaan, of zelfs vergeleken worden met andere teams. Er zijn zelfs organisaties, die (het verhogen van) velocity gebruiken als KPI tijdens beoordelingsrondes. Dit is raar, want het team bepaalt zelf haar velocity en velocity als KPI zal de verbetering van het team tegengaan.

    Velocity is maar voor twee zaken goed te gebruiken:

    1.       Voor het team om te bepalen hoeveel ze denken te kunnen opleveren in deze sprint

    2.       Voor de product owner om een inschatting te kunnen maken wanneer een bepaalde functionaliteit klaar zou kunnen zijn met de huidige informatie.

    “Wij kunnen het zelf wel”

    De voorgaande vier punten zijn signalen, dat dit idee waarschijnlijk wel leeft binnen de organisatie. We hebben namelijk jarenlang projectmanagers gehad en de mensen, die beslissen zijn vaak ervaren managers. Dus dat Scrum implementeren en Scrum master zijn, dat kunnen we zelf wel. Daar hebben we niemand van buiten voor nodig.

    Scrum ( of agile in het algemeen) is simpel te begrijpen, maar om het goed te doen moet je meer dan alleen die 19 pagina’s kennen van de Scrum guide. Het is voor de meeste organisaties een compleet nieuwe manier van werken. Door de verandering te laten doen door mensen die gewend zijn op de huidige manier te werken, zal de verandering niet of niet op de juiste manier in de organisatie landen. Als daarna toch een Scrum master of Agile coach van buiten moet komen om te helpen, duurt het alleen maar langer. Niet alleen omdat diegene de oude manier van werken moet veranderen, maar ook om de problemen op te lossen die door de verandering zijn ontstaan. Dit levert veel frustratie en vertraging op binnen de organisatie, maar zeker binnen de teams, die het meeste met Scrum moeten werken.

    Dus 5 ideeën, die je tegenhouden in je verbetering. Herken je één of meerdere van deze voorbeelden uit je eigen organisatie? Neem dan eens contact op om echt te verbeteren.

    Alex Roos, DevOps Consultant/Agile coach