Jeśli chodzi o dostarczanie scrum, ludzie zwykle oczekują wykonania wydania po zakończeniu sprintu. Oznacza to bezpośrednio po udanej prezentacji demonstracyjnej dla klienta.
Ale zawsze zastanawiałem się, jak to może być takie automatyczne oczekiwanie. Zwłaszcza jeśli weźmiesz pod uwagę poniższe możliwe działania, które muszą nastąpić przed lub obok.
- Opracuj i uzupełnij wszystkie historie w ramach sprintu. Niektóre mogą zostać ukończone wcześniej, ale w większości przypadków historie są ukończone tuż przed końcem sprintu. Może nawet po prezentacji demo, żeby być tutaj otwartym.
- Wykonaj wszystkie zaplanowane testy zawartości sprintu, aby upewnić się, że kod, który ma zostać wydany, jest gotowy do produkcji.
- Nadrabiaj wykryte błędy i napraw je na czas, zanim nastąpi wydanie.
- Upewnij się, że potok wdrażania jest aktualizowany przy użyciu najnowszej zawartości, a sam potok jest niezawodny do wykonania.
- Uruchom potok we wszystkich odpowiednich środowiskach, aby wprowadzić je do najnowszego stanu zarówno z perspektywy kodu, jak i danych.
- Przygotuj informacje o wydaniu i poinformuj klienta o wpływie wydania i o tym, co dokładnie zmieni się później.
- W razie potrzeby zsynchronizuj się z innymi równoległymi zespołami scrumowymi, aby upewnić się, że zależna treść zostanie wydana jednocześnie. Niczego nie powinno brakować, aby zawartość wydania działała zgodnie z oczekiwaniami.
- Oprócz tego przejdź przez wszystkie ceremonie scrumowe. Nie tylko związane z bieżącym sprintem, ale także te, które są ukierunkowane na następny sprint (np. sesje udoskonalania historii).
Teraz wyobraź sobie, że sprint trwa dwa tygodnie.
Same działania związane ze zwalnianiem wymagają czasu i ludzi. Ale to nie może zająć zbyt wiele. Tuż po ostatnim dniu sprintu przychodzi bezpośrednio pierwszy dzień kolejnego sprintu i krąg zaczyna się od nowa.
Czy oczekiwanie na uwolnienie po każdym sprincie nadal wygląda tak automatycznie?
Spis treści:
Zwolnij przetwarzanie treści
Jeśli wszystkie procesy w ramach sprintu są zautomatyzowane, istnieje możliwość „pociągnięcia za spust” i zainstalowania najnowszej wersji kodu na produkcji pod koniec każdego sprintu. Problem w tym, że nigdy nie doświadczyłem tak idealnego stanu zespołu scrumowego.
Jeśli tak jest w przypadku niektórych małych prywatnych firm, naprawdę im zazdroszczę. Ale rzeczywistość w świecie korporacji jest taka, że zespół scrumowy nie osiągnie takiego poziomu dojrzałości. Wręcz przeciwnie, procesy wydania są zwykle związane z czasochłonnymi czynnościami, które obejmują większość kolejnego sprintu, wpływając na ten sprint z perspektywy treści i wszystkich metryk. Uwolnienie jest po prostu stresującym aktem, przez który nikt w zespole nie jest zadowolony.
Byłem więc po odkryciu kolejnego najlepszego scenariusza radzenia sobie z wydaniami.
Wniosek był taki, aby każdy drugi sprint był sprintem uwalniającym. Oto, co to oznacza.
Oddzielna wersja kodu dla następnej wersji
Chodzi o obsługę oddzielnych gałęzi w repozytorium GIT. Istnieje wiele sposobów podejścia do tego samego problemu i wszystkie z nich mogą zakończyć się sukcesem. Ale na potrzeby tego artykułu zamierzam uprościć sprawę, aby zademonstrować podejście i jego wpływ.
Aby w jak najmniejszym stopniu wpłynąć na trwające prace rozwojowe, ważne jest, aby zawartość kolejnego wydania wydzielić do oddzielnej gałęzi. Nazwijmy to Oddziałem Zwolnienia. Dzięki temu zostaną rozwiązane następujące kwestie:
- Zespół programistów może kontynuować działania i łączyć się z nowymi historiami głównej gałęzi bez zakłóceń.
- Nie ma ryzyka, że na treść wydania będą miały wpływ nieoczekiwane modyfikacje kodu ze strony zespołu scrumowego.
- Czynności testowe mogą być wykonywane w odizolowanej przestrzeni. Tutaj zostaną wprowadzone tylko zmiany niezbędne do rozwiązania testu.
- Ponieważ potok wydawniczy wdroży do produkcji tylko zawartość z gałęzi wydania, mamy przejrzysty proces i pełną kontrolę nad treścią, która ma zostać wydana. Nie może się zdarzyć, że jakieś nieoczekiwane zatwierdzenie w gałęzi Git złamie już przetestowany kod.
Więc po prostu odłóż na bok zawartość następnej wersji i pozwól jej dojść do stabilnego stanu, gotowego do wydania.
Czas wydań tak, aby działały wielokrotnie
Zrezygnowałem z ambicji wypuszczania po każdym sprincie. Było jasne, że to nie ma szans zadziałać. Przynajmniej nie z takimi skutkami ubocznymi jak:
- wpływ na treść rozwoju następnego sprintu,
- brak możliwości ustabilizowania treści wydania,
- nadrobienie wszystkich wymaganych czynności testowych itp.
Tak więc celem było wykonanie wydania do końca co drugiego sprintu. Oznaczałoby to, co następuje:
- Wydanie zawsze będzie zawierało historie z ostatnich dwóch zakończonych już sprintów. Ponieważ wydanie jest wykonywane w bieżącym (aktywnym sprincie), ta treść sprintu nie jest jeszcze uwzględniona w wydaniu.
- Na ukończenie niezbędnych czynności testowych i poprawek błędów jest cały czas jednego sprintu.
- Właściciel wydania ma wystarczająco dużo czasu, aby zebrać informacje istotne dla wydania (przypadki testowe, uwagi do wydania itp.) podczas sprintu bez wydania. W ten sposób mogą działać w zasadzie samodzielnie, a reszta zespołu programistów pracuje nad nowymi historiami.
- W przypadku wykrycia błędu właściciel wydania może szybko połączyć się z konkretnym deweloperem, aby naprawić problem i powrócić do bieżącej zawartości sprintu. Dlatego zawsze powinien być przydzielony pewien procent czasu ze zdolności zespołu na wsparcie tego naprawiania błędów. Ile dokładnie można odkryć w czasie.
Oczywiste jest, że użytkownicy nie otrzymają najnowszej zawartości sprintu w najnowszej wersji. Ale z czasem to przestanie mieć znaczenie. I tak otrzymają dwa sprinty zawartości z każdym kolejnym wydaniem, po każdym drugim sprincie.
Wygląda to na dobry kompromis między satysfakcją z szybkiej dostawy a nadążaniem za działaniami scrumowymi bez znacznych zakłóceń.
Wykonaj wdrożenie wydania
Po pomyślnym zakończeniu testowania, naprawiania błędów i gotowości potoku, wykonanie potoku produkcyjnego i zakończenie wydania do produkcji jest dość prostym procesem.
Ponieważ jest wdrażany z samodzielnej gałęzi, może to być w zasadzie niezauważalna i niewidoczna czynność. Nikt nie musi wiedzieć. W takim przypadku jest to najlepsza możliwa implementacja wdrożenia wydania.
Warunkiem wstępnym jest stworzenie solidnego zautomatyzowanego potoku DevOps. Służy nie tylko do wdrażania w środowisku produkcyjnym, ale także we wszystkich innych środowiskach niższego poziomu. Może to obejmować programowanie, piaskownicę, testy, zapewnianie jakości, środowisko wydajności itp. To powinno być jednym kliknięciem, aby wdrożyć wszystkie rozwiązania dla każdego pojedynczego środowiska.
Uwolnienie nie powinno być punktem bólu ani stresem. Lub koszmar, którego wszyscy się boją i który przygotowuje się na ten dzień przez tydzień. Nie – zamiast tego, jeśli nikt tego w ogóle nie zauważy, jest to najlepsza oznaka udanego wydania.
Połącz ponownie gałąź wydania z gałęzią rozwoju
Gałąź wydania zawiera teraz specjalną zawartość, której nie ma w zwykłej gałęzi ciągłego rozwoju. Jest to związane ze wszystkimi poprawkami, które zostały wdrożone w okresie testowym. Ta zawartość musi zostać ponownie włączona do gałęzi programistycznej, aby zapewnić, że poprawki pozostaną tam nawet po następnej wersji.
W tym momencie najnowsza gałąź wydania służy jako awaryjny kod produkcyjny gotowy do ponownego wdrożenia. Jeśli pilny problem o wysokim priorytecie musi zostać rozwiązany wkrótce po wdrożeniu produkcyjnym, może skorzystać z tej gałęzi. Łatwo jest wziąć ten kod i zaimplementować poprawkę w środku. Nadal jest to dokładna kopia obecnego kodu produkcyjnego bez żadnych nowych, niewydanych treści.
Wreszcie, po rozpoczęciu nowego okresu testowania, poprzednia gałąź wydania może zostać usunięta i zastąpiona nową. Nowa jest ponownie tworzona jako kopia z bieżącej gałęzi rozwojowej.
Ustanowienie regularnych wydań
I teraz to mamy 😀 — solidny proces zbliżania się do premiery. Brakuje tylko zobowiązania do regularności. W tym przypadku po każdym drugim sprincie.
Utrzymując go regularnie, w rzeczywistości tworzymy grunt, aby ułatwić jego osiągnięcie, głównie dlatego, że:
- Jeśli wydanie nastąpi po niezbyt długim czasie, nie ma zbyt wielu nowych treści do zainstalowania w środowisku produkcyjnym. Przyrost jest niewielki i uważany za stabilny.
- Teraz tak dużo nowej zawartości oznacza niezbyt dużo czynności związanych z testowaniem i tworzeniem przypadków testowych. Mniej komunikacji, wezwań do uzgodnienia i współpracy z interesariuszami na temat tego, co wszystko wymaga ponownej walidacji. Zgodzą się również, że od ostatniego wydania nie minęło tak wiele czasu. Dlatego temu działaniu przywiązuje się mniejszą wagę.
- Zespół przyzwyczai się do tego cyklu; z czasem stanie się naturalną częścią zespołu.
- Efektem ubocznym jest często odświeżanie danych w środowiskach programistycznych i testowych. Jest to i tak potrzebne dla każdego nowego cyklu testowania. Więc nie będzie to tylko kolejna zaplanowana czynność do wykonania. Raczej działanie, które jest już częścią ustalonego procesu. Ta zmiana perspektywy ma ogromny wpływ na atmosferę w zespole. Nikt by w to nie uwierzył.
Wniosek
Ten rozdział kończy moje poprzednie posty na temat cyklu życia scruma. Chodzi także o to, co sprawdziło się w prawdziwym życiu.
Często zespoły zaczynają działać w sposób zwinny i robią wiele rzeczy źle. Potem w końcu ewoluują i zaczynają robić rzeczy inaczej. Ta seria może pomóc niektórym z nich szybciej dokonać tej zmiany.
Ani to podejście do wydania nie jest jedynym wykonalnym, ani nie jest pozbawione problemów. Te nadal będą istnieć, a zespoły muszą sobie z nimi radzić. Następnie popraw to, co jest możliwe i zapomnij o tym, co nie ma sensu.
Ale z tego, co wiem, to podejście, choć proste, udowodniło, że zmiana jest możliwa. Od chaotycznych, nieprzewidywalnych sprintów po bardziej stabilne dostarczanie z regularnymi wydaniami, na których można polegać i planować. I nie wymaga specjalnej, bardzo skomplikowanej metodologii – wystarczą proste zasady i chęć podążania za planem.