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.

Celem Scrum Mastera jest dbanie o to, aby każdy pracował wydajnie i był na bieżąco. W związku z tym Scrum Master koordynuje większość tego, co trafia do programu Agile, a także jego rezultaty. Taka osoba organizuje wydarzenia Agile, takie jak rozpoczęcie sprintu, codzienne spotkania stand-up, przeglądy sprintu, retrospektywy sprintu, a także współpracuje z zespołem i menedżerami ds. tworzenia oprogramowania nad szacowaniem większych jednostek, takich jak epiki oraz pojedyncze historyjki użytkowników w backlogu. Scrum Master może nie być tak biegły w kwestiach technicznych, jak pozostali członkowie zespołu, dlatego menedżer ds. tworzenia oprogramowania może dostarczać Scrum Masterowi cennego kontekstu w komunikacji z zespołem, jeśli pojawią się braki wiedzy. W miarę jak zespół coraz lepiej radzi sobie ze stosowaniem metodyki Agile, Scrum Master w mniejszym stopniu koncentruje się na szacowaniu, a w większym na optymalizacji prędkości dostarczania.

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