Koodi jäätyy: ovatko ne vielä ajankohtaisia ketterille tuotepäälliköille?

se tuntuu selvältä tapaukselta.

koodin jäätymiset ovat jäänne. Jäänne ajoilta, jolloin jäykät Vesiputousmetodit tarjosivat ainoan vaihtoehdon tuotekehitykselle ja julkaisulle. Koko tuotannon pysäyttämisen ja julkaisun viivyttämisen käsitteellä—vain vikojen ja muiden toiminnallisten ongelmien testaamiseksi—ei ole sijaa nykyaikaisessa, ketterässä tuotehallinnassa.

ainakin tämä näyttää olevan monien ketterien gurujen yksimielinen näkemys.

mutta kestääkö se? Kun raaputat pintaa yleisimmistä argumenteista koodipakasteiden sisällyttämistä ketterään tuotehallintaan vastaan, vaikuttavatko ne vielä arkaaisilta?

tässä artikkelissa tarkastelemme kolmea pääperustetta, jotka estävät koodijäädytysten sisällyttämisen ketterään tuotehallintaasi, ja erittelemme, missä nämä argumentit hajoavat, auttaaksemme sinua tekemään paremman päätöksen siitä, pitäisikö sinun sisällyttää koodijäädytykset ketterään tuotehallintaasi.

argumentti 1: Koodijäädytykset ovat epäolennaisia ja tarpeettomia

tämä argumentti on melko yksinkertainen ja konkreettinen-nykyaikaiset ketterät menetelmät ja työkalut ovat poistaneet tarpeen Oman QA-ja testausikkunan.

ketterät menetelmät, kuten vertaiskoodiarvioinnit, pariohjelmointi ja järjestelmän kunnon jatkuva seuranta, antavat paljon paremman näkyvyyden sovelluksen tai ominaisuuden suorituskykyyn sitä kehitettäessä. Viat ja ongelmat on helpompi ja todennäköisempää saada kiinni itse kehityksen aikana ja ratkaista ennen mitään erityistä testaus-ja LAADUNVARMISTUSTOIMINTAA.

uudet työkalut ovat myös automatisoineet monia testejä. He arvioivat koodia jatkuvasti varmistaakseen, että se on puhdas ja valmis tuotantoon koko ajan. Ongelmat tunnistetaan reaaliajassa, ja hälytykset lähetetään välittömästi niiden ratkaisemiseksi ASAP. Automatisoitujen testien määrä on jo laaja-alainen ja kasvaa edelleen, mikä vähentää huomattavasti manuaalisten testien määrää.

näiden uusien ketterien menetelmien ja työkalujen tulos on helppo nähdä. Suurin osa koodin jäädyttämisen aikana suoritetuista ydinkokeista ja LAADUNVARMISTUSTOIMISTA suoritetaan joko kehitystyön aikana tai ohjelmiston avulla. Agilessa ohjelmistot ja ominaisuudet poistuvat nyt kehitystyöstä paljon suuremmalla luottamuksella kuin ennen, mikä tekee dedikoidun koodin jäädyttämisestä yhä vaikeampaa perustella.

argumentti 2:koodin jäätymiset murtavat ytimen ketterän periaatteen

tämä toinen argumentti on hieman korkeampi. Pohjimmiltaan, se väittää, että koodin jäätyminen ei ole koti Agile metodologia, koska ne rikkovat yhden Agile metodologian perusperiaatteet-vähentää aikaa kehittämisen ja julkaisemisen.

mitä hienostuneempi lähestymistapasi ketterään on, sitä enemmän yrität kutistaa tätä aikaikkunaa. Jalostetuimpia nykyisiä Agile-lähestymistapoja ovat jatkuva integraatio ja jatkuva kehitys (Cicd), ja ne pyrkivät pilkkomaan kehityksen pieniksi, inkrementaalisiksi muutoksiksi, jotta muutokset koodiin ”vapautuisivat” mahdollisimman nopeasti. Cicd: n puhtaimmassa sovelluksessa kehitys ja julkaisu ovat hädin tuskin olemassa erillisinä vaiheina— uusi koodi integroidaan sovellukseen lähes heti sen valmistuttua.

sen sijaan, sinun täytyy ylläpitää erillisiä kehitys-ja julkaisuvaiheita, jos aiot ottaa käyttöön koodin jäätymisiä. Siellä koodijäädytys elää – noiden kahden eri vaiheen välissä. Sen sijaan, että yrittäisit minimoida tai poistaa tuon aikaikkunan kehityksen ja julkaisun välillä, kuten useimmat ketterät menetelmät, koodi jäätyy pakottaa sinut virallistamaan tämän ikkunan siihen pisteeseen, että sinun täytyy rakentaa kehitys-ja julkaisuaikataulut sen ympärille.

jos koodin jäätyminen ei ole linjassa core Agile-periaatteiden kanssa, on vaikea sanoa, että ne edelleen kuuluvat metodologiaan.

argumentti 3: koodin jäätyminen johtaa hitaampiin, heikompilaatuisiin julkaisuihin

tämä lopullinen argumentti on suuri, ja se sisältää muutamia eri näkökulmia.

aluksi se väittää, että koodin jäätyminen lisää tiekarttaasi paljon monimutkaisuutta ja lisää liikkuvia osia ja luonnollisesti lisää mahdollisuuksia, että jokin menee vikaan ja heittää aikajanasi pois. Vaikka mikään ei mene pieleen, työ mukana koodi jäätyy on aikaa vievää ja arvaamaton (koska et tiedä, mitä vikoja löydät tai kuinka kauan se kestää korjata ne), että yksinkertaisesti lisäämällä koodi jäätyy Oman etenemissuunnitelman luo hitaampaa kehitystä ja release syklit.

seuraavaksi se väittää, että koodin jäätyminen vähentää kehitystiimisi tuottavuutta. Vaikka Ketterä yleensä, ja erityisesti CICD, pitää kehittäjät jatkuvasti töissä katkeamattomassa tuottavuusketjussa, koodin jäätyminen pakottaa kehittäjät lopettamaan työn ennalta määritellyin väliajoin. Tekemällä tämän, voit rikkoa niiden rytmi ja pakottaa heidät yrittää kiertää koodin jäädyttää politiikkoja, sen sijaan löytää ja ylläpitää mitä virtaus tekee niistä tuottavimpia.

lopuksi, se väittää, että luoda oma windows, jossa et enää vastaanota liiketoiminnan vaatimukset rajoittaa ominaisuuksia ja toimintoja teidän julkaisujen mitä tahansa voidaan saada valmiiksi ennen jäädyttämistä, mikä johtaa heikompilaatuisia, vähemmän kattavia ohjelmistoja ja sovelluksia.

Making the Case for Code Freezes: a Losing Battle?

tässä vaiheessa näyttää aika synkältä, jos haluaa vielä sisällyttää Koodijäädytykset ketterään metodiikkaan. Tätä käytäntöä arvostelevat tahot esittävät joitakin hyvin vakuuttavia argumentteja ja kaiken kaikkiaan pitäviä todisteita siitä, että nykyaikaisen ketterän menetelmän kehittämisen jälkeen koodi jäätyy on tullut:

1. vanhentuneet ja epäolennaiset
2. Väärinkohdellut nykyaikaisten kehityskäytäntöjen kanssa
3. este nopeille, korkealaatuisille julkaisuille

, mutta vaikka nämä väitteet ovat vakuuttavia ja sisältävät paljon tarkkaa tietoa, ne eivät ole luodinkestäviä. Ja on perustavanlaatuisia puutteita kussakin, jotka on keskusteltava ennen sulkemista kirjan koodi jäätyy hyödyllisenä osana Ketterä tuotehallinta.

argumentin 1 ongelma: automatisoitu testaus ei ole kattava

automatisoitu laadunvarmistus ja ketterät kehityskäytännöt ovat parantaneet koodin laatua sitä tuotettaessa, se on tosiasia. Mutta vaikka koodi on läpäissyt testauksen, se ei tarkoita, että se olisi valmis tuotantoon. Jopa hienostuneimmat CICD-lähestymistavat eivät aina sisällä kriittisiä vaiheita—kuten regressiotestausta—jotka varmistavat, että koodi on virheetön. Kun se tulee alas se on vain joitakin asioita et voi testata ja ratkaista, kun pala koodia on tuotannossa.

jos päätät käyttää koodipakasteita, et aio luopua automatisoidun laadunvarmistuksen ja ketterien parhaiden käytäntöjen eduista. Sinä ja tiimisi yksinkertaisesti kiinni koodin pienempi, enemmän triviaaleja ongelmia tuotannon aikana, clearing kannet keskittyä kiinni suurempia, suurempi vaikutus ongelmia aikana jäädyttää, kuten yleistä vakautta ja luotettavuutta uuden ohjelmiston tai ominaisuus.

argumentin 2 ongelma: ”vähennä”, ei ”poista”

Ketterä on suunniteltu lyhentämään aikaa kehityksen ja julkaisun välillä, sekin on tosiasia. Mutta on suuri ero yrittää pienentää tätä ikkunaa, ja yrittää poistaa se kokonaan. Se olisi lähes mahdotonta varsinkin isommissa hankkeissa.

koodin jäädytys voi olla hyvin lyhyt CICD: ssä— tai se voi koskea vain tiettyä haaraa kehityksen jatkuessa muilla haaroilla-mutta se on edelleen olemassa. Ei ole väliä kuinka hienostunut Ketterä tuli, lähes aina tulee olemaan piste kaikissa kehitys ja julkaisu roadmaps jossa uusi pala ohjelmisto tai ominaisuus arvioidaan kiinteässä tilassa ennen kuin se menee ulos reaalimaailman käyttäjille.

Argumentin Ongelma 3: Nopeuden ja laadun uudelleenarviointi

jos käytät koodin jäätymistä, lisäät uuden askeleen kehitys-ja julkaisusykliisi. Siitä ei ole epäilystäkään. Ja aina kun lisäät uuden vaiheen mihin tahansa prosessiin, hidastat prosessia ja luot uuden mahdollisen vikapisteen. Koodin jäätyminen ei ole poikkeus.

mutta on tärkeää ottaa askel taaksepäin ja tarkastella laajemmin hidastumista ja menetettyä tuottavuutta.

jos ominaisuudessasi on vikoja, sinun on korjattava ne riippumatta siitä, saitko ne kiinni koodin jäädyttämisen aikana tai ilmoittautuivatko ne julkaisun jälkeen. Puhtaan kehityksen näkökulmasta niiden korjaamiseen tarvittava aika on suunnilleen sama molemmissa skenaarioissa.

mutta jos käsittelet vikoja elävässä ympäristössä, sinulla on monia muita asioita, jotka sinun täytyy ottaa aikaa käsitellä, mukaan lukien:

• päättää, siirretäänkö buginen ominaisuus takaisin vai jätetäänkö se suorana.
• otat kehittäjäsi pois uusista projekteistaan, kun he ovat aloittaneet työnsä.
• oikeiden käyttäjien, joihin bugit vaikuttivat.
• vastaat ja hoidat sisäisiä sidosryhmiäsi, jotka eivät ole kovin tyytyväisiä ongelmalliseen julkaisuusi.

lista jatkuu. Ei ole mitään monimutkaisempaa, aikaa vievää ja tuhoisampaa tuottavuudelle-sinulle ja tiimillesi—kuin rikkinäisen ominaisuuden tai tuotteen vapauttaminen. Koodi jäätyy minimoida mahdollisuudet tämän tapahtuvan.

ja mitä tulee väitteeseen, jonka mukaan koodin jäädyttäminen johtaa huonompiin laatuominaisuuksiin ja tuotteisiin, koska ne vähentävät liiketoiminnan vaatimuksia, joita voit kerätä? Yrityksesi vaatimukset ovat aina vähän enemmän kuin” paras arvaus ” siitä, mitä tuotteen tai ominaisuuden pitäisi toimia kuin. Arvokkaimmat vaatimukset tulevat aina reaalimaailman käyttäjiltä, jotka käyttävät tuotettasi tai ominaisuuttasi reaalimaailman skenaarioissa. Ja voit kerätä nämä vaatimukset vain antamalla käyttäjille toiminnallisia julkaisuja, jotka he voivat ottaa käyttöön mahdollisimman sujuvasti ja virheettömästi.

kannattaako Koodipakasteita hyödyntää ketterässä tuotehallinnassa?

lopulta koodin jäätymisellä on edelleen tärkeä rooli monille ketterille tuotepäälliköille.

nyt on tapauksia, joissa niillä on vähemmän kriittinen rooli. Hyvin pienet projektit eivät välttämättä tarvitse erityisiä koodien jäädytysaikoja. Uudet ominaisuudet, joilla on suhteellisen pienet seuraukset, jos ne toimitetaan epätäydellisesti, eivät ehkä ole jäädyttämisen arvoisia. Sama pätee phased release suunnitelmat-kuten Canary Releases-kun haluat vain testata uusia ominaisuuksia lämmin yleisö, joka olet pohjustettu odottaa buginen, epätäydellinen kokemus.

mutta useimmissa tapauksissa kannattaa käyttää aikaa—jopa hyvin lyhyt aika—varmistaaksesi, että uudet ominaisuutesi ovat niin täydellisiä kuin luulet niiden olevan, ennen kuin annat ne kaikkein tärkeimpien ihmisten eli reaalimaailman käyttäjien käsiin.

tämä artikkeli on julkaistu alun perin flagship.io