пропозиції роботи
Wypowiedzi
-
Jakub Drzazga:
(...)Programiści pracują zdalnie, klient jest mało konkretny, przysyła info odnośnie co ma być zrobione deweloperowi w jednym projekcie i po jakimś czasie oczekuje aby zmiany były zaadaptowane wszędzie. Musimy sobie jakoś z tym poradzić a wymiana mailowa jest delikatnie mówiąc nieefektywna.
Może możecie coś polecić?
Ja polecam, żeby Klient kontaktował się np. z Product Ownerem który zarządza wymaganiami i przekazuje je zespołowi. Jasne, greenhopper i inne narzędzia są fajne, ale nie w tym chyba problem. Jeśli Klient idzie bezpośrednio do dewelopera to chyba nie jesteśmy w odpowiedniej grupie (Scrum).
[EDIT] właśnie widzę datę pierwszego postu, niezły odgrzany kotlet :)Maciej Tafliński edytował(a) ten post dnia 27.02.13 o godzinie 12:08 -
W przypadku naprawdę sporej liczby zespołów odpowiedzią mógłby być Scrum of Scrums. Z każdego zepsołu wybierana jest jedna osoba która reprezentuje go na normalnych wszystkich spotkaniach, czyli review, retro planning i oczywiście daily scrum. Na takim daily scrumie należałoby zadać pytania standardowe:
1) Co Twój zespół zrobił od ostatniego spotkania?
2) Co zrobi do następnego spotkania?
3) Czy jest coś blokującego?
i dodatkowe
4) czy jest coś, co może wejść w paradę innemu zespołowi.
Oczywiście taki scrum scrumów musi mieć PO i Scrum Mastera :)
To może działać w przypadku większej ilości zespołów. W przypadku 2-3 myślę, że jeden PO z dobrze zorganizowym backlogiem, niezależnymi user storiesami (ogólnie INVESTowanymi) i dobrą komunikacją pomiędzy zespołami mógłby to ogarnąć. Oczywiście testy integracyjne tutaj grałyby dużą rolę. -
Product Owner jest odpowiedzialny za rozwój produktu i to jest jego główne zadanie. Dlatego powinien poświęcić temu produktowi tyle czasu, ile jest to wymagane. PM (jako project manager, ja jestem product managerem np) ma tendencję do tego, że po skończeniu jego części projektu obtrąbia sukces i idzie, nie przejmując sie za bardzo tym, co po sobie zostawił. Ważne, że dwa wierzchołki trójkąta projektowego zostały spełnione.
Natomiast Product Owner powinien myśleć o całości życia produktu. PO dwa razy się zastanowi wypuszczając funkcjonalność która zaciągnie dług technologiczny taki, że będzie go później spłacać i opóźniać nowe przyrosty produktu.
Nie wydaje mi się, że jest jakiś specjalny obszar z którego PO powinien pochodzić. Musi po prostu zaangażować się w produkt (i mieć na to czas), wiedzieć o co w nim chodzi i być decyzyjny. -
SCRUM powinien opierać się na zaufaniu i przejrzystości. Jeśli istnieją jakieś podejrzenia, że zespół świadomie zaniża swoją velocity, należałoby to jawnie wyświetlić na retrospekcji.
Dla mnie osobiście o wiele gorsza jest nierówna velocity niż niska velocity :) Jeśli nie wiem ile story points zespół zrobi, to nie daje mi to możliwości planowania. Natomiast jeśli jest niskie velocity, to po prostu może nie uda się zrobić najmniej wartościowych elementów w backlogu.
Jeśli są podejrzenia o sterowanie wskaźnikami, to jest temat dla SM i na retrospekcję. -
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.
-
Maciej Kurek:
Zgodze sie, ze user stories powinny byc niezalezne, wertykalnie zdefiniowane i reprezentowac jakis end-to-end flow. Jednak czasami nawet najlepiej zdefiniowana historia, spelniajaca INVEST i majaca swietne kryteria akceptacji bedzie po prostu za duza na jeden sprint (na przyklad: zespol wyestymuje ja na 8 punktow, a jego velocity to 5, stad taki commitment bedzie ryzykowny). Wtedy dalsze rozbicie 'pierwotnej' historii wedlug poszczegolnych kryteriow akceptacji moze okazac sie byc wyjsciem z sytuacji. W opisywanym przykladzie mniejsza historia zdefiniowana tak:
jako klient
chce miec mozliwosc sortowania wynikow wyszukiwania rosnaco
tak, abym mogl bardzo szybko znalezc produkt o najnizszej cenie
moglaby byc dobrym kandydatem wciaz przynoszacym wartosc biznesowa i nieco mniejszym, realnym do dostarczenia po jednym sprincie.
Po pierwsze kryterium "ślepy zaułek" jest słabo zdefiniowanym wymaganie.
A po drugie podejście jak wyżej, z rozbiciem na poszczególne funkcjonalności jest jak najbardziej słuszne.
Najpierw robisz samą wyszukiwarkę, później np. sortowanie, opcje zaawansowane itd.
W ten sposób otrzymujesz przyrost produktu którym możesz się pochwalić Klientowi, oczywiście zaczynając od tej najbardziej wartościowej, biorąc pod uwagę zależności (nie ma sensu robienie sortowania wyników bez samej wyszukiwarki :)) -
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. -
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.
-
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. -
Po pierwsze chciałbym się przywitać na forum :)
A po drugie:
OC, moim zdaniem, nie istnieje w naszym kraju z jednego powodu: są inne jednostki które są o wiele lepiej przygotowane do pełnienia tych funkcji, na przykład te wchodzące w skład Krajowego Systemu Ratowniczo-Gaśniczego.
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
