Temat: Zbieranie wymagań w SCRUM

Jestem bardzo ciekaw jakie macie doświadczenie i jak się zapatrujecie na kwestię zbierania wymagań na potrzeby procesu wytwórczego prowadzonego SCRUM'em.

Założenie w sumie jest takie, że wymagania precyzuje się i analizuje w iteracjach (zespół), a przed przystąpienie do jakichkolwiek prac powinny powstać wymagania w formie dość ogólnej (ramowej). Niemniej jednak zespół deweloperów, który jest dość cennym zasobem, nie powinien być uwikłany w coś co jest zbyt słabo zdefiniowane przez biznes, gdzie w tym samym czasie może prowadzić (kodować) inne projekty, które zostały już wcześniej lepiej określone. Chodzi w zasadzie o maksymalne wykorzystanie tego zasobu w przypadku ciągłego prowadzenia projektów.

Wiadomo, że duże pole do popisu w projektach ma biznes, który musi powiedzieć czego oczekuje, sprecyzuje cele, a także zakres projektu oraz deadline. Założenia te trzeba przeanalizować m.in. pod kątem wykonalności (tutaj mają pole do popisu analitycy), a żeby to zrobić założenia powinny być na przyzwoitym poziomie szczegółowości (byle nie przesadzić). Wiadomo, że założenia zawsze mogą ulec zmianie w trakcie trwania prac, ale pytanie jak bardzo powinno się wchodzić w szczegóły przed pracami SCRUM'owymi...

Jakie jest Wasze zdanie na ten temat?

Temat: Zbieranie wymagań w SCRUM

Nie chodzi o maksymalne wykorzystanie „zasobu”, ale o maksymalizację wartości pracy zespołu. To dwie różne kwestie. Skupienie się na maksymalizacji wykorzystania „zasobu” sprawia, że dążymy do odseparowania zespołu od wszelkiej innej pracy niż wytwarzanie i w rezultacie zespół rzeczywiście wikła się w coś, w analizę czego nie był zaangażowany aż do „startu”.

Dlatego w Scrumie zbieranie wymagań i zarządzanie nimi ma charakter ciągły — Właściciel Produktu pracuje ciągle nad Rejestrem Produktu. W analizę tych wymagań angażuje się Zespół Deweloperski i robi to też w sposób ciągły — poświęca część każdego Sprintu na pielęgnację Rejestru Produktu.

To, jak dokładnie poszczególne elementy Rejestru Produktu powinny być określone, żeby Zespół Deweloperski był w stanie wybrać je do kolejnego Sprintu, może różnić się pomiędzy różnymi Zespołami Scrumowymi i organizacjami. Niektóre zespoły praktykują Definicję Gotowości (Definition of Ready), tj. kryteria, które np. historyjka użytkownika powinna spełniać, żeby Zespół Deweloperski mógł ją wybrać podczas Planowania Sprintu. Kryteriami tymi mogą być: historyjka zgodna z modelem INVEST, zrozumiała przez Zespół Deweloperski, oszacowana, określone kryteria akceptacyjne, bez otwartych pytań do Właściciela Produktu.

Oczywistym jest, że niewiele elementów Rejestru Produktu będzie spełniać te wymagania na początku projektu. Ale właśnie o to chodzi, żeby nie poświęcać temu zbyt dużo czasu, a robić to w sposób ciągły, wspólnie z Właścicielem Produktu, w miarę jak kolejne elementy zbliżają się do góry rejestru.

Temat: Zbieranie wymagań w SCRUM

Zbieranie wymagań a praca nad nimi to dwie osobne rzeczy moim zdaniem. Zbieranie to praca dla Product Ownera, który spotyka się z interesariuszami/klientami i dorzuca wymagania do backlogu, oczywiście kolejkując je odpowiednio na podstawie wszelkich czynników (wartość, zależności, pracochłonność, time to market itd.).
Natomiast praca nad wymagniami, to moim zdaniem już zadanie dla całego zespołu SCRUMowego. Od tego są groomingi, by wymagania które PO zapisał w backlogu zostały poddane przez cały zespół analizie oraz ewentualnie granulacji/uszczegółowieniu. Im szybciej zespół angażowany jest w pracę nad produktem, tym większą bierze za niego odpowiedzialność, co przekłada się nad zaangażowanie.

Temat: Zbieranie wymagań w SCRUM

W teorii wszystko jest piękne. Najważniejsze jest właśnie zaangażowanie całego zespołu, zwłaszcza Product Ownera. Jeżeli PO nie wie co robić i reszta zespołu musi nim kierować to nie jest zbyt dobrze...

Niemniej dziękuję za przedstawienie swojego punktu widzenia. Muszę baczniej przyjrzeć się modelowi INVEST, bo już któryś raz o nim słyszę. Później zweryfikuję pod tym kątem DoR naszego zespołu.

Temat: Zbieranie wymagań w SCRUM

INVEST jako taki dotyczy pisania user stories. Osobiście staram się, by moje stories spełniały te wymagania. Jednak należy pamiętać, że stories są dla zespołu, więc to głównie na potrzeby tego zespołu powinny być pisane.

Temat: Zbieranie wymagań w SCRUM

Michał Kotarba:
W teorii wszystko jest piękne. Najważniejsze jest właśnie zaangażowanie całego zespołu, zwłaszcza Product Ownera. Jeżeli PO nie wie co robić i reszta zespołu musi nim kierować to nie jest zbyt dobrze...

Co dokładnie masz na myśli pisząc, że PO nie wie, co robić i reszta zespołu musi nim kierować?

Temat: Zbieranie wymagań w SCRUM

Bogdan B.:

Michał Kotarba:
W teorii wszystko jest piękne. Najważniejsze jest właśnie zaangażowanie całego zespołu, zwłaszcza Product Ownera. Jeżeli PO nie wie co robić i reszta zespołu musi nim kierować to nie jest zbyt dobrze...

Co dokładnie masz na myśli pisząc, że PO nie wie, co robić i reszta zespołu musi nim kierować?

Chodzi o to, że PO nie ma doświadczenia w pracy z zespołem SCRUM'owym i nie potrafi się dobrze przygotować. Ciągłe poprawki user stories, przypominanie o stałych elementach metodyki, wręcz uświadamianie PO, że ma moc decyzyjną. Poza tym zbyt pobieżne rozpoznanie tematu po stronie PO co przekłada się na odkładanie decyzji w czasie (sami wiecie, że punktualność w tym zakresie jest bardzo istotna) lub podejmowanie ich spontanicznie.

Temat: Zbieranie wymagań w SCRUM

Michał Kotarba:
Chodzi o to, że PO nie ma doświadczenia w pracy z zespołem SCRUM'owym i nie potrafi się dobrze przygotować. Ciągłe poprawki user stories, przypominanie o stałych elementach metodyki, wręcz uświadamianie PO, że ma moc decyzyjną. Poza tym zbyt pobieżne rozpoznanie tematu po stronie PO co przekłada się na odkładanie decyzji w czasie (sami wiecie, że punktualność w tym zakresie jest bardzo istotna) lub podejmowanie ich spontanicznie.

To Scrum Master ma pole do popisu! :)

Temat: Zbieranie wymagań w SCRUM

Bogdan B.:

Michał Kotarba:
Chodzi o to, że PO nie ma doświadczenia w pracy z zespołem SCRUM'owym i nie potrafi się dobrze przygotować. Ciągłe poprawki user stories, przypominanie o stałych elementach metodyki, wręcz uświadamianie PO, że ma moc decyzyjną. Poza tym zbyt pobieżne rozpoznanie tematu po stronie PO co przekłada się na odkładanie decyzji w czasie (sami wiecie, że punktualność w tym zakresie jest bardzo istotna) lub podejmowanie ich spontanicznie.

To Scrum Master ma pole do popisu! :)

Oj ma, oj ma...

Niemniej jednak dlatego podpytywałem czy nie można ogarnąć w większym stopniu wymagań przed przystąpieniem zespołu SCRUM'owego do prac, bo szkoda ich czasu jak PO nie ma w zasadzie bladego pojęcia co trzeba robić. Pierwsze tygodnie pracy byłoby marnowane na dochodzenie do tego co w ogóle chce biznes. Z drugiej jednak strony nie można zbytnio uszczegółowić wymagań, bo one i tak się mogą zmienić (jak zawsze).

Temat: Zbieranie wymagań w SCRUM

Michał Kotarba:

Bogdan B.:

Michał Kotarba:
Chodzi o to, że PO nie ma doświadczenia w pracy z zespołem SCRUM'owym i nie potrafi się dobrze przygotować.

Proponuję użyć analityka biznesowego który będzie w stanie zaopiekować się modelem dziedziny w trakcie realizacji kolejnych funkcji systemu. Jeśli iteracja trwa 2 tygodnie to co 2 tygodnie obecny PO ma szansę przekazać nowe wymagania , w tym czasie pracując z analitykiem - analityk może pełnić rolę SM - w zależności od specyfiki organizacji/projektu. Poza tym PO może mieć zawsze informację o aktualnym statusie zadań i na tej podstawie planować dalsze zlecenia.

Poza tym jeśli wymagania spływają za wolno czyli jest przestój to można zmniejszyć zespół wykonawczy lub jak w każdej fabryce zarządzić postój - kodeks pracy też może być Agile ;).Piotr T. edytował(a) ten post dnia 12.02.12 o godzinie 22:44

Temat: Zbieranie wymagań w SCRUM

Piotr T.:

Michał Kotarba:
Chodzi o to, że PO nie ma doświadczenia w pracy z zespołem SCRUM'owym i nie potrafi się dobrze przygotować.

Proponuję użyć analityka biznesowego który będzie w stanie zaopiekować się modelem dziedziny w trakcie realizacji kolejnych funkcji systemu. Jeśli iteracja trwa 2 tygodnie to co 2 tygodnie obecny PO ma szansę przekazać nowe wymagania , w tym czasie pracując z analitykiem - analityk może pełnić rolę SM - w zależności od specyfiki organizacji/projektu. Poza tym PO może mieć zawsze informację o aktualnym statusie zadań i na tej podstawie planować dalsze zlecenia.

Nadal jednak obracamy się wokół PO, a to czy zostanie użyty analityk biznesowy czy też nie, to już kwestia zaplecza jakim dysponuje PO oraz jego użycia.

Jednak wskazówka warta przemyślenia. Analityków mamy, ale oni uczestniczą we wstępnej fazie inicjowania projektu, czyli w zbieraniu początkowych wymagań do projektu. Później przechodzą do innych projektów, a PO ogrania całość w zasadzie sam. Muszę się jednak zastanowić czy nie wykorzystać ich bardziej w trakcie trwania prac SCRUM'owych...

Poza tym jeśli wymagania spływają za wolno czyli jest przestój to można zmniejszyć zespół wykonawczy lub jak w każdej fabryce zarządzić postój - kodeks pracy też może być Agile ;).

Zdecydowanie stawiałbym większy nacisk na więcej wsadu merytorycznego w trakcie prac niż zmniejszenie zespołu, a tym samym wydłużenie trwania projektu. Ale z tym kodeksem pracy to ciekawe podejście... ;)

Temat: Zbieranie wymagań w SCRUM

Zespół jest tak mocny jak jego najsłabsze ogniwo. Widziałem zespoły z dobrym Product Ownerem a średnią mocą "wykonawczą" oraz odwrotnie, świetną część deweloperską, ale prace były wstrzymywane ze względu na słabą jakość wsadu dostarczaną przez PO.
Pytanie więc, czy w tym przypadku PO dobrze zbiera te wymagania, czy może już sam Klient/interesariusz nie wie czego chce. Faktycznie jest tu spore pole do popisu dla SMa, by popracował z PO nad metodyką pracy. Pozostają jeszcze kwestie wyboru samego PO, jeśli nie jest on wystarczająco zaangażowany (słyszałem, że dobry PO może mieć dwa zespoły, a bardzo dobry PO jeden, właśnie ze względu na to, że trzeba być prawie cały czas zaangażowany w pracę zespołu) to może należy pomyśleć o jakiejś zmianie.

Temat: Zbieranie wymagań w SCRUM

Michał Kotarba:
Niemniej jednak dlatego podpytywałem czy nie można ogarnąć w większym stopniu wymagań przed przystąpieniem zespołu SCRUM'owego do prac, bo szkoda ich czasu jak PO nie ma w zasadzie bladego pojęcia co trzeba robić. Pierwsze tygodnie pracy byłoby marnowane na dochodzenie do tego co w ogóle chce biznes. Z drugiej jednak strony nie można zbytnio uszczegółowić wymagań, bo one i tak się mogą zmienić (jak zawsze).

Z tego, co piszesz wcześniej:

„PO nie ma doświadczenia w pracy z zespołem SCRUM'owym i nie potrafi się dobrze przygotować. Ciągłe poprawki user stories, przypominanie o stałych elementach metodyki, wręcz uświadamianie PO, że ma moc decyzyjną.”

wynika, że dobrze wiecie, w czym leży przyczyna problemu — osoba wyznaczona na PO nie jest przygotowana odpowiednio do tej roli i ten problem należy rozwiązać. Tak, jak Maciej Tafliński napisał: „zespół jest tak mocny jak jego najsłabsze ogniwo.”, a PO to także członek zespołu.

W takiej sytuacji bardzo dużo zależy od Scrum Mastera (edukacja PO) oraz całego zespołu (wsparcie dla PO w pracach nad historyjkami użytkownika). „Ogarnięcie wymagań” poza Zespołem Scrumowym nie rozwiąże problemu (PO nie stanie się lepszym PO), a jedynie uczyni problem niewidocznym dla Zespołu przez krótki czas (Rejestr Produktu będzie w dobrym stanie do czasu, aż zajdzie potrzeba wprowadzenia w nim zmian).

Brak decyzyjności i nieprzygotowanie PO może wynikać też z tego, że rolę tę pełni nieodpowiednia osoba w organizacji. Trudno wyrokować nie znając sytuacji, jednak pomoc organizacji w wyborze właściwego PO to także zadanie dla Scrum Mastera i znowu: „ogarnięcie wymagań” poza zespołem nie pomoże w rozwiązaniu rzeczywistego problemu.

Temat: Zbieranie wymagań w SCRUM

Bogdan B.:

Michał Kotarba:
Niemniej jednak dlatego podpytywałem czy nie można ogarnąć w większym stopniu wymagań przed przystąpieniem zespołu SCRUM'owego do prac, bo szkoda ich czasu jak PO nie ma w zasadzie bladego pojęcia co trzeba robić. Pierwsze tygodnie pracy byłoby marnowane na dochodzenie do tego co w ogóle chce biznes. Z drugiej jednak strony nie można zbytnio uszczegółowić wymagań, bo one i tak się mogą zmienić (jak zawsze).

Z tego, co piszesz wcześniej:

„PO nie ma doświadczenia w pracy z zespołem SCRUM'owym i nie potrafi się dobrze przygotować. Ciągłe poprawki user stories, przypominanie o stałych elementach metodyki, wręcz uświadamianie PO, że ma moc decyzyjną.”

wynika, że dobrze wiecie, w czym leży przyczyna problemu — osoba wyznaczona na PO nie jest przygotowana odpowiednio do tej roli i ten problem należy rozwiązać. Tak, jak Maciej Tafliński napisał: „zespół jest tak mocny jak jego najsłabsze ogniwo.”, a PO to także członek zespołu.

W takiej sytuacji bardzo dużo zależy od Scrum Mastera (edukacja PO) oraz całego zespołu (wsparcie dla PO w pracach nad historyjkami użytkownika). „Ogarnięcie wymagań” poza Zespołem Scrumowym nie rozwiąże problemu (PO nie stanie się lepszym PO), a jedynie uczyni problem niewidocznym dla Zespołu przez krótki czas (Rejestr Produktu będzie w dobrym stanie do czasu, aż zajdzie potrzeba wprowadzenia w nim zmian).

Brak decyzyjności i nieprzygotowanie PO może wynikać też z tego, że rolę tę pełni nieodpowiednia osoba w organizacji. Trudno wyrokować nie znając sytuacji, jednak pomoc organizacji w wyborze właściwego PO to także zadanie dla Scrum Mastera i znowu: „ogarnięcie wymagań” poza zespołem nie pomoże w rozwiązaniu rzeczywistego problemu.

Nie o to chodzi, że PO to niewłaściwa osoba, ale:

1. Pewne rzeczy długo się procesują (umowy, kontakty z zewnętrznymi partnerami, testowanie podsystemów, oczekiwanie na opinię konsultantów technicznych, itp.)
2. PO nie do końca wie co zespół (the team) może oczekiwać od niego

W tym wypadku:

ad. 1. Kwestia ustalenia terminu startu prac, a jeżeli projekt jest palący, sterowanie znanym zakresem do momentu jego ostatecznego ustabilizowania.
ad. 2. Ustalenia wymagań dla wymagań żeby PO wiedział co i na kiedy ma przygotować.

Moje wątpliwości dotyczą właśnie tego drugiego obszaru.

Temat: Zbieranie wymagań w SCRUM

W takim razie zespół powinien jasno postawić swoje wymagania odnośnie Definition of Ready. Jeśli PO nie spełni tych wymagań, zespół nie weźmie do pracy jego stories, a co za tym idzie, PO będzie świecił oczami przed Klientem.