Kode Fryser: Er de Fortsatt Relevante for Agile Produktsjefer?

det virker som en åpen og lukket sak.

kode fryser er en relikvie. En leftover fra dagene da stive Foss metoder tilbudt det eneste alternativet for produktutvikling og utgivelse. Hele konseptet med å stoppe produksjonen og forsinke utgivelsen—bare for å teste for feil og andre funksjonelle problemer-har ingen plass i moderne, Smidig produktstyring.

i det minste synes det å være konsensusvisningen blant Mange Smidige guruer.

men holder det opp? Når du skraper overflaten av de vanligste argumentene mot å inkorporere kode fryser i Smidig produktstyring, vil de fortsatt virke arkaiske?

i dette stykket vil vi utforske de tre hovedargumentene mot å inkorporere kodefrys i Agile – produktadministrasjonen din, og vi vil bryte ned hvor disse argumentene faller fra hverandre, alt for å hjelpe deg med å ta en bedre beslutning om hvorvidt du bør innlemme kodefrys i Agile-produktadministrasjonen.

Argument 1: Kode Fryser Er Irrelevant Og Unødvendig

dette argumentet er ganske enkelt og konkret-moderne Smidige metoder og verktøy har eliminert behovet for et dedikert QA og testvindu.

Agile metoder som peer kode vurderinger, par programmering, og konstant overvåking av systemtilstand gir deg mye større synlighet i et program eller funksjonens ytelse mens den blir utviklet. Bugs og problemer er enklere, og mer sannsynlig, å bli fanget under utviklingen selv, og løst før noen dedikerte testing og QA aktiviteter.

Nye verktøy har også automatisert mange tester. De evaluerer kontinuerlig kode for å sikre at den er ren og klar for produksjon til enhver tid. Problemer identifiseres i sanntid, og varsler sendes umiddelbart UT FOR å løse DEM ASAP. Antallet tester som har blitt automatisert, er allerede omfattende og fortsetter å vokse, noe som dramatisk reduserer volumet av manuelle tester som må utføres.

resultatet av Disse Nye Smidige metodene og verktøyene er lett å se. De fleste kjernetesting og QA-aktiviteter som utføres under en kodefrysing, utføres enten under utvikling eller utføres av programvare. I Agile, programvare og funksjoner nå avslutte utvikling på et mye høyere nivå av tillit enn de pleide å, noe som gjør en dedikert kode fryse vanskeligere og vanskeligere å rettferdiggjøre.

Argument 2: Kode Fryser Bryte En Kjerne Smidig Prinsipp

Dette andre argumentet er litt høyere nivå. I utgangspunktet hevder det at kode fryser ikke har et hjem i Agile-metodikk fordi de bryter En Av Agile-metodikkens kjerneprinsipper-reduserer tiden mellom utvikling og utgivelse.

jo mer raffinert din tilnærming Til Agile, desto mer vil du prøve å krympe dette tidsvinduet. De mest raffinerte nåværende tilnærmingene Til Agile er Continuous Integration and Continuous Development (CICD), og de tar sikte på å bryte utviklingen i små, inkrementelle endringer for å «frigjøre» endringer i koden så raskt som mulig. I den reneste anvendelsen av CICD eksisterer utvikling og utgivelse knapt som forskjellige faser-ny kode er integrert i søknaden nesten så snart den er fullført.

derimot må du opprettholde forskjellige utviklings-og utgivelsesfaser hvis du skal distribuere kode fryser. Tross alt, det er der koden fryser liv-i mellom de to forskjellige faser. I stedet for å prøve å minimere eller eliminere det tidsvinduet mellom utvikling og utgivelse som de fleste Av Agile metodikk, kode fryser tvinge deg til å formalisere dette vinduet til det punktet du trenger for å bygge din utvikling og slipp tidsplaner rundt det.

hvis koden fryser ikke stemmer overens med Kjerne Agile prinsipper, er det vanskelig å gjøre saken de fortsatt hører hjemme i metodikken.

Argument 3: Kode Fryser Føre Til Tregere, Lavere Kvalitet Utgivelser

dette siste argumentet er en stor en, og det inkluderer et par forskjellige vinkler.

for å starte, hevder det at kode fryser legge mye kompleksitet og flere bevegelige deler til veikart, og naturligvis øke sjansene for at noe vil gå galt og kaste av tidslinjen. Selv om ingenting går galt, er arbeidet som er involvert i kode fryser tidkrevende og uforutsigbar (som du ikke vet hva bugs du vil finne eller hvor lang tid det vil ta å fikse dem), at ved å legge kode fryser til veikart vil du skape tregere utvikling og slipp sykluser.

deretter hevder det at kode fryser vil redusere utviklingsteamets produktivitet. Mens Agile generelt, og CICD spesifikt, holde utviklerne jobber kontinuerlig i en ubrutt kjede av produktivitet, kode fryser tvinge utviklerne til å stoppe arbeidet på forhåndsdefinerte intervaller. Ved å gjøre dette, vil du bryte sin rytme og tvinge dem til å prøve å omgå koden fryse politikk, i stedet for å finne og opprettholde hva flyten gjør dem mest produktive.

til Slutt hevder det at å skape dedikerte vinduer der du slutter å motta forretningskrav, vil begrense funksjonene og funksjonaliteten til utgivelsene dine til det som kan fullføres før frysingen, noe som vil føre til lavere kvalitet, mindre omfattende programvare og applikasjoner.

Å Gjøre Saken For Kode Fryser: En Tapende Kamp?

På dette punktet ser det ganske dyster ut for alle som fortsatt vil inkludere kode fryser I Agile metodikk. Kritikere fra denne praksisen gjør noen svært overbevisende argumenter og en samlet solid sak som, siden utviklingen av moderne Smidig metodikk, kode fryser har blitt:

1. Foreldet og irrelevant
2. Feiljustert med moderne utviklingspraksis
3. en barriere for raske utgivelser av høy kvalitet

men selv om disse argumentene er overbevisende og inneholder mye nøyaktig informasjon, er de ikke skuddsikre. Og det er grunnleggende feil i hver som må diskuteres før du lukker boken på kode fryser som et nyttig element I Smidig produktstyring.

Problemet Med Argument 1: Automatisert Testing Er Ikke Omfattende

Automatisert QA og Smidig utviklingspraksis har økt kvaliteten på koden som den er produsert, det er et faktum. Men bare fordi et stykke kode har passert enhetstesting, betyr det ikke at det faktisk er produksjonsklart. Selv de mest raffinerte cicd-tilnærmingene inkluderer ikke alltid kritiske trinn-som regresjonstesting – som sikrer at et stykke kode er feilfritt. Når det kommer til det, er det bare noen ting du ikke kan teste og løse mens et stykke kode er i produksjon.

hvis du velger å bruke kode fryser, kommer du ikke til å gi opp fordelene med automatisert QA og Smidig beste praksis. Du og teamet ditt vil ganske enkelt fange kodens mindre, mer trivielle problemer under produksjonen, rydde dekkene for å fokusere på å fange større problemer med større innvirkning under frysingen, for eksempel den generelle stabiliteten og påliteligheten til den nye programvaren eller funksjonen.

Problemet Med Argument 2: «Reduser», Ikke «Eliminer»

Agile er designet for å redusere tiden mellom utvikling og utgivelse, det er også et faktum. Men det er en stor forskjell mellom å prøve å redusere dette vinduet, og prøver å eliminere det helt. Å gjøre det ville være nesten umulig, spesielt for større prosjekter.

kodefrysingen kan være svært kort i CICD-eller kan bare gjelde for en bestemt gren mens utviklingen fortsetter på andre grener-men den eksisterer fortsatt— Uansett hvor raffinert Agile ble, vil det nesten alltid være et punkt i all utvikling og utgivelse av veikart hvor et nytt stykke programvare eller funksjon vil bli evaluert i fast tilstand før den går ut til virkelige brukere.

Problemet Med Argument 3: Rethinking Hastighet Og Kvalitet

hvis du bruker kode fryser, vil du legge til et nytt skritt til utvikling og utgivelse syklus. Det er det ingen tvil om. Og hver gang du legger til et nytt trinn i en prosess, reduserer du prosessen og du oppretter et nytt potensielt feilpunkt. Kode fryser er ikke noe unntak.

men det er viktig å ta et skritt tilbake, og å ta et bredere syn på nedgang og tapt produktivitet.

hvis funksjonen din har feil, må du fikse dem, uansett om du fanget disse feilene under en kodefrysing, eller om de gjorde seg kjent etter utgivelsen. Fra et rent utviklingsperspektiv vil tiden som trengs for å fikse dem, være omtrent det samme i begge scenarier.

Men hvis du har å gjøre med feil i et levende miljø, har du en rekke andre problemer du må ta deg tid til å håndtere, inkludert:

• Bestemme om å rulle tilbake buggy-funksjonen eller la den leve.
• Ta utviklerne av sine nye prosjekter, etter at de har begynt arbeidet.
• Gjør det opp til dine virkelige brukere som ble påvirket av feilene.
• Svare på og administrere dine interne interessenter som ikke er så glade for din problematiske utgivelse.

listen fortsetter. Det er ikke noe mer komplisert, tidkrevende og ødeleggende for produktiviteten-for deg og teamet ditt—enn å frigjøre en ødelagt funksjon eller et produkt. Kode fryser minimere sjansene for at dette skjer.

og som til argumentet om at koden fryser føre til lavere kvalitet funksjoner og produkter fordi de redusere mengden av forretningsbehov du kan samle? Dine forretningsbehov vil alltid være litt mer enn en «beste gjetning» om hva produktet eller funksjonen skal fungere som. De mest verdifulle kravene vil alltid komme fra virkelige brukere, distribuere produktet eller funksjonen i virkelige scenarier. Og du kan bare samle disse kravene ved å gi brukerne funksjonelle utgivelser som de kan distribuere så flytende og feilfri som mulig.

Bør Du Bruke Kode Fryser I Agile Produktstyring?

til Slutt spiller koden fryser fortsatt en viktig rolle for Mange Smidige produktledere.

nå er det tilfeller der de spiller en mindre kritisk rolle. Svært små prosjekter trenger kanskje ikke dedikerte kodefryseperioder. Nye funksjoner som har relativt små konsekvenser hvis de sender ufullkomment, kan ikke være verdt frysen. Det samme gjelder for fasede utgivelsesplaner—som Canary-Utgivelser-når du bare vil teste nye funksjoner med et varmt publikum som du har primet for å forvente en buggy, ufullkommen opplevelse.

men i de fleste tilfeller er det verdt å ta seg tid—selv en veldig kort periode – for å sikre at de nye funksjonene er så perfekte som du tror de er før du legger dem i hendene på de som betyr mest: dine virkelige brukere.

denne artikkelen ble opprinnelig publisert på flagship.io