Cześć! Dzisiaj kolejny wpis o spotkaniach w Scrumie. Na moim blogu znaleźć możesz już teksty dotyczące Sprint Review oraz ogólny wpis dotyczący pracy testera w Scrumie. Dzisiaj spróbuję wyjaśnić Ci, czym jest Retrospekcja i dlaczego jest tak ważna (przynajmniej moim zdaniem). Wpis ten jest też odpowiedzią na pytania, jakie dostaję od was. No to zaczynamy :).
Co to jest Retrospekcja?
Jest to spotkanie, w którym udział bierze cały Zespół Scrumowy (Zespół Developerski, Scrum Master i Product Owner), i podczas którego analizuje się sposób pracy zespołu podczas dobiegającego końca sprintu. Celem jest zastanowienie się w jaki sposób pracę tą można by było usprawnić w przyszłości.
żródło Codesprinters – Agile Experts (scrum.org.pl)
Najważniejsze kwestie, jakie powinieneś wiedzieć, jeżeli chodzi o Retrospekcję
- Jest to spotkanie cykliczne, czyli odbywa się regularnie dokładniej raz w Sprincie na sam jego koniec. Jest to spotkanie skierowane do całego zespołu.
- Celem retrospekcji jest spojrzenie z perspektywy całego sprintu i wyłuskanie plusów i minusów odnośnie do pracy całego zespołu. Uwagi dawane w trakcie Retrospekcji mogą być personalne, np. Tester Wojtek super coś przetestował, jak i ogólne np. „Nowe narzędzie do pisania test case bardzo ułatwiło nam życie!”. Oczywiście minusy również mogą być personalne, jak i ogólne 😉
- Do otrzymanych w ramach Retrospekcji uwag mamy podejść jak do możliwości rozwoju tak osobistego, jak i również zespołowego.
- W trakcie kolejnego spotkania tego typu powinien się znaleźć czas na nawiązanie do uwag z poprzedniego spotkania. Wszystko po to, by sprawdzić, czy udało nam się rozwiązać problemy z poprzedniego sprintu.
Częste błędy w czasie Retrospekcji
Brak przygotowania do Retrospekcji
Głównym błędem popełnianym podczas tego spotkania jest brak przygotowania uczestników. Pamiętaj, że Sprint w Scrumie może trwać od dwóch tygodni do aż czterech. Zadaj sam sobie pytanie, czy jesteś w stanie teraz wymienić wszystko to, co było ok i nie ok w ciągu ostatnich dwóch tygodni?
Moim sposobem na podejście do Retro jest spisywanie sobie plusów i minusów w dokumencie, który odkładam sobie na dysku aż do czasu spotkania :).
Obawa, że skarżymy
Drugim błędem jest zatajanie informacji, ponieważ nie lubimy „skarżyć”. Nauczeni od dziecka wiemy, że nie są lubiane osoby, które skarżą. Tymczasem w Retrospekcji nie o skarżenie chodzi a o to by były zmiany na lepsze. Bez świadomości, że coś nie działa, nic nie zrobimy.
Pamiętaj, że jeżeli się nie powie o problemie, to on wcale nie znika. W najgorszym przypadku może on w pewnym momencie do Ciebie wrócić jak bumerang i narobić Ci kłopotów. Dodatkowo robisz też krzywdę osobie, która popełniła błąd, bo nie wie, że powinna coś poprawić.
Na początku tego wpisu znajdziesz regułkę, zgodnie z którą w Retrospekcji uczestniczy Product Owner. Z mojej praktyki wynika, że często nie robi się spotkania z Product Ownerem, ponieważ ludzie mają obawy do rozmawiania otwarcie przy kliencie. Jeżeli klient nalega na uczestniczenie, to często robi się dwa spotkania — wewnętrzne i zewnętrzne.
Ostatnia moja sugestia odnośnie do spotkania – pamiętaj, że nie warto zaspamować Scrum mastera pierdołami, a czasami mamy taką tendencję do odkładania nawet najmniejszych plusów, jak i minusów. Sam podchodzę do tego tak, że wybieram do trzech najważniejszych moim zdaniem plusów i minusów z mojej listy.
