Codul îngheață: sunt încă relevante pentru managerii de produse Agile?

pare un caz deschis și închis.

înghețarea codului este o relicvă. O rămășiță din zilele în care metodologiile rigide de cascadă ofereau singura opțiune pentru dezvoltarea și lansarea produsului. Întregul concept de oprire a producției și de întârziere a lansării—doar pentru a testa erorile și alte probleme funcționale—nu are loc în gestionarea modernă și agilă a produselor.

cel puțin aceasta pare a fi opinia consensuală în rândul multor Guru agili.

dar rezistă? Odată ce zgâriați suprafața celor mai frecvente argumente împotriva încorporării înghețării codului în gestionarea agilă a produselor, vor părea în continuare arhaice?

în această piesă, vom explora cele trei argumente principale împotriva încorporării blocărilor de cod în gestionarea agilă a produselor și vom descompune acolo unde aceste argumente se destramă, toate pentru a vă ajuta să luați o decizie mai bună dacă ar trebui sau nu să încorporați blocarea codului în gestionarea agilă a produselor.

argumentul 1: Blocările de cod sunt irelevante și inutile

acest argument este destul de simplu și concret— metodologiile și instrumentele Agile moderne au eliminat necesitatea unei ferestre dedicate de asigurare a calității și testare.

metodologiile Agile, cum ar fi recenziile codurilor de la egal la egal, programarea perechilor și monitorizarea constantă a sănătății sistemului vă oferă o vizibilitate mult mai mare asupra performanței unei aplicații sau a unei funcții în timp ce este dezvoltată. Bug – uri și probleme sunt mai ușor, și mai probabil, să fie prins în timpul dezvoltării în sine, și rezolvate înainte de orice activități de testare și QA dedicate.

noile instrumente au automatizat, de asemenea, multe teste. Ei evaluează în mod constant codul pentru a se asigura că este curat și gata de producție în orice moment. Problemele sunt identificate în timp real, iar alertele sunt trimise imediat pentru a le rezolva cât mai curând posibil. Numărul de teste care au fost automatizate este deja larg și continuă să crească, reducând dramatic volumul testelor manuale care trebuie efectuate.

rezultatul acestor noi metodologii și instrumente Agile este ușor de văzut. Majoritatea activităților de testare de bază și QA efectuate în timpul înghețării Codului sunt fie efectuate în timpul dezvoltării, fie efectuate de software. În Agile, software-ul și caracteristicile ies acum din dezvoltare la un nivel de încredere mult mai ridicat decât obișnuiau, ceea ce face ca un cod dedicat să înghețe din ce în ce mai greu de justificat.

argumentul 2: Codul îngheață rupe un principiu de bază agil

acest al doilea argument este un pic mai mare nivel. Practic, susține că înghețarea codului nu are o casă în metodologia Agile, deoarece încalcă unul dintre principiile de bază ale metodologiei Agile— reducerea timpului dintre dezvoltare și lansare.

cu cât abordarea dvs. către agil este mai rafinată, cu atât veți încerca mai mult să micșorați această fereastră de timp. Cele mai rafinate abordări actuale ale Agile sunt integrarea continuă și dezvoltarea continuă (CICD) și își propun să rupă dezvoltarea în mici modificări incrementale pentru a „elibera” modificările Codului cât mai repede posibil. În cea mai pură aplicație a CICD, dezvoltarea și lansarea abia există ca faze distincte— noul cod este integrat în aplicație aproape imediat ce este finalizat.

în schimb, trebuie să mențineți faze distincte de dezvoltare și eliberare dacă veți implementa blocarea codului. La urma urmei, acolo trăiește înghețarea codului— între aceste două faze distincte. În loc să încercați să minimizați sau să eliminați acea fereastră de timp între dezvoltare și lansare, ca majoritatea metodologiei Agile, înghețarea codului vă obligă să formalizați această fereastră până la punctul în care trebuie să vă construiți programele de dezvoltare și lansare în jurul acesteia.

dacă înghețurile de cod nu se aliniază principiilor Agile de bază, atunci este greu să faci cazul în care încă aparțin metodologiei.

argumentul 3: Codul îngheață duce la versiuni mai lente, de calitate inferioară

acest argument final este unul mare și include câteva unghiuri diferite.

pentru început, susține că înghețarea codului adaugă multă complexitate și piese suplimentare în mișcare foii de parcurs și, în mod natural, crește șansele ca ceva să meargă prost și să vă arunce cronologia. Chiar dacă nimic nu merge prost, munca implicată în înghețarea codului este consumatoare de timp și imprevizibilă (deoarece nu știți ce bug-uri veți găsi sau cât timp va dura pentru a le remedia), că prin simpla adăugare a codului îngheață în foaia de parcurs, veți crea cicluri de dezvoltare și eliberare mai lente.

apoi, susține că înghețarea codului va reduce productivitatea echipei de dezvoltare. În timp ce Agile, în general, și CICD în mod specific, păstrați dezvoltatorii dvs. în mod constant de lucru într-un lanț neîntrerupt de productivitate, codul îngheață forța dezvoltatorii dvs. pentru a opri munca la intervale predefinite. Procedând astfel, le veți rupe ritmul și îi veți forța să încerce să lucreze în jurul politicilor dvs. de înghețare a codului, în loc să găsiți și să mențineți orice flux îi face cei mai productivi.

în cele din urmă, susține că crearea de ferestre dedicate în care nu mai primiți cerințe de afaceri va limita caracteristicile și funcționalitățile versiunilor dvs. la orice poate fi finalizat înainte de îngheț, ceea ce va duce la software și aplicații de calitate inferioară, mai puțin cuprinzătoare.

a face cazul pentru codul îngheață: o bătălie pierdută?

în acest moment, se pare destul de sumbru pentru oricine care încă mai vrea să includă codul îngheață în metodologia Agile. Detractorii din această practică fac câteva argumente foarte convingătoare și un caz solid în general că, de la dezvoltarea metodologiei Agile moderne, înghețarea codului a devenit:

1. învechit și irelevant
2. nealiniat cu practicile moderne de dezvoltare
3. o barieră în calea lansărilor rapide, de înaltă calitate

dar, în timp ce aceste argumente sunt convingătoare și conțin o mulțime de informații exacte, ele nu sunt antiglonț. Și există defecte fundamentale în cadrul fiecăruia care trebuie discutate înainte de a închide cartea despre înghețarea codului ca element util al managementului agil al produselor.

problema cu argumentul 1: testarea automată nu este cuprinzătoare

QA automată și practicile de dezvoltare Agile au crescut calitatea codului așa cum este produs, acesta este un fapt. Dar doar pentru că o bucată de cod a trecut testarea unității, asta nu înseamnă că este de fapt gata de producție. Chiar și cele mai rafinate abordări CICD nu includ întotdeauna pași critici—cum ar fi testarea regresiei—care asigură o bucată de cod fără defecte. Când vine vorba de ea, există doar câteva lucruri pe care nu le puteți testa și rezolva în timp ce o bucată de cod este în producție.

dacă alegeți să utilizați blocări de cod, nu veți renunța la beneficiile QA automatizate și la cele mai bune practici Agile. Dvs. și echipa dvs. veți prinde pur și simplu problemele mai mici și mai banale ale codului dvs. în timpul producției, eliminând punțile pentru a vă concentra pe prinderea unor probleme mai mari, cu impact mai mare în timpul înghețării, cum ar fi stabilitatea generală și fiabilitatea noului software sau caracteristică.

problema cu argumentul 2: „Reduce”, nu „elimina”

Agile este conceput pentru a reduce timpul dintre dezvoltare și eliberare, care este, de asemenea, un fapt. Dar există o mare diferență între încercarea de a reduce această fereastră și încercarea de ao elimina complet. Acest lucru ar fi aproape imposibil, mai ales pentru proiecte mai mari.

înghețarea codului poate fi foarte scurtă în CICD— sau se poate aplica numai unei ramuri specifice în timp ce dezvoltarea continuă pe alte ramuri—dar există în continuare. Indiferent cât de rafinat a devenit Agile, aproape întotdeauna va exista un punct în toate foile de parcurs de dezvoltare și lansare în care o nouă piesă de software sau caracteristică va fi evaluată într-o stare fixă înainte de a ieși la utilizatorii din lumea reală.

Problema Cu Argumentul 3: Regândirea vitezei și a calității

dacă utilizați codul îngheață, veți adăuga un nou pas în ciclul de dezvoltare și eliberare. Nu există nici o îndoială despre asta. Și de fiecare dată când adăugați un nou pas la orice proces, încetiniți acel proces și creați un nou punct potențial de eșec. Înghețarea codului nu face excepție.

dar este important să facem un pas înapoi și să avem o viziune mai largă asupra încetinirii și pierderii productivității.

dacă funcția dvs. are erori, va trebui să le remediați, indiferent dacă ați prins aceste erori în timpul înghețării codului sau dacă s-au făcut cunoscute după lansare. Dintr-o perspectivă pură de dezvoltare, timpul necesar pentru remedierea acestora va fi aproximativ același în ambele scenarii.

dar dacă aveți de-a face cu bug-uri într-un mediu live, aveți o serie de alte probleme pe care trebuie să le faceți timp pentru a le rezolva, inclusiv:

• decide dacă să se rostogolească înapoi caracteristica buggy sau lăsați-l în direct.
• scoaterea dezvoltatorilor de pe noile lor proiecte, după ce au început să lucreze.
• făcându-l până la utilizatorii din lumea reală, care au fost afectate de bug-uri.
• răspunzând și gestionând părțile interesate interne care nu sunt prea mulțumite de eliberarea dvs. problematică.

lista continuă. Nu este nimic mai complicat, consumator de timp și distructiv pentru productivitate—pentru dvs. și echipa dvs.—decât eliberarea unei caracteristici sau a unui produs defect. Codul îngheață minimizează șansele ca acest lucru să se întâmple.

și în ceea ce privește argumentul că codul îngheață duce la caracteristici și produse de calitate inferioară, deoarece acestea reduc cantitatea de cerințe de afaceri pe care le puteți colecta? Cerințele dvs. de afaceri vor fi întotdeauna puțin mai mult decât o „cea mai bună presupunere” cu privire la ceea ce ar trebui să funcționeze produsul sau funcția dvs. Cele mai valoroase cerințe vor veni întotdeauna de la utilizatorii din lumea reală, implementând produsul sau funcția dvs. în scenarii din lumea reală. Și puteți colecta aceste cerințe doar oferindu-le utilizatorilor versiuni funcționale pe care le pot implementa cât mai fluid și fără erori.

ar trebui să utilizați codul îngheață în managementul de produs AGIL?

în cele din urmă, înghețarea codului joacă încă un rol important pentru mulți manageri de produse agili.

acum, există cazuri în care acestea joacă un rol mai puțin critic. Este posibil ca proiectele foarte mici să nu aibă nevoie de perioade dedicate de înghețare a codului. Noile caracteristici care au consecințe relativ minore dacă sunt expediate imperfect ar putea să nu merite înghețarea. Același lucru este valabil și pentru planurile de lansare pe etape—cum ar fi lansările Canary—atunci când doriți doar să testați noi funcții cu un public cald pe care l-ați pregătit să vă așteptați la o experiență imperfectă și imperfectă.

dar, în majoritatea cazurilor, merită să vă luați timp—chiar și o perioadă foarte scurtă de timp—pentru a vă asigura că noile dvs. caracteristici sunt la fel de perfecte pe cât credeți că sunt înainte de a le pune în mâinile oamenilor care contează cel mai mult: utilizatorii dvs. din lumea reală.

acest articol a fost publicat inițial pe flagship.io