aktualności

Artykuł Goldenberry w Computerworld na temat pułapek we wprowadzaniu Scrum, a także materiały do pobrania - lista kontrolna gotowości przed rozpoczęciem pierwszego projektu Scrum i rozwiązywanie problemów.

Materiały do pobrania

Na podstawie doświadczeń we wprowadzaniu podejścia opartego na Scrum w dużych instytucjach opracowaliśmy listę kontrolną obejmującą najważniejsze czynniki sukcesu, a także listę najczęstszych problemów wraz z sugestiami rozwiązań.

Powyżej: mapa pojęć metod zwinnych i zakres dokumentu

Powyżej: lista kontrolna Scrum w dużych organizacjach

W wersji pełnej znajduje się oprócz tego między innymi opis Sprint 0, opis preferowanych profili Scrum Mastera i Właściciela Produktu, porównanie elementów Scrum w małych i dużych organizacjach, pełna lista problemów z rozwiązaniami, przykłady wykorzystywanych narzędzi. 

Pobierz plik pdf (4 strony): Scrum W Dużych Organizacjach wersja skrócona v1.1.pdf

Pełna wersja jest dostępna bezpłatnie dla osób, którym powierzono rolę wprowadzenia Scrum w dużej organizacji - prosimy o kontakt na adres contact@goldenberry.eu.

"Scrum nie jest uniwersalnym rozwiązaniem"

Artykuł Diny Dąbrowskiej opublikowany w Computerworld 15/2014.

Wielu projektów IT nie udaje się skończyć w planowanym czasie i budżecie. Na domiar złego okazuje się, że w trakcie prac zmieniły się potrzeby biznesu. Metodyki agile dają nadzieję uniknięcia tych problemów, ale oznaczają także pewne koszty i ryzyko.

Do niedawna metodyki zwinne kojarzone były głównie z projektami startupowymi. Obecnie coraz więcej organizacji – w tym również większych graczy, takich jak banki, ubezpieczyciele, firmy medyczne czy logistyczne – prowadzą lub rozważają prowadzenie projektów w ten sposób. Jednak zmiana podejścia projektowego w kulturze, w której przez lata dominował tradycyjny, kaskadowy model wytwarzania oprogramowania, jest trudna.

W agile łatwiej o zmianę zakresu

Dla wielu firm model kaskadowy ma istotne wady – produkcja oprogramowania trwa długo, a użytkownicy widzą efekty i zaczynają używać rozwiązania dopiero pod koniec projektu. Wcześniej niemożliwe może być nawet zweryfikowanie, czy ich wymagania zostały właściwie zrozumiane i spełnione. Zakres, harmonogram i budżet projektu ustalany jest przed jego rozpoczęciem. Jeżeli w trakcie realizacji wymagań pojawi się potrzeba dodania nowych funkcjonalności, decyzja o ich realizacji może spowodować zmianę wcześniejszych ustaleń. Czasem rodzi to konflikty pomiędzy użytkownikiem, wykonawcą i sponsorem projektu, dlatego generalnie zmiany nie są pożądane.

Podejście zwinne ma na celu szybsze przekazanie kolejnych części rozwiązania końcowemu użytkownikowi. Liczy się to, aby od samego początku rozmawiać z użytkownikami o ich faktycznych potrzebach. W krótszych cyklach łatwiej jest też zarządzać dynamicznie zmieniającymi się wymaganiami – wystarczy na daną iterację zaplanować elementy, które w ostatnim czasie zyskały wysoki priorytet z punktu widzenia użytkownika. Takie podejście wydaje się być idealnym rozwiązaniem wspomnianych problemów, dlatego firmy coraz częściej decydują się na jego zastosowanie.

Moda na Scrum bywa kosztowna

Najpopularniejszym obecnie podejściem zwinnym jest Scrum. Zespół pracujący w ten sposób ma wspólny cel: wyprodukować w danej iteracji – tutaj zwanej sprintem – pewien zbiór funkcjonalności reprezentowanych przez tzw. historyjki (user stories), które można zaprezentować użytkownikowi końcowemu. Historyjki użytkownika są krótkimi opisami wymagań do danej funkcjonalności oraz przypadków jej użycia i definiowane są wspólnie w zespole na początku trwania projektu. Powstaje wtedy rejestr produktu (product backlog), czyli dokument zawierający opis zakresu. Historyjki są następnie uszczegóławiane przed sprintem, w którym mają być wykonane.

Celem Scrum jest między innymi uproszczenie pracy. Nie oznacza to jednak, że Scrum jest łatwy we wprowadzeniu. Panująca moda oraz szereg publikacji zachwalających jego zalety zachęcają firmy do stosowania tego podejścia, mimo że nie posiadają one wystarczającej wiedzy i doświadczenia w zrealizowaniu takiej zmiany. Nieumiejętne podejście do przestawienia produkcji na Scrum może się okazać kosztowne i nieefektywne.

Scrum wymaga solidnego przygotowania

Scrum zakłada, że zespół projektowy zdolny jest do samoorganizowania się, a wszyscy jego członkowie rozumieją swoją rolę i aktywnie uczestniczą w planowaniu i realizacji sprintów. Tymczasem nie w każdej firmie jest to możliwe – szczególnie, jeśli do tej pory kultura metodyk zwinnych nie była przez nią praktykowana. Z jednej strony, zespoły nie mają więc umiejętności zarządzania własną pracą, z drugiej zaś, menedżerowie wciąż starają się kontrolować swoich pracowników według dotychczasowych zasad, co utrudnia sprawne realizowanie założeń tego podejścia.

Rozproszona odpowiedzialność za projekt sprawia, że trudno nim zarządzać. W trakcie sprintów zbieranych jest wiele informacji, które warto w odpowiedni sposób monitorować i analizować, aby utrzymać kontrolę nad postępem projektu. Jest to na przykład wydajność zespołu, czy poprawność estymacji i skomplikowania zadania. Zdarza się jednak, że zespoły nie zastanawiają się nad tym, zanim przystąpią do pracy w Scrum. Zamiast tego próbują wypracować podejście już po zebraniu pierwszych danych. Często okazuje się, że oprócz tego, co zostało zanotowane w poprzednim sprincie, przydałyby się dodatkowe dane lub zmiana sposobu ich raportowania. Zajmuje to dodatkowy czas zespołu oraz uniemożliwia porównywanie tych samych danych na przestrzeni minionych sprintów. Dlatego warto dokładnie przemyśleć, jakie informacje powinniśmy gromadzić w czasie pracy nad projektem oraz w jakim celu będziemy je potem wykorzystywać.

Praca w Scrum zajmuje dużo czasu

Szacowanie czasu i planowanie sprintów to powtarzalne elementy Scrum. Oprócz tego zespoły muszą rejestrować faktyczny czas spędzony nad danym zadaniem, aby porównać, czy dobrze oszacowały poziom jego skomplikowania. Na koniec sprintu odbywa się jego podsumowanie i demonstracja wykonanych historyjek użytkownika.

Po jednym lub kilku sprintach mogą być wydawane wersje, co oznacza, że dotychczas zrealizowane fragmenty rozwiązania trafiają na środowisko produkcyjne. Dobrą praktyką jest też regularna rewizja i porządkowanie kodu. Wszystkie te czynności zajmują czas i generują koszty, co powinno być brane pod uwagę przy podejmowaniu decyzji o wprowadzeniu Scrum.

W praktyce trudno o prawdziwego właściciela produktu

Istotną rolą w zespole Scrum jest właściciel produktu. Reprezentuje on użytkowników końcowych rozwiązania i bezpośrednio uczestniczy w pracach zespołu. Właściciel produktu decyduje również o zmianach w zakresie produkowanych funkcjonalności oraz akceptuje dotychczas zrealizowane historyjki. W dużych organizacjach właściciel produktu wywodzi się najczęściej z biznesu. Często swoją rolę projektową musi on pełnić obok zadań operacyjnych, co stwarza problemy z jego dostępnością, na przykład na cyklicznych spotkaniach. Pewnym rozwiązaniem jest wyznaczenie na właściciela produktu osoby, której czas w większości lub nawet w całości może być dedykowany na potrzeby projektu. Zwykle jednak ma ona mniejszą decyzyjność w zakresie priorytetów biznesowych, budżetu czy harmonogramu projektu.

Problemy wynikają też często z faktu, że zwykle to dział IT inicjuje pomysł wprowadzenia Scrum i szkoli tylko swoich pracowników w tym kierunku. Zatem w trakcie rozpoczynania pracy w Scrum użytkownicy biznesowi, którzy również mają brać udział w projektach, nie mają tej samej wiedzy, co ich koledzy z IT. Utrudnia to komunikację w zespole i zniechęca do angażowania właściciela produktu we wszystkie elementy sprintu – niechęć ta widoczna jest zarówno po stronie zespołu, jak i samego właściciela.

Scrum nie zwalnia z projektowania

Pułapką jest myślenie, że w Scrum nie ma potrzeby, aby organizacja IT projektowała całościową koncepcję rozwiązania. Jeśli w podejściu kaskadowym projekty były prowadzone nieprawidłowo (np. brakowało im analizy procesowej, czy solidnej architektury rozwiązania), to Scrum tego braku nie wypełni. Przeciwnie, bez wysokopoziomowej koncepcji trudno będzie zaplanować sprint. Zaletą Scrum w tym przypadku jest jednak to, że ewentualne braki w architekturze szybko wyjdą na jaw w miarę prezentacji kolejnych, zrealizowanych historyjek.

Scrum, ale nie do końca

Powyższe trudności sprawiają, że firmy wdrażają Scrum na raty, wykorzystując tylko te elementy, które są wygodne lub atrakcyjne z punktu widzenia wewnętrznego i zewnętrznego PR-u. To między innymi organizacja pracy w sprintach, rezygnacja z tworzenia rozbudowanej dokumentacji analitycznej i technicznej przed rozpoczęciem kodowania, czy brak rozbudowanego harmonogramu dla całości projektu. Jednocześnie firmy zostają przy praktykach wyuczonych w dotychczasowej kulturze organizacyjnej, takich jak utrzymywanie dystansu pomiędzy IT i biznesem, czy zachowanie sztywnej sekwencyjności działań, gdy, na przykład, programiści czekają z rozpoczęciem kodowania na ukończenie pełnej analizy w danym temacie.

Scrum nie jest dla wszystkich

Metodyki zwinne niewątpliwie mają wiele zalet i w niektórych warunkach świetnie zastępują model kaskadowy. Niemniej decyzja o realizacji projektu w Scrum powinna być poprzedzona analizą wszystkich za i przeciw, a nie próbą podążania za modą na innowacyjne podejście projektowe. To, że Scrum jest popularny wśród spółek technologicznych nie oznacza, że sprawdzi się w każdej innej firmie. Wiele zależy od specyfiki projektów, rodzaju biznesu, kultury i zdolności organizacji oraz jej pracowników do szybkiego uczenia się.

Kluczowe znaczenie ma również wybór odpowiednich, doświadczonych osób, które będą odpowiadać za przeprowadzenie zmiany. Najlepiej zastosować metodę małych kroków – wybrać mniejszy projekt, który w całości będzie przeprowadzony metodyką zwinną i, jeśli podejście sprawdzi się w organizacji, stopniowo zwiększać skalę.