Zobacz jak Scrum może pomóc Twojej firmie Published: 16.12.2016 - 07:00:00 Back to References 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. Zalety Scrum Łatwość komunikacji jest często opisywaną zaletą Scrum. Inżynierowie zawsze mają coś do powiedzenia o tym, co zespół planuje zrobić i jak można to, ich zdaniem, zrobić lepiej. Nie chcą mieć z góry określonych zadań, wolą aktywnie uczestniczyć w procesie decyzyjnym. Gdy mają tę możliwość, a w Scrumie mają - wszyscy są z tego powodu szczęśliwsi. Skutek jest taki, że jakość projektu jest dużo wyższa. Przykładowo może się zdarzyć tak, że jedno wymaganie sprawia, że produkt nie spełni 5 innych. Przenoszenie takich wymagań do projektu wprost mogłoby pociągnąć za sobą negatywne skutki. Inaczej jest gdy następuje natychmiastowa wymiana informacji - inżynierowie od razu mówią klientowi o problemie i jest rozwiązywany. Przepływ informacji jest przejrzysty. Wszyscy w zespole projektowym powinni wiedzieć, co z czego wynika. Po co siedzą godzinami nad funkcjonalnością, która może nikomu się nie przydać? Kolejna zaleta Scrum uwidacznia się w tym, że zespół dostaje regularnie informacje zwrotne o produkcie. Kiedy pojawiają się nowe wymagania, Product Owner może nadać im wysoki priorytet i w ciągu maksymalnie dwóch sprintów będą spełnione, a nowa wersja zostanie wypuszczona do klienta. Projekty naszego działu to przede wszystkim oprogramowanie dla sterowników silników. Niektórzy je nazywają inwerterami, falownikami - zależnie czy spytasz eksperta od automatyki czy programowania. Jest to urządzenie, które steruje silnikami magnetycznymi w sprytny sposób i kontroluje ich moc, prąd i pozostałe parametry. Siłę Scruma można wytłumaczyć na podstawie jednego z naszych ostatnich projektów. Klient potrzebował wersji oprogramowania spełniającej nowe wymagania. Wymagania powstały z powodu uczestnictwa w przetargu na pięcioletnie państwowe zlecenie. W tradycyjnej, kaskadowej metodyce nie udałoby się tego wdrożyć w terminie. W Scrumie się to udało i to przede wszystkim dlatego, że każdy kto pracował przy projekcie wiedział, że gra o wysoką stawkę. Uczestniczymy w produkcji wspólnie i poczucie współodpowiedzialności oraz pełnego uczestnictwa w procesie sprawia, że praca idzie znacznie sprawniej. Podsumowanie Wprowadzenie Scrum wiąże się z pewnym kosztem, bo trzeba dogłębnie poznać nową metodę. Jest to kilka stron materiałów, ale większość rzeczy nabiera sensu dopiero w praktyce. Scrum pojawił się w dziale programistycznym Etteplanu częściowo z konieczności, a częściowo z chęci. Chciałem wprowadzić go wcześniej, ale udało się dopiero gdy nasz klient zobaczył w tym wartość i zaczęliśmy wspólnie się szkolić. Scrum jest mocno angażujący dla klienta i to nie zawsze się podoba. Dlatego firmy, które chcą korzystać z metody Scrum muszą mieć świadomość, że ich klienci też muszą być na to gotowi. Bardzo często w Scrum Teamach jest miejsce dla osób odpowiedzialnych za edukowanie klienta w temacie Agile i metody Scrum. Dla nowych klientów pojawia się Agile coach, który tłumaczy czemu produkt końcowy może być wyższej jakości dzięki korzystaniu ze Scruma. Naszemu klientowi bardzo się to podoba, nam się podoba i dużo dobrego z tego wyszło. Jednak nawet gdy nie prowadzisz projektów programistycznych, pewne zasady Scrum możesz wprowadzać w codziennym i zawodowym życiu - transparentna komunikacja, wartościowa dyskusja czy oszczędzanie czasu przez regularne rozwiązywanie małych problemów. Koniec końców Scrum jest tylko metodą na to, aby stymulować codzienną i efektywną komunikację całego zespołu - najważniejszy aspekt prowadzenia każdego projektu.