Krystian Brożek

Cze 11, 2019

11 czerwca 2019

Poniżej przedstawiam moje doświadczenia ze Scrumem z kilkunastu projektów, w których go wykorzystywałem. W internecie można znaleźć wiele materiałów na ten temat. Często można trafić na artykuły mówiące czym Scrum nie jest. Idealnego Scruma nie ma, a dążenie za wszelką cenę do ideału jest niezgodne z podstawowymi zasadami Agile, z którego się on wywodzi.

Czym jest Scrum

Scrum to zbiór zasad tworzenia nowego produktu. Można to porównać do budowania z małych klocków. Na początku planujemy jak dany klocek ma wyglądać i co ma robić. Pracę dzielimy na sprinty, czyli z góry określone interwały czasu (często 2 tygodnie) i w ciągu jednego sprintu budujemy naszą cegiełkę w całości i dołączamy ją do reszty produktu. Codziennie spotykamy się, aby omówić postęp prac i zidentyfikować potencjalne problemy. Na koniec zastanawiamy się, czy pasuje to, co udało nam się zrobić do całości. W razie potrzeby wykonujemy odpowiednie poprawki i planujemy kolejną cegiełkę. Bardzo dobrze obrazuje to poniższy rysunek.
Scrum należy do metodyk zwinnych. Czym są zwinne metodyki pracy? W trakcie prowadzenia projektu wymagania ulegają zmianom. Klient zamawia aplikacje i dopiero gdy dostanie pierwszą wersję do testów, potrafi określić co mu się podoba, a co nie. Więc wytwarza się oprogramowanie przyrostowo. Oznacz to, że dajemy jakąś funkcjonalność i później robimy kolejną i kolejną. W trakcie prac niektóre użyteczności ewoluują, a inne zostaną usunięte. Na samym końcu będziemy mieli produkt, którą klient potrzebuje, a nie którą wydawało mu się na początku, że chce.
Bardzo lubię podejście MVP (Minimum Viable Product). Polega ono na stworzeniu minimalnej działającej wersji, a później, na podstawie opinii użytkowników poprawianie i dodawanie kolejnych funkcjonalności. Scrum do tego nadaje się idealnie.

Poniżej opisałem wszystkie składowe scruma. Jeśli wolisz posłuchać, to zapraszam Cię do obejrzenia nagrania z webinaru, gdzie opowiadam o scrumie.

Różnica między Agile i Scrum

To dość proste: Agile to zbiór założeń, a Scrum stworzenie zasad działania na ich podstawie. Manifest Agile mówi o tym, aby bardziej cenić:

  • Ludzi i interakcje od procesów i narzędzi
  • Działające oprogramowanie od szczegółowej dokumentacji
  • Współpracę z klientem od negocjacji umów
  • Reagowanie na zmiany od realizacji założonego planu

Tablica Scrum

Tablica Scrumowa dość mocno przypomina tę kanbanową, jednak jest znacznie prostsza. Zwykle mamy do dyspozycji trzy kolumny:

  • To do – zadania do zrobienia
  • In progress – zadania nad którymi pracujemy
  • Done – zadania, które zostały zrobione

W zależności od potrzeb pojawia się więcej kolumn. Ja najczęściej spotykałem się z poniższymi:

  • Test – zadania w trakcie weryfikacji poprawności wykonania
  • On Hold – zadania zablokowane, np. w trakcie wykonywania pojawiły się problemy i trzeba poświęcić dodatkowy czas na analizę
  • UAT – kolumna podobna do Test, ale tu przeprowadzane są testy biznesowe
  • To deploy – zadania czekające na wdrożenie na środowisko produkcyjne

Scrum Master

Często ta rola sprowadza się do „szefowania” w zespole, gonienia wszystkich na spotkania i dodawania ich w kalendarzu. Główną rolą Scrum Mastera jest jednak wsparcie

  • Product Ownera – w zarządzani Product Backlogiem
  • wspieranie zespołu deweloperskiego – usuwając przeszkody, choćby w postaci niedziałającego środowiska testowego
  • wspieranie organizacji – pomagając zrozumieć Scruma pracownikom lub inicjując działania zwiększające produktywność zespołu

W wielu firmach w ramach „nagrody” rolę tę pełni zasłużony członek zespołu, co często doprowadza do straty dobrego dewelopera, testera lub analityka na rzecz osoby biegającej po spotkaniach i użerającej się z systemem. Podoba mi się podejście rotacyjne, gdzie rola Scrum Mastera co sprint lub dłuższy okres czasu przechodzi na kolejnego członka zespołu, choć osobiście nie miałem okazji pracować w takim trybie.

Product Owner

W dużym skrócie – to on przynosi robotę. Osoba odpowiedzialna za rozwój produktu. Niekiedy rolę Product Ownera pełni tzw. biznes – np. dział zajmujący się dostosowywaniem systemów do potrzeb firmy. Teoretycznie to jedyna osoba zarządzająca Product Backlogiem, choć w większości znanych mi przypadków pozostaje to jedynie teorią. Najczęściej spotykałem się z dwoma rodzajami Ownerów:

  • wewnątrz firmy – pracownik firmy, będący członkiem zespołu Scrumowego lub przypisanym do konkretnego produktu
  • na zewnątrz – pracownik klienta

Scrum Sprint

W Scrumie pracuje się w Sprintach – równych okresach czasu (najczęściej 1, 2 lub 4 tygodnie). Po każdym Sprincie zespół powinien dostarczyć działającą wersję produktu. Zwykle w pierwszym dniu odbywa się planowanie, a następnie realizuje się założone wtedy cele.

Scrum Planning – planowanie

Podczas planowania zespół „bierze na siebie” taski, które w trakcie Sprintu wykona. Brałem udział w bardzo różnych Scrum Planingach – wycenialiśmy zadania i na tej podstawie stwierdzaliśmy ile uda nam się zrobić lub każdy stwierdzał, które zadania zrobi podczas sprintu. Przydzielanie zadań też obywało się na różne sposoby:

  • z góry przydzielona osoba do realizacji zadania
  • kto pierwszy ten lepszy – skończyłeś zadanie, to bierzesz najwyższe na liście, które dasz radę zrobić
  • totalna samowolka

Wycena zadań

Wyceny polegają na określaniu złożoności zadań za pomocą punktów: 0, 1/2 , 1, 2, 3, 5, 8, 13, 21, 100 lub innymi podobnymi wariacjami. Powinno się wyceniać to abstrakcyjnie, czyli punkty oznaczają złożoność, więc zadanie dość proste to np. 2 punkty, a odrobinę trudniejsze już 3, za to bardzo trudne i złożone nawet 13 lub 21. Złożone zadania dobrze jest rozbijać, czyli takie wielkości 13 lub więcej dzieli się na mniejsze części tak, aby np. dwie osoby mogły podzielić się pracą. Niestety wielokrotnie taka wycena sprowadzała się do tego, że jeden dzień to 4 lub 5 punktów, co prowadziło do określania zadań wg tego ile zejdzie czasu, a nie złożoności.

Scrum Poker

Przy wycenie pojawia się też coś takiego jak Scrum Poker. To karty z punktami, które np. na „trzy-cztery” każdy rzuca określając złożoność zadania. Są one pomocne, ponieważ wtedy członkowie zespołu wymieniają się spostrzeżeniami na temat zadania. Bardziej doświadczony programista może wiedzieć o fragmencie kodu, który po użyciu znacznie uprości zadanie i rzuci 2 punkty albo tester dający kartę z liczbą 13 o większej ilości miejsc, w których omawiany mechanizm jest wykorzystywany.

Scrum Daily, Scrum Meeting

Codzienna poranna spowiedź na stojąco.

Każdego dnia o ustalonej godzinie zespół spotyka się na kilka minut, aby omówić postęp prac i ewentualne problemy. Dzięki temu wszyscy wiedzą co dzieje się w projekcie. Wielokrotnie po Daily osoba stwierdzająca problem siada do komputera z innym członkiem zespołu, który może znać rozwiązanie i razem pracują nad rozwiązaniem. Niestety to jeden z najbardziej nielubianych elementów Scruma, ja jednak uważam, że bardzo potrzebny i nie raz słyszałem o wprowadzaniu jedynie Daily z całego Scruma do kultury pracy w firmie.

Scrum Refinement

Poprzednia nazwa tego spotkania to Scrum Grooming, ale to dość negatywne określenie, więc nazwa została zmieniona – zresztą sam sprawdź. Refinement rzadko spotykałem w firmach. Podczas niego pielęgnuje się Backlog, choć najczęściej wykorzystywany jest do omawiania jednego konkretnego zagadnienia, a czasem nawet rozbicia go na mniejsze zadania i ich wyceny. Refinement to nieregularne spotkanie – organizuje się wtedy, gdy jest potrzebne.

Sprint Review

Na koniec sprintu trzeba sprawdzić co się udało i co robimy dalej. Do tego służy Review. Czasem sprowadzane jest do zwykłego demo tego, co zrobił zespół. W każdej firmie jakiej pracowałem i odbywało się Review wyglądało ono inaczej. Spotykaliśmy się ze wszystkimi zainteresowanymi osobami (np. osobami z działów zainteresowanych nową funkcjonalnością) i prezentowaliśmy (programiści każdy swoje, innym razem testerzy lub Product Owner, żeby reszta mogła schować się w kącie) co zrobiliśmy i ewentualnie rozmawialiśmy o poprawkach, zmianach lub dalszym rozwoju. Bywało też tak, że Product Owner lub inna osoba pokazywała biznesowi co zostało wykonane, a reszta unikała Review jak ognia.

Scrum Retrospective

Godzina na koniec sprintu na narzekanie lub męczenie zespołu. Tak zwykle określa się Retro. Podczas niego zwykle dąży się do usprawnienia pracy. Rozmawia się o tym, co nam pasuje, a co byśmy zmienili.

Scrum pytania rekrutacyjne

Najczęstsze pytania z jakimi spotykałem się odnośnie Scruma sprowadzały się do opisu tego jak wyglądał on w poprzedniej firmie. Czasem padło pytanie o rolę Scrum Matera lub Product Ownera albo o moje odczucia co do Daily. Dopiero startując na Tema Leadera lub Scrum Mastera otrzymywałem sporo pytań o znajomość Scruma, ale pozostałe stanowiska nie wymagały szczegółowej wiedzy, poza ogólnym pojęciem.

Powyżej przedstawiłem moje doświadczenia ze Scrumem. Zapewne wiele z nich odbiega od tego o czym mówi Scrum Guide, jednak Scrum to narzędzie, a manifest Agile głosi wyższość ludzi i interakcji nad narzędziami. Jakie są Twoje doświadczenia ze Scrumem? Podziel się w komentarzy tym, co Ci się w nim podoba, a co najchętniej wymazałbyś z historii ludzkości.

Przeczytaj więcej

Transakcja w bazach danych

Transakcja w bazach danych

Jednym z najważniejszych mechanizmów używanych w relacyjnych bazach danych są transakcje. Właściwie wszystko co robimy w bazie danych działa w oparciu o transakcje. Służą one do utrzymania integralności i pozwalają na wykonanie serii poleceń w całości.

Zapowiedź webinarów i zmian na blogu

Zapowiedź webinarów i zmian na blogu

Ostatnio dosyć często powtarzam, że chcę coraz szerzej dzielić się swoją wiedzą. Taki mam plan na 2019 rok i sukcesywnie wdrażam go w życie. Przyszła pora, aby podsumować działania, podzielić się wieściami i poinformować, w jakim kierunku będzie zmierzał ten blog.

Rozmowa rekrutacyjna – naucz się mówić o sobie!

Rozmowa rekrutacyjna – naucz się mówić o sobie!

Przychodzisz na rozmowę kwalifikacyjną. Witasz się z osobami rekrutującymi. Siadasz. Pada pierwsze polecenie: "Proszę nam opowiedzieć coś o sobie". Spotkasz je na prawie każdej rozmowie kwalifikacyjnej. W dodatku zadane zostanie najczęściej jako pierwsze przed...

0 komentarzy

0 komentarzy

Wyślij komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *