Scrum

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 on się 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 aplikację i dopiero, gdy dostanie pierwszą wersję do testów, potrafi określić, co mu się podoba, a co nie. Więc oprogramowanie wytwarza się 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órego klient potrzebuje, a nie którego 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 polega na stworzeniu zasad działania na podstawie tych założeń. 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 do kalendarza. Główną rolą Scrum Mastera jest jednak wsparcie:

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

W wielu firmach w ramach „nagrody” rolę Scrum Mastera 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ń według tego, ile minie czasu, a nie według 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ę je 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, w jakiej pracowałem, w której odbywało się Review zawsze 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 poświęcona jest 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 Mastera 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

7 powodów, dla których warto nauczyć się SQLa i baz danych

7 powodów, dla których warto nauczyć się SQLa i baz danych

Rozpoczynając swoją przygodę z IT bardzo często zastanawiamy się jakiej technologii użyć. Wybrać Javę, Pythona, a może jednak C++ lub C#. Istnieje jednak jedna technologia, która jest uniwersalna i w zasadzie każdy powinien ją znać. To bazy danych. Język SQL i wykorzystujące go relacyjne bazy danych są na tyle uniwersalne, że nie tylko specjaliści od IT powinni zagłębić się w tym temacie.

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.

0 komentarzy

0 komentarzy

Wyślij komentarz

Twój adres e-mail nie zostanie opublikowany.

Dołącz do newslettera już dziś!
Zero spamu - tylko wartościowe treści!
Musisz już lecieć?
Zostaw swój adres e-mail i dołącz do BEZPŁATNYCH WEBINARÓW dotyczących SQLa!
  • „Jak uczyć się SQLa?” – 4 października
  • „SQL dla testerów” – 12 października