Zamrożenie kodu: czy są one nadal istotne dla Agile product Managerów?

wydaje się, że sprawa jest otwarta i zamknięta.

zamrożenie kodu to relikt. Pozostałość po czasach, kiedy sztywne metody wodospadu oferowały jedyną opcję rozwoju i wydania produktu. Cała koncepcja zatrzymania produkcji i opóźnienia Wydania-tylko po to, aby sprawdzić błędy i inne problemy funkcjonalne—nie ma miejsca w nowoczesnym, zwinnym zarządzaniu produktem.

przynajmniej wydaje się to być pogląd konsensusu wśród wielu zwinnych Guru.

ale czy wytrzyma? Czy po zarysowaniu najczęstszych argumentów przeciwko włączeniu kodu do zwinnego zarządzania produktem, nadal będą one wydawać się archaiczne?

w tym artykule omówimy trzy główne argumenty przeciwko włączeniu zamrożenia kodu do zwinnego zarządzania produktem i omówimy, gdzie te argumenty się rozpadają, wszystko po to, aby pomóc ci podjąć lepszą decyzję o tym, czy należy włączyć zamrożenie kodu do zwinnego zarządzania produktem.

Argument 1: Zamrożenie kodu jest nieistotne i niepotrzebne

ten argument jest dość prosty i konkretny— nowoczesne zwinne metodologie i narzędzia wyeliminowały potrzebę dedykowanego okna QA i testowania.

zwinne metodyki, takie jak recenzje kodu partnerskiego, programowanie w parach i ciągłe monitorowanie stanu systemu, zapewniają znacznie lepszy wgląd w wydajność aplikacji lub funkcji podczas jej opracowywania. Błędy i problemy są łatwiejsze i bardziej prawdopodobne, że zostaną wykryte podczas samego rozwoju i rozwiązane przed wszelkimi dedykowanymi działaniami testowymi i QA.

nowe narzędzia również zautomatyzowały wiele testów. Stale oceniają kod, aby upewnić się, że jest czysty i gotowy do produkcji przez cały czas. Problemy są identyfikowane w czasie rzeczywistym, a alerty są natychmiast wysyłane, aby je rozwiązać JAK NAJSZYBCIEJ. Liczba zautomatyzowanych testów jest już szeroka i stale rośnie, co znacznie zmniejsza liczbę testów ręcznych, które należy wykonać.

rezultat tych nowych metodologii i narzędzi zwinnych jest łatwy do zauważenia. Większość podstawowych czynności testowania i kontroli jakości wykonywanych podczas zamrożenia kodu jest wykonywana podczas programowania lub przez oprogramowanie. W Agile, oprogramowanie i funkcje Obecnie opuszczają rozwój na znacznie wyższym poziomie zaufania niż kiedyś, co sprawia, że dedykowany kod zamarza coraz trudniej uzasadnić.

Argument 2: Code Freezes złamać podstawową zasadę zwinności

ten drugi argument jest nieco wyższy. Zasadniczo twierdzi, że zamrożenie kodu nie ma miejsca w metodologii zwinnej, ponieważ łamie jedną z podstawowych zasad metodyki zwinnej— skracając czas między rozwojem a wydaniem.

im bardziej dopracowane jest twoje podejście do Agile, tym bardziej będziesz starał się zmniejszyć to okno czasu. Najbardziej wyrafinowanymi obecnie podejściami do Agile są Continuous Integration and Continuous Development (CICD), które mają na celu rozbicie rozwoju na małe, przyrostowe zmiany w celu „uwolnienia” zmian w kodzie tak szybko, jak to możliwe. W najczystszej aplikacji CICD, rozwój i wydanie ledwo istnieją jako odrębne fazy-nowy kod jest zintegrowany z aplikacją niemal natychmiast po jej zakończeniu.

natomiast, jeśli zamierzasz wdrożyć zamrożenie kodu, musisz zachować odrębne fazy rozwoju i Wydania. W końcu to właśnie tam żyje code freeze-pomiędzy tymi dwoma odrębnymi fazami. Zamiast próbować zminimalizować lub wyeliminować to okno czasu między rozwojem a wydaniem, jak większość metodologii Agile, zamrożenie kodu zmusza cię do sformalizowania tego okna do tego stopnia, że musisz zbudować wokół niego harmonogramy rozwoju i Wydania.

jeśli zamrożenie kodu nie jest zgodne z podstawowymi zasadami Agile, trudno jest udowodnić, że nadal należą do metodologii.

Argument 3: zamrożenie kodu prowadzi do wolniejszych, gorszej jakości wydań

ten ostatni argument jest duży i zawiera kilka różnych kątów.

na początek argumentuje, że zamrożenie kodu dodaje wiele złożoności i dodatkowych ruchomych części do mapy drogowej i naturalnie zwiększa szanse, że coś pójdzie nie tak i odrzuci Twoją oś czasu. Nawet jeśli nic nie pójdzie źle, praca związana z zamrożeniem kodu jest czasochłonna i nieprzewidywalna (ponieważ nie wiesz, jakie błędy znajdziesz i ile czasu zajmie ich naprawienie), że po prostu dodając zamrożenie kodu do mapy drogowej stworzysz wolniejsze cykle rozwoju i Wydania.

następnie argumentuje, że zamrożenie kodu zmniejszy produktywność Twojego zespołu programistów. Podczas gdy zwinność w ogóle, a w szczególności CICD, sprawiają, że programiści stale pracują w nieprzerwanym łańcuchu produktywności, zamrożenie kodu zmusza programistów do zatrzymania pracy w zdefiniowanych odstępach czasu. W ten sposób złamiesz ich rytm i zmusisz do obejścia zasad zamrożenia kodu, zamiast znajdowania i utrzymywania tego, co sprawia, że są najbardziej produktywni.

wreszcie twierdzi, że tworzenie dedykowanych okien, w których przestajesz otrzymywać wymagania biznesowe, ograniczy funkcje i funkcjonalności Twoich wydań do tego, co można ukończyć przed zamrożeniem, co doprowadzi do niższej jakości, mniej kompleksowego oprogramowania i aplikacji.

Robienie podstaw do zamrożenia kodu: przegrana bitwa?

w tym momencie wygląda to dość ponuro dla każdego, kto nadal chce włączyć kod do metodyki Agile. Krytycy tej praktyki wysuwają bardzo przekonujące argumenty i ogólnie solidny argument, że od czasu rozwoju nowoczesnej metodologii Agile, zamrożenie kodu stało się:

1. przestarzałe i nieistotne
2. niedopasowane do nowoczesnych praktyk programistycznych
3. bariera dla szybkich, wysokiej jakości wydań

ale chociaż te argumenty są przekonujące i zawierają wiele dokładnych informacji, nie są kuloodporne. W każdym z nich są fundamentalne wady, które należy omówić przed zamknięciem książki na temat zamrożenia kodu jako użytecznego elementu zwinnego zarządzania produktem.

Problem z argumentem 1: automatyczne testowanie nie jest wyczerpujące

zautomatyzowane QA i zwinne praktyki programistyczne zwiększyły jakość kodu w miarę jego tworzenia, to fakt. Ale tylko dlatego, że kawałek kodu przeszedł testy jednostkowe, nie oznacza to, że jest gotowy do produkcji. Nawet najbardziej wyrafinowane metody CICD nie zawsze obejmują krytyczne kroki – takie jak testowanie regresji—które zapewniają, że kawałek kodu jest wolny od wad. Jeśli chodzi o to, są tylko pewne rzeczy, których nie można przetestować i rozwiązać, gdy kawałek kodu jest w produkcji.

jeśli zdecydujesz się wykorzystać zamrożenie kodu, nie zrezygnujesz z zalet zautomatyzowanej kontroli jakości i najlepszych praktyk zwinnych. Ty i twój zespół po prostu złapiecie mniejsze, bardziej trywialne problemy swojego kodu podczas produkcji, oczyszczając talie, aby skupić się na złapaniu większych, bardziej wpływowych problemów podczas zamrażania, takich jak ogólna stabilność i niezawodność nowego oprogramowania lub funkcji.

Problem z argumentem 2: „Zmniejsz”, a nie „wyeliminuj”

Agile ma na celu skrócenie czasu między rozwojem a wydaniem, to również fakt. Ale jest duża różnica między próbą zmniejszenia tego okna, a próbą całkowitego wyeliminowania go. Byłoby to prawie niemożliwe, zwłaszcza w przypadku większych projektów.

zamrożenie kodu może być bardzo krótkie w CICD— lub może dotyczyć tylko określonej gałęzi, podczas gdy rozwój trwa w innych gałęziach—ale nadal istnieje. Bez względu na to, jak wyrafinowany stał się zwinny, prawie zawsze będzie punkt we wszystkich mapach rozwoju i wydawania, w którym nowe oprogramowanie lub funkcja będą oceniane w stałym stanie, zanim trafią do rzeczywistych użytkowników.

Problem Z Argumentem 3: Zmiana szybkości i jakości

jeśli wykorzystasz zamrożenie kodu, dodasz nowy krok do swojego cyklu rozwoju i Wydania. Nie ma co do tego wątpliwości. Za każdym razem, gdy dodajesz nowy krok do dowolnego procesu, spowalniasz ten proces i tworzysz nowy potencjalny punkt awarii. Zamrożenie kodu nie jest wyjątkiem.

ale ważne jest, aby zrobić krok wstecz i spojrzeć szerzej na spowolnienie i utratę wydajności.

jeśli twoja funkcja ma błędy, musisz je naprawić, niezależnie od tego, czy złapałeś je podczas zamrażania kodu, czy też zgłosiły się po wydaniu. Z czystej perspektywy rozwoju, ilość czasu potrzebnego na ich naprawę będzie mniej więcej taka sama w obu scenariuszach.

ale jeśli masz do czynienia z błędami w środowisku rzeczywistym, masz wiele innych problemów, z którymi musisz się uporać, w tym:

• decydowanie, czy wycofać funkcję buggy, czy pozostawić ją aktywną.
• pozbawienie deweloperów nowych projektów po rozpoczęciu pracy.
• wynagradzanie użytkowników z prawdziwego świata, którzy zostali dotknięci przez błędy.
• odpowiadanie i zarządzanie wewnętrznymi interesariuszami, którzy nie są zbyt zadowoleni z twojego problematycznego wydania.

Nie ma nic bardziej skomplikowanego, czasochłonnego i niszczącego produktywność-dla Ciebie i Twojego zespołu—niż wypuszczenie zepsutej funkcji lub produktu. Zamrożenie kodu minimalizuje szanse na to.

a co do argumentu, że zamrożenie kodu prowadzi do niższej jakości funkcji i produktów, ponieważ zmniejszają ilość wymagań biznesowych, które można zebrać? Twoje wymagania biznesowe zawsze będą czymś więcej niż” najlepszym zgadywaniem”, jak powinien funkcjonować twój produkt lub funkcja. Najcenniejsze wymagania będą zawsze pochodzić od rzeczywistych użytkowników, którzy wdrażają produkt lub funkcję w rzeczywistych scenariuszach. Wymagania te można zbierać tylko poprzez udostępnienie użytkownikom wersji funkcjonalnych, które mogą wdrożyć w sposób możliwie płynny i wolny od błędów.

czy należy wykorzystać zamrożenie kodu w zwinnym zarządzaniu produktem?

ostatecznie zamrożenie kodu nadal odgrywa ważną rolę dla wielu zwinnych menedżerów produktu.

teraz są przypadki, w których odgrywają mniej krytyczną rolę. Bardzo małe projekty mogą nie wymagać dedykowanych okresów zamrożenia kodu. Nowe funkcje, które mają stosunkowo niewielkie konsekwencje, jeśli są dostarczane niedoskonale, mogą nie być warte zamrożenia. To samo dotyczy stopniowych planów wydawniczych—takich jak Canary Releases-kiedy chcesz po prostu przetestować nowe funkcje z ciepłą publicznością, której przygotowałeś, aby oczekiwać wadliwego, niedoskonałego doświadczenia.

ale w większości przypadków warto poświęcić trochę czasu—nawet bardzo krótki okres czasu—aby upewnić się, że nowe funkcje są tak doskonałe, jak myślisz, zanim oddasz je w ręce ludzi, którzy mają największe znaczenie: użytkowników z prawdziwego świata.

flagship.io