Menedżerowie ds. tworzenia oprogramowania a Scrum Masterzy

To odwieczni wrogowie, którzy toczą walkę na śmierć i życie. (To oczywiście żart. W rzeczywistości te dwie role całkiem dobrze funkcjonują obok siebie).

Dan Radigan Autor: Dan Radigan
Przeglądaj tematy

Zespoły Agile pod względem strukturalnym różnią się od ich odpowiedników w modelach kaskadowych. Zespoły stosujące podejście kaskadowe odzwierciedlają strukturę organizacji, a planowanie często odbywa się „od góry do dołu”, co oznacza, że to kierownictwo nadaje tempo i wyznacza harmonogram prac. W przypadku programowania Agile zespół samodzielnie organizuje swoją pracę. Wyznacza własny harmonogram na podstawie priorytetów ustalonych przez product ownera i dostępnego potencjału wykonawczego zespołu.

Scrum Masterzy i menedżerowie ds. tworzenia oprogramowania wypełniają lukę organizacyjną między starszym kierownictwem a poszczególnymi zespołami programistycznymi. Ich celem jest optymalizacja pracy zespołów oraz ich członków w taki sposób, aby dostarczali najlepszej jakości oprogramowanie, przyczyniając się tym samym do realizacji celów firmy. Scrum Master i menedżer ds. tworzenia oprogramowania chronią również zespoły przed zewnętrznymi zakłóceniami, takimi jak niekontrolowane rozrastanie się funkcji, antywzorce modelu kaskadowego, bałagan organizacyjny czy projekty poboczne, przez które zespół zbacza z realizacji rzeczywistych celów.

Zarówno Scrum Masterzy, jak i menedżerowie ds. tworzenia oprogramowania zazwyczaj współpracują z wieloma zespołami Agile. Przyjrzyjmy się temu, jak współpracują z poszczególnymi zespołami w większych portfelach Agile.

Kim jest menedżer ds. tworzenia oprogramowania?

Menedżerowie ds. tworzenia oprogramowania są kluczowymi uczestnikami organizacji działających według zasad Agile, a ich rola ma zasadnicze znaczenie. Odpowiadają oni za jakość produktu — od architektury kodu po finalny produkt docierający do użytkownika końcowego. Uczestniczą w przeglądach kodu, aby mieć pewność, że członkowie zespołu udostępniają kod, który spełnia krótko- i długoterminowe cele programu. Dzięki temu, że znajdują się oni tak blisko zespołu, zazwyczaj mają duży wpływ na wybór technologii do realizacji programu. W rezultacie taka praca blisko samego procesu oraz produktu umożliwia menedżerom ds. tworzenia oprogramowania przekazywanie kontekstu na poziomie wewnętrznym członkom zespołu, a także szerszemu gronu całej organizacji.

Wysokiej klasy menedżerowie ds. tworzenia oprogramowania odpowiadają też za budowanie zespołu, a proces ten zaczyna się od zatrudniania. Menedżerowie ds. tworzenia oprogramowania kierują procesem zatrudniania i są do tego dobrze przygotowani, ponieważ:

  • zatrudnianie jest czasochłonne i rozprasza innych członków zespołu;
  • poszukiwanie kandydatów odciąga uwagę od tworzenia fantastycznych produktów,
  • menedżer ds. tworzenia oprogramowania może pomóc w ograniczeniu niektórych aspektów onboardingu, gdy każda z nowych osób integruje się z zespołem.

Mówiąc wprost, gdy menedżer ds. tworzenia oprogramowania podejmuje się zadań związanych z rekrutacją i zatrudnianiem nowych pracowników, zespół może skoncentrować się na produkcie.

Menedżerowie ds. tworzenia oprogramowania pełnią również funkcję partnera i mentora, ponieważ biegle znają podstawy zarządzania: spotkania indywidualne, przekazywanie informacji zwrotnych oraz coaching. Skuteczni menedżerowie ds. tworzenia oprogramowania wspierają inżynierów, oferując im wszystko, co najlepsze: pomysły, kod, testy oraz kulturę. Czasami zespół miewa trudności z podjęciem decyzji dotyczących na przykład projektu architektonicznego czy strategii tworzenia gałęzi. Kompetentni menedżerowie tworzenia oprogramowania wiedzą, kiedy zaingerować, a kiedy pozwolić zespołowi na samodzielne pokonanie trudności w celach edukacyjnych.

Jedną z największych różnic między zespołami Agile a zespołami pracującymi według modelu kaskadowego jest fakt, że menedżer ds. tworzenia oprogramowania jest partnerem w procesie szacowania. W zespole stosującym podejście kaskadowe następująca rozmowa nie byłaby niczym niezwykłym:

  • Menedżer: „Cześć, ile czasu zajmie dostarczenie tej funkcji?”.
  • Inżynier: „Sześć tygodni. Musimy zrobić A, B i C, żeby wprowadzić tę funkcję na rynek”.
  • Menedżer: „Hmm. To ma sens, jednak musicie znaleźć sposób, żeby uporać się z tym w cztery tygodnie”.

Natomiast menedżer ds. tworzenia oprogramowania w modelu Agile wie, że musi zatrudnić fantastycznych ludzi, a potem im zaufać. Podstawowa zasada procesu Agile głosi, że osoby znajdujące się najbliżej pracy potrafią najlepiej ustalić jej zakres i ją dostarczyć. To zespół wyznacza harmonogram. Menedżer ds. tworzenia oprogramowania wnosi unikatową wartość, kwestionując i weryfikując założenia przyjęte podczas szacowania. Uczestniczy on w tym procesie na zasadzie partnera, zamiast narzucać własne szacunki.

W organizacjach stosujących zasady Agile nie usłyszysz stwierdzenia „znajdź sposób, żeby uporać się z tym w cztery tygodnie”. (A jeśli tak, no cóż… czymś to pachnie, prawda?).

Kim jest Scrum Master?

Scrum Masterzy są liderami projektów w zespole Agile koncentrującymi się na optymalizacji wydajności. Stanowią oni ogniwo łączące product ownera z zespołem w celu realizowania spójnych i skutecznych sprintów. Odpowiadają również za koordynację międzyzespołową, aby główny zespół mógł skoncentrować się na opracowywaniu produktu.

The goal of the scrum master is to keep everyone efficient and on the same page. As a result, the scrum master coordinates most of the inputs and outputs required for an agile program. He or she drives the agile ceremonies of sprint kickoff, daily stand-ups, sprint review, sprint retrospective, and works with the team and development managers to estimate larger items like epics and individual user stories in the backlog. The scrum master may not be as technical as the rest of the team, so the development manager can step in to lend valuable context between the scrum master and the team when a knowledge gap appears. As the team matures in it's application of agile, the scrum master focuses less on estimation and more on optimizing the velocity of delivery.

Scrum Master pełni również funkcję trenera Agile w ramach szerszej organizacji, pomagając zespołowi przyjmować i stosować praktyki Agile w obrębie całego cyklu życia produktu: od szacowania punktów historyjek, poprzez planowanie sprintów, aż po ciągłe dostarczanie. Aspekt coachingowy w pracy Scrum Mastera ma krytyczne znaczenie. Scrum Masterzy są ekspertami w dziedzinie metodyki Agile, dlatego wiedzą, dlaczego jest to właściwe rozwiązanie w przypadku projektu oraz firmy i mogą bronić zasadności tego modelu, gdy firma będzie się borykać z narastającymi trudnościami w jego wdrażaniu.

Współpraca Scrum Masterów i menedżerów ds. tworzenia oprogramowania w ramach portfeli Agile

Praca większości zespołów w modelu kaskadowym koncentruje się wokół osoby menedżera. Zespoły zasięgają opinii menedżerów w kwestii ustalania priorytetów, monitorowania postępów oraz oceny wydajności. Z kolei zespoły Agile stawiają na samodzielną organizację i same odpowiadają za harmonogram oraz dostarczanie. Aby takie rozwiązanie sprawdziło się w większych organizacjach, Scrum Masterzy i menedżerowie ds. tworzenia oprogramowania starają się wspólnie wprowadzić kulturę Agile w całej organizacji i pełnią funkcję bufora między zespołami a kadrą zarządzającą wyższego szczebla. W związku z tym, że obydwie role zakładają pracę na rzecz wielu zespołów Agile, osoby, której je pełnią, są kluczowymi członkami portfela Agile.

Scrum Master powinien koncentrować się na przyjęciu i wdrożeniu metodyki Agile przez zespół, natomiast zadaniem menedżera ds. tworzenia oprogramowania powinno być przede wszystkim zatrudnianie właściwych osób, mentoring dla dotychczasowych członków zespołu oraz budowanie właściwej kultury programistycznej w każdym zespole. Współpracując ze sobą, osoby pełniące te role będą wspierać zespoły Agile w osiąganiu lepszych wyników.

Następny
Git