Laat hem dat maar oplossen, hij is de enige die weet hoe het werkt.鈥� Veel bedrijven werken met applicaties die een aantal jaar geleden gebouwd zijn. De bouw van deze applicaties lag in de handen van een handjevol ontwikkelaars die precies wisten wat ze deden, maar dit niet documenteerden.

Inmiddels zijn veel van deze ontwikkelaars alweer bezig met het bouwen van nieuwe applicaties, ergens anders gaan werken of misschien wel met pensioen. Het bedrijf kan weliswaar verder werken met de applicaties zonder deze mensen, maar wat als er eens een systeem moet worden ge眉pdatet, of als er nieuwe innovaties of implementaties plaats moeten vinden? En wat als er bijvoorbeeld een geschreven broncode moet worden aangepast? Wie is hier verantwoordelijk voor?

Barri猫res doorbreken

E茅n van de opties om bovenstaande situatie te tackelen, is door te werken met de DevOps-principes. DevOps doorbreekt barri猫res tussen development (de applicatiebouwers) en operations (het beheerteam). En natuurlijk ben je dan nog steeds afhankelijk van specifieke mensen. Daarom is het belangrijk de shift te maken van handmatig werk naar geautomatiseerd werken. Of de mens dan overbodig wordt? Integendeel, de mens kan hierdoor juist meer tijd besteden aan innovatie, terwijl de kwaliteit en betrouwbaarheid van het systeem gegarandeerd blijven.

Geautomatiseerd versiebeheer

Stel, Christiaan maakt stuk B en C op vrijdag, maar verwijdert daarmee per ongeluk stuk A (geschreven door Jennifer op woensdag). Dan wil je dat Jennifer en Christiaan de versie van woensdag terug kunnen halen. Je kunt dit vergelijken met het werken in eenzelfde document in Sharepoint. Je wil kortom, je versiebeheer geautomatiseerd op orde hebben.

Stapsgewijs automatiseren

Het automatiseren van versiebeheer is in de wereld van DevOps mooi uitgewerkt in termen en schema鈥檚. Met Continuous Integration leg je vast wie bijvoorbeeld de code heeft geschreven, wat het doet en welke impact het op het systeem kan hebben. Continuous Delivery gaat nog een stapje verder. Daarin leg je vast hoe er geautomatiseerd wordt getest, zodat je alleen nog maar op een 鈥榞roene knop鈥� hoeft te drukken om je systeem, innovatie of update live te brengen. En met Continuous Deployment ga je n贸g een stapje verder. Hiermee borg je dat het hele proces van begin tot eind geautomatiseerd is.

Kijk maar eens:

Hoge verwachting

Niemand zit erop te wachten dat we door een systeemupdate een heel weekend niet digitaal kunnen betalen. We hebben hoge verwachtingen van onze banken, pakketbezorgers, online winkels en andere leveranciers. Om aan de verwachtingen te kunnen voldoen (snelheid 茅n kwaliteit) is naast de mens, ook automatisering cruciaal.

Wil je meer weten over DevOps of ontdekken hoe je binnen je organisatie processen (beter) kunt automatiseren op basis van de DevOps-principes?

Lees ons vorige blog over DevOps en de mens, of ons volgende blog over DevOps in een hybride omgeving.

The post De DevOps-reis (2): automatiseren kun je leren appeared first on 麻豆原创 Nederland Blogs & Nieuws.

Wat je hiervoor nodig hebt is het volgende:

• Een gestructureerd proces
• Een multidisciplinair team
• Duidelijke bedrijfsdoelstellingen en steun vanuit het management
• Betrouwbare en up-to-date data (zowel )
• Een meetbare doelstelling voor ieder initiatief
• Flexibele resources
• De juiste tools

Een flinke lijst dus. Laten we inzoomen op deze zeven punten.

1. Een gestructureerd proces

De multidisciplinaire aanpak en de behoefte aan verschillende resources op verschillende momenten maakt voorspelbaarheid bij CI noodzakelijk. Dankzij deze voorspelbaarheid kan je reguliere taken en besprekingen vooraf plannen, zodat alle betrokken partijen hieraan kunnen deelnemen.

Wanneer je snel stappen wilt zetten is het on-the-fly organiseren en improviseren van iedere stap van elke verbeteringscycli simpelweg geen optie. Een vast ritme helpt mensen bij het inplannen van andere werkzaamheden en stellen van prioriteiten. De bijdragen van collega’s aan het proces kunnen een goede motivator zijn. Een gebrek aan inzet kan de motivatie bij mensen echter juist doen verdwijnen. Zorg daarom dat je de planning strak in de hand houdt, zeker aan het begin van het project.

2. Een multidisciplinair team

Hoewel potenti毛le verbeteringen vanuit de onderkant van de organisatie worden aangedragen, brengt het CI-team hierin prioriteiten aan. Het maken van een overzicht van alle kleine problemen is daarnaast slechts de eerste stap. Hun oplossingen kunnen bijvoorbeeld specifieke expertise en kennis vereisen.

Dit betekent dat verschillende disciplines – zoals UX-ontwerpers, architecten, consultants, en managers – betrokken moeten zijn bij het bepalen van de initi毛le prioriteiten. Hun betrokkenheid bij de daarop volgende stappen is afhankelijk van de geprioriteerde initiatieven (zie #6).

3. Duidelijke bedrijfsdoelstellingen en steun vanuit het management

Nadat een lijst met mogelijke verbeteringen is opgesteld, moeten prioriteiten worden gesteld op basis van een 鈥楶ain & Gain鈥�-analyse. Je weegt hierbij de kosten af tegen de voordelen. Voor het correct in beeld brengen van de voordelen is het noodzakelijk dat je de doelstellingen van de organisatie, de afdeling en het kanaal in het oog houdt. Dit is uiteraard alleen mogelijk indien strategische doelstellingen beschikbaar zijn. Is dit niet het geval? Dan bepaalt de product owner wat prioriteit krijgt. Dit maakt hem of haar echter wel kwetsbaar voor kantoorpolitiek.

4. Betrouwbare en up-to-date data

Een goed CI-proces start met het observeren van en luisteren naar mensen in de praktijk. Dat zijn in dit geval werknemers en klanten. De theorie achter CI is dat je structureel kleine problemen optimaliseert.

Over het algemeen vraag je de CEO, afdelingsmanager of strategische consultant dan ook niet naar hun mening over de beste verbeteringen. Zij hebben uiteraard invloed op het proces, alleen pas later in het stadium. Initieel wil je juist mensen die dicht bij de bron van problemen staan bij het proces betrekken. Zij kunnen je vertellen of je een stap in het proces moet verwijderen of juist beter een extra stap kunt toevoegen. Of dat het versoepelen van een bepaalde integratie voordeel kan opleveren.

Deze input is afkomstig uit , die feedback van zowel klanten als werknemers omvat in combinatie met (big) data-analyses van operationele data. Deze gegevens verzamel je via bijvoorbeeld interne en externe onderzoeken, AB-testen, interviews, webanalytics, BI-analyses, machine learning en expertreviews. Verlies hierbij nooit het volledige end-to-end-proces en de customer journey uit het oog. Zo weet je zeker dat alle initiatieven zijn gericht op de aspecten van de organisatie die de meeste waarde voor de business opleveren.

5. Een meetbare doelstelling voor ieder initiatief

Het kernteam stelt voor ieder initiatief het volgende op:

• Een duidelijke definitie van het initiatief
• De waarde van het initiatief voor de business (voordelen)
• Een schatting van de benodigde arbeidstijd en budget (kosten)
• Duidelijke en meetbare KPI鈥檚 die succes defini毛ren
• De verwachte resultaten

Definieer een duidelijke methode voor het beoordelen van initiatieven, zodat iedereen op 茅茅n lijn zit wat betreft de resultaten en weet wat een initiatief succesvol maakt. Hiermee voorkom je onproductieve discussies. Het definitieve besluit over geselecteerde initiatieven is aan de product owner, die hierbij kijkt naar onder meer technische afhankelijkheden, resources en andere relevante uitdagingen.

6. Flexibele resources

Hoewel het kernteam zich aan een strikt proces houdt, is het uitvoeren van taken gerelateerd aan verbeteringen minder voorspelbaar. Deze moeten daarom voor iedere cycli opnieuw gepland worden. Sommige taken kunnen worden toegewezen aan het kernteam, terwijl andere wellicht gespecialiseerde of andere resources vereisen. Je kunt dit op verschillende manieren managen, afhankelijk van de aard van de organisatie. Enkele opties zijn:

• Het reserveren van een percentage van de resources per functie (bijvoorbeeld UX, ontwerp of development). Op basis van beschikbaarheid en prioriteit maak je vervolgens een planning.
• Problemen met meerdere disciplines delen met behulp van een Kanban-bord.
• Het cre毛ren van een echt multidisciplinair team, dat zich per cycli op een specifieke vertical richt. Denk hierbij aan een kwartaal dat volledig is toegewijd aan het verbeteren van lead generation. Let op: deze optie is afhankelijk van de flexibiliteit van je architectuur.
• De inzet van flexibele medewerkers of externe experts die je op basis van de CI-behoeften direct kunt inschakelen (zie het artikel over Blended Teams).

Een goede product owner kan in grote lijnen inschatten waar de komende paar cycli resources nodig zijn. Daarnaast verschuift hij indien nodig prioriteiten op basis van de beschikbare resources. Het belangrijkst is het vinden van een juiste balans tussen alle taken en resources. Zorg dat de prioriteiten niet structureel afhankelijk zijn van de beschikbaar van resources, en dat je indien nodig nieuwe prioriteiten aan de bovenkant van het lijstje kunt toevoegen.

7. De juiste tools

De behoefte aan tools is onder meer afhankelijk van de omvang van het project. Indien het kernteam bijvoorbeeld op een vaste locatie samenwerkt is communicatie vaak minder een probleem. Werken echter meerdere teams samen aan een project of werkt 茅茅n team aan meerdere producten? Dan kan communicatie al snel een uitdaging zijn. In alle gevallen moet er een systeem zijn dat input verzamelt en resultaten inzichtelijk maakt.

Communicatie

Een van de meest belangrijke tools die je kunt omarmen is een communicatieprotocol waartoe iedereen toegang heeft. Denk hierbij aan Skype, Microsoft Teams, Slack of een andere tool die de communicatie verbetert.

Voor het komen tot nieuwe idee毛n en ontwikkelen van een roadmap voor de realisatie van deze idee毛n zijn eveneens tools beschikbaar. Denk hierbij aan tools die helpen bij:

• het beheren van idee毛n (van creatie tot het uiteindelijke selecteren)
• het cre毛ren van een roadmap
• backlog management
• project- en resourcemanagement
• het opstellen van doelen en monitoren van prestaties

Een voorbeeld van een dergelijke tool is Aha!

Feedbackmanagement

Het meest belangrijke onderdeel van CI is wellicht feedbackmanagement. Zonder de juiste en actuele input van klanten en jouw eigen organisatie is het zicht op potenti毛le verbeteringen beperkt.

Dit brengt risico鈥檚 met zich mee. Zo kan je belangrijke opties over het hoofd zien of te veel waarde toeschrijven aan een een bepaalde optie. Wie serieus aan de slag wilt met het doorvoeren van incrementele verbeteringen en veel tijd investeert in het opstellen van een team en proces, heeft hiervoor een sterke fundering nodig. Start het proces niet op basis van aannames en zorg dat zowel de input als output meetbaar is.

Slimme software kan hierbij helpen. Met een applicatie als Qualtrics stroomlijn je het verzamelen van input vanuit klanten en werknemers. Qualtrics vergroot ook het inzicht in het project. Zo zijn resultaten van initiatieven in real-time beschikbaar via op maat gemaakte dashboards.

The post 7 elementen om van Continuous Integration een succes te maken appeared first on 麻豆原创 Nederland Blogs & Nieuws.