Temat: kilka pytań

Hej,
Wdrażam się ostatnimi dniami w scruma. Niestety póki co tylko teoretycznie. Pojawiło się kilka pytań, może pomożecie ? :-)

1. Grupowanie 'user stories' - Przy sporym projekcie backlog produktu może mieć masę pozycji. Wydaje mi się, że priorytetyzacja czegoś takiego może być problemem. Co myślicie na temat łączenia user stories w grupy ?, których elementy bez siebie nie mają sensu. Pozwoli to na sprawniejszą priorytetyzację. Oczywiście elementy z grupy można w każdym momencie wyjać, można tam też coś dołożyć.

2. Bugi wykryte w funkcjonalnościach z poprzedniego sprintu - Bugi się zdarzają ;) Czy jeśli problem okazuje się być spory, to poprawiacie go od razu czy wrzucacie do backlogu ?

3. Zgrubna estymacja terminu wykonania - Klienci, którzy mają już w sporym stopniu zaprojektowaną funkcjonalnie aplikację, chcą często znać chociażby przybliżony termin wykonania. Jak to ładnie zrobić ?

4. Architektura i modelowanie pod funkcjonalności rozbijane na 2 sprinty - Załóżmy sytuację: w backlogu mamy dwie >powiązane< funkcjonalności: F1 i F2. F1 ma dużo wyższy priorytet dlatego planujemy ją na pierwszy sprint. F2, też jest wymagana, ale z mniejszym priorytetem i w pierwszym sprincie nie jest uwzględniania. Planując pierwszy sprint nie myślimy o F2. Bardzo ładnie tworzymy wszystko dla F1. W drugim sprincie okazuje się, że F2 wymaga ogromnych zmian w architekturze/modelu, który wykonaliśmy pod F1 oraz, że gdybyśmy zaplanowali architekturę i model pod obie funkcjonalności na raz, to mielibyśmy mniej pracy. I tu moje pytanie - czy coś można/trzeba zrobić inaczej ? czy może tak już po prostu jest ?

Z góry dzięki za wszystkie odpowiedzi.
Proszę mnie też nie krzyżować, jeśli jakieś moje pytania są z gruntu złe - dopiero się uczę ;)

Temat: kilka pytań

1. Mozna tagowac zadania, badz w user stories dodawac informacje bedaca tagiem.

2. Tak, standardowo dodawane jest do backloga i operuje sie na nim jak na normalnym user stories.

3. W takim przypadku ustala sie terminy, bedace odzwierciedleniem sprintu, badz kilku sprintow, w ktorych zostaly ukonczone zadania umozliwiajace dzialanie konkretnych funkcjonalnosci.

4. W takim przypadku nie rozbijaj F1 i F2 na 2 niezalezne sprinty, a polacz je, w 1 sprincie wiekszosc zadan z F1 i czest zadan z F2, ktore sa od siebie zalezne, a reszte sumarycznie w pozostalych, zwacajac oczywiscie uwage na zaleznosci zadan miedzy soba.

Temat: kilka pytań

Karol Traczykowski:
Hej,
Wdrażam się ostatnimi dniami w scruma. Niestety póki co tylko teoretycznie. Pojawiło się kilka pytań, może pomożecie ? :-)

1. Grupowanie 'user stories' - Przy sporym projekcie backlog produktu może mieć masę pozycji. Wydaje mi się, że priorytetyzacja czegoś takiego może być problemem. Co myślicie na temat łączenia user stories w grupy ?, których elementy bez siebie nie mają sensu. Pozwoli to na sprawniejszą priorytetyzację. Oczywiście elementy z grupy można w każdym momencie wyjać, można tam też coś dołożyć.

Grupowanie User Stories ułatwia priorytetyzację. Można grupować po "temacie" względem personas, lub funkcjonalności produktu. Każda grupa ma odpowiednia wagę.

2. Bugi wykryte w funkcjonalnościach z poprzedniego sprintu - Bugi się zdarzają ;) Czy jeśli problem okazuje się być spory, to poprawiacie go od razu czy wrzucacie do backlogu ?

Testowanie musi być częścią definicji DONE. Jeżeli znaleziony bug dotyczy aktualnego Sprint musi być naprawiony w Sprincie. Jeżeli dotyczy poprzedniego, to idzie do Product Backlog i jest priorytetyzowany przez Product Ownera. Jeżeli bud jest spory to może przekształcić się w Story.

3. Zgrubna estymacja terminu wykonania - Klienci, którzy mają już w sporym stopniu zaprojektowaną funkcjonalnie aplikację, chcą często znać chociażby przybliżony termin wykonania. Jak to ładnie zrobić ?

Trzeba zrobić Release Planning meeting oszacować zgrubnie User Stories i przeliczyć punkty używając Team Velocity. Wtedy wyjdzie Ci ilość Spritów potrzebna do wykonania tego zakresu prac (to jest Fixed Scope Planning). Można też zrobić to w druga stronę jako Fixed Schedule Planning i określić ile zrobisz do danej daty.

4. Architektura i modelowanie pod funkcjonalności rozbijane na 2 sprinty - Załóżmy sytuację: w backlogu mamy dwie >powiązane< funkcjonalności: F1 i F2. F1 ma dużo wyższy

> priorytet dlatego planujemy ją na pierwszy sprint. F2, też jest

wymagana, ale z mniejszym priorytetem i w pierwszym sprincie nie jest uwzględniania. Planując pierwszy sprint nie myślimy o F2. Bardzo ładnie tworzymy wszystko dla F1. W drugim sprincie okazuje się, że F2 wymaga ogromnych zmian w architekturze/modelu, który wykonaliśmy pod F1 oraz, że gdybyśmy zaplanowali architekturę i model pod obie funkcjonalności na raz, to mielibyśmy mniej pracy. I tu moje pytanie - czy coś można/trzeba zrobić inaczej ? czy może tak już po prostu jest ?

Jeżeli już wiesz o F2, to powinieneś to przewidzieć przy wykonywaniu F1. Zrobić architekturę jak najbardziej elastyczna, jak najwięcej elementów zrobić niezależnych. W kolejnym Sprincie przy planowaniu F2 uwzględnij re-factoring, który jest nieodzowna częścią Scrum tak jak był w XP.

Z góry dzięki za wszystkie odpowiedzi.
Proszę mnie też nie krzyżować, jeśli jakieś moje pytania są z gruntu złe - dopiero się uczę ;)

To są bardzo dobre pytania. Dobrze podchodzisz do tematu.

Temat: kilka pytań

Wielkie dzięki za odpowiedzi i rozwianie moich wątpliwości.

Krystian K.:
Dobrze podchodzisz do tematu.

Dzięki. Dobrze wiedzieć ;)Karol Traczykowski edytował(a) ten post dnia 07.04.10 o godzinie 13:01