W tym poście zamieszczę listę 15 najważniejszych aspektów technicznych, które Scrum Master musi znać, pracując z zespołem w IT. Oczywiście lista będzie pomocna również dla innych osób, takich jak: Product Owner, Project Manager, czy osoby współpracujące z zespołami IT. Każdy z tych punktów, skrótowo omówię.
Spoiler alert 1: Wpis zdecydowałam się podzielić na 3 części ze względu na jego długość. Każdy odcinek zawiera po 5 punktów z listy. Pozostałe punkty znajdziecie w kolejnych wpisach.
Spoiler alert 2: Planuję wykorzystać każdy z tych punktów jako inspirację do nowych postów. Będę sukcesywnie je szczegółowo opisywać. Zachęcam Cię do regularnych wizyt na moim blogu :).
1. Kompleksowe rozumienie co to cykl wytwarzania oprogramowania (SDLC = Software Development Life Cycle)
Może to oczywistość, ale pracując z zespołem nad aplikacją, nie wyobrażam sobie, nie rozumieć, jak wygląda cały proces jej tworzenia. To by wyglądało tak jakbyśmy, pracując w restauracji nie wiedzieli, jak wygląda proces przygotowania posiłku. Wyobraź sobie, że pracujesz jako kelner(ka) podając zamówione dania i nie interesuje Cię co się dzieje w kuchni, jak są przygotowywane dania, jakie są alergeny. Dziwne, nie?
Trzeba kompleksowo rozumieć jak wytwarza się software. Począwszy od zbierania wymagań, poprzez analizę, budowę, testy i wdrożenie. Wiedza jak ten proces wygląda w podejściu kaskadowym i zwinnym jest niezbędna w branży IT. Oczywiście można mieć ogląd sytuacyjny, ale im lepiej rozumiemy fazy i ich zależności, konsekwencje, problemy, tym bardziej efektywni będziemy w naszej pracy.
2. Języki programowania i frameworki
Każda firma ma swój stack technologiczny. W skrócie jest to zbiór technologii i narzędzi, w które firma inwestuje. Podstawą są języki programowania i frameworki, których programiści używają do różnych celów. Firmy uważnie decydują się na konkretny język. Patrzą na specyfikę budowanego rozwiązania, dostępność programistów od danego języka, na to jaki jest próg wejścia w daną technologię i wiele innych.
Trzeba rozumieć, choćby na poziomie podstawowym, jak ma się napisany w latach 70. program "Hello World!", który wprowadził jako pierwszy pojęcie syntaxu i był inspiracją dla tworzenia kolejnych języków programowania. Na jego podstawie powstało wiele języków programowania wyższego i niższego rzędu. Na pewno zapunktuje Ci w przyszłości, jeśli zrozumiesz, po co:
tworzone są kolejne języki programowania,
wychodzą ich nowsze wersje i jakie to ma znaczenie dla Waszej aplikacji,
są używane kompilatory,
warto być programistą COBOL'a [żarcik branżowy].
Dobrze jest rozumieć różnicę pomiędzy językiem programowania a frameworkiem.
3. Jak buduje się aplikacje, czyli o warstwach cebuli
Aplikacje mają zazwyczaj 3 warstwy:
interface użytkownika, który potocznie nazywany frontendem,
logikę biznesową, znaną jako backend bądź API,
bazę danych.
Każda z nich ma swoją rolę i muszą one się ze sobą komunikować, by dostarczyć wartość użytkownikowi [funkcjonalność odpowiadającą na potrzebę użytkownika]. Niektóre aplikacje mogą nie posiadać którejś z warstw np.:
frontendu jest popularny w aplikacjach lub serwisach, gdzie nie potrzeba żadnego interface'u dla użytkowników,
bazy danych - jeśli nie potrzebujemy przechowywać danych lub potrzebujemy jedynie tymczasowe rozwiązania typu serverless.
Nie przychodzi mi do głowy aplikacja bez backendu.
Należy się zagłębić w to jak się te warstwy komunikują: skrypty, end pointy, szyny danych [eng. data bus], protokoły, itp. Im bardziej skomplikowana aplikacja i architektura rozwiązań firmy, tym więcej warstw.
4. Do czego służą różne środowiska
Środowisko jest rozumiane jako przestrzeń robocza do pracy dla programistów i innych specjalistów, która jest niezbędna do dostarczania oprogramowania. Termin ekosystem jest jak najbardziej zasadny. W SDLC zazwyczaj wykorzystujemy 3-4 środowiska dla 1 aplikacji.
lokalne — znajduje się na komputerze deva, tam pierwotnie pisze rozwiązanie,
deweloperskie — tutaj trafia do pozostałego "ekosystemu" aplikacji. Czyli mamy tutaj robocze rozwiązania, nad którymi pracuje zespół. Ma ono bardzo ograniczoną w rekordach bazę danych,
testowe/staging — miejsce, gdzie odbywają się testy manualne i sprawdzanie, czy nie ma problemów i konfliktów aplikacji. Weryfikuje się, czy wszystkie wymagania zostały spełnione. To środowisko powinno być bardzo zbliżone do produkcji — w celu wyłapywania jak największej ilości błędów przed wdrożeniem na produkcję,
produkcje — wersja aplikacji na produkcji udostępniana użytkownikom. To z niej korzystasz na co dzień :D.
5. Zaniedbania jakości kodu i ich konsekwencje
Wraz ze wzrostem aplikacji, wzrasta też dług techniczny aplikacji. Nowe funkcjonalności, narzędzia, integracje, linijki kodu, testy automatyczne, nowe biblioteki powodują, iż dostarczanie nowych elementów bywa coraz bardziej trudniejsze i bardziej pracochłonne. I niejednokrotnie efektem widocznym jest zwiększona ilość wyłapywanych błędów.
Każda aplikacja ma swoje wymagania odnośnie jakości kodu, jaki dostarczają devi. Ale nawet zachowując najwyższe standardy, dorzucenie kolejnej funkcjonalności może być problematyczne i należy dbać o kod, który już mamy w aplikacji. Często dorzucając nową funkcjonalność do istniejącej części systemu, wypadałoby wykonać jej refaktor. Niekiedy nowa wersja biblioteki spowoduje, że część tego kodu należy przerobić.
Istotne w pracy w IT jest nie tylko rozumienie tych zależności, ale również czy podejmowane działania przynoszą wartość dodaną dla produktu, nad którym zespół pracuje.
Dlaczego to ważne?
Scrum Master jest partnerem dla Product Ownera. Niekoniecznie są to osoby obeznane z technologią czy światem IT. Naszą pracą jest ich wspierać i pomagać, zatem w karierze każdego z nas jest moment, kiedy musimy podjąć dialog odnośnie do adresowania długu technicznego przez zespół bądź wytłumaczenia pewnych zależności technicznych i ich efektu na aplikację. Dzięki za dziś i do przeczytania :). ~ Kate
Kommentare