{"id":34157,"date":"2019-10-31T21:56:43","date_gmt":"2019-10-31T18:56:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-nachat-devops-transformatsiyu\/"},"modified":"2019-10-31T21:56:43","modified_gmt":"2019-10-31T18:56:43","slug":"kak-nachat-devops-transformatsiyu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-nachat-devops-transformatsiyu","title":{"rendered":"Hvordan man starter DevOps-transformation","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hvis du ikke forst\u00e5r, hvad DevOps er, s\u00e5 her er en kort huskeseddel. DevOps er et s\u00e6t praksisser, der minder ingeni\u00f8rernes frygt<\/strong> og reducerer antallet af nedbrud i softwareproduktionen. Som regel reducerer de ogs\u00e5 tid til markedet<\/strong> \u2014 perioden fra id\u00e9 til levering af det endelige produkt til kunderne, hvilket g\u00f8r det muligt hurtigt at gennemf\u00f8re forretningseksperimenter.<\/strong>.<\/p>\n

Hvordan starter man DevOps transformation? Kort sagt: v\u00e6lg den service, vi skal begynde processen med, identificer dem, der har en interesse i servicen, byg en Value Stream Map, skab et midlertidigt team, der skal arbejde med transformationen i starten, og giv dem en opgave. Gentag cyklussen det n\u00f8dvendige antal gange.<\/p>\n

\"Hvordan<\/p>\n

En detaljeret plan for DevOps transformation med eksempler og instruktioner findes nedenfor \u2014 i transkriptionen af pr\u00e6sentationen<\/a><\/noindex> Andrey Aleksandrov<\/b> \u2014 ingeni\u00f8r hos Express42, som r\u00e5dgiver om implementering af DevOps, hvilket fremskynder denne proces, da de allerede har kortlagt de udfordringer, der kan opst\u00e5. Hvis du mener, at transformationen ikke er n\u00f8dvendig, eller at din specifikation g\u00f8r, at DevOps-praksis ikke passer, \u2014 brug pr\u00e6sentationen som en guide til at finde og fjerne begr\u00e6nsninger.
\n<\/a><\/noindex>
\nHvis du er bekymret for DevOps transformation, s\u00e5 har du en stor virksomhed, og det er n\u00f8dvendigt gradvist at skalere denne proces til hele strukturen. S\u00e5 l\u00e6nge der er behov for at transformere teamet eller fjerne en begr\u00e6nsning, kan algoritmen nedenfor gentages.<\/p>\n

Valg af service<\/h2>\n

\nPlanen er lagt, lad os begynde med det f\u00f8rste skridt \u2014 valg af service. Det f\u00f8rste kriterium \u2014 levetid<\/strong>: der findes gamle service \u2014 legacy, og nye. Man kan starte med begge.<\/p>\n

At v\u00e6lge en ny service er logisk.<\/strong>Den er ny, der er endnu ikke etablerede arbejdsprocesser i det team, der arbejder med den. Omkring den er der ikke en bjerg af teknisk g\u00e6ld, man beh\u00f8ver ikke hele tiden at reparere den. Vi kan g\u00f8re hvad vi vil med den.<\/p>\n

I tilf\u00e6lde af en gammel service er der problemer relateret til, at det altid er sv\u00e6rt at \u00e6ndre.<\/strong>Der er allerede et s\u00e6t alvorlige begr\u00e6nsninger, men muligvis er der folk, der allerede er klar til at \u00e6ndre alt \u2014 de er tr\u00e6tte og vil g\u00f8re noget anderledes, fordi det g\u00f8r ondt.<\/p>\n

At arbejde med en gammel service skaber et st\u00e6rkt eksempel<\/strong> i din virksomhed \u2014 man kan \u00e6ndre noget. Hvis du \u00e6ndrer en ny service, der g\u00e5r i produktion 100 gange i timen, og alt er godt, kan folk i din virksomhed sige:<\/p>\n

\u2014 Det er en ny tjeneste! Det var s\u00e5 enkelt, fors\u00f8g at lave noget med vores gamle skrammel.<\/em><\/p>\n

Legacy-tjenesten giver mening at transformere, n\u00e5r du g\u00f8r det med nogen, for eksempel hvis du har inviteret en ekstern konsulent. Lad os v\u00e6re \u00e6rlige, transformationen vil ryste alt, hvad der er muligt.<\/strong>. Du eksperimenterer og ved ikke, hvor du vil ende, hvilke teknologier og hvorfor du vil bruge, hvor og hvilke faldgruber der kan opst\u00e5 i processerne. Derfor er det nemmere at \u00e6ndre det nye.<\/p>\n

Hvis du g\u00f8r alt selv, og der ikke er seri\u00f8s ekspertise i virksomheden \u2014 s\u00e5 v\u00e6lg den nye tjeneste. Hvis du kender en ekstern konsulent og har midlerne \u2014 s\u00e5 v\u00e6lg den gamle.<\/p><\/blockquote>\n

\nDer er tjenester, der bare repr\u00e6senterer et interface for brugerne, for eksempel en simpel hjemmeside eller en mobilapplikation. Men der er ogs\u00e5 alvorlige ting som fakturering. Hvis noget g\u00e5r galt med faktureringen \u2014 bliver det sv\u00e6rt at finde ud af. Her har vi ogs\u00e5 et valg.<\/p>\n

Vi arbejder enten med en kritisk tjeneste<\/strong>, men vi lider allerede under den, den skaber begr\u00e6nsninger, eller vi arbejder med interfacet<\/strong>. Dette er det andet valgkriterium. Ligeledes, hvis der er mulighed for at engagere en erfaren konsulent \u2014 arbejder vi med den tunge variant.<\/p>\n

Men selv i dette tilf\u00e6lde ville jeg ikke anbefale at g\u00f8re det, fordi mens der ikke er en forst\u00e5else for, hvad man arbejder med og hvilken retning man skal transformere, er det ikke en god id\u00e9 at tage det kritiske og gennemg\u00e5 det \u2014 derfor foretr\u00e6kker vi i dette tilf\u00e6lde at arbejde med interfacet, hvis det g\u00e5r i stykker er det ikke kritisk.<\/p>\n

Lad os kigge n\u00e6rmere p\u00e5 tjenesteteamet<\/b>. Med dem, der besk\u00e6ftiger sig med denne tjeneste, bliver vi n\u00f8dt til at arbejde og interagere konstant i meget t\u00e6t kontakt.<\/p>\n

Folk i teamet kan overordnet opdeles i to kategorier: konservative<\/strong> \u2014 lever i den gamle verden, eller ved simpelthen ikke noget om DevOps, og innovatorer<\/strong>, der tr\u00e6kker alle de moderne praksisser ind. De sidstn\u00e6vnte forst\u00e5r ikke altid emnet, men de er i det mindste \u00e5bne for det.<\/p>\n

P\u00e5 den ene side er de konservative \u2014 erfarne personer: de har v\u00e6ret i virksomheden l\u00e6nge, forst\u00e5r fra A til Z, men ved ikke noget om praksisser. P\u00e5 den anden side \u2014 innovatorer, der har h\u00f8rt noget, men sandsynligvis ikke har v\u00e6ret i virksomheden s\u00e6rlig l\u00e6nge. Hvem er bedst at arbejde sammen med?<\/p>\n

Vi m\u00e5 interagere med konservatorerne, da det er deres service. Vi skal kommunikere med dem for at finde ud af detaljerne om servicen, hvad vi kan g\u00f8re p\u00e5 \u00e9n m\u00e5de, og hvad der skal g\u00f8res p\u00e5 en anden m\u00e5de. Vi er afh\u00e6ngige af deres r\u00e5dgivning. Det vil helt sikkert v\u00e6re n\u00f8dvendigt at give dem opgaver, da de kender deres service bedst. Derfor er det vigtigt, hvilken gruppe vi ender med at have kontakt til.<\/p>\n

Det er logisk at v\u00e6lge innovatorer til teamet, fordi konservatorerne kan finde p\u00e5 at sabotere.\n<\/p><\/blockquote>\n

\nI praksis viser det sig ofte, at konservative personer har betydelig erfaring, men ikke forst\u00e5r, hvordan man skal komme videre. De er simpelthen bange for, at de bliver fyret efter transformationen og omstruktureringen af servicen, og nogle gange saboterer de arbejdet blot fordi de ikke forst\u00e5r, hvad der sker.<\/p>\n

Jeg havde en situation, hvor en fyr fra teamet reparerede alt muligt, fordi det angiveligt var mere kritisk end det, vi lavede lige nu. Vi s\u00e6tter en opgave: at implementere denne del i dag \u2013 nej, der er brand p\u00e5 den anden side af jorden, s\u00e5 lad os tage derhen og fikse det. Det er sv\u00e6rt at arbejde med s\u00e5danne mennesker.<\/p>\n

Folk fra konservatorernes team glemmer ofte opgaver eller uds\u00e6tter dem til det sidste. Og hvis, Gud forbyde, du har lavet en fejl og givet dem KPI for antallet af udf\u00f8rte opgaver, men nogle opgaver ikke er inkluderet i KPI\u2019en, s\u00e5 vil de overhovedet ikke g\u00f8re noget. Faktisk vil de have ret, fordi de s\u00e5 mister deres bonus.<\/p>\n

Det er lettere at arbejde med innovatorer \u2013 de er mere loyale.<\/strong>De har allerede h\u00f8rt noget, vil gerne bev\u00e6ge sig fremad, s\u00e5 de vil hj\u00e6lpe. Vi har brug for folk, der er villige til at t\u00e5le lidt i starten: hvis servicen \u00e6ndres, vil innovatorerne som pionerer tage alle st\u00f8dene og faldgruberne. Innovatorerne s\u00f8ger alt det nyeste og moderne, og de er villige til at lide lidt.<\/p>\n

Senere kan konservatorerne overbevises om vores tro. N\u00e5r du viser, at du har \u00e6ndret en del og at alt fungerer, vil de sandsynligvis ogs\u00e5 v\u00e6re interesserede og tage imod den nye DevOps-religion.<\/p>\n

\"Hvordan
\n<\/p>\n

Lad os opsummere. Hvis vi selv laver hele transformationen i vores virksomhed, v\u00e6lger vi: en ny service, helst med et simpelt interface for ikke at lide for meget under dens nedbrud, og et team af innovatorer.<\/p><\/blockquote>\n

\nHvis det er muligt at hyre en ekstern konsulent, s\u00e5 v\u00e6lger vi at bruge den gamle service, vi allerede lider under, i stedet for at f\u00e5 en ny. De personer, der har arbejdet med transformation i forskellige virksomheder over l\u00e6ngere tid, har set forskellige tilf\u00e6lde og ved allerede, hvordan man g\u00f8r det rigtigt, og hvilken retning man skal g\u00e5.<\/p>\n

Hvem er involveret?<\/h2>\n

\nVi skal finde alle, der har nogen form for tilknytning til servicen: udviklere, testere, administratorer, sikkerhedsspecialister, ledere og muligvis Product Owners. Selvom Product Owners ikke er teknikere, har de alligevel en forbindelse til servicen: de tr\u00e6ffer beslutninger og s\u00e6tter opgaver.<\/p>\n

\"Hvordan
\n<\/p>\n

Alle, der tr\u00e6ffer nogen beslutninger og p\u00e5virker, hvad der sker med servicen, skal findes, introduceres og taler med.<\/p><\/blockquote>\n

\nHvad skal de bruge os til? For at vide, hvem vi skal forhandle med.<\/strong>. Under transformationen, n\u00e5r den s\u00e6dvanlige arbejdsmetode for servicen \u00e6ndres, vil der v\u00e6re rystelser. Der vil v\u00e6re nogle fejl i et stykke tid, mens vi tester nye tilgange. Menneskerne skal v\u00e6re klar til og enige om dette.<\/p>\n

Herefter skal vi bygge en Value Stream Map, og uden disse mennesker kan vi ikke g\u00f8re det, for kun de kender den fulde sammenh\u00e6ng. \u00c9n person kender aldrig alt, hvad der sker med servicen.<\/p>\n

De vil anbefale folk til teamet. Senere vil vi diskutere, hvorfor vi har brug for et separat team. Vi m\u00e5 tage folk fra eksisterende afdelinger. De, der har tilknytning til servicen, kan anbefale kolleger, der t\u00e6nker i vores retning, som kan hj\u00e6lpe os og har den n\u00f8dvendige kompetence.<\/p>\n

Derefter samler vi alle disse mennesker fra forskellige afdelinger i \u00e9t rum og begynder at bygge Value Stream Map.<\/p>\n

Vi bygger Value Stream Map.<\/h2>\n

\nValue Stream Map er et diagram eller kort, der viser v\u00e6rdistr\u00f8mmen til kunden.<\/strong>. Det er hele processen fra id\u00e9en til implementering, inklusive alle mellemtrin og hvordan v\u00e6rdien i sidste ende n\u00e5r vores kunder.<\/p>\n

Value Stream Map er n\u00f8dvendig for at visualisere alle udviklingsfaser<\/strong>, lokalisere problemer gennem m\u00e5linger i den nuv\u00e6rende proces og begynde at l\u00f8se disse problemer, og fasts\u00e6tte det oprindelige m\u00e5l<\/strong>. Det er her, vi begynder at g\u00f8re noget reelt.<\/p>\n

M\u00e5linger<\/h3>\n

\nI litteraturen om Value Stream Map er der beskrevet mange forskellige m\u00e5linger, men for nu er tre nok.<\/p>\n

Lead Time \u2014 forsinkelse\/ventetid<\/strong> \u2014 tiden, hvor vi venter p\u00e5 noget. For eksempel venter en tester p\u00e5, at testmilj\u00f8et bliver ledigt, og i mellemtiden kan vedkommende ikke lave andet.<\/p>\n

Value Added Time \u2014 tiden for v\u00e6rdifuldt arbejde<\/strong> \u2014 den tid, vi bruger i et bestemt trin for at skabe v\u00e6rdi for brugeren. For eksempel har testeren startet sin test og begyndt at kontrollere noget. Dette er tiden for v\u00e6rdifuldt arbejde, hvor vi faktisk laver noget for produktet. Det er det, kunderne betaler for \u2014 for kvalitetssoftware.<\/p>\n

%C\/A \u2014 procentdelen af accepteret arbejde. <\/strong>Vi har \u00e9t trin \u2014 udvikling, det andet trin \u2014 test. Hvor mange funktioner testerne har accepteret fra udviklerne, og da er der denne procent.<\/p>\n

S\u00e5dan ser vores kort ud.<\/p>\n

\"Hvordan
\n
\nDet kan se anderledes ud afh\u00e6ngig af organisationens struktur, antallet af afdelinger og hvad I laver. Men generelt vil kortet have to trin: id\u00e9 <\/strong>og analyse<\/strong>. I dette trin forventes data, for eksempel Lead Time 2 uger og Value Added Time 2 dage.<\/p>\n

Metrikker d\u00e6kker alle trin.<\/p><\/blockquote>\n

\nBacklog<\/strong> \u2014 hvor mange opgaver der l\u00e5 efter, at analytikerne havde fundet p\u00e5 dem.<\/p>\n

Udvikling<\/strong> \u2014 hvor mange uger udviklerne ventede p\u00e5 afklaringer ang\u00e5ende opgaver, testmilj\u00f8er eller udstyr \u2014 ligegyldigt, men de venter p\u00e5 noget. For eksempel implementerer de en funktion i 4 dage. Her kommer metrikken %C\/A ind. Udviklerne tog kun 80% af opgaverne fra Backlog. De mener, at 20% af dem ikke har en tilstr\u00e6kkelig klar kravspecifikation, og sendte dem tilbage til revidering.<\/p>\n

Testning<\/strong>. I diagrammet er LT angivet til 4 dage. For eksempel ventede testerne p\u00e5 frigivelsen af testmilj\u00f8et, VA 2 dage hvor de faktisk tester noget, og %C\/A = 40 %. \u2014 kun 40 % af koden eller funktionerne, som udviklerne sendte, blev vurderet som acceptable af testerne. Alt andet kunne de ikke lide af en eller anden grund.<\/p>\n

Jeg vil ikke g\u00e5 i detaljer med, hvordan man foretager disse m\u00e5linger, men jeg vil anbefale litteratur, hvor man kan l\u00e6re om dem i slutningen af artiklen.<\/p>\n

Det eneste, jeg vil r\u00e5de til \u2014 tro ikke p\u00e5 folk, der vil lave en Value Stream Map med dig. De p\u00e5st\u00e5r at vide, hvor lang tid forskellige processer tager, men disse vurderinger er ikke altid korrekte, s\u00e5 det er bedst at m\u00e5le selv.<\/p>\n

Vi havde en situation, hvor vi gik til Operations-afdelingen og spurgte, hvor lang tid det tager at levere en ny funktion til produktion. Vi fik at vide, at det tager 10 minutter, og vi t\u00e6nkte, hvorfor vi overhovedet kom til denne virksomhed? Det viste sig, at 10 minutter er den tid, det tager for et script at tage koden og levere den til serveren. Men inden dette ligger udgivelsen tre dage p\u00e5 serveren og samler st\u00f8v \u2013 der ligger en opgave i Backlogen, der skal implementeres. Det viser sig, at der er en ventefase f\u00f8r implementeringen, hvor projektet blot ligger stille. Hvis ikke vi var g\u00e5et med en notesblok, havde vi ikke f\u00e5et \u00f8je p\u00e5 opgaven i Jira og begyndt at f\u00f8lge den trin for trin, s\u00e5 ville vi have troet, alt var fint og at der ikke var noget problem.<\/p>\n

Derfor bliver du n\u00f8dt til selv at foretage m\u00e5lingerne, helst ikke kun \u00e9n gang, for at skabe et s\u00e5 realistisk billede som muligt. Afh\u00e6ngig af Value Stream Map vil du tage en beslutning om, hvorfra du skal starte og hvad der skal rettes f\u00f8rst.<\/p>\n

Midlertidigt team<\/h2>\n

\nMange virksomheder, der har besluttet at implementere DevOps, opretter et team, men ikke et midlertidigt, et der har eksisteret i flere \u00e5r. Hvis du bes\u00f8ger en DevOps-tjeneste, der beskriver forskellige m\u00f8nstre for at opbygge organisatorisk struktur i DevOps, vil du forst\u00e5, at dette er et antipattern.<\/p>\n

N\u00e5r DevOps-teamet eksisterer konstant i flere \u00e5r \u2013 er det en stor fejl, fordi DevOps handler om kommunikation mellem afdelinger, om hastighed og effektivitet.<\/p><\/blockquote>\n

\nHvis teamet eksisterer mellem afdelingerne, kun for at lave noget separat, og har eksisteret l\u00e6nge, skaber det en un\u00f8dvendig barriere. Nu skal programm\u00f8ren, i stedet for straks at henvende sig til administrationen for at l\u00f8se et sp\u00f8rgsm\u00e5l, f\u00f8rst g\u00e5 til DevOps-afdelingen, som s\u00e5 m\u00e5 tage det videre.<\/p>\n

Derfor, for at komme i gang, skal der oprettes et midlertidigt team.<\/strong>Den vil eksistere i cirka et halvt \u00e5r, maks et \u00e5r, afh\u00e6ngigt af opgaven, for kun at f\u00e5 l\u00f8st en begr\u00e6nsning, vi har valgt. Derefter vil den d\u00f8. Hvis vi v\u00e6lger det n\u00e6ste punkt, hvor vi har meget ondt, og indser, at vi ogs\u00e5 har brug for et separat team til det, vil vi s\u00e5 oprette det igen. Men s\u00e5danne teams b\u00f8r ikke eksistere permanent - ellers forstyrrer de kommunikationen og p\u00e5tager sig opgaver, der kun skal l\u00f8ses. Disse opgaver kan slet ikke v\u00e6re relateret til DevOps og transformation. Hvorfor ikke overdrage denne opgave til eksisterende afdelinger?<\/p>\n

Hvorfor er et midlertidigt team n\u00f8dvendigt<\/h3>\n

\nKonflikt med nuv\u00e6rende processer<\/strong>DevOps-transformation er ikke kun en \u00e6ndring af teknologierne og v\u00e6rkt\u00f8jerne, vi bruger, men ogs\u00e5 en \u00e6ndring af selve arbejdsprocessen, tankem\u00e5den og v\u00e6rdierne. Hvis teamet arbejder p\u00e5 den m\u00e5de, de allerede er vant til, vil de ikke kunne afpr\u00f8ve andre tilgange.<\/p>\n

Disse mennesker skal leve efter andre regler: ignorere alle KPI'er i virksomheden, fordi de pr\u00f8ver at arbejde anderledes. Midlertidige teams vil ikke udfylde ans\u00f8gninger om at f\u00e5 en server, men vil i stedet henvende sig direkte til den afdeling, der administrerer dem, med krav om at f\u00e5 det, de har brug for f\u00f8rst, fordi det er en prioriteret opgave, og fordi de fors\u00f8ger at leve anderledes. Teamet er i fuld konflikt med alle nuv\u00e6rende processer. For at eksisterende arbejdsmetoder ikke skal forstyrre dem nu, og de ikke skal forstyrre andre, isolerer vi disse mennesker ved at oprette et separat team.<\/p>\n

Undg\u00e5 bureaukrati i eksperimenter<\/strong>I midlertidige teams er der ikke bureaukrati, de udfylder ikke timerapporter, og de skal ikke rapportere til ledere. Det er en helt separat verden, hvor mennesker lever og t\u00e6nker anderledes og laver helt andre ting. Der er ikke behov for at forstyrre dem un\u00f8digt.<\/p>\n

Uafbrudt arbejde p\u00e5 servicen<\/strong>I det f\u00f8rste punkt valgte vi noget, vi vil eksperimentere med. Eksperimenter og s\u00f8gninger efter bedre arbejdsmetoder er gode, men funktioner \u00f8nsker vi ogs\u00e5 at lave. Hvis hele teamet i stedet for funktioner besk\u00e6ftiger sig med transformation, vil vi begynde at miste indt\u00e6gter, fejl vil h\u00e6nge l\u00e6nge - det er ikke noget, vi vil have. Oprettelsen af et midlertidigt team giver mulighed for at eksperimentere uden at stoppe arbejdet med produktet.<\/p>\n

Ikke spilde tid p\u00e5 arbejdsopgaver<\/strong>. Dette handler igen om produktet. Det tager lang tid for teamet at pr\u00f8ve andre v\u00e6rkt\u00f8jer og s\u00e5 videre. For at folk kan l\u00e6re v\u00e6rkt\u00f8jerne at kende, begynde at implementere dem og bruge dem ordentligt, vil det tage mindst et halvt \u00e5r. Hvis de ogs\u00e5 arbejder med produktet, vil de seks m\u00e5neder str\u00e6kke sig ud i det uendelige. Hvis folk arbejder med produktet, arbejder de igen med gamle processer \u2014 det har vi ikke brug for.<\/p>\n

Derfor udv\u00e6lger vi folk fra forskellige afdelinger til et separat team, som skal arbejde med transformationen af servicen. Som resultat fungerer servicen, forts\u00e6tter med at udvikle sig, og vi laver nogle eksperimenter p\u00e5 den.<\/p>\n

Det midlertidige team arbejder kun med DevOps-transformation \u2014 fjernelse af den begr\u00e6nsning, vi har fundet, og ikke andet.<\/p><\/blockquote>\n

\nTeamet best\u00e5r af alsidige personer<\/strong>. Det betyder, at vi ikke kun har taget udviklere. Vi kom ikke ind i servicen og tog halvdelen af teamet \u2014 nej, vi tog folk fra forskellige afdelinger<\/strong>. Flere punkter tilbage fandt vi forskellige afdelinger og ansatte, som har relation til den transformerede service. Herfra samler vi et team, fordi det skal v\u00e6re alsidigt \u2014 vi vil \u00e6ndre b\u00e5de testprocessen, udviklingsprocessen og servicevedligeholdelsen. Forskellige kompetencer er n\u00f8dvendige.<\/p>\n

Normalt tager vi betinget en udvikler, en tester og en ingeni\u00f8r \u2014 hver is\u00e6r \u00e9n, og sammen med dem finder vi en l\u00f8sning, der g\u00f8r det muligt at leve anderledes.<\/p>\n

Det er \u00f8nskeligt, at disse personer har autoritet i organisationen<\/strong>. Det kan v\u00e6re n\u00f8dvendigt at tage en konservator, selv om det ikke er \u00f8nskeligt. Hvis vi har en stor virksomhed, er der langt fra alle, der vil tro p\u00e5 vores id\u00e9, og nogle kan finde p\u00e5 at s\u00e6tte k\u00e6ppe i hjulet, for eksempel ved ikke at stille en stand til r\u00e5dighed. Her vil \"autoriteten\" v\u00e6re n\u00f8dvendig \u2014 en respekteret person med stor erfaring, der har opn\u00e5et et godt forhold til kolleger. En medarbejders autoritet i teamet vil g\u00f8re opgaven og det midlertidige teams arbejde lettere. Folk vil t\u00e6nke:<\/p>\n

\u2014 Aha, denne seje fyr, som vi alle kender og elsker, er tr\u00e5dt ind \u2014 \u00e5benbart er der noget ved DevOps, som er v\u00e6rd at se n\u00e6rmere p\u00e5!<\/em><\/p>\n

S\u00e6tter et m\u00e5l<\/h2>\n

\nVi har samlet folk, valgt servicen, set begr\u00e6nsningerne, bestemt, hvilke personer vi vil p\u00e5virke. Nu er det n\u00f8dvendigt at s\u00e6tte et m\u00e5l, og det skal v\u00e6re direkte if\u00f8lge SMART<\/strong> \u2014 alt som vi elsker.<\/p>\n

Specifik \u2014 specifik<\/strong>.<\/p>\n

M\u00e5lbar \u2014 m\u00e5lbar<\/strong>. Dette er et meget vigtigt punkt i SMART. Hvis du ikke kan m\u00e5le noget, kan du ikke \u00e6ndre det og forst\u00e5, hvad og hvordan du har gjort det bedre eller d\u00e5rligere.<\/p>\n

Opn\u00e5elig \u2014 opn\u00e5elig<\/strong>. Tag h\u00f8jde for din specifik. Hvis du er en enterprise-virksomhed med en lang historie og et stort ansvar, der udgiver en produktversion om \u00e5ret, vil du ikke v\u00e6re i stand til at n\u00e5 at udgive nye produktversioner hver time p\u00e5 seks m\u00e5neder. Det kommer ikke til at ske. Derfor skal du s\u00e6tte et realistisk m\u00e5l, der kan opn\u00e5s inden for en rimelig tidsramme.<\/p>\n

Relevant \u2014 relevant. <\/strong>Vi fjerner kun den begr\u00e6nsning, som virkelig forf\u00f8lger vores nuv\u00e6rende m\u00e5l.<\/p>\n

Tidsbegr\u00e6nset \u2014 tidsbegr\u00e6nset<\/strong>. Hvis der ikke er nogen deadline, vil teamet besk\u00e6ftige sig med alt muligt: pr\u00f8ve 15 teknologier i stedet for 3, skrive omfattende rapporter, udf\u00f8re meningsl\u00f8se unders\u00f8gelser, polere deres implementering til perfektion, n\u00e5r m\u00e5let allerede er n\u00e5et.<\/p>\n

M\u00e5lene fastl\u00e6gges netop ved hj\u00e6lp af Value Stream Map \u2014 vi samler alle mennesker igen og tegner. Men denne gang baserer vi det p\u00e5 den tidligere Value Stream Map, vi tegner, hvad vi \u00f8nsker at opn\u00e5.<\/p>\n

\"Hvordan
\n
\nVi identificerer \u00e9n begr\u00e6nsning, som vi vil fjerne lige nu \u2014 det er det, teamet vil arbejde med. For eksempel har jeg taget ventetiden fra den f\u00e6rdige udgivelse til dens deployment i produktionen \u2014 det er den mest almindelige begr\u00e6nsning, folk henvender sig til konsulenter med.<\/p>\n

Baseret p\u00e5 dette s\u00e6tter vi opgaven: vi \u00f8nsker, at ventetiden mellem den f\u00e6rdige version og lanceringen h\u00f8jst skal v\u00e6re en time.<\/p>\n

Eksempler p\u00e5 opgaver.<\/p>\n