Kode fryser: er de stadig relevante for Agile produktledere?

det virker som en åben og lukket sag.

kode fryser er en relikvie. En rest fra de dage, hvor stive Vandfaldsmetoder tilbød den eneste mulighed for produktudvikling og frigivelse. Hele konceptet med at stoppe produktionen og forsinke frigivelsen—bare for at teste for fejl og andre funktionelle problemer—har ingen plads i moderne, smidig produktstyring.

i det mindste synes det at være konsensusvisningen blandt mange Agile guruer.

men holder det op? Når du først har ridset overfladen på de mest almindelige argumenter mod at inkorporere kodefrysning i smidig produktstyring, vil de stadig virke arkaiske?

i dette stykke undersøger vi de tre hovedargumenter mod at inkorporere kodefrysning i din Agile produktstyring, og vi nedbryder, hvor disse argumenter falder fra hinanden, alt sammen for at hjælpe dig med at træffe en bedre beslutning om, hvorvidt du skal inkorporere kodefrysning i din Agile produktstyring.

Argument 1: Kode fryser er irrelevante og unødvendige

dette argument er ret simpelt og konkret— moderne Agile metoder og værktøjer har elimineret behovet for et dedikeret KVALITETSSIKRINGSVINDUE og testvindue.

Agile metoder såsom peer-kode anmeldelser, par programmering, og den konstante overvågning af systemet sundhed giver dig meget større synlighed i et program eller funktion ydeevne, mens det er under udvikling. Fejl og problemer er lettere og mere tilbøjelige til at blive fanget under selve udviklingen og løst inden dedikerede test-og KVALITETSSIKRINGSAKTIVITETER.

nye værktøjer har også automatiseret mange tests. De evaluerer konstant kode for at sikre, at den er ren og klar til produktion til enhver tid. Problemer identificeres i realtid, og advarsler sendes straks ud for at løse dem ASAP. Antallet af test, der er blevet automatiseret, er allerede bredt og fortsætter med at vokse, hvilket dramatisk reducerer mængden af manuelle test, der skal udføres.

resultatet af disse nye Agile metoder og værktøjer er let at se. De fleste af de centrale test-og KVALITETSSIKRINGSAKTIVITETER, der udføres under en kodefrysning, udføres enten under udvikling eller udføres af programmer. I Agile afslutter programmel og funktioner NU udviklingen på et meget højere niveau af tillid, end de plejede at gøre, hvilket gør en dedikeret kode fryse sværere og sværere at retfærdiggøre.

Argument 2: kode fryser bryde en kerne Agile princip

dette andet argument er lidt højere niveau. Grundlæggende hævder det, at kodefrysning ikke har et hjem i agil metode, fordi de bryder en af Agile metodologis kerneprincipper— hvilket reducerer tiden mellem udvikling og frigivelse.

jo mere raffineret din tilgang til Agile, jo mere vil du forsøge at krympe dette tidsvindue. De mest raffinerede nuværende tilgange til Agile er kontinuerlig Integration og kontinuerlig udvikling (CICD), og de sigter mod at bryde udviklingen i små, trinvise ændringer for at “frigive” ændringer i koden så hurtigt som muligt. I den reneste anvendelse af CICD eksisterer udvikling og frigivelse næppe som forskellige faser— ny kode er integreret i applikationen næsten så snart den er afsluttet.

i modsætning hertil skal du opretholde forskellige udviklings-og frigivelsesfaser, hvis du skal implementere kodefrysning. Når alt kommer til alt er det her, hvor kodefrysningen lever— mellem disse to forskellige faser. I stedet for at forsøge at minimere eller eliminere det tidsvindue mellem udvikling og frigivelse som de fleste af Agile metoder, kode fryser tvinge dig til at formalisere dette vindue til det punkt, at du har brug for at opbygge din udvikling og frigive tidsplaner omkring det.

hvis kodefrysning ikke stemmer overens med centrale Agile principper, er det svært at gøre sagen, at de stadig hører hjemme i metoden.

Argument 3: Kodefrysning fører til langsommere udgivelser af lavere kvalitet

dette sidste argument er stort, og det inkluderer et par forskellige vinkler.

for at starte argumenterer det for, at kodefrysning tilføjer en masse kompleksitet og yderligere bevægelige dele til din køreplan, og øger naturligvis chancerne for, at noget går galt og smider din tidslinje. Selvom intet går galt, er arbejdet involveret i kodefrysning tidskrævende og uforudsigeligt (da du ikke ved, hvilke fejl du finder, eller hvor lang tid det tager at rette dem), at ved blot at tilføje kodefrysning til din køreplan vil du skabe langsommere udviklings-og frigivelsescyklusser.

Næste, det hævder, at kode fryser vil reducere din udvikling team produktivitet. Mens Agile generelt, og cicd specifikt, holde dine udviklere konstant arbejder i en ubrudt kæde af produktivitet, kode fryser tvinge dine udviklere til at stoppe arbejdet med foruddefinerede intervaller. Ved at gøre dette vil du bryde deres rytme og tvinge dem til at forsøge at omgå dine kodefrysningspolitikker i stedet for at finde og vedligeholde den strøm, der gør dem mest produktive.

endelig hævder det, at oprettelse af dedikerede vinduer, hvor du holder op med at modtage forretningskrav, vil begrænse funktionerne og funktionaliteterne i dine udgivelser til det, der kan afsluttes før frysningen, hvilket vil føre til lavere kvalitet, mindre omfattende programmer og applikationer.

gør sagen for kode fryser: en tabende kamp?

på dette tidspunkt ser det ret dyster ud for alle, der stadig ønsker at inkludere kodefrysning i Agile metodologi. Modstandere fra denne praksis fremsætter nogle meget overbevisende argumenter og en samlet solid sag, der, siden udviklingen af moderne smidig metode, kodefrysning er blevet:

1. forældet og irrelevant
2. forkert justeret med moderne udviklingspraksis
3. en barriere for hurtige udgivelser af høj kvalitet

men selvom disse argumenter er overbevisende og indeholder en masse nøjagtige oplysninger, er de ikke skudsikre. Og der er grundlæggende mangler inden for hver, der skal diskuteres, før bogen om kodefrysning lukkes som et nyttigt element i smidig produktstyring.

problemet med Argument 1: automatiseret test er ikke omfattende

automatiseret kvalitetssikring og Agile udviklingspraksis har øget kvaliteten af kode, som den er produceret, det er en kendsgerning. Men bare fordi et stykke kode har bestået enhedstest, betyder det ikke, at det faktisk er produktionsklar. Selv de mest raffinerede cicd-tilgange inkluderer ikke altid kritiske trin—som regressionstest—der sikrer, at et stykke kode er fejlfri. Når det kommer til stykket, er der bare nogle ting, du ikke kan teste og løse, mens et stykke kode er i produktion.

hvis du vælger at bruge kodefrysninger, vil du ikke opgive fordelene ved automatiseret kvalitetssikring og Agile bedste praksis. Du og dit team vil simpelthen fange din kodes mindre, mere trivielle problemer under produktionen, rydde dækene for at fokusere på at fange større problemer med større effekt under din frysning, såsom den generelle stabilitet og pålidelighed af dit nye program eller funktion.

problemet med Argument 2: “Reducer”, ikke “Eliminer”

Agile er designet til at reducere tiden mellem udvikling og frigivelse, det er også en kendsgerning. Men der er stor forskel på at forsøge at reducere dette vindue og forsøge at fjerne det helt. Det ville være næsten umuligt, især for større projekter.

kodefrysningen kan være meget kort i CICD— eller gælder muligvis kun for en bestemt gren, mens udviklingen fortsætter på andre grene—men den findes stadig. Uanset hvor raffineret Agile blev, vil der næsten altid være et punkt i al udvikling og frigivelse køreplaner, hvor et nyt stykke program eller funktion vil blive evalueret i en fast tilstand, før det går ud til virkelige brugere.

Problemet Med Argument 3: Nytænkning hastighed og kvalitet

hvis du bruger kode fryser, vil du tilføje et nyt skridt til din udvikling og frigivelse cyklus. Det er der ingen tvivl om. Og hver gang du tilføjer et nyt trin til enhver proces, sænker du processen, og du opretter et nyt potentielt fejlpunkt. Kode fryser er ingen undtagelse.

men det er vigtigt at tage et skridt tilbage og tage et bredere overblik over afmatning og tabt produktivitet.

hvis din funktion har fejl, skal du rette dem, uanset om du fangede disse fejl under en kodefrysning, eller om de gav sig til kende efter frigivelsen. Fra et rent udviklingsperspektiv vil den tid, der er nødvendig for at rette dem, være omtrent den samme i begge scenarier.

men hvis du har at gøre med fejl i et levende miljø, har du en lang række andre problemer, du skal tage dig tid til at håndtere, herunder:

• beslutning om at rulle buggy-funktionen tilbage eller lade den være live.
• fjernelse af dine udviklere fra deres nye projekter, efter at de er begyndt at arbejde.
• gør det op til dine virkelige brugere, der blev påvirket af fejlene.
• besvare og styre dine interne interessenter, der ikke er alt for glade for din problematiske udgivelse.

listen fortsætter. Der er intet mere kompliceret, tidskrævende og ødelæggende for produktiviteten-for dig og dit team—end at frigive en ødelagt funktion eller et produkt. Kode fryser minimere chancerne for dette sker.

og hvad angår argumentet om, at kode fryser, fører til funktioner og produkter af lavere kvalitet, fordi de reducerer mængden af forretningskrav, du kan indsamle? Dine forretningskrav vil altid være lidt mere end et “bedste gæt” om, hvad dit produkt eller din funktion skal fungere som. De mest værdifulde krav kommer altid fra brugere i den virkelige verden, implementering af dit produkt eller din funktion i virkelige scenarier. Og du kan kun indsamle disse krav ved at give dine brugere funktionelle udgivelser, som de kan implementere så flydende og fejlfrit som muligt.

skal du bruge kode fryser i din Agile produktstyring?

i sidste ende spiller kodefrysning stadig en vigtig rolle for mange Agile produktledere.

nu er der tilfælde, hvor de spiller en mindre kritisk rolle. Meget små projekter har muligvis ikke brug for dedikerede kodefrysningsperioder. Nye funktioner, der har relativt mindre konsekvenser, hvis de sender ufuldstændigt, er måske ikke værd at fryse. Det samme gælder for fasede udgivelsesplaner-som Canary Releases-når du bare vil teste nye funktioner med et varmt publikum, som du har klar til at forvente en buggy, ufuldkommen oplevelse.

men i de fleste tilfælde er det værd at tage sig tid—selv en meget kort periode—for at sikre, at dine nye funktioner er så perfekte, som du tror, de er, før du lægger dem i hænderne på de mennesker, der betyder mest: dine virkelige brugere.

denne artikel blev oprindeligt offentliggjort den flagship.io