DevOpsModern ICT-onderwijs faciliteren zonder omkijken

Laat studenten zonder gedoe grenzeloos leren in de cloud 

 

Studenten tijdens college

Opleidingen HBO-ICT kunnen tegenwoordig niet meer om de cloud heen. Daar vinden ze de tools die studenten na het afstuderen ook gebruiken om oplossingen te maken voor de maatschappij. Idealiter geef je ze een budget wat ze volledig vrij kunnen besteden. Op die manier stimuleer je zelfsturing en creativiteit. Met Microsoft Azure geef je ze die vrijheid zonder dat ze iets van een ander kapotmaken, ongestraft afkijken of budgetten overschrijden. 

De ideale werknemer is creatief, zelfredzaam, verantwoordelijkeen teamplayer en ziet de kracht van nieuwe digitale oplossingen. Het is de taak van hogescholen om ICT-studenten met deze eigenschappen klaar te stomen voor een succesvolle toekomst. De techniek van nu en de toekomst ligt in de cloud. Hier vinden studenten alle bouwstenen om snel innovatieve en schaalbare oplossingen te maken.  

 

Stimuleer zelfstandigheid en creativiteit 

Veel on-premise oplossingen kun je zien als een bouwdoos met daarin 3 legoblokjes. Dcloud daarentegen is een continu groeiende legodoos met een onbeperkt aantal legoblokjes van allerlei soorten en maten die altijd in elkaar passenJe vindt er bouwplannen, maar niets staat je in de weg om zelf bouwstenen te combineren tot een automatisch schaalbare website of een zelflerende chatbot voor de klantenservice. Je wil dat je studenten daarin zelf keuzes maken en zelf de bouwstenen via selfservice afnemen en bouwen. Dat prikkelt hun verbeeldingsvermogen en verbetert zelfstandigheid. 

Cloud-boek

 

Volledige vrijheid binnen kaders 

In een digitale wereld zonder grenzen leiden enthousiasme en nieuwsgierigheid wel eens tot budgetoverschrijdingen en defecte systemen. Vallen en opstaan is leerzaam, maar mag niet ten koste van anderen gaan. Tijdens opdrachten wil je niet bij hoeven sturen, of je zorgen maken dat studenten andermans werk slopen of accounts uit de schooldatabase verwijderen. Met Microsoft Azure geef je studenten en leraren de vrijheid en tools voor modern onderwijs en tegelijk heb je er zelf geen omkijken meer naar. Dat dankzij een eenvoudige en doeltreffende governance. 

microsoft azure banner

 

Gemakkelijk projectgroepen met budgetten aanmaken 

kosten besparen met Azure

Bij de Haagse Hogesschool werken ze al op die manier. Toegangsrechtenprojectgroepen en budgetten klik je eenvoudig in enkele minuten bij elkaar. Studenten kunnen direct aan de slag met bijvoorbeeld een groepsbudget van 75 euro per maand. Daarmee kiezen ze zelf hun resources; ze bepalen zelf met welke databases, virtuele machines of cognitive services ze hun oplossingen maken. Er zijn alleen een paar regels ingesteld zodat ze niet in één keer hun budget erdoorheen jagen met bijvoorbeeld het huren van één zware virtuele machine.

 

Automatische budgetdiscipline bijbrengen 

Dagelijks lezen we in de media dat budgetdiscipline overheden en bedrijven niet altijd even gemakkelijk afgaat. Een stok achter de deur zou handig zijn. Om projectgroepen en docenten hierin te helpen krijgen ze automatisch een e-mail als ze op 80% van hun budget zitten, eentje als ze op 100 % zitten en bij 20% budgetoverschrijding krijgen ze bericht dat al hun resources verwijderd zijn. Het is dan natuurlijk wel zo verstandig als ze via automatisering deze resources met één druk op de knop opnieuw aan kunnen makenOp die manier houd je de zelfsturing binnen de financiële kaders en geef je studenten inzicht in de gevolgen van hun keuzes. Docenten houden gemakkelijk alle vorderingen bij en krijgen, net als ICT-managers, budgetrapportages. Kijken studenten af of kopiëren ze andermans werk en wil je dat niet? Dankzij de logging is dat gemakkelijk achterhaald. 

 

Start met modern onderwijs zonder gedoe 

Wil jij als ICT-manager modern onderwijs faciliteren zonder gedoe? Met Microsoft Azure in combinatie met de oplossing van Delta-N geef je studenten en leraren de tools om grenzeloos te ontdekken en te bouwen binnen de kaders die jij stelt. Wil je weten hoe we jou hierin kunnen helpen? 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