Kod fryser: är de fortfarande relevanta för smidiga produktchefer?

det verkar som ett öppet och stängt fall.

kodfrysningar är en relik. En rest från de dagar då styva Vattenfallsmetoder erbjöd det enda alternativet för produktutveckling och release. Hela konceptet att stoppa produktionen och fördröja frisläppandet—bara för att testa för buggar och andra funktionella problem—har ingen plats i modern, smidig produkthantering.

åtminstone verkar det vara konsensusvyn bland många smidiga guruer.

men håller det upp? När du kliar på ytan av de vanligaste argumenten mot att integrera kodfrysningar i smidig produkthantering, kommer de fortfarande att verka arkaiska?

i det här stycket kommer vi att undersöka de tre huvudargumenten mot att integrera kodfrysningar i din smidiga produkthantering, och vi kommer att bryta ner var dessa argument faller ihop, allt för att hjälpa dig att fatta ett bättre beslut om huruvida du ska införliva kodfrysningar i din smidiga produkthantering.

Argument 1: Kodfrysningar är irrelevanta och onödiga

detta argument är ganska enkelt och konkret— moderna smidiga metoder och verktyg har eliminerat behovet av ett dedikerat QA-och testfönster.

agila metoder som peer – kod recensioner, par programmering, och den ständiga övervakningen av systemhälsa ger dig mycket större insyn i ett program eller funktion prestanda medan det utvecklas. Buggar och problem är enklare och mer sannolikt att fångas under själva utvecklingen och lösas före några dedikerade test-och QA-aktiviteter.

nya verktyg har också automatiserat många tester. De utvärderar ständigt koden för att se till att den är ren och redo för produktion hela tiden. Problem identifieras i realtid och varningar skickas omedelbart ut för att lösa dem ASAP. Antalet tester som har automatiserats är redan omfattande och fortsätter att växa, vilket dramatiskt minskar volymen av manuella tester som behöver utföras.

resultatet av dessa nya smidiga metoder och verktyg är lätt att se. De flesta av kärntestningarna och QA-aktiviteterna som utförs under en kodfrysning utförs antingen under utveckling eller utförs av programvara. I Agile avslutar programvara och funktioner nu utvecklingen på en mycket högre nivå av förtroende än de brukade, vilket gör en dedikerad kodfrysning svårare och svårare att motivera.

Argument 2: kod fryser bryta en kärna Agile princip

detta andra argument är lite högre nivå. I grund och botten hävdar det att kodfrysningar inte har ett hem i Agile— metodik eftersom de bryter mot en av Agile-metodens kärnprinciper-vilket minskar tiden mellan utveckling och frisättning.

ju mer förfinad din inställning till Agile, desto mer kommer du att försöka krympa detta tidsfönster. De mest förfinade nuvarande metoderna för Agile är kontinuerlig Integration och kontinuerlig utveckling (CICD), och de syftar till att bryta utvecklingen i små, inkrementella förändringar för att ”släppa” ändringar i koden så snabbt som möjligt. I den renaste tillämpningen av CICD finns utveckling och frisättning knappt som distinkta faser— ny kod integreras i applikationen nästan så snart den är klar.

däremot måste du behålla distinkta utvecklings-och släppfaser om du ska distribuera kodfrysningar. Det är ju där kodfrysningen lever – mellan de två olika faserna. I stället för att försöka minimera eller eliminera det tidsfönstret mellan utveckling och release som de flesta av Agile metodik, kod fryser tvinga dig att formalisera detta fönster till den punkt som du behöver för att bygga din utveckling och släppa scheman runt den.

om kodfrysningar inte stämmer överens med centrala agila principer, är det svårt att göra det fall de fortfarande hör hemma i metoden.

Argument 3: Kodfrysningar leder till långsammare utgåvor av lägre kvalitet

detta sista argument är stort och innehåller några olika vinklar.

till att börja med hävdar det att kodfrysningar lägger till mycket komplexitet och ytterligare rörliga delar i din färdplan och naturligtvis ökar chansen att något kommer att gå fel och kasta bort din tidslinje. Även om inget går fel är arbetet med kodfrysningar tidskrävande och oförutsägbart (eftersom du inte vet vilka buggar du hittar eller hur lång tid det tar att fixa dem), att genom att helt enkelt lägga till kodfrysningar i din färdplan kommer du att skapa långsammare utvecklings-och släppcykler.

därefter hävdar det att kodfrysningar kommer att minska ditt utvecklingsteams produktivitet. Medan Agile i allmänhet, och CICD specifikt, hålla dina utvecklare ständigt arbetar i en obruten kedja av produktivitet, kod fryser tvinga dina utvecklare att stoppa arbetet med fördefinierade intervall. Genom att göra detta kommer du att bryta deras rytm och tvinga dem att försöka arbeta runt din kodfrysningspolicy, istället för att hitta och behålla det flöde som gör dem mest produktiva.

slutligen hävdar det att skapa dedikerade fönster där du slutar ta emot affärskrav kommer att begränsa funktionerna och funktionerna i dina utgåvor till vad som helst som kan slutföras före frysningen, vilket leder till lägre kvalitet, mindre omfattande programvara och applikationer.

att göra fallet för kod fryser: en förlorande kamp?

vid denna tidpunkt ser det ganska dyster ut för alla som fortfarande vill inkludera kodfrysningar i smidig metodik. Belackare från denna praxis gör några mycket övertygande argument och ett övergripande solidt fall att, sedan utvecklingen av modern smidig metodik, kodfrysningar har blivit:

1. föråldrad och irrelevant
2. feljusterad med modern utvecklingspraxis
3. ett hinder för snabba, högkvalitativa utgåvor

men även om dessa argument är övertygande och innehåller mycket korrekt information, är de inte skottsäkra. Och det finns grundläggande brister inom var och en som måste diskuteras innan du stänger boken om kodfrysningar som ett användbart element i smidig produkthantering.

problemet med Argument 1: automatiserad testning är inte omfattande

automatiserad QA och smidiga utvecklingsmetoder har ökat kvaliteten på koden som den produceras, det är ett faktum. Men bara för att en bit kod har passerat enhetstestning betyder det inte att det faktiskt är produktionsklart. Även de mest raffinerade CICD-tillvägagångssätten inkluderar inte alltid kritiska steg—som regressionstestning—som säkerställer att en bit kod är felfri. När det kommer till kritan finns det bara några saker du inte kan testa och lösa medan en bit kod är i produktion.

om du väljer att använda kodfrysningar kommer du inte att ge upp fördelarna med automatiserad QA och smidiga bästa metoder. Du och ditt team kommer helt enkelt att fånga din kods mindre, mer triviala problem under produktionen, rensa däcken för att fokusera på att fånga större problem med högre effekt under din frysning, till exempel den övergripande stabiliteten och tillförlitligheten hos din nya programvara eller funktion.

problemet med Argument 2:” Minska”, inte”eliminera”

Agile är utformat för att minska tiden mellan utveckling och release, det är också ett faktum. Men det finns en stor skillnad mellan att försöka minska det här fönstret och försöka helt eliminera det. Att göra det skulle vara näst intill omöjligt, särskilt för större projekt.

kodfrysningen kan vara mycket kort i CICD-eller kan bara gälla för en viss gren medan utvecklingen fortsätter på andra grenar—men den finns fortfarande. Oavsett hur raffinerad Agile blev, kommer det nästan alltid att vara en punkt i alla utvecklings-och släppplaner där en ny programvara eller funktion kommer att utvärderas i ett fast tillstånd innan det går ut till verkliga användare.

Problemet Med Argument 3: Ompröva hastighet och kvalitet

om du använder kodfrysningar lägger du till ett nytt steg i din utvecklings-och släppcykel. Det råder ingen tvekan om det. Och varje gång du lägger till ett nytt steg i någon process, saktar du ner processen och skapar en ny potentiell felpunkt. Kodfrysningar är inget undantag.

men det är viktigt att ta ett steg tillbaka och ta en bredare bild av avmattning och förlorad produktivitet.

om din funktion har fel måste du fixa dem, oavsett om du fångade dessa fel under en kodfrysning eller om de gjorde sig kända efter utgivningen. Ur ett rent utvecklingsperspektiv kommer den tid som behövs för att fixa dem att vara ungefär densamma i båda scenarierna.

men om du har att göra med buggar i en levande miljö har du en mängd andra problem du behöver ta dig tid att hantera, inklusive:

• besluta om att rulla tillbaka buggy-funktionen eller lämna den live.
• ta bort dina utvecklare från sina nya projekt, efter att de har börjat arbeta.
• gör det upp till dina verkliga användare som påverkades av buggarna.
• svara på och hantera dina interna intressenter som inte är så glada över din problematiska release.

listan fortsätter. Det finns inget mer komplicerat, tidskrävande och destruktivt för produktiviteten-för dig och ditt team—än att släppa en trasig funktion eller produkt. Kodfrysningar minimerar risken för att detta händer.

och när det gäller argumentet att koden fryser leder till lägre kvalitetsfunktioner och produkter eftersom de minskar mängden affärskrav du kan samla in? Dina affärskrav kommer alltid att vara lite mer än en” bästa gissning ” om vad din produkt eller funktion ska fungera som. De mest värdefulla kraven kommer alltid från verkliga användare, distribuera din produkt eller funktion i verkliga scenarier. Och du kan bara samla in dessa krav genom att ge dina användare funktionella utgåvor som de kan distribuera så smidigt och felfritt som möjligt.

ska du använda Kodfrysningar i din smidiga produkthantering?

i slutändan spelar kodfrysningar fortfarande en viktig roll för många smidiga produktchefer.

nu finns det fall där de spelar en mindre kritisk roll. Mycket små projekt kanske inte behöver dedikerade kodfrysningsperioder. Nya funktioner som har relativt små konsekvenser om de skickar ofullständigt kanske inte är värda frysningen. Detsamma gäller för fasade utgivningsplaner – som Canary-utgåvor-när du bara vill testa nya funktioner med en varm publik som du har grundat för att förvänta dig en buggy, ofullkomlig upplevelse.

men i de flesta fall är det värt att ta sig tid—även en mycket kort tid—för att se till att dina nya funktioner är så perfekta som du tror att de är innan du lägger dem i händerna på de människor som betyder mest: dina verkliga användare.

denna artikel publicerades ursprungligen på flagship.io