You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Opierając się o wiele źródeł, można stwierdzić, że Backlog Refinement to jedno z najważniejszych spotkań w SCRUMie. Jednak nie wszystkie źródła traktują to spotkanie w identyczny sposób. Część opisuje to spotkanie jako moment, w którym możliwe jest dopracowanie User Stories w przypadku gdy występuje dużo placeholdersów lub niepewności. Inne źródła mówią o tym procesie jak o narzędziu, które pozwala na utrzymanie Backlogu aktualnego (np. zmiana priorytetów). Jednak większość źródeł jest zgodna: to spotkanie jest często częściowo ignorowane lub występuje w nieregularnych odstępach czasu, prowadzone bez odpowiedniej agendy i przygotowania. Podsumowując - nie ma ono w takiej formie jakiegokolwiek sensu, zabiera czas.
Jednak gdyby się zastanowić nad tym co może dostarczyć dobrze przeprowadzony Backlog Refinement w trakcie Sprintu, okazuje się, że niesie to ze sobą korzyści zarówno dla Produktu jak i Zespołu Developerskiego.
możliwość poznania zależności między zadaniami o ile takie występują
Dla Zespołu Developerskiego:
poznanie sensu biznesowego danych Stories
---
PART II
Czym grozi brak refinementu (błędne koło backlog refinementu):
brak uszczegółowienia zadań
brak realizacji celu sprintu (odejście od realizacji celu sprintu na rzecz zadań, które mogły „wskoczyć”, nie koniecznie z dobrze dobranym priorytetem)
co raz dłuższe rozmowy na retrospekcji (bo przecież chcemy robić lepiej/inaczej)
POCZUCIE PEŁNEJ MOBILIZACJI - żeby udało się dowieźć cel sprintu… nie trzeba czuć mobilizacji do działania, wystarczy wiedzieć co się robi.
CHĘĆ DZIAŁANIA - po pełnej mobilizacji do działania oraz poświęceniu czasu na „wgryzanie się” w pracę nie ma już czasu na dodatkowe spotkania (np. Refinement) oraz na zastanowienie się nad tym czy aby napewno nasz produkt dąży w dobrym kierunku.
W tym miejscu chciałbym zakończyć bardzo krótkie wprowadzenie w Backlog Refinement oraz w dalszej części dostosować „dojście” do refinementu w trakcie sprintu do realiów Code-Poets.
---
PART III
Biorąc pod uwagę aktualny workflow Code-Poets oraz SCRUMowe podejście do zarządzania projektami przy wytwarzaniu oprogramowania można w odniesieniu do wielu źródeł zaproponować poniższą ścieżkę dojścia do Backlog Refinementu.
Ogólny zbiór wymagań Produktu > Priorytetyzacja wymagań Produktu > Uszczegółowienie Backloga (Stories, Placeholders) > Sprint Planning > Sprint Execution > Backlog Refinement
Jak robić Backlog Refinement?
Kiedy?
W trakcie sprintu, w ściśle określony dzień, o stałej godzinie.
Jak długo?
Backlog Refinement powinien zabierać nie więcej jak 10% czasu trwania Sprintu.
Kto?
W różnych źródłach proponowane są różne konfiguracje personalne do przeprowadzenia refinementu, np. praca w parach senior - junior dev, product owner - senior dev, product owner - architekt.
Jak?
Tak aby Backlog był uporządkowany i spriorytetyzowany, tak aby spełnić cel sprintu
---
Code-Poets Workflow:
Powyższy opis jest zbiorem informacji pozyskanych z różnych źródeł internetowych. Aby w pełni móc korzystać ze wszystkich dobrodziejstw tego procesu, należy go dostosować do danej organizacji, specyfiki projektu/produktu.
W Code-Poets pomimo niezachowania zasady „organizowania” tego spotkania w wyznaczonym czasie, odbywa się to w sposób ciągły, tj. Continuous Backlog Refinement. Jest to bieżąca/codzienna praca nad Backlogiem. Jest to dobre podejście w projektach, które nie są w pełni wyspecyfikowane na etapie planowania lub bądź nastawione są na szybki rozwój produktu (np. Concent)
The text was updated successfully, but these errors were encountered:
Backlog Refinement - sesja doskonalenia Backlogu.
PART I
Opierając się o wiele źródeł, można stwierdzić, że Backlog Refinement to jedno z najważniejszych spotkań w SCRUMie. Jednak nie wszystkie źródła traktują to spotkanie w identyczny sposób. Część opisuje to spotkanie jako moment, w którym możliwe jest dopracowanie User Stories w przypadku gdy występuje dużo placeholdersów lub niepewności. Inne źródła mówią o tym procesie jak o narzędziu, które pozwala na utrzymanie Backlogu aktualnego (np. zmiana priorytetów). Jednak większość źródeł jest zgodna: to spotkanie jest często częściowo ignorowane lub występuje w nieregularnych odstępach czasu, prowadzone bez odpowiedniej agendy i przygotowania. Podsumowując - nie ma ono w takiej formie jakiegokolwiek sensu, zabiera czas.
Jednak gdyby się zastanowić nad tym co może dostarczyć dobrze przeprowadzony Backlog Refinement w trakcie Sprintu, okazuje się, że niesie to ze sobą korzyści zarówno dla Produktu jak i Zespołu Developerskiego.
Korzyści:
---
PART II
Czym grozi brak refinementu (błędne koło backlog refinementu):
W tym miejscu chciałbym zakończyć bardzo krótkie wprowadzenie w Backlog Refinement oraz w dalszej części dostosować „dojście” do refinementu w trakcie sprintu do realiów Code-Poets.
---
PART III
Biorąc pod uwagę aktualny workflow Code-Poets oraz SCRUMowe podejście do zarządzania projektami przy wytwarzaniu oprogramowania można w odniesieniu do wielu źródeł zaproponować poniższą ścieżkę dojścia do Backlog Refinementu.
Ogólny zbiór wymagań Produktu > Priorytetyzacja wymagań Produktu > Uszczegółowienie Backloga (Stories, Placeholders) > Sprint Planning > Sprint Execution > Backlog Refinement
Jak robić Backlog Refinement?
Kiedy?
W trakcie sprintu, w ściśle określony dzień, o stałej godzinie.
Jak długo?
Backlog Refinement powinien zabierać nie więcej jak 10% czasu trwania Sprintu.
Kto?
W różnych źródłach proponowane są różne konfiguracje personalne do przeprowadzenia refinementu, np. praca w parach senior - junior dev, product owner - senior dev, product owner - architekt.
Jak?
Tak aby Backlog był uporządkowany i spriorytetyzowany, tak aby spełnić cel sprintu
---
Code-Poets Workflow:
Powyższy opis jest zbiorem informacji pozyskanych z różnych źródeł internetowych. Aby w pełni móc korzystać ze wszystkich dobrodziejstw tego procesu, należy go dostosować do danej organizacji, specyfiki projektu/produktu.
W Code-Poets pomimo niezachowania zasady „organizowania” tego spotkania w wyznaczonym czasie, odbywa się to w sposób ciągły, tj. Continuous Backlog Refinement. Jest to bieżąca/codzienna praca nad Backlogiem. Jest to dobre podejście w projektach, które nie są w pełni wyspecyfikowane na etapie planowania lub bądź nastawione są na szybki rozwój produktu (np. Concent)
The text was updated successfully, but these errors were encountered: