Runājot par scrum piegādi, cilvēki parasti sagaida atbrīvošanu pēc sprinta beigām. Tas nozīmē uzreiz pēc veiksmīgas demonstrācijas prezentācijas klientam.
Bet es vienmēr prātoju, kā tas var būt tik automātisks gaidījums. It īpaši, ja apsverat tālāk minētās iespējamās darbības, kurām jānotiek pirms vai līdzās.
- Izstrādājiet un pabeidziet visus stāstus sprinta laikā. Daži no tiem varētu tikt pabeigti ātrāk, taču lielāko daļu laika stāsti tiek pabeigti tieši pirms sprinta beigām. Varbūt pat pēc demo prezentācijas būt atvērtam šeit.
- Veiciet visas ieplānotās sprinta satura pārbaudes, lai nodrošinātu, ka izlaižamais kods ir gatavs ražošanai.
- Iepazīstieties ar atklātajām kļūdām un savlaicīgi izlabojiet tās pirms izlaišanas.
- Nodrošiniet, lai izvietošanas konveijera saturs būtu atjaunināts ar jaunāko saturu un ka pats cauruļvads ir uzticams izpildei.
- Palaidiet cauruļvadu visās attiecīgajās vidēs, lai tās nonāktu jaunākajā stāvoklī no koda un datu perspektīvas.
- Sagatavojiet izlaiduma piezīmes un sazinieties ar klientu par laidiena ietekmi un to, kas tieši mainīsies pēc tam.
- Ja nepieciešams, sinhronizējiet ar citām paralēlām scrum komandām, lai nodrošinātu, ka atkarīgais saturs tiek izlaists vienlaikus. Nekam nevajadzētu trūkt, lai jūsu laidiena saturs darbotos, kā paredzēts.
- Papildus tam, izejiet cauri visām scrum ceremonijām. Ne tikai saistīti ar pašreizējo sprintu, bet arī ar tiem, kas paredzēti nākamajam sprintam (piemēram, stāstu precizēšanas sesijas).
Tagad iedomājieties, ka sprintam ir divas nedēļas.
Atbrīvošanas darbību pabeigšana prasa laiku un cilvēkus. Bet tas nevar prasīt pārāk daudz. Tūlīt pēc pēdējās sprinta dienas pienāk nākamā sprinta pirmā diena, un aplis sāksies no jauna.
Vai cerības par atbrīvošanu pēc katra sprinta joprojām izskatās tik automātiskas?
Izlaidiet satura apstrādi
Ja visi sprintā notiekošie procesi ir automatizēti, ir iespēja vienkārši “novilkt sprūdi” un katra sprinta beigās instalēt jaunāko koda versiju ražošanā. Problēma ir tāda, ka es nekad neesmu pieredzējis tik perfektu scrum komandas stāvokli.
Ja tā patiešām ir dažos mazos privātos uzņēmumos, es viņus patiešām apskaužu. Taču realitāte korporatīvajā pasaulē ir tāda, ka scrum komanda nesasniegs šo brieduma līmeni. Gluži pretēji, izlaišanas procesi parasti ir saistīti ar laikietilpīgām darbībām, kas sasniedz lielāko daļu nākamā sprinta, kas ietekmē šo sprintu no satura un visu metrikas perspektīvu. Atbrīvošana ir tikai saspringta darbība, ko neviens komandas loceklis nav laimīgs piedzīvot.
Tāpēc es atklāju nākamo labāko scenāriju, kā rīkoties ar izlaidumiem.
Secinājums bija veikt katru otro sprintu par atbrīvošanas sprintu. Lūk, ko tas nozīmē.
Atsevišķa koda versija nākamajam laidienam
Šeit ir runa par atsevišķu filiāļu apstrādi GIT repozitorijā. Ir daudz veidu, kā risināt vienu un to pašu problēmu, un tie visi var būt veiksmīgi. Bet šī raksta nolūkos es visu padarīšu vienkārši, lai parādītu pieeju un tās ietekmi.
Lai pēc iespējas mazāk ietekmētu notiekošās izstrādes aktivitātes, ir svarīgi nākamā laidiena saturu nodalīt atsevišķā nozarē. Sauksim to par atbrīvošanas nozari. Tādējādi tiks atrisinātas šādas problēmas:
- Izstrādes komanda var turpināt darbību un netraucēti ieplūst galvenās nozares jaunajos stāstos.
- Nav riska, ka laidiena saturu ietekmēs negaidītas koda izmaiņas no scrum komandas.
- Testēšanas darbības var veikt izolētā telpā. Šeit tiks ieviestas tikai testēšanas atrisināšanai nepieciešamās izmaiņas.
- Tā kā izlaiduma konveijera ražošanā tiks izmantots tikai izlaiduma nodaļas saturs, mums ir skaidrs process un pilnīga kontrole pār izlaižamo saturu. Nevar gadīties, ka kāda negaidīta apņemšanās Git filiālē sabojātu jau pārbaudīto kodu.
Tāpēc vienkārši atstājiet nākamā laidiena saturu malā un ļaujiet tam nonākt līdz stabilam stāvoklim, kas ir gatavs izlaišanai.
Laiks izlaidumiem, lai tie darbotos atkārtoti
Es atteicos no ambīcijām veikt atbrīvošanu pēc katra sprinta pabeigšanas. Bija ļoti skaidrs, ka tam nebūs nekādu izredžu strādāt. Vismaz ne ar tādām blakusparādībām kā:
- ietekmējot nākamo sprinta izstrādes saturu,
- nespēja stabilizēt izlaiduma saturu,
- visu nepieciešamo testēšanas darbību veikšana utt.
Tāpēc mērķis bija izpildīt atbrīvošanu līdz katra otrā sprinta beigām. Tas nozīmētu sekojošo:
- Laidienā vienmēr būs stāsti no pēdējiem diviem jau pabeigtajiem sprintiem. Tā kā izlaišana tiek veikta pašreizējā (aktīvā sprintā), šis sprinta saturs vēl nav iekļauts laidienā.
- Nepieciešamo testēšanas darbību un kļūdu labojumu pabeigšanai ir vajadzīgs vesels viens sprinta laiks.
- Laidiena īpašniekam ir pietiekami daudz laika, lai savāktu ar laidienu saistīto informāciju (pārbaudes gadījumus, piezīmes par laidienu utt.) ar neizlaiduma sprintu. Tādā veidā viņi var darboties būtībā atsevišķi un pārējai izstrādes komandai var strādāt pie jauniem stāstiem.
- Kļūdas atklāšanas gadījumā laidiena īpašnieks var ātri sazināties ar konkrētā izstrādātāju, lai novērstu problēmu un atgrieztos pie pašreizējā sprinta satura. Tāpēc vienmēr ir jāparedz kāds procentuālais laiks, kas atvēlēts no komandas iespējām, lai atbalstītu šo kļūdu labošanu. Cik precīzi var atklāt laika gaitā.
Ir skaidrs, ka lietotāji jaunākajā laidienā nesaņems jaunāko sprinta saturu. Bet laika gaitā tas kļūs nenozīmīgs. Viņi jebkurā gadījumā saņems divus satura sprintus ar katru nākamo laidienu, pēc katra otrā sprinta.
Tas izskatās kā labs kompromiss starp ātru piegādi un sekošanu līdzi scrum aktivitātēm bez būtiskiem traucējumiem.
Izpildiet izlaiduma izvietošanu
Kad testēšana, kļūdu labošana un konveijera gatavības darbības ir veiksmīgi pabeigtas, ražošanas konveijera izpilde un izlaišanas pabeigšana ražošanā ir diezgan vienkāršs process.
Tā kā tas tiek izvietots no atsevišķa filiāles, tā būtībā var būt nepamanīta un neredzama darbība. Nevienam nav jāzina. Ja tas tā ir, tā ir labākā iespējamā laidiena izvietošanas īstenošana.
Priekšnoteikums tam ir stabila automatizēta DevOps konveijera izveide. Izmanto ne tikai izvietošanai ražošanas vidē, bet arī visās citās zemāka līmeņa vidēs. Tas var ietvert izstrādātāju, smilškaste, testēšanu, kvalitātes nodrošināšanu, veiktspējas vidi utt. Tas ir viens klikšķis, lai izvietotu visus risinājumus katrai videi.
Atbrīvošanās nedrīkst būt sāpju punkts vai stress. Vai arī murgs, no kura visi baidās un gatavojas tai dienai vienu nedēļu. Nē — tā vietā, ja neviens to vispār nepamana, tā ir labākā veiksmīgas izlaišanas pazīme.
Atpakaļ sapludiniet izlaišanas nodaļu ar izstrādes nodaļu
Izlaiduma nodaļā tagad ir ietverts īpašs saturs, kas neeksistē parastajā notiekošajā izstrādes nozarē. Tas ir saistīts ar visiem labojumiem, kas tika ieviesti testēšanas periodā. Šis saturs ir jāapvieno atpakaļ izstrādes nozarē, lai nodrošinātu, ka labojumi paliks tajā pat pēc nākamā laidiena.
Tajā brīdī jaunākā izlaiduma nodaļa kalpo kā ārkārtas situācijas pārizvietošanai gatavs ražošanas kods. Ja īsi pēc ražošanas izvietošanas ir jāatrisina steidzama augstas prioritātes problēma, tā var izmantot šo filiāli. Ir vienkārši paņemt šo kodu un ieviest labojumu iekšā. Šī joprojām ir precīza pašreizējā ražošanas koda kopija bez jauna neizlaista satura.
Visbeidzot, kad sākas jaunais testēšanas periods, iepriekšējo laidiena filiāli var izdzēst un aizstāt ar jaunu. Jaunais atkal tiek izveidots kā kopija no pašreizējās izstrādes filiāles.
Izveidojiet regulārus izdevumus
Un tagad mums tas ir 😀 — stabils process, lai tuvotos izlaišanai. Vienīgais, kas trūkst, ir apņemšanās to ievērot regulāri. Šajā gadījumā pēc katra otrā sprinta.
Saglabājot to regulāri, mēs faktiski izveidojam pamatu, lai to būtu vieglāk paveikt, galvenokārt tāpēc, ka:
- Ja izlaišana notiek pēc ne pārāk ilga laika, nav tik daudz jauna satura, ko instalēt ražošanas programmā. Pieaugums ir neliels un tiek uzskatīts par stabilu.
- Tagad tik daudz jauna satura nozīmē, ka nav pārāk daudz testēšanas darbību un pārbaudes gadījumu izveides. Mazāk saziņas, vienošanās zvanu un sadarbības ar ieinteresētajām personām par to, kas viss ir atkārtoti jāapstiprina. Viņi arī piekritīs, ka nav pagājis tik ilgs laiks kopš pēdējās izlaišanas. Tāpēc šai darbībai tiek piešķirta mazāka nozīme.
- Komanda pieradīs pie šī cikla; ar laiku tā būs dabiska komandas sastāvdaļa.
- Kā blakusparādība izstrādes un testēšanas vidēs bieži tiek atsvaidzināti dati. Tas jebkurā gadījumā ir vajadzīgs katram jaunam testēšanas ciklam. Tātad tā nebūs tikai vēl viena plānota darbība. Drīzāk darbība, kas jau ir daļa no iedibinātā procesa. Šī skatījuma maiņa tik ļoti ietekmē komandas atmosfēru. Cilvēks tam neticētu.
Secinājums
Šī nodaļa noslēdz manus iepriekšējos ierakstus par scrum dzīves cikla tēmu. Tas ir arī par to, kas izrādījās veiksmīgs reālajā dzīvē.
Bieži vien komandas sāk veikli un daudzas lietas dara nepareizi. Tad viņi galu galā attīstās un sāk darīt lietas savādāk. Šī sērija varētu palīdzēt dažiem no viņiem veikt šīs izmaiņas ātrāk.
Arī šī izlaišanas pieeja nav vienīgā izmantojamā, un tā nav bez problēmām. Tie joprojām pastāvēs, un komandām ar tiem ir jātiek galā. Pēc tam uzlabojiet to, kas ir iespējams, un aizmirstiet to, kam nav jēgas.
Bet no tā, ko es zinu, šī pieeja, kaut arī vienkārša, pierādīja, ka pārmaiņas ir iespējamas. No haotiskiem, neparedzamiem sprintiem līdz stabilākai piegādei ar regulāriem izlaidumiem, uz kuriem var paļauties un ar kuriem var plānot. Un tam nav nepieciešama īpaša, ļoti sarežģīta metodika – vienkārši noteikumi un vēlme ievērot plānu.