Scrum w pigułce cz. 2


Jak wcześniej obiecywałem dziś publikuję drugą część Scrum w pigułce. Jak już wiemy Scrum jest najczęściej wykorzystywaną metodyka Agile dlatego staram się wam przybliżyć jego najważniejsze elementy. W tym poście omówimy:

  • sprinty,
  • rejestr zaległości w sprincie,
  • dokumentacja w Scrum,
  • najczęstsze problemy w Scrum
  • i inne

scrum1

1.  Spotkanie planujące sprint

Często nie przykładamy się bądź też nie przykładamy dużej wagi do spotkań, a to one inicjują najważniejsze rzeczy w projekcie. Spotkania w Scrum:

  • służą przekazaniu wizji i jest ograniczone czasowo do 8 godzin
  • określenie listy zaległości produktowych (4h)
  • szacowanie nakładu pracy każdej zaległości
  • przygotowanie zaległości sprintu (4h)
  • przyjęcie zobowiązania przez zespół

2.  Rejestr zaległości sprintu

Co to jest sprint backlog i co zawiera:

  • lista zadań, które powodują przekształcenie zaległości produktowych w zbywalny produkt
  • zadania są szacowane w godzinach i przydzielane członkom zespołu w czasie trwania sprintu

3.  Sprint

Sprint i wszystko co chcecie o nim wiedzieć:

  • 14-30 dni kalendarzowych
  • lista zobowiązań jest „zamrażana”
  • zespół jest izolowany od czynników zewnętrznych i całkowicie sam sobą zarządza
  • właściciel produktu powinien być dostępny dla zespołu aby udzielać wyjaśnień
  • praktyka „sashimi
  • zbieranie wymagań, analiza, projektowanie, kodowanie, testowanie i tworzenie dokumentacji odbywa się w każdym sprincie i widoczne jest w każdym przyroście funkcjonalności
  • wewnętrzne artefakty (modele UML, wymagania, itp.) nie są nigdy pokazywane udziałowcom

4.  Codzienne spotkanie Scrum

Codzienne spotkania dobrze organizują pracę krótkoterminową warto wiedzieć gdzie “są” poszczególni członkowie zespołu.

  • 15 minut każdego rana
  • 3-5 pytań skierowanych do każdego członka zespołu (przejrzystość w zespole)

1. co zrobiłeś od ostatniego spotkania?

2. czym teraz będziesz się zajmować?

3. czy coś cię blokuje w osiągnięciu celu?

4. czy powinniśmy coś dodać do listy zadań?

5. czy nauczyłeś się czegoś o czym powinni wiedzieć inni członkowie zespołu?

5. Zakończenie sprintu

Spotykamy się również na koniec sprintów aby podsumować pracę zespołu, poniżej przedstawiam co podczas takich spotkań powinno się wydarzyć.

Spotkanie przeglądu sprintu (4h)

  • zaprezentowanie wykonanej funkcjonalności
  • zespół nie powinien przygotowywać się do prezentacji dłużej niż godzinę
  • funkcjonalność która nie jest wykonana nie może być zaprezentowana
  • pod koniec spotkania właściciel produktu odpowiada na pytania, wrażenia, pożądane zmiany, itp.
  • modyfikacja i rearanżacja zaległości produktowych

Retrospektywne spotkanie zespołu (3h)

  • co poszło dobrze podczas ostatniego sprintu?
  • co poszło źle?
  • co chcemy zacząć robić?
  • co robimy niepotrzebnie?

Scrum master wykorzystuje te informacje aby w przyszłości ułatwić pracę zespołu

 

Wszyscy docenią Scruma, bowiem opisuje on dokładnie to, co robimy, gdy zostaniemy przyparci do
                                                                                 Jim Coplien

(The Scrum Guide, Ken Schwaber, Jeff Sutherland)

 

6. SCRUM – dokumentacja

Dokumentacja we wszystkich projektach zwinnych jest dość uboga ale mięsista. Podobnie jest w przypadku Scrum. Poniżej najprostsza dokumentacja w projekcie prowadzona Scrumem

  • Rejestr zadań (Product backlog)
    • Historyjki klienta (User stories)
      • Must be
      • Should be
      • Nice to have
  • Rejestr zadań przebiegu (Sprint product backlog)
  • Wykres spalania (Burn down) – wykres pracochłonności

scrum2

7. Scrum nie jest:

  • magiczną różdżką, nie uzdrawia cudownie, nie leczy arogancji, ignorancji, lenistwa i wiary w cuda – powoduje natomiast, że wszystkie te problemy stają się bardzo, bardzo widoczne
  • Scrum nie jest metodyką która mówi jak wytwarzać lepsze produkty
  • Scrum nie odpowiada na pytanie jak należy produkować oprogramowanie wyższej jakości, lepiej, szybciej
  • Scrum (jak wszystkie zwinne metody) bazuje na postulacie, że nie istnieje meta–rozwiązanie dla produkcji oprogramowania
  • możliwe jest jedynie zdefiniowanie ram w obrębie których stosowane procesy i narzędzia będą empirycznie doskonalone
  • Scrum jest modelem koncepcyjnym, narzędziem, które pomaga ustalić co jest przeszkodą w produkowaniu oprogramowania o wyższej jakości, lepiej, szybciej

8. To jaki jest SCRUM

Scrum jest łatwy i intuicyjny, i jednocześnie niezwykle trudny do opanowania.

9. Test charakteru całej organizacji

Zwykle, gdy ktoś usuwa jeden z podstawowych elementów Scruma, robi tak ponieważ element ten obnaża aspekty rzeczywistości których nikt nie chce zauważać.

Ken Schwaber

10. Najczęstsze problemy

  • Przyrost nie jest wykonany w sposób kompleksowy, w związku z czym postęp prac nie jest klarowny
  • Dług technologiczny się kumuluje ponieważ przyrosty nie są w pełni zakończone
  • Zespoły nie są interdyscyplinarne
  • Zespoły nie są samoorganizujące się
  • Zespołom przerywa się pracę w Sprintach
  • Data ukończenia i zakres prac są w dalszym ciągu używane łącznie i traktowane jako niezmienne

11. Na zakończenie

  • Zalety Scrum
    • samozarządzanie zespołu
    • Przejrzystość – wiesz gdzie jest projekt, gdzie ty w projekcie, gdzie inni
    • ramy czasowe – nic nie jest przeciągane w nieskończoność, skupienie na zadaniu a nie na bzdurach/pogaduszkach
    • komunikacja twarzą w twarz
    • właściciel produktu nie musi być informatykiem
    • Scrum dobrze działa w połączeniu z eXtreme Programming (XP)
  • Ale
    • Scrum nie jest złotym środkiem
    • Scrum najlepiej sprawdza się dla projektów o wysokim ryzyku i niepewności
    • Zespół musi pracować w jednym miejscu (codzienne spotkania)

scrum3


Dodaj komentarz