Code bevriest: zijn ze nog steeds Relevant voor Agile productmanagers?

het lijkt een open en gesloten zaak.

codevriezen zijn een relikwie. Een overblijfsel uit de tijd dat rigide waterval methodologieën bood de enige optie voor productontwikkeling en release. Het hele concept van het stoppen van de productie en het uitstellen van de release—alleen maar om te testen op bugs en andere functionele problemen—heeft geen plaats in moderne, wendbare product management.

dat lijkt tenminste de consensus te zijn onder veel Agile goeroes.

maar houdt het stand? Zodra u krassen op het oppervlak van de meest voorkomende argumenten tegen het opnemen van code bevriest in Agile product management, zullen ze nog archaïsch lijken?

In dit stuk zullen we de drie belangrijkste argumenten onderzoeken tegen het opnemen van code freezes in uw Agile product management, en we zullen uitzoeken waar deze argumenten uiteenvallen, allemaal om u te helpen een betere beslissing te nemen over het al dan niet opnemen van code freezes in uw Agile product management.

Argument 1: Code Freezes zijn Irrelevant en onnodig

dit argument is vrij eenvoudig en concreet— moderne Agile methodologieën en tools hebben de noodzaak voor een speciale QA en testvenster geëlimineerd.

Agile methodologieën zoals peer code reviews, pair programming, en de constante monitoring van de gezondheid van het systeem geven u veel meer inzicht in de prestaties van een toepassing of functie terwijl het wordt ontwikkeld. Bugs en problemen zijn gemakkelijker, en waarschijnlijker, te worden gevangen tijdens de ontwikkeling zelf, en opgelost voorafgaand aan speciale testen en QA-activiteiten.

nieuwe instrumenten hebben ook vele tests geautomatiseerd. Ze evalueren voortdurend code om er zeker van te zijn dat het te allen tijde schoon en klaar is voor productie. Problemen worden in real-time geïdentificeerd, en waarschuwingen worden onmiddellijk verzonden om ze zo snel mogelijk op te lossen. Het aantal tests dat is geautomatiseerd is al breed en blijft groeien, drastisch verminderen van het volume van de handmatige tests die moeten worden uitgevoerd.

het resultaat van deze nieuwe Agile methodologieën en tools is gemakkelijk te zien. Het merendeel van de kern testen en QA activiteiten uitgevoerd tijdens een code bevriezen worden ofwel uitgevoerd tijdens de ontwikkeling, of uitgevoerd door software. In Agile, Software en functies nu verlaten ontwikkeling op een veel hoger niveau van vertrouwen dan ze gewend zijn, waardoor een speciale code bevriezen moeilijker en moeilijker te rechtvaardigen.

Argument 2: Code bevriest breek een Core Agile Principe

dit tweede argument is iets hoger. Kortom, het stelt dat code bevriest geen thuis in Agile methodologie omdat ze breken een van Agile methodologie ‘ s kernprincipes-het verminderen van de tijd tussen ontwikkeling en release.

hoe verfijnder uw benadering van Agile, hoe meer u zult proberen dit tijdvenster te verkleinen. De meest verfijnde huidige benaderingen van Agile zijn continue integratie en continue ontwikkeling (CICD), en ze zijn gericht op het breken van de ontwikkeling in kleine, incrementele veranderingen om zo snel mogelijk veranderingen in de code “vrij te geven”. In de zuiverste toepassing van CICD, ontwikkeling en release nauwelijks bestaan als verschillende fasen-nieuwe code wordt geïntegreerd in de applicatie bijna zodra het is voltooid.

daarentegen moet u verschillende ontwikkelings-en releasefasen behouden als u code bevriest gaat implementeren. Immers, dat is waar de code freeze leeft – tussen die twee verschillende fasen. In plaats van te proberen te minimaliseren of te elimineren dat venster van de tijd tussen de ontwikkeling en release, zoals de meeste van Agile methodologie, code bevriest dwingen u om dit venster te formaliseren tot het punt dat u nodig hebt om uw ontwikkeling en release schema ‘ s rond het op te bouwen.

als codevriezen niet overeenkomen met Agile Core principes, dan is het moeilijk om het geval te maken dat ze nog steeds thuishoren in de methodologie.

Argument 3: Code bevriest leidt tot langzamere, lagere kwaliteit Releases

dit laatste argument is een groot argument, en het bevat een paar verschillende hoeken.

om te beginnen, stelt het dat code-bevriezingen veel complexiteit en extra bewegende delen toevoegen aan uw roadmap, en natuurlijk verhogen de kans dat er iets mis gaat en uw tijdlijn te gooien. Zelfs als er niets mis gaat, is het werk dat betrokken is bij code freezes tijdrovend en onvoorspelbaar (omdat je niet weet welke bugs je zult vinden of hoe lang het zal duren om ze op te lossen), dat door simpelweg code freezes toe te voegen aan je roadmap je tragere ontwikkelings-en release cycli creëert.

Vervolgens stelt het dat het vastlopen van code de productiviteit van uw ontwikkelteam zal verminderen. Terwijl Agile in het algemeen, en CICD in het bijzonder, houden uw ontwikkelaars voortdurend werken in een ononderbroken keten van productiviteit, code bevriest dwingen uw ontwikkelaars om te stoppen met het werk op vooraf gedefinieerde intervallen. Door dit te doen, zult u hun ritme te breken en hen dwingen om te proberen om te werken rond uw code bevriezen beleid, in plaats van het vinden en onderhouden van welke stroom maakt ze het meest productieve.

ten slotte stelt het dat het creëren van speciale vensters waarin u geen zakelijke vereisten meer ontvangt, de functies en functionaliteiten van uw releases zal beperken tot wat vóór de bevriezing kan worden voltooid, wat zal leiden tot minder uitgebreide software en applicaties van lagere kwaliteit.

het pleidooi voor Code Freezes: een verloren strijd?

op dit moment ziet het er vrij somber uit voor iedereen die nog steeds code freezes wil opnemen in Agile methodologie. Tegenstanders van deze praktijk maken een aantal zeer overtuigende argumenten en een algemeen solide geval dat, sinds de ontwikkeling van de moderne Agile methodologie, code bevriezingen zijn geworden:

1. verouderd en irrelevant
2. verkeerd afgestemd op moderne ontwikkelingspraktijken
3. een belemmering voor snelle, hoogwaardige releases

maar hoewel deze argumenten overtuigend zijn en veel nauwkeurige informatie bevatten, zijn ze niet kogelvrij. En er zijn fundamentele gebreken in elk die moeten worden besproken voordat het sluiten van het boek over code bevriest als een nuttig element van Agile product management.

het probleem met Argument 1: geautomatiseerd testen Is niet uitgebreid

geautomatiseerde QA en Agile ontwikkelingspraktijken hebben de kwaliteit van de code tijdens de productie verhoogd, dat is een feit. Maar alleen omdat een stuk code is geslaagd voor unit testing, betekent dat niet dat het eigenlijk klaar is voor de productie. Zelfs de meest verfijnde CICD benaderingen bevatten niet altijd kritische stappen-zoals regressie testen-die ervoor zorgen dat een stuk code is defect-vrij. Als het erop aankomt zijn er gewoon een aantal dingen die je niet kunt testen en oplossen terwijl een stuk code in productie is.

als u ervoor kiest om code freezes te gebruiken, geeft u de voordelen van geautomatiseerde QA en Agile best practices niet op. U en uw team zullen eenvoudig de kleinere, meer triviale problemen van uw code tijdens de productie te vangen, het opruimen van de decks om zich te concentreren op het vangen van grotere, hogere impact problemen tijdens uw bevriezing, zoals de algehele stabiliteit en betrouwbaarheid van uw nieuwe software of functie.

het probleem met Argument 2: “verminderen”, niet “elimineren”

Agile is ontworpen om de tijd tussen ontwikkeling en release te verkorten, dat is ook een feit. Maar er is een groot verschil tussen proberen dit venster te verkleinen, en proberen het volledig te elimineren. Dat zou bijna onmogelijk zijn, vooral voor grotere projecten.

de code freeze kan erg kort zijn in CICD— of kan alleen van toepassing zijn op een specifieke branch terwijl de ontwikkeling op andere branches doorgaat—maar het bestaat nog steeds. Het maakt niet uit hoe verfijnd Agile werd, er is bijna altijd een punt in alle ontwikkeling en release roadmaps waar een nieuw stuk software of functie zal worden geëvalueerd in een vaste staat voordat het gaat uit naar real-world gebruikers.

Het Probleem Met Argument 3: Snelheid en kwaliteit

als u code freezes gebruikt, voegt u een nieuwe stap toe aan uw ontwikkelings-en releasecyclus. Daar is geen twijfel over mogelijk. En elke keer als je een nieuwe stap toevoegt aan een proces, vertraag je dat proces en creëer je een nieuw potentieel storingspunt. Code bevriest zijn geen uitzondering.

maar het is belangrijk een stap terug te doen en een breder beeld te krijgen van de vertraging en het verlies aan productiviteit.

als uw functie bugs bevat, moet u deze oplossen, ongeacht of u deze bugs hebt opgelopen tijdens het bevriezen van de code, of dat ze zich na de release bekend hebben gemaakt. Vanuit een puur ontwikkelingsperspectief zal de hoeveelheid tijd die nodig is om ze op te lossen in beide scenario ‘ s ongeveer hetzelfde zijn.

maar als je te maken hebt met bugs in een live omgeving, heb je een groot aantal andere problemen waar je de tijd voor moet nemen, waaronder:

• beslissen of om terug te rollen de buggy functie of laat het leven.
• uw ontwikkelaars van hun nieuwe projecten verwijderen, nadat ze met hun werk zijn begonnen.
• het goedmaken met uw echte gebruikers die werden beïnvloed door de bugs.
• beantwoorden en beheren van uw interne stakeholders die niet al te blij zijn met uw problematische release.

de lijst gaat verder. Er is niets ingewikkelder, tijdrovend en destructief voor de productiviteit—voor u en uw team—dan het vrijgeven van een kapotte functie of product. Code bevriest minimaliseert de kans dat dit gebeurt.

en met betrekking tot het argument dat het vastlopen van code leidt tot lagere kwaliteitskenmerken en producten omdat ze de hoeveelheid zakelijke vereisten verminderen die u kunt verzamelen? Uw zakelijke eisen zal altijd weinig meer dan een” beste gok ” over wat uw product of functie moet functioneren als. De meest waardevolle eisen zullen altijd komen van real-world gebruikers, het implementeren van uw product of functie in real-world scenario ‘ s. En u kunt deze vereisten alleen verzamelen door uw gebruikers functionele releases te geven die ze zo vloeiend en bug-vrij mogelijk kunnen implementeren.

mocht U Code Freezes gebruiken in uw Agile Product Management?

uiteindelijk spelen codevriezen nog steeds een belangrijke rol voor veel Agile productmanagers.

er zijn gevallen waarin zij een minder belangrijke rol spelen. Zeer kleine projecten kunnen niet speciale code bevriezen periodes nodig. Nieuwe functies die relatief kleine gevolgen hebben als ze niet perfect schip misschien niet de moeite waard de bevriezing. Hetzelfde geldt voor gefaseerde release plannen – zoals Canary Releases-als je gewoon nieuwe functies wilt testen met een warm publiek dat je hebt voorbereid om een buggy, onvolmaakte ervaring te verwachten.

maar in de meeste gevallen is het de moeite waard om de tijd te nemen—zelfs een zeer korte periode—om ervoor te zorgen dat uw nieuwe functies zo perfect zijn als u denkt dat ze zijn voordat u ze in handen geeft aan de mensen die er het meest toe doen: uw echte gebruikers.

dit artikel werd oorspronkelijk gepubliceerd op flagship.io