Als je niet begrijpt wat DevOps is, dan is hier een korte samenvatting. DevOps is een set van praktijken die de angsten van ingenieurs vermindert en het aantal software-uitval vermindert. Gewoonlijk verkort het ook de time-to-market — de periode van idee tot levering van het eindproduct aan klanten, wat snelle zakelijke experimenten mogelijk maakt..
Hoe begin je met de DevOps-transformatie? Kort gezegd: kies de service waarmee je het proces begint, identificeer degenen die met de service te maken hebben, maak een Value Stream Map, stel een tijdelijk team samen dat de transformatie in het begin zal begeleiden en geef het een taak. Herhaal de cyclus het nodige aantal keren.
Een gedetailleerd plan voor de DevOps-transformatie met voorbeelden en instructies vind je verderop — in de uiteenzetting Andrey Alexandrov — van een engineer bij Express42, die adviseert over het tot stand brengen van DevOps en dit proces versnelt, omdat ze al een kaart van valkuilen hebben opgesteld. Als jij denkt dat een transformatie niet nodig is, of als je speciale omstandigheden hebt waardoor DevOps-praktijken niet geschikt zijn, gebruik dan het verslag als een handleiding voor het identificeren en verhelpen van obstakels.
Als je je zorgen maakt over de DevOps-transformatie, heb je een groot bedrijf en moet je dit proces geleidelijk opschalen naar de hele structuur. Zolang er behoefte is om het team te transformeren of een obstakel te verwijderen, kan je het onderstaande algoritme herhalen.
Kies een service
Het plan is in grote lijnen opgesteld, laten we beginnen met de eerste stap — het kiezen van de service. Het eerste criterium is de levensduur: er zijn oude services — legacy, en nieuwe. Je kunt met beide beginnen.
Het is logisch om voor een jonge service te kiezen. Het is vers, er is nog geen gevestigde werkwijze in het team dat ervoor verantwoordelijk is. Er is geen enorme technische schuld rondom, het hoeft niet continu gerepareerd te worden. We kunnen doen wat we willen.
Bij een oude service zijn er problemen die voortkomen uit het feit dat verandering altijd moeilijk is.Daar zijn al een aantal serieuze beperkingen, maar misschien zijn er mensen die klaar zijn om alles om te gooien — ze zijn moe en willen het anders doen omdat het pijn doet.
Werken met een oude service creëert een krachtig precedent in jouw bedrijf — je kunt dingen veranderen. Als je een nieuwe service hebt veranderd, draait deze 100 keer per uur in productie en alles is goed, dan kunnen de mensen in jouw bedrijf zeggen:
— Dit is een nieuwe service! Probeer maar eens iets te doen met onze versleten oude versie.
Het heeft zin om de legacy-service te transformeren als je dit samen met iemand doet, bijvoorbeeld als je een externe consultant hebt uitgenodigd. Laten we eerlijk zijn, de transformatie zal alles op zijn kop zetten wat maar mogelijk is.Je experimenteert en je weet niet waar je uitkomt, welke technologieën je gaat gebruiken en welke verborgen problemen er in de processen zullen ontstaan. Daarom is het makkelijker om iets nieuws te veranderen.
Als je alles zelf doet en er geen serieuze competentie in het bedrijf is — ga dan voor de nieuwe service. Als je een externe consultant kent en het budget hebt — kies dan voor de oude.
Er zijn services die simpelweg als interface voor gebruikers dienen, zoals een eenvoudige website of mobiele app. Maar er zijn ook serieuze zaken zoals facturering. Als er iets misgaat met de facturering, zal het moeilijk zijn om het op te lossen. Hier hebben we ook een keuze.
We werken ofwel met een kritieke service, waar we al onder lijden, het creëert beperkingen, of we werken met de interface. Dit is het tweede selectiecriterium. Daarnaast is er de mogelijkheid om een ervaren consultant in te schakelen — we werken met de zware variant.
Maar zelfs in dat geval zou ik niet aanraden het zo aan te pakken, omdat je, zolang je niet begrijpt waarmee je werkt en in welke richting je moet transformeren, iets kritieks nemen en daar volop in gaan rommelen — dat is geen goed idee. Daarom geven we in dit geval de voorkeur aan het werken met de interface, waarvan de storing niet kritiek is.
Laten we verder kijken naar het team van de service. Met degenen die met deze service bezig zijn, moeten we voortdurend werken en zeer nauw samenwerken.
De mensen in het team zijn voor het gemak onderverdeeld in twee categorieën: conservatieven — zij leven in de oude wereld of weten gewoon niets van DevOps, en innovatieve types, die alle trendy praktijken omarmen. De laatsten begrijpen het onderwerp misschien niet altijd, maar ze zijn in ieder geval bereid om het te leren.
Aan de ene kant zijn de conservatieven ervaren mensen: ze zijn al lange tijd in het bedrijf, begrijpen alles van A tot Z, maar weten niets van de praktijken. Aan de andere kant zijn er de innovatoren, die iets gehoord hebben, maar waarschijnlijk niet zo lang in het bedrijf werken. Met wie is het beter om samen te werken?
We will have to interact with the conservatives anyway, as this is their service. We need to communicate with them, clarify the specifics of the service, what can be done and what cannot. We are dependent on their advice. Surely, we will have to delegate tasks to them, because they know their service better. Therefore, it is important which team we will ultimately be in contact with.
It makes sense to choose innovators for the team, because conservatives might cause complications.
In practice, it often happens that conservative people have significant experience but lack an understanding of how to move forward. They are simply afraid that after the transformation and restructuring of the service, they will be dismissed for being unnecessary. Sometimes, due to a lack of understanding of what is happening, they sabotage the work.
I had a situation where a guy from the team was repairing everything possible because he thought it was more critical than what we were currently doing. We set a task: to implement this piece today — but no, there’s a fire on the other side of the world, let’s go fix it. It’s hard to work with such people.
People from the conservative team often neglect tasks or postpone them until the last minute. And if, heaven forbid, you make a mistake and assign them KPIs based on the number of completed tasks, but some part is inexplicably excluded from the KPIs, they will not do anything at all. In fact, they will be right, because they will then lose their bonuses.
Working with innovators is easier — they are more loyal.. They have heard something, want to go somewhere, so they will help. We need people who are ready to endure at first: if the service changes, all the bumps and pitfalls will be caught by the innovators as pioneers. Innovators want all the latest and trendiest things, and they are willing to suffer.
Conservatives can later be converted to your belief. When you show that a piece has been changed and everything works well, they will likely want to try it too and accept the new DevOps religion.
In summary. If we are doing the entire transformation in our company ourselves, we choose: a new service, preferably with a simple interface, so as not to suffer too much from its breakdown, and a team of innovators.
Als het mogelijk is om een externe consultant te bellen, nemen we in plaats van een nieuwe de oude service, waar we al last van hebben. Mensen die lang met transformatie bezig zijn in verschillende bedrijven hebben verschillende gevallen gezien en begrijpen al hoe het goed te doen en welke richting ze überhaupt moeten ingaan.
Wie is erbij betrokken?
We moeten echt iedereen vinden die enige relatie heeft met de service: ontwikkelaars, testers, beheerders, beveiligers, managers en mogelijk Product Owners. Ook al zijn Product Owners geen technici, ze hebben wel invloed op de service: ze nemen beslissingen en stellen taken op.
Alleen degenen die enige beslissingen nemen en invloed hebben op wat er met de service gebeurt, moeten we vinden, leren kennen en een gesprek mee aangaan.
Waar hebben we ze voor nodig? Om te weten met wie we moeten overleggen.. Tijdens de transformatie, wanneer het gebruikelijke werkproces van de service verandert, zal deze toch enige schokken ondervinden. Een tijdje zullen er storingen zijn terwijl we nieuwe benaderingen testen. Mensen moeten hierop voorbereid zijn en hiermee instemmen.
Daarna moeten we een Value Stream Map opstellen en zonder deze mensen kun je dat niet doen, omdat alleen zij samen het volledige plaatje van de situatie kennen. Eén persoon weet nooit alles wat er met de service gebeurt.
Ze zullen mensen voor het team aanbevelen. Later zullen we bespreken waarom een apart team nodig is. We moeten mensen uit bestaande afdelingen aantrekken. Degenen die betrokken zijn bij de service kunnen collega's aanbevelen die in onze lijn denken, ons kunnen helpen en de competentie hebben die we nodig hebben.
Vervolgens verzamelen we al deze mensen uit verschillende afdelingen in één kamer en beginnen we met het bouwen van de Value Stream Map.
We bouwen de Value Stream Map.
De Value Stream Map is een schema of kaart die de waardecreatie tot de klant laat zien.. Dit is het gehele proces van het bedenken van een idee tot de implementatie ervan, inclusief alle tussenstappen en hoe de waarde uiteindelijk bij onze klanten terechtkomt.
De Value Stream Map is nodig om alle fasen van de ontwikkeling te visualiseren,, problemen te lokaliseren via metingen die in het huidige proces bestaan, en deze problemen te beginnen oplossen, en een aanvankelijke doelstelling vast te stellen.. Dit is de plek waar we echt iets gaan doen.
Statistieken
In de literatuur over Value Stream Map worden veel verschillende metrics besproken, maar in het begin hebben we genoeg aan drie.
Lead Time — vertraging/wachttijd — de tijd waarin we op iets wachten. Bijvoorbeeld, een tester wacht tot de teststand vrij is, en in die tijd kan hij niets doen.
Value Added Time — de tijd van waardevolle arbeid — datgene dat we in een bepaalde fase hebben besteed om eindwaarde voor de gebruiker te creëren. Bijvoorbeeld, de tester heeft zijn test uitgevoerd en begint iets te controleren. Dit is de tijd van waardevolle arbeid, wanneer we echt iets voor het product doen. Dit is waar klanten voor betalen — voor kwalitatieve software.
%C/A — het percentage van aangename werkzaamheden. We hebben één fase — ontwikkeling, en een tweede fase — testen. Hoeveel features hebben testers geaccepteerd van ontwikkelaars, en daar is dit percentage.
Zo ziet onze kaart eruit.
Het kan anders lijken, afhankelijk van de organisatiestructuur, het aantal afdelingen en waar je mee bezig bent. Maar in algemene zin heeft de kaart twee fasen: idee en analyse. In deze fase worden gegevens verwacht, bijvoorbeeld Lead Time 2 weken en Value Added Time 2 dagen.
Meten we absoluut alle fasen.
Backlog — hoeveel taken er lagen nadat analisten ze hadden bedacht.
Ontwikkeling — hoeveel weken ontwikkelaars wachtten op verduidelijkingen over taken, teststand of apparatuur — het maakt niet uit, maar ze wachten op iets. Bijvoorbeeld, 4 dagen realiseren ze een feature. Hier komt de metriek %C/A naar voren. Ontwikkelaars hebben slechts 80% van de taken uit de Backlog genomen. Ze denken dat de overige 20% niet voldoende duidelijke specificaties hebben en hebben ze voor herziening teruggestuurd.
Testen. In de schematische weergave is LT ingesteld op 4 dagen. Bijvoorbeeld, testers wachtten op vrijgave van de teststand, VA 2 dagen hebben ze echt iets getest, en %C/A = 40 %. — slechts 40% van de code of features die door ontwikkelaars zijn gestuurd, vonden de testers adequaat. De rest beviel om een of andere reden niet.
Ik zal niet in detail treden over hoe deze metingen uit te voeren; aan het einde van het artikel zal ik literatuur aanbevelen waar je hierover meer kunt leren.
Het enige dat ik aanbeveel — geloof niet de mensen die met je een Value Stream Map zullen opstellen. Ze geven aan hoeveel tijd verschillende processen in beslag nemen, maar deze schattingen zijn niet altijd juist, dus het is beter om zelf te meten.
Er was een moment dat we op de Operations-afdeling kwamen en vroegen hoe lang het duurt om een nieuwe functie naar productie te brengen. Ons werd verteld dat het 10 minuten kostte, en we vroegen ons af waarom we überhaupt bij dit bedrijf waren gekomen. Het bleek dat 10 minuten de tijd was dat een script nodig had om de code te nemen en deze naar de server te brengen. Maar daarvoor ligt de release drie dagen op de server en verwaait gewoon — er ligt een taak in de Backlog die gedepubliceerd moet worden. Het resultaat is dat er vóór de publicatiefase een wachttijd is, waarin het project gewoon stil ligt. Als we niet met een notitieboekje waren gegaan, niet met onze ogen op de taak in Jira waren gevallen en deze niet stap voor stap waren gaan volgen, zouden we denken dat alles geweldig is en er geen probleem is.
Daarom moet je de metingen toch zelf doen, bij voorkeur niet één keer, om een realistisch beeld te hebben. Afhankelijk van de Value Stream Map, neem je de beslissing waar je moet beginnen en wat je als eerste moet verbeteren.
Tijdelijke team
Veel bedrijven die DevOps willen implementeren, creëren een team, maar dan niet tijdelijk, maar een dat al meerdere jaren bestaat. Als je een beroep doet op de DevOps-service die verschillende patronen voor de organisatie-structuur in DevOps beschrijft, zul je begrijpen dat dit een antipatroon is.
Wanneer een DevOps-team jarenlang voortdurend bestaat, is dat een grote fout, omdat DevOps gaat over communicatie tussen afdelingen, over snelheid en efficiëntie.
Als het team tussen afdelingen bestaat, alleen maar om iets anders te doen, en lang bestaat, creëert het een onnodige barrière. Nu moet de programmeur, in plaats van meteen naar de administrator te gaan om het probleem op te lossen, eerst de DevOps-afdeling benaderen, en die gaat dan verder.
Daarom, om te beginnen, moet je een tijdelijk team creëren.. Het zal conditioneel zes maanden, maximaal een jaar meegaan, afhankelijk van de gestelde taak, alleen om één beperking die we hebben gekozen te verhelpen. Daarna zal het verdwijnen. Als we het volgende punt kiezen waar we veel pijn ervaren, en we begrijpen dat we hiervoor ook een apart team nodig hebben, dan zullen we het opnieuw creëren. Maar in de 'zolang als nodig' modus moeten zulke teams niet bestaan — anders verstoren ze gewoon de samenwerking en nemen ze überhaupt aparte taken op zich, gewoon om iets te doen. Deze taken kunnen helemaal niet gerelateerd zijn aan DevOps en aan de transformatie. Waarom zouden we deze taak niet aan bestaande afdelingen toevertrouwen?
Waarom een tijdelijk team nodig is
Conflict met de huidige processen. DevOps-transformatie is niet alleen het veranderen van de technologieën en tools die we gebruiken, maar ook het veranderen van het werkproces, de denkwijze en waarden. Als het team werkt zoals het gewend is, zal het niet in staat zijn om nieuwe benaderingen uit te proberen.
Deze mensen moeten volgens andere regels leven: alle KPI's in het bedrijf negeren, omdat ze proberen op een andere manier te werken. Tijdelijke teams zullen geen aanvragen indienen om een server te krijgen, maar zullen rechtstreeks naar de afdeling gaan die verantwoordelijk is voor hen, met het verzoek om hen als eerste te geven wat zij nodig hebben, omdat dit een prioritaire taak is en omdat ze proberen anders te leven. Het team heeft een complete conflict met alle huidige processen. Om ervoor te zorgen dat bestaande werkmethoden hen nu niet storen, en zij anderen niet storen, isoleren we deze mensen door ze in een apart team onder te brengen.
Bureaucratie vermijden in experimenten. In tijdelijke teams is er geen bureaucratie, ze vullen geen urenrapporten in, ze verantwoorden zich niet naar managers. Dit is een absoluut aparte wereld, waarin mensen anders leven en denken, en zich met totaal andere zaken bezighouden. Ze hoeven niet onnodig gestoord te worden.
Ononderbroken werken aan de service. In het eerste punt hebben we iets gekozen waar we mee gaan experimenteren. Experimenten en zoeken naar manieren om beter te werken is goed, maar we willen ook functies ontwikkelen. Als het hele team in plaats van functies zich met de transformatie bezighoudt, zullen we inkomsten beginnen te verliezen, bugs zullen lang blijven hangen — dat hebben we niet nodig. Het creëren van een tijdelijk team maakt het mogelijk om te experimenteren zonder het werk aan het product stil te leggen.
Geen tijd verspillen aan werkgerelateerde taken. Dit gaat weer over het product. Het kost veel tijd voor het team om andere tools en dergelijke uit te proberen. Het kost minstens een half jaar voordat mensen de tools beheersen, ze beginnen te implementeren en ze normaal gebruiken. Als ze ook nog werken aan het product, kan dat halfjaar enorm uitrekken. Als mensen met het product bezig zijn, werken ze opnieuw met oude processen — dat willen we niet.
Daarom halen we mensen uit verschillende afdelingen in een apart team, dat zich bezighoudt met de transformatie van de service. Hierdoor blijft de service operationeel, blijft zich ontwikkelen, en experimenteren we ermee.
Het tijdelijke team houdt zich alleen bezig met de DevOps-transformatie — het wegnemen van de beperkingen die we hebben gevonden, en verder niets.
Het team bestaat uit veelzijdige mensen. Dit betekent dat we niet alleen ontwikkelaars hebben gekozen. We zijn niet naar de service gegaan en hebben daar de helft van het team meegenomen — nee, we hebben mensen uit verschillende afdelingen. Enkele punten terug vonden we verschillende afdelingen en medewerkers die betrokken zijn bij de te transformeren service. We stellen een team samen omdat het veelzijdig moet zijn — we gaan zowel het testproces, het ontwikkelproces als het onderhoudsproces van de service veranderen. We hebben verschillende competenties nodig.
Normaal gesproken nemen we een ontwikkelaar, een tester en een engineer — elk één, en samen met hen bedenken we een oplossing die het mogelijk maakt om anders te werken.
Bij voorkeur hebben deze mensen autoriteit binnen de organisatie. Misschien moeten we wel een conservatieve stem meenemen, hoewel we dat niet willen. Als we een groot bedrijf hebben, zal niet iedereen in onze plannen geloven, en sommigen kunnen ons tegenwerken, bijvoorbeeld door geen testomgeving beschikbaar te stellen. Hier is autoriteit noodzakelijk — een gerespecteerde persoon met veel ervaring, die het goede vertrouwen van collega’s heeft verdiend. De autoriteit van een medewerker in het team maakt het werk voor het tijdelijke team eenvoudiger. Mensen zullen denken:
— Aha, die geweldige kerel die we allemaal kennen en waarderen, is erbij gekomen — blijkbaar is er iets in DevOps dat het waard is om te bekijken!
We stellen een doel
We hebben mensen verzameld, een service gekozen, de beperkingen bekeken, en bepaald op welke mensen we van invloed zijn. Nu moeten we een doel stellen en die moet duidelijk zijn volgens SMART — precies zoals we dat graag zien.
Specifiek — specifiek.
Meetbaar — meetbaar. Dit is een zeer belangrijk punt van SMART. Als je iets niet kunt meten, kun je het niet veranderen en begrijpen wat je beter of slechter hebt gedaan.
Haalbaar — haalbaar. Houd rekening met je specifieke situatie. Als je een enterprise-bedrijf bent met een lange geschiedenis en een grote last van verantwoordelijkheden, dat eenmaal per jaar een productversie uitbrengt, kun je niet binnen zes maanden de frequentie van het uitbrengen van nieuwe productversies naar elk uur verhogen. Dat werkt niet. Stel daarom een realistisch doel dat haalbaar is binnen een acceptabele tijd.
Relevant — relevant. We pakken alleen die beperking aan die onze huidige doelen daadwerkelijk beïnvloedt.
Tijdgebonden — tijdgebonden. Als er geen deadline is, zal het team zich met van alles bezighouden: 15 technologieën uitproberen in plaats van 3, enorme rapporten schrijven, nutteloze onderzoeken uitvoeren, hun implementatie perfectioneren tot het schittert, terwijl de doelstelling al is bereikt.
We stellen het doel op met behulp van de Value Stream Map — we verzamelen weer alle mensen en tekenen. Maar nu tekenen we op basis van de eerdere Value Stream Map wat we willen bereiken.
We identificeren één beperking die we nu gaan aanpakken — daar gaat het team mee aan de slag. Als voorbeeld heb ik de wachttijd van de voltooiing van de release tot de deployment in productie genomen — dit is de meest voorkomende beperking waarmee mensen consultants benaderen.
Op basis hiervan formuleren we de taak: we willen dat de wachttijd tussen de voltooiing van de release en het 'gevecht' maximaal één uur is.
Voorbeelden van taken.
- De Lead Time voor testen verkorten van 4 dagen naar 1 uur.
- De Value Added Time voor testen verkorten van 2 dagen naar 3 uur.
- De Lead Time voor deployment verkorten van 5 uur naar 10 minuten.
- De C/A verhogen van 50% naar 95%, dat wil zeggen, het aantal functies verhogen dat door testers wordt goedgekeurd, met andere woorden, de kwaliteit van het werk van de ontwikkelaars verbeteren.
De voorbeelden van taken zijn niet willekeurig — ze zijn gebaseerd op metingen die we hebben gedaan toen we de Value Stream Map ontwikkelden.
We stellen een soortgelijke taak aan ons team en een deadline. Afhankelijk van hoe goed het gaat in jouw bedrijf, stel je verschillende termijnen. Gemiddeld duurt het ongeveer zes maanden om de beperking aan te pakken als mensen dit voor het eerst doen en nog niet weten met welke technologieën en hoe ze het probleem specifiek gaan oplossen.
Korte planning
Dus, ons team is gevormd, het heeft een doel, en de mensen beginnen te werken. Een belangrijk punt is de korte planning van het werk: sprints van één tot twee wekenen niet meer dan dat, meetbare verbeteringen elke week en cursuscorrectie.
Bijvoorbeeld, we gebruiken vaak de benadering moving-moving, waarbij het hele team aan het begin van elke week bij elkaar komt en opschrijft wat iedereen zal doen. Na een week bekijken we: wat is er gedaan, en wat niet, en als het niet is gedaan, waarom niet, en we denken na over wat we verder moeten doen.
Sprints stellen ons in staat om op tijd de koers aan te passen.
We hebben een of twee weken iets geprobeerd: technologieën, benaderingen, werkwijzen, daarna meet je weer en kijk je — is het met deze benadering beter of slechter geworden? Als het slechter is, zijn we niet op de goede weg, we moeten de koers aanpassen: een andere taak stellen, een andere technologie gebruiken of iets anders doen. Korte sprints van 1-2 weken maken het mogelijk om te laveren en op tijd weg te blijven van slechte beslissingen.
Succes delen
Het team behaalt enige successen, groot of klein — het maakt niet uit, er is altijd een resultaat. Iedereen moet van dit resultaat weten: zowel degenen die betrokken zijn bij DevOps als de naastgelegen afdelingen. In een ideale wereld is het wenselijk dat dit iedereen in het bedrijf bereikt. Waarom? Als we niet een deel van het bedrijf willen transformeren, niet één beperking willen wegnemen, maar werkelijk alles, zodat het bedrijf flexibel wordt, de code snel bij de klant komt, en er niets kapot gaat, is het nodig dat iedereen loyaal is aan het idee van DevOps. Je kunt de benadering niet toepassen op diensten en teams die categorisch tegen zijn..
Om loyaliteit te creëren, moeten we iedereen vertellen wat we hebben geprobeerd — we hebben resultaat behaald, probeer het ook! Dit zal de interesse en loyaliteit verhogen voor wat we doen, mensen zullen meteen proberen iets te doen. Uit de praktijk blijkt dat wanneer we vertellen wat we hebben geprobeerd en wat we hebben bereikt, andere teams vragen beginnen te stellen over hoe en wat we hebben gedaan. Zij bekijken implementaties, code, documentatie, komen met vragen en proberen iets bij zichzelf te veranderen.
Het is belangrijk om te vertellen wat je hebt bereikt. Zo overtuig je conservatieven die alles op de oude manier wilden doen om over te stappen naar jouw kamp en transformeer je hen in innovators.
We kiezen een dienst
Total
, als uitgangspunt — de plek waar we de veranderingen in het bedrijf zullen beginnen., als startpunt — de plek waar we de veranderingen in het bedrijf gaan beginnen. We identify everyone who has any relation to the service and together with them we build a Value Stream Map, measure, and look at where and what limitations exist.
We create a new temporary team, which will solve the task at hand. Based on measurements and the Value Stream Map we draw a new map, highlighting the limitation that we will address. Based on this limitation we set a task, which the team will work on. The task must be definitely SMART — specific, measurable, relevant to current tasks, and time-bound.
We repeat the process, until we transform all our services into the required form and eliminate all limitations.
Bonus. Useful materials
For those who decided to tackle DevOps independently.
Het project "Phoenix"
The original title is "The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win." It is a novel about DevOps — a story about how an employee was made head of a department that was always on fire. The new manager was given the task:
— You have a few years to fix everything so that we can finally deliver our product quickly and effectively to our clients.
"The Phoenix Project: A Novel about How DevOps Changes Lives for the Better" is a book for all managers, as these are the people who make decisions about what happens in the company. If you are an engineer or programmer and want things to start moving and transforming in your company — buy the book and give it to management. This novel explains everything and is quick and easy to read.
DevOps-gids
A more complex book. It was released a few years ago in English under the title "The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations," but it is now available in Russian. This is a true handbook — a practical guide: on how to conduct measurements, what a Value Stream Map is and why it is needed, where to go, and in what order. The book is just for those who want to do everything themselves. Most importantly, it contains examples of other companies' experiences.
Bijvoorbeeld, er wordt uitgelegd hoe een bedrijf een Value Stream Map heeft gemaakt en begreep dat de beperking niet in het product zat, maar in het feit dat de kassamedewerker van de winkel naar het naastgelegen kantoor moest lopen om dat product te kunnen gebruiken. In plaats van het probleem met de software op te lossen, kochten ze gewoon tablets voor hun verkopers, en nu hoeft niemand meer ergens heen te gaan; alle handelingen worden op de werkplek uitgevoerd. Conclusie: een Value Stream Map kan niet alleen op software, maar op alle processen binnen een organisatie worden toegepast.
Accelerate
Volledige titel: "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations". Dit is het volgende niveau — hardcore. Het boek is vorig jaar uitgekomen, voorlopig alleen in het Engels, en het gaat over onderzoek. De auteurs — Nicole Forsgren, Jez Humble en Gene Kim — hebben jarenlang verschillende praktijken in verschillende bedrijven toegepast en onderzocht welke praktijken, hoe en op wat voor manier invloed hebben.
In het tweede hoofdstuk, dat aan metingen is gewijd, worden Value Stream Maps genoemd, de metrics die ik heb genoemd, en tal van andere, evenals het meetproces in detail beschreven. De auteurs voeren metingen uit met behulp van vragenlijsten en zelftracking van taken. Er wordt in detail uitgelegd welke metrics correct gemeten moeten worden, welke niet, en menselijke fouten bij metingen. Als je problemen hebt met meten, neem dan contact op met het tweede hoofdstuk van het boek "Accelerate". Als je team gewoon veel praktijken heeft, maar het onduidelijk is welke praktijken je nu moet toepassen, welke later, welke echt werken en welke niet — lees het, het boek verklaart alles.
Transformatie is een vraag aan de kruising van DevOps en beheer. Op dezelfde snijpunten van ontwikkeling, exploitatie en testen bevinden zich de onderwerpen die we proberen te bespreken op , dezelfde integratie is nodig voor het creëren van een kwalitatief product – het belangrijkste onderwerp . Beheer op het festival wordt gepresenteerd — betekent dat voor ideeën voor transformatie iedereen daarheen gaat. Sluit je aan op 27 en 28 mei, we gaan integreren en transformeren.
Bron: habr.com
