Temat: Zależność między historyjkami biznesowymi.

Czy w scrumie jest zasada, że nie bierze się do jednego sprintu historyjek biznesowych zależnych od siebie? Np. są 3 historyjki:
- stworzyć obsługę reklam w "cmsie"
- pokazać reklamy na stronie głównej
- pokazać reklamy na stronie kategorii

Jak widać, aby pokazać reklamy na stronie, trzeba mieć już jakiś mechanizm, aby dodawać te reklamy. Czy można takie taski wziąć do jednego sprintu?

To jest tylko przykład. Wiem, że rozwiązaniem tego problemu było by połączenie tych 3 historyjek w jeden, ale ja chcę wiedzieć tylko czy jest taka zasada, czy nie?

Temat: Zależność między historyjkami biznesowymi.

Trochę mnie dziwi ta zasada, w każdym bądź razie nic o niej nie słyszałem. Natomiast zasadą o której słyszałem to:
1. Wybrana historia powinna być zrealizowana w całości.
2. Sprint musi być zaplanowany tak, aby zadania na nim zaplanowane wypełniały czas do następnego sprinta.

Pułapką w mniej doświadczonych zespołach, może być to, że ktoś najpierw weźmie zadanie, które jest zależne od innego, które z kolei jest zależne od kolejnego itd. I tu jest zadanie dla Scrum Mastera, aby podczas planowania sprintu tego rodzaju zależności wychwycić.

Na koniec dodam, że "pokazać reklamy na stronie głównej" nie jest historyjką, a raczej zadaniem. Ale rozumiem, że jest to pewnego rodzaju uproszczenie :)

Temat: Zależność między historyjkami biznesowymi.

Dominik "Socek" Długajczyk:
To jest tylko przykład. Wiem, że rozwiązaniem tego problemu było by połączenie tych 3 historyjek w jeden, ale ja chcę wiedzieć tylko czy jest taka zasada, czy nie?

drugim rozwiązaniem jest wybranie tylko pierwszej historyjki do 1 sprintu ;)

Jak widać, aby pokazać reklamy na stronie, trzeba mieć już jakiś mechanizm, aby dodawać te reklamy. Czy można takie taski wziąć do jednego sprintu?

Jeśli członkowie zespołu w trakcie sprintu mogą wybrać dowolne zadanie z sprint backlog-a do realizacji to nie mogą mieć w sprintbacklog-u zadań zależnych.

Temat: Zależność między historyjkami biznesowymi.

Moze troche dyplomatycznie, ale moze to rzuci nowe swiatlo na sposob definiowania przez Was historii, co pomoze uzyskac bardziej przejrzysty obraz w backlogu zanim zespol przystapi do jakichkolwiek deklaracji. Polecam definiowac historie wg. zasady INVEST tj.

I ndependent
N egotiable
V aluable
E stimable
S mall
T estable

Pozdrawiam.

Temat: Zależność między historyjkami biznesowymi.

Dominik "Socek" Długajczyk:
Czy w scrumie jest zasada, że nie bierze się do jednego sprintu historyjek biznesowych zależnych od siebie? Np. są 3 historyjki:
- stworzyć obsługę reklam w "cmsie"
- pokazać reklamy na stronie głównej
- pokazać reklamy na stronie kategorii

Jak widać, aby pokazać reklamy na stronie, trzeba mieć już jakiś mechanizm, aby dodawać te reklamy. Czy można takie taski wziąć do jednego sprintu?

Nie ma zasady, że nie można do jednego sprintu brać powiązanych ze sobą historyjek. Wręcz odwrotnie: sprinty powinny mieć określone cele, a więc najczęściej bierze się historyjki powiązane tematycznie i biznesowo, np. dotyczące tej samej funkcjonalności.

Natomiast aby podnieść jakość samych historyjek, a przez to zwiększyść efektywność, zaleca się, aby tworzyć je zgodnie z modelem INVEST, o którym wspomniał Maciej Kurek. Jedną z cech dobrej historyjki w tym modelu jest niezależność, czyli możliwość implementacji historyjek niezależnie od siebie i w dowolnej kolejności. Oczywiście niezawsze się da, ale warto do tego dążyć.

Co do podanego przykładu, to nie jestem pewien, czy go dobrze rozumiem, ale wydaje mi się, że chodzi o stworzenie mechanizmu w CMS-ie, za pomocą którego redaktor będzie mógł zarządzać reklamami wyświetlanymi na serwisie, m.in. dodać reklamę i ustawić, gdzie ma zostać wyświetlona: czy na stronie głównej czy na stronie konkretnej kategorii.

Jeśli tak, to sam mechanizm, aby dodawać te reklamy nie jest historyjką wartościową, bo samo dodawanie nie pozwoli na wyświetlanie reklam. Dobra historyjka mogłaby brzmieć np. "Jako redaktor chcę dodać reklamę, aby móc ją wyświetlić w wybranym przez siebie miejscu w serwisie".

Jeżeli taka historyjka jest za duża, aby skończyć ją w ramach jednego sprintu, to można ją zdekomponować na mniejsze, ale tak, aby one nadal spełniały kryteria modelu INVEST. O wzorcach dekompozycji historyjek już wspominałem kiedyś na tym forum.

Zdekomponowane w ten sposób mniejsze historyjki mogłyby brzmieć:
"Jako redaktor chcę dodać reklamę, aby móc ją wyświetlić na stronie głównej serwisu"
"Jako redaktor chcę dodać reklamę, aby móc ją wyświetlić na stronie wybranej kategorii serwisu"

Dzięki jasnemu określeniu priorytetów i celu biznesowego historyjki można zarządzać zakresem i przez to tworząc mechanizm "zarządzania reklamami w serwisie" na razie skupić się na najważniejszym. Pozostałe ficzery mechanizmu (zliczanie odsłon, kliknięć, przenoszenie reklam pomiędzy kategoriami, planowanie kampanii itp.) zebrać jako osobne historyjki i wykonywać je, kiedy przyjdzie na nie pora, rozbudowując mechanizm przyrostowo.Bogdan B. edytował(a) ten post dnia 21.07.11 o godzinie 17:48

Temat: Zależność między historyjkami biznesowymi.

A co jeśli jest 5 zadań i 5 osób w sprincie. Każde zadanie jest zależne od siebie. Gdzie powiedzmy jest stworzenie w jednym zadaniu połączenia konta z FB. Drugie to ściąganie przyjacioł przez konto FB. Trzecie to dodanie przyjaciół przez FB. I tak dalej. Załóżmy, że aby dodać przyjaciół na FB, trzeba najpierw starych ściągnąć.
Jak w takiej sytuacji? Nie da się wziąć zadań równolegle przecież.

Temat: Zależność między historyjkami biznesowymi.

Dominik "Socek" Długajczyk:
A co jeśli jest 5 zadań i 5 osób w sprincie. Każde zadanie jest zależne od siebie.

te 5 zadań to wąskie gardło nie ma sensu pakować w to więcej niż 1 osoby
więc dołóż zadań lub zmniejsz zespół do 1 osoby.

jeśli jest to grupa zadań typu "wszystko albo nic" to użyj modelu wodospadowego
0. stwórz model obiektowy dla usług realizowanych w ramach grupy zadań
1. ustal kontrakt pomiędzy usługami zrealizowanymi dla tych 5 zadań, to da API
2. jeśli istnieje API to nie potrzebujesz implementacji do czasu integracji, na etapie implementacji wystarczą atrapy
3. na koniec integracja i testy end-to-end i demo

Temat: Zależność między historyjkami biznesowymi.

Witam

Myślę, że problemem jest tutaj złe tworzenie user stories.
Dominik: przykłady które podałeś są to zadania, które może zdekomponować z user story. Nawet gdybyśmy się uparli aby traktować je jako user story to nie wnoszą one żadnej wartości dla klienta.

Zamiast pisać: "stworzyć obsługę reklam w CMSie" napisz "administrator może dodać reklamę", "administrator może opublikować reklamę"
Lub zamiast "połączenie z FB" napisz "użytkownik może się zalogować używając FB".

Prawda że teraz łatwiej nimi zarządzać i traktować jako całość? To już od zespołu będzie należało kto zrobi połączenie do FB, kto będzie pobierał dane itp. Wy na etapie planowania wybieracie funkcjonalność, którą może odebrać klient.

Pozdrawiam

Temat: Zależność między historyjkami biznesowymi.

czyli zasadniczo dobrze jest sie trzymac zasady:

As a... <kto>
I want to... <cel>
So that... <wartosc jaka przynosi cel>

Pozdrawiam,
Maciek

Dawid P.:
Witam

Myślę, że problemem jest tutaj złe tworzenie user stories.
Dominik: przykłady które podałeś są to zadania, które może zdekomponować z user story. Nawet gdybyśmy się uparli aby traktować je jako user story to nie wnoszą one żadnej wartości dla klienta.

Zamiast pisać: "stworzyć obsługę reklam w CMSie" napisz "administrator może dodać reklamę", "administrator może opublikować reklamę"
Lub zamiast "połączenie z FB" napisz "użytkownik może się zalogować używając FB".

Prawda że teraz łatwiej nimi zarządzać i traktować jako całość? To już od zespołu będzie należało kto zrobi połączenie do FB, kto będzie pobierał dane itp. Wy na etapie planowania wybieracie funkcjonalność, którą może odebrać klient.

Pozdrawiam

Temat: Zależność między historyjkami biznesowymi.

Dominik "Socek" Długajczyk:
A co jeśli jest 5 zadań i 5 osób w sprincie. Każde zadanie jest zależne od siebie. Gdzie powiedzmy jest stworzenie w jednym zadaniu połączenia konta z FB. Drugie to ściąganie przyjacioł przez konto FB. Trzecie to dodanie przyjaciół przez FB. I tak dalej. Załóżmy, że aby dodać przyjaciół na FB, trzeba najpierw starych ściągnąć.
Jak w takiej sytuacji? Nie da się wziąć zadań równolegle przecież.

To ile w takim razie trwa Sprint, jak każdy ma po zadaniu i jak duże są te zadania? :)

Przez przypadek kliknąłem, ze wartościowa. Coś nie mogę się przyzwyczaić do interfejsu.

Temat: Zależność między historyjkami biznesowymi.

Krystian K.:
...
To ile w takim razie trwa Sprint, jak każdy ma po zadaniu i jak duże są te zadania? :)

Na ogół zaleca się, aby Sprint trwał miesiąc, a Team liczył 8-12 osób. Mam wrażenie, że jednak w Polsce nie mamy dużych projektów, dlatego że zmniejszamy Team do 1-5 osób, a Sprinty skracamy do 1-2 tygodni. Wydaje mi się jednak, że jeśli Team liczy 2 osoby a Sprint ma trwać 1 tydzień, to już lepiej przejść na eXtreme Programming, dlatego że w tego rodzaju projektach Scrum staje się za ciężki.

Natomiast jeśli chodzi o wyznaczanie zadań i szacowanie czasu dla nich, to trzeba wybrać odpowiednią jednostkę miary czasu trwania zadania i wyceniać wszystkie zadania w tej jednostce. Np. Scrum trwa 4 tygodnie, wtedy długość zadań trzeba liczyć w dniach. Jeśli Team liczy 8 osób, a zadania przeciętnie trwają 3 dni, to dostaniemy około 56 zadań. Swoją drogą jestem ciekaw, jak co niektórzy polscy kozacy wykonują planowanie takiego Scrumu w 30 min. ;)

Mogę przytoczyć tu również "polską" wersję Scrumu. Scrum trwa 1 tydzień, mamy zespół 2. osobowy. Wtedy lepszą miarą dla wielkości zadania będzie godzina. Weźmy np. że zadanie przeciętnie trwa 5 godzin. Wtedy dostaniemy około 16 zadań.

Tak więc w takim planowaniu ludzie będą mieli co robić i nie będą się "zabijać" o zadania. Natomiast jeśli mamy sytuację, gdy mamy 5 osób i 5-10 zadań w Sprincie, to ewidentnie coś z tą listą zadań jest nie tak.

Temat: Zależność między historyjkami biznesowymi.

Do teamów mniejszych niż 4 osoby nie ma sensu stosować Scruma, bo główny (w moim przekonaniu) atut w postaci synergii w zespole praktycznie nie występuje. Przy małych zespołach czy krótkich iteracjach warto zainteresować się Kanbanem.

Planowanie sprintu w 30 minut? Dla 2 tygodniowej iteracji to ok 4 godzin, dla 4 tygodniowej 8 godzin. Z nabieraniem doświadczenia przez zespół można z czasem przyspieszać, ale zrobienie tego szybciej skutkuje zazwyczaj słabą estymacją lub dużą ilością zadań nieplanowanych.

Temat: Zależność między historyjkami biznesowymi.

Aleksander Olszewski:

Na ogół zaleca się, aby Sprint trwał miesiąc, a Team liczył 8-12 osób.

5-9 osób.

Mam wrażenie, że jednak w Polsce nie mamy dużych projektów, dlatego że zmniejszamy Team do 1-5 osób, a Sprinty skracamy do 1-2 tygodni.

W całej nie ma projektów, które mogę zająć więcej niż 5 osób na dłużej niż 2 tygodnie?

Długość Sprint jest związana ze skłonnością wymagań do zmian. Zalecana długość to 30 dni, ale kiedy wymagania zmieniają się częściej, wtedy długość Sprintów można skrócić.

Scrum trwa 4 tygodnie, wtedy długość zadań trzeba liczyć w dniach.

Dlaczego? :) Zadania powinny być w granicach od 1h do powiedzmy 12h, żeby zadanie było wystarczająco małe i niezależne, ale też łatwe do oszacowania z małym marginesem błędu.
User Story nie może być większa niż 3 dni przy 2 tygodniowym Sprincie ze względu na ryzyko blokowania flow i czekania z testowaniem do końca iteracji, kiedy będzie za późno.

Jeśli Team liczy 8 osób, a zadania przeciętnie trwają 3 dni, to dostaniemy około 56 zadań.

Skąd te wyliczenia? Po co w ogóle wyliczać ile zadań "powinno być"?

Mogę przytoczyć tu również "polską" wersję Scrumu. Scrum trwa 1 tydzień, mamy zespół 2. osobowy. Wtedy lepszą miarą dla wielkości zadania będzie godzina. Weźmy np. że zadanie przeciętnie trwa 5 godzin. Wtedy dostaniemy około 16 zadań.

Takie rzeczy są w polskiej wersji Scrum Guide? Serio?

Natomiast jeśli mamy sytuację, gdy mamy 5 osób i 5-10 zadań w Sprincie, to ewidentnie coś z tą listą zadań jest nie tak.

I tu się zgodzę :)

Temat: Zależność między historyjkami biznesowymi.

Krzysztof Z.:
Do teamów mniejszych niż 4 osoby nie ma sensu stosować Scruma, bo główny (w moim przekonaniu) atut w postaci synergii w zespole praktycznie nie występuje.

True. O dynamice zespołu można zapomnieć. Prawdopodobnie zrobią się 2 pary. Jeżeli jedna osoba zachoruje albo weźmie urlop (a mamy cross-functional team), to nie będzie komu zrobić grafiki, albo przetestować zadań, albo zrobić code review i rośnie ryzyko nie dostarczenia User Stories na koniec Sprintu.

Temat: Zależność między historyjkami biznesowymi.

Krystian K.:

Aleksander Olszewski:

Na ogół zaleca się, aby Sprint trwał miesiąc, a Team liczył 8-12 osób.

5-9 osób.

Optymalna liczba członków Zespołu Deweloperskiego jest wystarczająco mała, by Zespół pozostał zwinnym i jednocześnie wystarczająco duża, by Zespół mógł wykonać znaczącą pracę. Mniej niż troje członków oznacza mniejszy stopień interakcji i mniejszy niż oczekiwany wzrost produktywności. Mniejsze Zespoły Deweloperskie mogą napotykać braki kompetencji uniemożliwiające im dostarczanie potencjalnie zbywalnego Przyrostu co Sprint. Więcej niż dziewięcioro członków wymaga zbyt dużych nakładów na koordynację. Duże Zespoły Deweloperskie wprowadzają zbyt dużą złożoność, aby możliwe było zarządzanie nimi przy wykorzystaniu procesu empirycznego. Osoby Właściciela Produktu i Scrum Mastera nie są wliczane w podane wyżej wartości, chyba że wykonują one jednocześnie pracę wynikającą Rejestru Sprintu (Sprint Backlog).[i/]

Ale mogę powiedzieć tak jak Ty:

max 7 osób.

Mam wrażenie, że jednak w Polsce nie mamy dużych projektów, dlatego że zmniejszamy Team do 1-5 osób, a Sprinty skracamy do 1-2 tygodni.

W całej nie ma projektów, które mogę zająć więcej niż 5 osób na dłużej niż 2 tygodnie?

Tak, w Polsce mamy tylko takie projekty zarządzane tylko Scrumem.

Długość Sprint jest związana ze skłonnością wymagań do zmian. Zalecana długość to 30 dni, ale kiedy wymagania zmieniają się częściej, wtedy długość Sprintów można skrócić.

Scrum trwa 4 tygodnie, wtedy długość zadań trzeba liczyć w dniach.

Dlaczego? :) Zadania powinny być w granicach od 1h do powiedzmy 12h, żeby zadanie było wystarczająco małe i niezależne, ale też łatwe do oszacowania z małym marginesem błędu.
User Story nie może być większa niż 3 dni przy 2 tygodniowym Sprincie ze względu na ryzyko blokowania flow i czekania z testowaniem do końca iteracji, kiedy będzie za późno.

[i]Optymalna długość trwania pojedynczego zadania w dzienniku to od czterech do dwunastu godzin dla dwutygodniowego sprintu

Jaka ma być długość zadania dla 4 tygodniowego Sprintu? Czy ograniczenie "User Story nie może być większa niż 3 dni przy 2 tygodniowym Sprincie" można znaleźć w Scrum Guide?

Jeśli Team liczy 8 osób, a zadania przeciętnie trwają 3 dni, to dostaniemy około 56 zadań.

Skąd te wyliczenia? Po co w ogóle wyliczać ile zadań "powinno być"?

Mam napisać obliczenie z działaniami czy sam podstawisz 2 operacje arytmetyczne? Nie narzucam tu liczby zadań a jedynie pokazuję skalę. Tego chyba nie muszę tłumaczyć?

Mogę przytoczyć tu również "polską" wersję Scrumu. Scrum trwa 1 tydzień, mamy zespół 2. osobowy. Wtedy lepszą miarą dla wielkości zadania będzie godzina. Weźmy np. że zadanie przeciętnie trwa 5 godzin. Wtedy dostaniemy około 16 zadań.

Takie rzeczy są w polskiej wersji Scrum Guide? Serio?

Oprócz polskiej wersji Scrum Guide są też inne źródła (nie tylko polskie). Czy tu sugerujesz że ślepo trzymasz się jedynie Scrum Guide? Nie czytasz opracowań pozostałych autorów manifestu Agile? Nie słyszałeś o estymacji projektu metodą liczb Fibonacciego? Podobno wywodzi się ona ze Scrumu.

Natomiast jeśli mamy sytuację, gdy mamy 5 osób i 5-10 zadań w Sprincie, to ewidentnie coś z tą listą zadań jest nie tak.

I tu się zgodzę :)

Na koniec pozytywnie: być może z tym tuzinem to rzeczywiście przesadziłem.

Temat: Zależność między historyjkami biznesowymi.

Aleksander Olszewski:

Krystian K.:
...
To ile w takim razie trwa Sprint, jak każdy ma po zadaniu i jak duże są te zadania? :)

Na ogół zaleca się, aby Sprint trwał miesiąc, a Team liczył 8-12 osób. Mam wrażenie, że jednak w Polsce nie mamy dużych projektów, dlatego że zmniejszamy Team do 1-5 osób, a Sprinty skracamy do 1-2 tygodni.

Kto tak zaleca? Myślałem, że miesiąc to maximum dla iteracji. Sugerujesz, że krótsze iteracje są tylko w mniejszych projektach? W firmie, w której pracuję są tylko duże (lub bardzo duże) projekty, distributed Scrum itd i w każdym teamie sprint trwa dwa tygodnie, bo wydaje się to być naturalnym czasem dla procesu tworzenia oprogramowania...

Temat: Zależność między historyjkami biznesowymi.

Scrum nieodłącznie łączy się z nieustannym usprawnianiem pracy. To, jak będzie pracował konkretny zespół zależy w dużej mierze od niego samego i nie ma sensu dywagować nad "oficjalnymi i jedynie słusznymi" wytycznymi. Wytwarzanie oprogramowania jest bardzo szeroką dziedziną, bo np. napisanie programu do poduszek powietrznych Porsche jest inne niż zakodowanie sklepu internetowego.

Scrum trzeba rozumieć jako zespół wskazówek, natomiast nieprzestrzeganie podstawowych zasad powoduje, że nie pracuje się w nim, a w czymś zbliżonym. Zbyt długie zadania mają minusy w postaci tego, że np. wykres wypalania stoi w miejscu, a czas płynie, więc wykres nie odzwierciedla faktycznego stanu prac. Działa to demotywująco i powoduje, że pod koniec sprintu zaczynamy widzieć na wykresie "klif" - zespół chcący osiągnąć cel iteracji "wypala" zadanie, ale jest ono słabo przetestowane i może być także gorzej napisane.

Podsumowując: długość iteracji jest indywidualna dla zespołu, chodzi o to, aby zaczynała się planowaniem, kończyła wydaniem potencjalnie użytecznej wersji produktu, spotkaniem przeglądowym i retrospekcją. Sami musicie ocenić, na ile jest to uzasadnione w waszym wypadku, bo zależy to bardzo mocno od kosztów wydania - jeżeli musicie np. w związku z końcem iteracji przygotować nową dokumentację techniczną, przeszkolić help desk itd. może się okazać, że wydłużenie jest ok. Przy projektach internetowych, gdzie koszty wydania są zazwyczaj dużo niższe często można skracać iteracje.

Temat: Zależność między historyjkami biznesowymi.

Łukasz Nowacki:

Aleksander Olszewski:

Krystian K.:
...
To ile w takim razie trwa Sprint, jak każdy ma po zadaniu i jak duże są te zadania? :)

Na ogół zaleca się, aby Sprint trwał miesiąc, a Team liczył 8-12 osób. Mam wrażenie, że jednak w Polsce nie mamy dużych projektów, dlatego że zmniejszamy Team do 1-5 osób, a Sprinty skracamy do 1-2 tygodni.

Kto tak zaleca? Myślałem, że miesiąc to maximum dla iteracji. Sugerujesz, że krótsze iteracje są tylko w mniejszych projektach? W firmie, w której pracuję są tylko duże (lub bardzo duże) projekty, distributed Scrum itd i w każdym teamie sprint trwa dwa tygodnie, bo wydaje się to być naturalnym czasem dla procesu tworzenia oprogramowania...

4. tygodnie dla Sprintu jest dobrym punktem wyjścia dla dużych projektów (powiedzmy 6-8 miesięcznych) lub dla zespołów które wchodzą w Scrum z jakieś ciężkiej metodyki. Jak zobaczysz Scrum Guide, to zauważysz, że są tam jedynie ogólne wskazówki, typu Sprint nie może trwać dłużej niż 30 dni. Sądziłem, że wszyscy są świadomi tego, że Scrum jest samoadaptującą się metodyką. Każde zalecenie powinno zostać poddane próbie w boju.

Są uzasadnienia dla krótszych iteracji, chociażby serwisy internetowe lub wewnętrzny klient lub bardzo zmotywowany prezes ;)

Jak widzisz wszystko zależy od sytuacji. Nie rozumiem jednak stwierdzeń "w mojej firmie mamy 2. tygodniowe Sprinty i tak powinno być".

Chętnie przeczytam twoje uzasadnienie dla 2. tygodniowych Sprintów dla projektu na 8 miesięcy dla 6. ludzi dla instytucji finansowej :)

Temat: Zależność między historyjkami biznesowymi.

Aleksander Olszewski:

Jak widzisz wszystko zależy od sytuacji. Nie rozumiem jednak stwierdzeń "w mojej firmie mamy 2. tygodniowe Sprinty i tak powinno być".

Erm... Nigdzie tak nie napisalem... Chodzilo mi jedynie o to, iz z Twojej wypowiedzi wynikalo iz zaleca sie 30 dniowy sprint, podczas gdy tak naprawde chodzi o adaptacje. Niektorym bedzie pasowalo 30 - innym (jak trafnie podales przyklady) lepiej odpowiada 14 dni... I wielkosc projektu w ogolnym stwierdzeniu nie ma tu nic do rzeczy - zalezy to od wielu innych czynnikow.

Uwazam jedynie, iz uogolnienie typu 'duzy projekt to 30 dni' jest zbyt... hmm... ogolne ;)

Temat: Zależność między historyjkami biznesowymi.

Długość Sprintu powinna być określana na postawie akceptowalnego poziomu ryzyka z jednej strony i czasu potrzebnego zespołowi na wytworzenie czegoś ukończonego z drugiej. Poziom ryzyka zależy od złożoności środowiska, w jakim pracujemy i horyzontu planowania.

Wielkość Zespołu Deweloperskiego to jeden z czynników składających się na złożoność środowiska, ale nie jedyny. Te czynniki to: znajomość i zmienność wymagań, co ma odzwierciedlenie w Rejestrze Produktu i jego dynamice; technologia (nowa czy dobrze znana itd.); i ludzie (wielkość zespołu, doświadczenie i poziom umiejętności, zgranie itd.).

Jeśli więc mamy np. początek projektu, kiedy w wymaganiach jest dużo niewiadomych, często się zmieniają, zespół jest duży (np. 9 osób), świeżo skompletowany i do tego pracuje w nowej technologii, której nie zna, to mamy do czynienia z bardzo złożonym środowiskiem. Obranie więc 30-dniowego horyzontu planowania w takiej sytuacji spowoduje prawdopodobnie to, że poziom ryzyka będzie nie do przyjęcia. Chcąc go zmniejszyć można redukować złożoność albo ograniczać horyzont planowania.

Oczywiście redukując i ograniczając do minimum możemy dojść do sytuacji, kiedy taki "zespół" nie będzie w stanie niczego wytworzyć. To ta druga strona determinująca minimalną długość iteracji.

Tak więc to wszystko zależy do bardzo wielu czynników i nie ma prostej odpowiedzi na optymalną długość Sprintu, chociaż ogólne wzorce można określić:

Dla krótkiego projektu (np. 2-miesięcznego) lepsze będą krótkie iteracje (np. 1-2 tygodniowe), bo długich (miesięcznych) będzie po prostu za mało i będziemy mieli zbyt mało okazji do inspekcji i adaptacji. W długich projektach można zaryzykować dłuższe iteracji, bo krótkie mogą okazać się zbyt dużym narzutem organizacyjnym.

Jeżeli mamy do czynienia z mało zaangażowanym klientem, lepsze mogą być znowu krótsze iteracje, bo zmusi go to do częstszych kontaktów z zespołem. Z zaangażowanym, ulokowanym w pobliżu zespołu Właścicielem Produktu umiejącym wykorzystywać Scrum w swojej pracy, można spróbować dłuższych.

Dla świeżych i niedoświadczonych zespołów znowu lepsze mogą być krótsze iteracje, żeby zespół nauczył się wytwarzać coś małego ale ukończonego. Długie iteracje to zbyt duże ryzyko, że więcej czasu i pracy się zmarnuje. Zgrany zespół wyjadaczy może się pokusić o miesięczne Sprinty.

Jeżeli wymagania są słabo znane, może być potrzeba wprowadzania częstszych zmian, a więc krótsze iteracje. Stabilny, dobrze przygotowany Rejestr Produktu, mało zmian — można dłuższe.

itd.

Ważne jest, żeby zdawać sobie sprawę z tych wszystkich czynników i przy określaniu długości Sprintu brać je wszystkie pod uwagę, a najlepiej długość określać empirycznie, tj. wypróbowując różne "ustawienia", pamiętając jednocześnie, że zbyt częste zmiany "ustawień" to znowu zwiększanie złożoności :)Bogdan B. edytował(a) ten post dnia 02.09.11 o godzinie 13:13