W czasach, kiedy zwinność nie była modna, a o przyrostowym i iteracyjnym tworzeniu oprogramowania słyszeli nieliczni, cały zespół wytwórczy żył udostępnieniem produkcyjnym oprogramowania. Weekendy „go live” były równie ekscytujące, co rozwiązywanie pierwszych błędów krytycznych pojawiających się zaraz po nich. Czy dziś, w dobie potencjalnie wdrażalnego Inkrementu jest tak samo? Co się dzieje z przyrostem po zakończonym z sukcesem Sprincie?
„Go live” made by Scrum Guide
Scrum jest metodyką skupiającą się na wytworzeniu produktu. Nie ma znaczenia, czy mówimy o oprogramowaniu czy rzeczach fizycznych. Te „wytworzenie” rozpoczyna się w momencie, kiedy wymaganie zapisywane jest do Backlogu Produktu, gdzie przechodzi ścieżkę doskonalenia polegającą na dodawaniu opisu, oszacowań, priorytetu i wartości. Ten proces to oczywiście Product Backlog Refinement. Samo wytwarzanie zaś kończy się z chwilą, kiedy zespół powie „Done”. Oznacza to, że produkt nad którym pracował jest gotowy i przygotowany do potencjalnego wdrożenia.
Co się dzieje dalej? Wchodzimy tu w obszar ciemności, o którym Scrum Guide nie wspomina. Nie znajdziemy w nim ani jednego słowa w jaki sposób podejść do udostępnienia Przyrostu klientowi końcowemu. Mówi tylko (niektórzy powiedzą „aż”), że udostępnienie to ma miejsce po decyzji Product Ownera. On decyduje o „go live”. A mówiąc bardziej szczegółowo, PO wdraża produkt wtedy, kiedy ma to sens.
Nic więcej ze Scrum Guide się nie dowiemy.
Go live w AgilePM
Od dobrych kilkunastu miesięcy rozwijamy naszą wiedzę w zakresie innych zwinnych metodyk. Jedną z nich jest popularny dziś AgilePM (czyli DSDM). W jaki sposób podchodzi on do udostępnienia Inkrementu? Otóż po zakończeniu iteracji Przyrost poddawany jest trójstopniowemu procesowi obsługi, który ma za cel jego wdrożenie. Na proces ten składają się następujące etapy: składaj, przeglądaj, wdrażaj.
Wdrożenie w rozumieniu AgilePM to wszystkie czynności, zmierzające „do przejścia rozwiązania (lub części rozwiązania) do rzeczywistego działania operacyjnego.”
Na działania te składać się mogą w szczególności takie rzeczy, jak rezerwacja sal w celu szkoleń użytkowników końcowych czy zapewnienie dostępu do serwerowni w czasie wdrożenia. Będą to więc te wszystkie czynności, które okażą się niezbędne, aby przejść przez proces oddawania produktu klientowi końcowemu.
Na pierwszy rzut oka widać, że podejście do przyrostu jest diametralnie różne, niż w przypadku Scruma. Ale sam AgilePM (DSDM) obejmuje swoją definicją o wiele więcej elementów związanych z zarządzaniem projektem. I tak ma być, w końcu DSDM to metodyka zarządzania projektem, a Scrum – wytwarzania produktu.
Dedykowany zespół
W jaki sposób wdrażamy Przyrost w Scrum? Najczęściej dokonuje tego dedykowany zespół – przecież wg założeń, odpowiedzialność Zespołu Deweloperskiego kończy się w momencie zakończenia Sprintu. W kolejnym zajmują się tworzeniem następnego Przyrostu. Wdrożenie odbywa się zatem poza Development Teamem, co może (choć nie musi) powodować pewne konsekwencje.
W tekście dotyczącym DevOps wspominałem o skin-in-the-game osób przygotowujących rozwiązanie. Jeśli nie będą one w żaden sposób odpowiedzialne za wdrożenie, nie poczują pozytywnych ani negatywnych konsekwencji wykonania tegoż wdrożenia. Jest ono dla nich transparentne, a jego przygotowanie i jakość znajdują się poza sferą ich zainteresowania. Czy tak powinno być?
Proces udostępnienia Inkrementu zależał będzie od wielkości czy stopnia jej sformalizowania. W jednych organizacjach będzie to proste „Udostępniamy!” wypowiedziane przez PO, w innych będzie to proces poprzedzony testami SIT czy UAT, a czasem nawet formalną decyzją Komitetu Sterującego.
Co dalej z przyrostem?
Pominięcie wdrożenia produktu na środowisko produkcyjne jest jednym z elementów, których w Scrumie brakuje. Wydaje się, że jasne opisanie procedury udostępnienia Przyrostu (vide AgilePM) nie spowodowałoby nadmiernego skomplikowania metodyki, a uzupełniłoby ją znacząco w kontekście całościowego spojrzenia na wytwarzanie produktu.
Scrum nie koncentruje się na aspektach życia produktu po jego wytworzeniu. Ewentualne błędy produkcyjne związane z utrzymaniem systemu na produkcji powinny zostać dodane jako Product Backlog Item, a następnie spriorytetyzowane przez PO i zaplanowane do realizacji. Skupienie się na wytworzeniu produktu, a nie na całościowej jego obsłudze powoduje, że muszę czasem przyznać rację mojemu bardzo serdecznemu Przyjacielowi, który zwykł mówić:
„Scrumem w kosmos nie polecisz.”
Traktując ten cytat literalnie, Scrum wykorzystam do zbudowania rakiety. Jednak o fizycznym zapłonie silników i starcie w kierunku przestworzy mogę zapomnieć. Muszę użyć do tego zupełnie innej metodyki lub obudować scrumowe „wytwarzanie”, „wdrażaniem”.
