Retrospektywa: Różnice pomiędzy wersjami
Z Encyklopedia Zarządzania
(LinkTitles.) |
m (cleanup bibliografii i rotten links) |
||
| (Nie pokazano 12 wersji utworzonych przez 2 użytkowników) | |||
| Linia 1: | Linia 1: | ||
'''Retrospektywa''' (należy do podstawowych spotkań [[Scrum|scrumowych]]) - jest okazją do sprawdzenia i dostosowania procesu działania [[Zespół projektowy|zespołu]]. | |||
Jest to 1-3 godz. spotkanie z podziałem czasu (w zależności od długości [[Sprint|sprintu]]) prowadzone przez [[Scrum master|Scrum Mastera]], podczas spotkania cały [[zespół]] omawia zakończony [[Sprint|Sprint]] i określa, co można zmienić, co może sprawić, żeby następny sprint był bardziej skuteczny lub produktywny [Scruminc, 2012]. | |||
[[Manifest Agile|Agile Manifesto]] sugeruje, że "zespół zastanawia się, jak stać się bardziej skutecznym" [Agile Manifesto, 2001]. | |||
==TL;DR== | |||
Retrospektywa jest spotkaniem zespołu projektowego po zakończonym sprincie, mającym na celu ocenę procesu pracy i znalezienie sposobów na jego ulepszenie. Spotkanie składa się z kilku etapów, w których zespół analizuje wykonaną pracę, identyfikuje problemy i podejmuje decyzje dotyczące poprawek. Retrospektywa ma na celu ciągłe doskonalenie pracy zespołu. Ważne jest skupienie się na wartości biznesowej i konkretnych działaniach, które poprawią efektywność zespołu. | |||
==Cel retrospektywy== | ==Cel retrospektywy== | ||
Po zakończeniu iteracji zwykle odbywają się dwa spotkania: | |||
Po zakończeniu iteracji zwykle odbywają się dwa spotkania: | |||
* '''[[Przegląd sprintu|Sprint Review]]''' - [[przegląd]] sprintu (lub demo), koncentruje się na uzyskiwaniu informacji zwrotnej o produkcie i omawianiu sposobu postępowania | * '''[[Przegląd sprintu|Sprint Review]]''' - [[przegląd]] sprintu (lub demo), koncentruje się na uzyskiwaniu informacji zwrotnej o produkcie i omawianiu sposobu postępowania | ||
* '''Retrospective''' - retrospektywa, koncentruje się na zespole i procesach używanych dla dostarczania oprogramowania. | * '''Retrospective''' - retrospektywa, koncentruje się na zespole i procesach używanych dla dostarczania oprogramowania. | ||
'''Celem retrospektyw''' jest pomaganie zespołom w ciągłym ulepszaniu ich pracy. Zwinna retrospektywa, w Scrumie, jest praktyką stosowaną przez zespoły do refleksji na temat sposobu pracy i ciągłego doskonalenia się w tym, co robią. | '''Celem retrospektyw''' jest pomaganie zespołom w ciągłym ulepszaniu ich pracy. Zwinna retrospektywa, w Scrumie, jest praktyką stosowaną przez zespoły do refleksji na temat sposobu pracy i ciągłego doskonalenia się w tym, co robią. | ||
Szczegółowe [[cele]] dla retrospektyw są następujące: | Szczegółowe [[cele]] dla retrospektyw są następujące: | ||
* Znalezienie sposoby na ulepszenie używanych praktyk | * Znalezienie sposoby na ulepszenie używanych praktyk | ||
* Odkrycie, co jest robione dobrze | * Odkrycie, co jest robione dobrze | ||
* Zapoznanie się z przyczynami nieudanych celów | * Zapoznanie się z przyczynami nieudanych celów | ||
* Znalezienie sposoby na poprawę reakcji zespołu na klientów | * Znalezienie sposoby na poprawę reakcji zespołu na klientów | ||
* Odbudowanie uszkodzonych relacji [Derby E., Larsen D. 2006, s. 17] | * Odbudowanie uszkodzonych relacji [Derby E., Larsen D. 2006, s. 17] | ||
<google>n</google> | |||
==Układ retrospektywy== | ==Układ retrospektywy== | ||
Układ retrospektywy zależy od: | Układ retrospektywy zależy od: | ||
* Długości iteracji | * Długości iteracji | ||
* Złożoności (technologii, relacje z zewnętrznymi działami, [[organizacja]] zespołu) | * Złożoności (technologii, relacje z zewnętrznymi działami, [[organizacja]] zespołu) | ||
* Rozmiaru zespołu | * Rozmiaru zespołu | ||
* Poziomu konfliktu lub kontrowersji [Derby E., Larsen D. 2006, s. 17] | * Poziomu konfliktu lub kontrowersji [Derby E., Larsen D. 2006, s. 17] | ||
Przykładowy podział czasu przy retrospektywie: | |||
Przykładowy podział czasu przy retrospektywie: | * ''Set the stage (Przygotuj się) 5%'' | ||
* ''Set the stage (Przygotuj się) 5%'' | |||
Ustawienie sceny (przygotowanie) wymaga powitania i wyjaśnienia celu spotkania. | Ustawienie sceny (przygotowanie) wymaga powitania i wyjaśnienia celu spotkania. | ||
* ''Gather data (Zbierz [[dane]]) 30-50%'' | * ''Gather data (Zbierz [[dane]]) 30-50%'' | ||
Gromadzenie danych dotyczy pracy w ostatnim sprincie. Dla podjęcia decyzji w kierunku polepszenia pracy zespołu niezbędnym jest opis zdarzeń w sprincie. | Gromadzenie danych dotyczy pracy w ostatnim sprincie. Dla podjęcia decyzji w kierunku polepszenia pracy zespołu niezbędnym jest opis zdarzeń w sprincie. | ||
* ''Generate insights (Wygeneruj spostrzeżenia) 20-30%'' | * ''Generate insights (Wygeneruj spostrzeżenia) 20-30%'' | ||
Jest czasem na przemyślenie, znalezienie przyczynowo-skutkowego związku pomiędzy zdarzeniami. | Jest czasem na przemyślenie, znalezienie przyczynowo-skutkowego związku pomiędzy zdarzeniami. | ||
* ''Decide what to do (Zdecyduj, co zrobić) 15-20%'' | * ''Decide what to do (Zdecyduj, co zrobić) 15-20%'' | ||
Decydujemy co chcemy zrobić z występującymi problemami. | Decydujemy co chcemy zrobić z występującymi problemami. | ||
* ''Close the retrospective (Zamknij retrospektywę) 10%'' | * ''Close the retrospective (Zamknij retrospektywę) 10%'' | ||
Zamykanie spotkania jest wyciągnięciem wniosków i czasem na ocenę skuteczności właśnie retrospektywy. | Zamykanie spotkania jest wyciągnięciem wniosków i czasem na ocenę skuteczności właśnie retrospektywy. | ||
* ''Shuffle time (Czas dodatkowy) 10-15%'' | * ''Shuffle time (Czas dodatkowy) 10-15%'' | ||
Dodatkowy czas jest potrzebny, aby objąć wszystkie fazy. Ludzie potrzebują czasu, dla przejścia z jednej czynności do drugiej | Dodatkowy czas jest potrzebny, aby objąć wszystkie fazy. Ludzie potrzebują czasu, dla przejścia z jednej czynności do drugiej [Derby E., Larsen D. 2006, s. 19; Andriyani Y., Hoda R., Amor R. 2017, s. 15] | ||
*1. '''Co zrobiliśmy dobrze?''' | Z zespołem, który jest nowy w retrospektywach, można skorzystać z ''czterech kluczowych pytań'', które zdefiniował Norman Kerth: | ||
* 1. '''Co zrobiliśmy dobrze?''' | |||
Podejście skoncentrowane na rozwiązaniach, opartych na sile. Musimy podkreślać udane czynności w zespole. | Podejście skoncentrowane na rozwiązaniach, opartych na sile. Musimy podkreślać udane czynności w zespole. | ||
*2. '''Czego się nauczyliśmy?''' | * 2. '''Czego się nauczyliśmy?''' | ||
Uświadamia ludziom, że aby stać się lepszymi, będą musieli się uczyć. | Uświadamia ludziom, że aby stać się lepszymi, będą musieli się uczyć. | ||
*3. '''Co powinniśmy zrobić inaczej?''' | * 3. '''Co powinniśmy zrobić inaczej?''' | ||
Zachęca członków zespołu do szukania rzeczy, które chcą zmienić. Często pomaga to ułatwić dyskusję, dowiedzieć się, dlaczego trzeba zmienić [[proces]] i zbudować wspólne zrozumienie i zaangażowanie w działania, które zespół wykona. | Zachęca członków zespołu do szukania rzeczy, które chcą zmienić. Często pomaga to ułatwić dyskusję, dowiedzieć się, dlaczego trzeba zmienić [[proces]] i zbudować wspólne zrozumienie i zaangażowanie w działania, które zespół wykona. | ||
*4. '''Co nadal nas wstrzyma?''' | * 4. '''Co nadal nas wstrzyma?''' | ||
Może ujawniając rzeczy, które poprzednio były niewypowiedziane [Gonçalves L., Linders B. 2013, s. 8-9] | Może ujawniając rzeczy, które poprzednio były niewypowiedziane [Gonçalves L., Linders B. 2013, s. 8-9] | ||
==Wartość biznesowa a Retrospektywa== | ==Wartość biznesowa a Retrospektywa== | ||
Kilka rzeczy, które można zrobić w czasie retrospektywy, aby podnieść [[wartość]] biznesową: | Kilka rzeczy, które można zrobić w czasie retrospektywy, aby podnieść [[wartość]] biznesową: | ||
* Uświadomienie zespołowi, że szukamy działań, które mogą wzmocnić zespół | * Uświadomienie zespołowi, że szukamy działań, które mogą wzmocnić zespół | ||
* Skupić się na uczeniu się i zrozumieniu zamiast obciążenia odpowiedzialnością | * Skupić się na uczeniu się i zrozumieniu zamiast obciążenia odpowiedzialnością | ||
* Ograniczenie liczby problemów i przedmiotów, które omawiasz w czasie retrospektywy. Lepiej mieć kilka działań wysokiej jakości, niż wiele z ryzykiem, że nie zostaną wykonane. Warto zmienić tylko jedną rzecz na raz. | * Ograniczenie liczby problemów i przedmiotów, które omawiasz w czasie retrospektywy. Lepiej mieć kilka działań wysokiej jakości, niż wiele z ryzykiem, że nie zostaną wykonane. Warto zmienić tylko jedną rzecz na raz. | ||
* Skoncentrowanie na jasno zdefiniowanych problemach i pomoc zespołom znaleźć działania usprawniające, które są dla nich ważne,aby ich działalność była lepsza. | * Skoncentrowanie na jasno zdefiniowanych problemach i pomoc zespołom znaleźć działania usprawniające, które są dla nich ważne,aby ich działalność była lepsza. | ||
* Użycie analizy przyczyn źródłowych, aby znaleźć przyczyny problemów. Następnie określenie działania, aby zapobiec ich ponownemu występowaniu. | * Użycie analizy przyczyn źródłowych, aby znaleźć przyczyny problemów. Następnie określenie działania, aby zapobiec ich ponownemu występowaniu. | ||
* Kontynuacja i [[ocena]] postępów działań, aby pomóc zespołowi zrozumieć, dlaczego niektóre działania zadziałały, a inne nie i sprawienie, by postęp był widoczny. | * Kontynuacja i [[ocena]] postępów działań, aby pomóc zespołowi zrozumieć, dlaczego niektóre działania zadziałały, a inne nie i sprawienie, by postęp był widoczny. | ||
* Użycie różnych ćwiczeń w retrospektywach w zależności od problemów, sposobu myślenia zespołu itp [Gonçalves L., Linders B. 2013, s. 3-4]. | * Użycie różnych ćwiczeń w retrospektywach w zależności od problemów, sposobu myślenia zespołu itp [Gonçalves L., Linders B. 2013, s. 3-4]. | ||
{{infobox5|list1={{i5link|a=[[Metodyka Extreme Programming]]}} — {{i5link|a=[[Backlog produktu]]}} — {{i5link|a=[[RACI]]}} — {{i5link|a=[[Daily scrum]]}} — {{i5link|a=[[Feature-Driven Development]]}} — {{i5link|a=[[Cykl Deminga]]}} — {{i5link|a=[[Sprint]]}} — {{i5link|a=[[Facylitacja]]}} — {{i5link|a=[[Metody szkoleń]]}} }} | |||
==Bibliografia== | ==Bibliografia== | ||
* Agile Manifesto (2001), ''[ | <noautolinks> | ||
* Andriyani Y., Hoda R., Amor R. (2017), '' | * Agile Manifesto (2001), ''[https://agilemanifesto.org/principles.html Principles behind the Agile Manifesto]'' | ||
* Derby E., Larsen D. (2006), ''[ | * Andriyani Y., Hoda R., Amor R. (2017), ''Reflection in Agile Retrospectives'', University of Auckland, New Zealand | ||
* Derby E., Larsen D. (2006), ''[https://agile.2ia.net/Agile%20Retrospectives.pdf Agile Retrospectives Making Good Teams Great]'', Pragmatic Bookshelf, USA | |||
* Gonçalves L., Linders B. (2013), ''[https://www.benlinders.com/wp-content/uploads/gettingvalueoutofagileretrospectives-sample-Leanpub-V10.pdf Getting Value out of Agile Retrospectives]'', Leanpub | * Gonçalves L., Linders B. (2013), ''[https://www.benlinders.com/wp-content/uploads/gettingvalueoutofagileretrospectives-sample-Leanpub-V10.pdf Getting Value out of Agile Retrospectives]'', Leanpub | ||
* Scruminc (2012), ''[https://www.scruminc.com/wp-content/uploads/2014/05/Three-Steps-to-an-Effective-Retrospective.pdf 3 Steps to an Effective Retrospective ]'' | * Scruminc (2012), ''[https://www.scruminc.com/wp-content/uploads/2014/05/Three-Steps-to-an-Effective-Retrospective.pdf 3 Steps to an Effective Retrospective]'' | ||
</noautolinks> | |||
{{a|Serhiienko Maiia}} | {{a|Serhiienko Maiia}} | ||
[[Kategoria:Techniki zwinne]] | |||
{{#metamaster:description|Retrospektywa - spotkanie scrumowe, podczas którego zespół projektowy analizuje zakończony sprint i planuje ulepszenia. Manifest Agile zachęca zespół do stałego doskonalenia.}} | |||
Aktualna wersja na dzień 23:25, 9 gru 2023
Retrospektywa (należy do podstawowych spotkań scrumowych) - jest okazją do sprawdzenia i dostosowania procesu działania zespołu. Jest to 1-3 godz. spotkanie z podziałem czasu (w zależności od długości sprintu) prowadzone przez Scrum Mastera, podczas spotkania cały zespół omawia zakończony Sprint i określa, co można zmienić, co może sprawić, żeby następny sprint był bardziej skuteczny lub produktywny [Scruminc, 2012].
Agile Manifesto sugeruje, że "zespół zastanawia się, jak stać się bardziej skutecznym" [Agile Manifesto, 2001].
TL;DR
Retrospektywa jest spotkaniem zespołu projektowego po zakończonym sprincie, mającym na celu ocenę procesu pracy i znalezienie sposobów na jego ulepszenie. Spotkanie składa się z kilku etapów, w których zespół analizuje wykonaną pracę, identyfikuje problemy i podejmuje decyzje dotyczące poprawek. Retrospektywa ma na celu ciągłe doskonalenie pracy zespołu. Ważne jest skupienie się na wartości biznesowej i konkretnych działaniach, które poprawią efektywność zespołu.
Cel retrospektywy
Po zakończeniu iteracji zwykle odbywają się dwa spotkania:
- Sprint Review - przegląd sprintu (lub demo), koncentruje się na uzyskiwaniu informacji zwrotnej o produkcie i omawianiu sposobu postępowania
- Retrospective - retrospektywa, koncentruje się na zespole i procesach używanych dla dostarczania oprogramowania.
Celem retrospektyw jest pomaganie zespołom w ciągłym ulepszaniu ich pracy. Zwinna retrospektywa, w Scrumie, jest praktyką stosowaną przez zespoły do refleksji na temat sposobu pracy i ciągłego doskonalenia się w tym, co robią.
Szczegółowe cele dla retrospektyw są następujące:
- Znalezienie sposoby na ulepszenie używanych praktyk
- Odkrycie, co jest robione dobrze
- Zapoznanie się z przyczynami nieudanych celów
- Znalezienie sposoby na poprawę reakcji zespołu na klientów
- Odbudowanie uszkodzonych relacji [Derby E., Larsen D. 2006, s. 17]
Układ retrospektywy
Układ retrospektywy zależy od:
- Długości iteracji
- Złożoności (technologii, relacje z zewnętrznymi działami, organizacja zespołu)
- Rozmiaru zespołu
- Poziomu konfliktu lub kontrowersji [Derby E., Larsen D. 2006, s. 17]
Przykładowy podział czasu przy retrospektywie:
- Set the stage (Przygotuj się) 5%
Ustawienie sceny (przygotowanie) wymaga powitania i wyjaśnienia celu spotkania.
- Gather data (Zbierz dane) 30-50%
Gromadzenie danych dotyczy pracy w ostatnim sprincie. Dla podjęcia decyzji w kierunku polepszenia pracy zespołu niezbędnym jest opis zdarzeń w sprincie.
- Generate insights (Wygeneruj spostrzeżenia) 20-30%
Jest czasem na przemyślenie, znalezienie przyczynowo-skutkowego związku pomiędzy zdarzeniami.
- Decide what to do (Zdecyduj, co zrobić) 15-20%
Decydujemy co chcemy zrobić z występującymi problemami.
- Close the retrospective (Zamknij retrospektywę) 10%
Zamykanie spotkania jest wyciągnięciem wniosków i czasem na ocenę skuteczności właśnie retrospektywy.
- Shuffle time (Czas dodatkowy) 10-15%
Dodatkowy czas jest potrzebny, aby objąć wszystkie fazy. Ludzie potrzebują czasu, dla przejścia z jednej czynności do drugiej [Derby E., Larsen D. 2006, s. 19; Andriyani Y., Hoda R., Amor R. 2017, s. 15]
Z zespołem, który jest nowy w retrospektywach, można skorzystać z czterech kluczowych pytań, które zdefiniował Norman Kerth:
- 1. Co zrobiliśmy dobrze?
Podejście skoncentrowane na rozwiązaniach, opartych na sile. Musimy podkreślać udane czynności w zespole.
- 2. Czego się nauczyliśmy?
Uświadamia ludziom, że aby stać się lepszymi, będą musieli się uczyć.
- 3. Co powinniśmy zrobić inaczej?
Zachęca członków zespołu do szukania rzeczy, które chcą zmienić. Często pomaga to ułatwić dyskusję, dowiedzieć się, dlaczego trzeba zmienić proces i zbudować wspólne zrozumienie i zaangażowanie w działania, które zespół wykona.
- 4. Co nadal nas wstrzyma?
Może ujawniając rzeczy, które poprzednio były niewypowiedziane [Gonçalves L., Linders B. 2013, s. 8-9]
Wartość biznesowa a Retrospektywa
Kilka rzeczy, które można zrobić w czasie retrospektywy, aby podnieść wartość biznesową:
- Uświadomienie zespołowi, że szukamy działań, które mogą wzmocnić zespół
- Skupić się na uczeniu się i zrozumieniu zamiast obciążenia odpowiedzialnością
- Ograniczenie liczby problemów i przedmiotów, które omawiasz w czasie retrospektywy. Lepiej mieć kilka działań wysokiej jakości, niż wiele z ryzykiem, że nie zostaną wykonane. Warto zmienić tylko jedną rzecz na raz.
- Skoncentrowanie na jasno zdefiniowanych problemach i pomoc zespołom znaleźć działania usprawniające, które są dla nich ważne,aby ich działalność była lepsza.
- Użycie analizy przyczyn źródłowych, aby znaleźć przyczyny problemów. Następnie określenie działania, aby zapobiec ich ponownemu występowaniu.
- Kontynuacja i ocena postępów działań, aby pomóc zespołowi zrozumieć, dlaczego niektóre działania zadziałały, a inne nie i sprawienie, by postęp był widoczny.
- Użycie różnych ćwiczeń w retrospektywach w zależności od problemów, sposobu myślenia zespołu itp [Gonçalves L., Linders B. 2013, s. 3-4].
| Retrospektywa — artykuły polecane |
| Metodyka Extreme Programming — Backlog produktu — RACI — Daily scrum — Feature-Driven Development — Cykl Deminga — Sprint — Facylitacja — Metody szkoleń |
Bibliografia
- Agile Manifesto (2001), Principles behind the Agile Manifesto
- Andriyani Y., Hoda R., Amor R. (2017), Reflection in Agile Retrospectives, University of Auckland, New Zealand
- Derby E., Larsen D. (2006), Agile Retrospectives Making Good Teams Great, Pragmatic Bookshelf, USA
- Gonçalves L., Linders B. (2013), Getting Value out of Agile Retrospectives, Leanpub
- Scruminc (2012), 3 Steps to an Effective Retrospective
Autor: Serhiienko Maiia
