Zobacz jak Scrum może pomóc Twojej firmie

Tradycyjny, kaskadowy model zarządzania projektami oznacza zapoznanie się z setkami stron płatnej księgi PMBOK (opis terminologii i wytycznych do zarządzania projektami, w ostatniej edycji 589 stron). Projekty planowane są z góry na kilka miesięcy lub lat i realizowane w jednym ciągu z wątpliwą skutecznością. Nowoczesna metoda, Scrum, mieści się na kilkunastu stronach otwarcie dostępnego przewodnika i nieporównywalnie ułatwia pracę zespołom programistycznym takim, jak nasz.

Jestem Project Managerem w dziale oprogramowania, w którym dwa lata temu nastąpiła Scrumowa rewolucja. Projektujemy oprogramowanie do produktów dla jednego, głównego klienta - globalnej korporacji technologicznej.

Dział jest częścią polskiego oddziału firmy Etteplan, który projektuje gotowe produkty przemysłowe - od projektów sprzętu, przez mechanikę, testery produkcyjne po oprogramowanie - dla klientów, którzy dalej sprzedają te produkty. Nasi klienci mają pomysły na swoje produkty albo gotowe rozwiązania do usprawnienia. My realizujemy pełne zaplecze techniczne działań niezbędnych do zaprojektowania i wprowadzenia na rynek przemysłowych rozwiązań z zakresu systemów wbudowanych (Embedded Systems) oraz internetu rzeczy (IoT).

Ok. 2 lata temu nasz klient zmienił nastawienie i podjął dużą inwestycję aby zmienić klasyczny model realizacji projektów na najbardziej popularny model Agile - Scrum. Wspólnie nauczyliśmy się jak tworzyć oprogramowanie zgodnie z nową metodą. Przechodziliśmy z każdym nowym projektem na Scrum, a wcześniejsze projekty o długim terminie realizacji dostosowaliśmy do nowej metody.

W tym artykule chcę pokazać, skąd wzięła się najpopularniejsza obecnia metoda prowadzenia projektów programistycznych, jak wygląda jej implementacja i jakie płyną z niej korzyści - nie tylko dla zespołów takich jak nasz, ale dla biznesu w ogóle.

 

Skąd Wziął Się Scrum?

 

Powstanie metody Scrum wynikło z powstania oraz działań ruchu Agile. Agile jest nazywany najpopularniejszym silnikiem innowacji na świecie, częściowo przez to że kompletnie zmienił jedną z najistotniejszych obecnie dziedzin w biznesie - inżynierię oprogramowania. Scrum jest najważniejszym tworem ruchu Agile, oraz obecnie głównym standardem w prowadzeniu projektów.

Chyba każdy poznając metodę Scrum zauważy to co ja - na początku wydaje się bardzo prosta. Cała zawarta jest w krótkim Scrum Guide otwarcie dostępnym w internecie. W przeciwieństwie do prawie 600 stron wytycznych tradycyjnego PMBOK, Scrum Guide ma stron do przeczytania aż 17. Jest to pewna subtelna różnica.

Wprowadzając metodę zauważyłem jednak, że każde słowo w tym przewodniku ma znaczenie. Dlatego przeczytanie w 5 minut krótkiego przewodnika nie wystarczy, aby później w środowisku przemysłowego oprogramowania realizować lepsze projekty. Trzeba się napocić dostosowując metodę do swoich działań.

Od dwóch lat każdy projekt realizujemy w Scrum. Doszliśmy w tym do biegłości, dzięki czemu mogliśmy zacząć współpracować z kolejnymi działami biznesowymi naszego klienta.

 

Na Czym Polega Scrum?

 

Scrum opiera się na prostym założeniu, że produkt rozwija się etapami - w Scrumie nazywa się etap sprintem.

Jest to najważniejsza przewaga nad tradycyjną metodą zarządzania projektami, która zakładała planowanie produkcji na długi czas do przodu. Kiedy w trakcie pojawiały się nowe wymagania do produktu, bardzo ciężko było je spełnić.

Planując sprintami można zachować elastyczność zespołu względem wymagań klienta. Ta elastyczność jest dziś niezbędna , gdyż rozwój na rynku oprogramowania jest niesamowicie dynamiczny. Wymagania mogą się zmieniać z tygodnia na tydzień, czasem z dnia na dzień.

Ta dynamika istnieje w całym rynku IT. Te firmy, które wciąż korzystają z tradycyjnych metod zarządzania projektami mogą mieć z tego powodu problemy. Zmiany wymagań i planów projektu bowiem trzeba przeliczać na pozostałe do zakończenia miesiące, co jest stratą czasu.

Scrum zakłada, że sprint może być rozplanowany na maksymalnie 4 tygodnie. U nas są z reguły dwutygodniowe. Są trzy różne role:

• Product Owner: właściciel produktu, w naszym przypadku klient. Ktoś z wizją, mocą decyzyjną i dostępny do stałej komunikacji. Odpowiada za priorytetyzację zadań.
• Scrum Master: moja rola, polegająca na koordynowaniu pracy pomiędzy właścicielem, a zespołem. Nie jest to klasyczne zarządzanie - jest to rola polegająca głównie na eliminacji wszelkich problemów, które przeszkadzają zespołowi w realizacji celów zakładanych na każdy sprint.
• Team: ostoja Scrum. Zespół jest w pełni samoorganizujący się i odpowiedzialny za dokończenie pracy na czas. Idealnie składa się z 7 osób, w projektach programistycznych są to inżynierowie, architekci, programiści, analitycy i testerzy. 

Scrum wymusza zdefiniowanie celu stworzenia produktu zanim praca się zacznie, już w trakcie tworzenia pierwszych wymagań. Opisywane jest to przez tzw. user stories. Ich stworzenie polega na postawieniu się w pozycji użytkownika produktu, administratora czy sprzedawcy. “Ja jako użytkownik potrzebuję tej funkcjonalności, bo...”. Najważniejsze jest klarownie wyjaśnić dlaczego produkt ma wyglądać w dany, a nie inny sposób.

Spotkania w środowisku profesjonalnym są często pozbawione sensu. Nie musisz prowadzić projektów programistycznych, żeby wiedzieć, że tradycyjne spotkania biznesowe czy projektowe są często stratą czasu. Jak nudne managerskie spotkanie, gdzie siedzi 5 smutnych Panów, jeden mówi, reszta śpi - wszyscy czują się ważni.

W spotkaniach Scrumowych nie ma straty czasu. Najgorsze co może się przytrafić zespołowi to nudniejsze spotkanie, co może wynikać tylko z tego, że wdrażana funkcjonalność nie jest ciekawa.

Nie ma ich wiele, bo 4 rodzaje. W tym codzienna piętnastominutówka, która jest szybkim zespołowym odświeżeniem informacji - kto, co zrobił i nad czym dalej pracuje.

Poza tym są trzy główne spotkania Scrumowe - planning, demo i retrospekcja. Na każdym spotkaniu dyskusja idzie w jednym, spójnym kierunku. Spotkania są miejscem, gdzie zespół może szczerze porozmawiać i znaleźć rozwiązania największych przeszkadzajek w ich pracy. Nie trzeba przyspieszać, wystarczy rozwiązywać małe problemy aby efektywność sama rosła, wraz z satysfakcją z pracy.

Każde uwzględnia użycie narzędzi stymulujących wartościową dyskusję, jak np. Planning Poker.

To proste narzędzie do zastosowania przy planowaniu sprintu, kiedy dyskutuje się nad funkcjonalnościami. Zespół ma karty z liczbami z ciągu Fibonacciego, z reguły są to - 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89.

Liczby odpowiadają temu, jak dużo pracy trzeba spędzić nad funkcjonalnością. Na znak sygnał czapką wszyscy rzucają karty z cyframi, które określają według nich wymagania nowej funkcjonalności.

Na przykład: Ty rzucisz 3, bo dla Ciebie nowa funkcjonalność to mało pracy, szybko da się ją napisać bo jest podobna do innej, testy już są, tylko się przemodeluje kod i to wszystko. Za to ja mówię, że to 8 - bo nie ma dokumentacji, trzeba będzie stworzyć. Testy są, ale już nie działają, także trzeba odświeżyć. Podobna funkcjonalność różni się w kluczowych miejscach, dlatego nie da się tylko przemodelować.

W ten sposób Planning Poker zapala dyskusję podczas planowania. Można dzięki temu zdobyć rzeczywiste informacje na temat tego, jak każdy w zespole rozumie wymagania. Punkty w Planning Pokerze nie mają właściwie znaczenia ale powodują, że zanim ktoś wybierze numer już zastanawia się nad nakładem pracy.

Dyskusja zaczyna się gładko, a jak się rozkręci to wszyscy zdążą przeanalizować problem tak, że implementacja będzie szybka i łatwa.