W metodyce zwinnej, jaką jest Scrum, retrospekcja jest spotkaniem, na którym podsumowujemy Sprint i wyciągamy wnioski w celu usprawnienia pracy zespołu w przyszłości. W dzisiejszym wpisie przeczytasz o tym, jak ważne jest wyciąganie wniosków, nauka na błędach i poświęcenie czasu na to, by podsumować swoje wyniki. Spokojnie, nie o życiu a o testowaniu będzie mowa :), choć, w jednym i drugim wyciąganie wniosków jest kluczowe, by się rozwijać i iść do przodu. Nie jest to też wpis, tylko i wyłącznie o retrospekcji jako spotkaniu w Scrumie, ale o tym, że wyciągać wnioski warto nawet samemu dla siebie.
Retrospekcja to:
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)
Po co pisać o wyciąganiu wniosków, skoro naturalnie uczymy się na błędach?
Zapewniam Cię, że w przypadku wytwarzania oprogramowania robienie podsumowania pracy nie jest to takie naturalne. Chcielibyśmy, aby tak było, ale rzeczywistość jest taka, że wiele projektów jest robiona w dużym pośpiechu. Pośpiech powoduje, że rezygnuje się z rzeczy na pozór zbędnych a zajmujących czas. Zespół jest eksploatowany do granic możliwości. Nie ma czasu na zastanowienie się, zaplanowanie pracy, a tym bardziej wyciąganie wniosków po zamknięciu Sprintu.
Cytując jeden z popularniejszych memów ostatnich czasów „Planowanie i Analiza są dla zarządu Panie Areczku, dla Pana jest komputer, myszka i 8h pracy”.
Człowiek uczy się na błędach.
Tylko czy naukę wyciągamy po jednym błędzie, czy wielu takich samych? W życiu zabiegani, przemęczeni pracą, również zwlekamy z wyciąganiem wniosków, bo zwyczajnie nie robimy nawet podsumowania.
Dlaczego wyciąganie wniosków jest takie ważne?
Jeżeli oficjalne źródła, które część ludzi bagatelizuje, jak i te nieoficjalne, które czytasz w Internecie, mówią, że to istotna część procesu wytwarzania oprogramowania, to jednak tak chyba jest. Tymczasem znam przypadki, kiedy zespół świadomie z tego typu inicjatyw rezygnował, bo przecież dobrze pracował 😉.
Co może Ci dać możliwość wyciągnięcia wniosku?
Kojarzysz powiedzenie „mądry Polak po szkodzie”? Jeżeli tak, to warto przesunąć to powiedzenie ciut wcześniej i zmienić na „mądry Polak przed szkodą”. Uczmy się na własnych błędach i starajmy się ich nie popełniać ponownie.
Optymalizacja tego, co robimy, jest naprawdę istotna!
Często słyszę od kursantów pytania „Jak mogę się rozwinąć?”, „Co mogę zrobić, żeby być lepszym testerem?”. Zwykle odpowiadam na nie w podobny sposób — zacznij od analizy tego, co Ci nie wychodzi i postaraj się poprawić te obszary, a dopiero potem poszerzaj swoją wiedzę o kolejne obszary.
Z czasem zobaczysz, że możesz powiedzieć, jestem dobry w tym i tym, czas zacząć uczyć się tego.
Czy sam staram się dokonywać takiej analizy?
Oczywiście! Robię to, przede wszystkim czerpiąc z dwóch rzeczy:
- Retrospekcja – bardzo cenne spotkanie w metodyce Scrum, które pozwala na podsumowanie cyklu wytwarzania oprogramowania poprzez spisanie wszystkich dobrych i złych rzeczy w tym również tych, które sam w jakiś sposób nie dowiozłem. I tak bywa, że na retrospekcji słyszę uwagi do mojej pracy. Nie obrażam się, bo to nic nie daje, zamiast tego staram się obiektywnie ocenić, czy uwaga ma sens i jeśli tak, to wdrażam zmiany w sposobie mojej pracy.
- Root cause analysis, o którym możesz poczytać tu: https://akademiaecoms.pl/rca-root-cause-analysis-jakie-ma-zastosowanie/
Mam nadzieję, że wpis się podobał – zwłaszcza że trochę sobie pofolgowałem z nie pisaniem przez długi czas😊.
