
Enigmatyczna nazwa stanowiska
Zazwyczaj nazwy stanowisk niosą w sobie tyle informacji, że przynajmniej jesteśmy sobie w stanie zaszufladkować charakter pracy, czy zakres obowiązków mniej lub bardziej trafnie.

Scrum Master – w przypadku tego stanowiska nie mamy jednak tyle szczęścia. Egzotycznie brzmiąca nazwa nic sensownego nie mówi. Nikt też specjalnie nie podejmuje się tłumaczenia tego stanowiska na język polski. Nieco więcej w tym temacie rozpisałem się tu.
Co warto wiedzieć? Wbrew pozorom jest to powszechne stanowisko w branży informatycznej i warto mieć świadomość o jego istnieniu. Tym bardziej kiedy jest się humanistą, który szuka dla siebie pomysłu na zmianę branży.
Co się pod tym kryje?
Przede wszystkim ogromny potencjał dla humanistów, którzy z automatu nigdy nie widzieliby siebie w IT.
Tajemnicza nazwa stanowiska sprawia, że raczej nikt nie bierze go pod uwagę, patrząc w stronę zmiany branży. Kto miał szczęście i poznał, co to znaczy być Scrum Masterem i „z czym to się je”, pewnie zdaje sobie sprawę z potencjału, jaki to stanowisko niesie.
Zacznę może od tego, czego Scrum Master nie robi – po pierwsze nie koduje. Po drugie, nie musi znać się na technologiach i posiadać matematycznie wytrenowanego umysłu.
No dobra, to jeśli nie wiedza techniczna, to co takiego trzeba wiedzieć, żeby zostać tym całym Scrum Masterem?
Pozwolę sobie zacząć tak: Scrum Master – jak sama nazwa wskazuje, potrzebne będzie mistrzostwo w pewnej dziedzinie. To tak pół żartem, pół serio. Natomiast, mówiąc już z pełną powagą, oczywiście trzeba się na czymś znać i to dobrze. A są to:
- Proces wytwarzania oprogramowania.
- Scrum
I zaryzykowałbym stwierdzenie, że w takiej właśnie kolejności.

Teraz horror dostępny w promocyjnej cenie.
Proces wytwarzania oprogramowania
Czyli cały szereg kroków, myśli, pomysłów, czynności i zdarzeń, którego wynikiem jest stworzenie, bądź udoskonalenie oprogramowania.
To jak z wytwarzaniem czegokolwiek; jak z produkcją dowolnej rzeczy, jaką mamy w swoim otoczeniu, kiedy podniesiemy wzrok znad monitora, czy telefonu. Tak, każdy z tych przedmiotów musiał być kiedyś wyprodukowany.
Na początku jest zawsze słowo.
Jednak, żeby tak się stało na początku musi paść to słowo, czyli – „robimy to”. Oczywiście nieco wcześniej powinna zaistnieć potrzeba, którą nasz produkt zaadresuje. Potem, budżet, który pozwoli na rozpoczęcie jakichkolwiek prac. Dalej, pomysł jak to wykonać. Zbudowanie prototypu i przetestowanie, czy działa, a następnie skonfrontować efekt tego wysiłku z klientem – najlepiej już na etapie prototypu. Wszystko to składa się na powszechną praktykę w każdej branży – kto ryzykowałby wypuszczenie całych partii produktu, nie mając pewności, że to właśnie to, czego klient potrzebuje?
Z produkcją software’u jest podobnie
Z tą różnicą, że efekt pracy jest wirtualny, ale równie wartościowy, co wszelkie artefakty namacalne.
Podzielmy sobie nasz proces to na etapy:
1. Potrzeba
Na tym etapie pierwsza z ról zespołu informatycznego wchodzi do gry. Product Owner (więcej o nim tu). To on właśnie otrzyma takie zlecenie od klienta, albo sam zdiagnozuje, znając rynek, że potrzebujemy zrobić to i to, bo z tego właśnie będą pieniądze.
2. Pomysł na rozwiązanie
Product Owner zaproponuje rozwiązanie językiem ludzkim, opisowo i „słowno-muzycznie”. Może to przedstawić za pomocą różnych narzędzi, technik i standardów jakie ma do wykorzystania, ale nie musi. W dodatku, każda z tych metod opisu potrzeb ogranicza się do opisowego języka naturalnego (więcej o nich tu).
3. Wyprodukowanie (development)
Tu dopiero się zaczyna faza techniczna. Widząc zlecenie od Product Ownera, zespół developerski/scrumowy (czyli głównie programiści i testerzy) omówią pomysł z autorem. Następnie zaproponują rozwiązanie, które zostanie podzielone na małe kawałeczki pracy i wycenione/wyestymowane. Głównie chodzi o to, ile czasu zespół będzie potrzebował na zrealizowanie przedsięwzięcia. Z tego ostatniego naturalnie można będzie oszacować potencjalny koszt i odnieść się do niego – tzn. czy nas na to stać, i jaki będzie ROI.
4. Przetestowanie
Za każdym razem, kiedy jakiś klocek pracy zostanie dostarczony/zakodowany, trzeba będzie go przetestować. Takie klocki, jako całość, stworzą na wczesnym etapie prototyp – surowy szkielet rozwiązania bez fajerwerków. Wszystko po to, żeby nasz klient (jak to się lubi o nim mawiać – stake holder), mógł szybko odnieść się do efektu pracy zespołu. Dlaczego? Żeby nie marnować pieniędzy na dopieszczanie produktu, który nie spełnia podstawowych założeń.
5. Dostarczenie klientowi
Czyli dostarczenie naszego rozwiązania na tzw. środowisko produkcyjne; komercyjne udostępnienie go klientowi. Środowisko produkcyjne to punkt docelowy naszej pracy – a mówiąc już o środowiskach, warto wspomnieć, że jest ich kilka. Dlaczego? Bo znów chodzi o przetestowanie naszego rozwiązania. Są środowiska, w których nasz produkt jest budowany i testowany wstępnie. Dalej na kolejnym środowisku testuje się go drobiazgowo i z każdej możliwej strony z innymi komponentami. A zanim trafi na to docelowe środowisko produkcyjne, udostępnia się klientowi oddzielne środowisko, na którym on sam może przetestować wprowadzone rozwiązanie.

Czy młody kapitan znajdzie odpowiedź na krańcu wszechświata?
Scrum – tak na szybko
To właśnie to podejście, metoda, czy standard w produkcji oprogramowania, narzuca pewne ramy, narzędzia i procesy, które mają nam pomóc i uwydajnić tworzenie software’u.
Scrum realizuje założenia filozofii Agile, czyli tzw. zwinnych praktyk w produkcji oprogramowania. Sprowadza się to do tego, że kilku panów, spotkało się kiedyś i doszli do wniosku że można to robić lepiej, prościej i szybciej. Bazując na swoim wieloletnim doświadczeniu, zgodzili się co do tego, co należy poprawić i spisali w kilku punktach. Nieco bardziej szczegółowy efekt ich pracy możemy zobaczyć w założeniach ich manifestu.
Scrum (obok Kanban, czy Lean), jako jedno z dostępnych metod, pomaga te założenia realizować.
Jak pracuje się w Scrumie?
Scrum mówi, budujmy małe zespoły (ok 5 osób) i pracujmy tak, żeby często efekt pracy pokazywać zainteresowanym. Zatem zespół scrumowy typowo pracuje iteracyjnie, czyli w powtarzalnych cyklach dwutygodniowych, zwanych tu sprintami.
Na każdy sprint składa się:
- przygotowanie pracy (backlog refinement)
- określenie zadań na dany sprint (sprint planning)
- development (kodowanie, testowanie)
- pokazywanie efektów pracy zainteresowanym (demo)
- wdrożenie (release)
Czego jeszcze oczekujemy od Scrum Mastera?
Najlepsi Scrum Master’owie, z którymi się zetknąłem, odznaczali się takimi cechami jak:
- rygor, dyscyplina pracy
- konsekwencja
- komunikatywność
- zwięzłość w komunikacji
- proaktywność
Gdzie w tym wszystkim jest Scrum Master?
Wszędzie i nigdzie (!). Mówi się o Scrum Masterze, że jest to taki ninja. Pojawia się, kiedy jest potrzebny, a kiedy wszystko działa tak jak powinno, pozostaje w cieniu, niewidoczny na pierwszy rzut oka.
W praktyce, bierze udział we wszystkich tzw. scrumowych ceremoniach, czyli spotkaniach, które narzucą sobą przestrzeganie Scrum’a. Pilnuje, czy praca ma miejsce zgodnie z założeniami Scruma, a jeśli nie, sugeruje rozwiązania.
Często oczekuje się od nich również organizacji tych spotkań i facylitowania ich, ale to jeden z typów Scrum Mastera, z których wyodrębnił bym kilka w oddzielnym wpisie.

Chciałbym podnieść standard życia.
Jeśli jesteś zainteresowany pracą w IT, zachęcam do eksplorowania bloga. Dużo bardziej szczegółowo omawiam software development w książce Almanach Informatyczny – Lite.
Jej założeniem jest wprowadzenie każdego do świata IT w 100 słowach i turbo kompaktowych definicjach. Wszystko, czego potrzebujesz, żeby świadomie wybrać rolę dla siebie i czuć się komfortowo, kiedy już zaczniesz.
Powiązane wpisy:
- Co to jest Scrum w IT?
- Co to jest Agile w IT?
- Jak dostać awans
- Co to jest Product Backlog w IT?
- Jak znaleźć pracę w korporacji
- Praca w IT bez doświadczenia
- Praca w IT bez programowania
- Czy angielski jest konieczny w IT
- Czym zajmuje się Scrum Master
- Czym zajmuje się Product Owner
- 8 cech dobrego Scrum Mastera
- Humanista w informatyce
- Rekrutacja w IT
Zobacz także:
- (Nie)techniczna skala wejścia do IT
- Jak się pracuje w IT – czy to wszystko mit?
- Estymowanie w Scrumie
- Jak pisać User Story
- Jak dobrze napisać historyjkę użytkownika, a jak robić to źle?
- Zmysły sztucznej inteligencji.
- Czy to wszystko mit? – czyli jak na prawdę pracuje się w IT?
- Humanista pośród informatyków
- Czym zajmuje się Scrum Master?
- Informatyk w informatyce.
- Umysł ścisły w informatyce
- AI w IT. Koniec dominacji ludzkiego intelektu?
- Geograficzna eksploracja IT
Dodaj komentarz