Co to ten scrum, bo już nie wiem.

@p_agon: Może być sensowny Scrum. Chwilowo odstawiając na bok, czy sensowny Scrum to nadal Scrum, ja widzę to tak:

Patrzymy jaki jest projekt. Jak pracuję w software housie i ktoś już podpisał umowę na dowiezienie określonego zakresu za określone pieniądze w określonym czasie, to po co mamy bawić się w szacowanie ile zajmie historyjka, trzeba ruszyć d.... odrzucić wszystko co wychodzi poza to za co klient płaci i zasuwać do celu. Robimy kanban boarda, ustalamy priorytety, jedziemy. Z "ceremonii" daily na początku projektu, żeby zobaczyć z kim pracujemy, wychwycić kto potrzebuje pomocy, bo utknął z jakimś zadaniem. Raz na 1-2 tygodnie krótki backlog refinement, żeby sprawdzić, czy zadania są zdefiniowane dostatecznie dobrze, czy jesteśmy w stanie podzielić je na historyjki, żeby później nie stać 3 dni z robotą, bo z zadania jest wyłącznie temat. Ktoś chce sobie szacować czy jesteśmy pod, czy nad kreską, to niech szacuje, ale nie jest to zadanie zespołu, tylko PM, SM czy PO. Zespół robi to co potrafi robić, czyli programuje.

Jeżeli mamy projekt pod agile, czyli biznes chce, żebyśmy dostarczyli narzędzie do czegoś tam, czy przygotowali jakąś usługę SaaS, to pracując w nowym zespole robimy na początek spotkanie, żeby każdy wiedział na czym polega projekt, co mamy dostarczyć, jaki jest sens biznesowy projektu, czy są jakieś deadline'y w najbliższym czasie (jeżeli występują). Mówimy sobie otwarcie - nie znamy się, nie pracowaliśmy razem, spróbujmy przez chwilę Scruma, bo nie mamy lepszych pomysłów, więc spróbujmy na początek tak jak Scrum proponuje. W tym miejscu potrzeba bardzo ogarniętego "adżail coacha", który po pierwsze wytłumaczy z czego składa się Scrum, jak, oraz co najważniejsze po co stosować zawarte w nim narzędzia. Uprzedzamy wszystkich, że będzie to wyglądać jak domowe przedszkole. Następnie co sprint robimy retro, na którym identyfikujemy najważniejsze problemy możliwe do rozwiązania w ramach zespołu. Jeżeli ktoś zgłasza, że jest za dużo spotkań, to zastanawiamy się, które z nich można usunąć, lub jak je ograniczyć. Przegadujemy również, czy poprzednie kroki odskramiające nie spowodowały jakichś problemów. Co ważne, nikt nie ma prawa użyć argumentu "scrum guide pisze, że coś tam trzeba". Wszystko co pada podczas takich spotkań musi być uargumentowane pod kątem tego jak zmiana pomoże w projekcie. Jak biznes czegoś wymaga, to też koncentrujemy się na tym wymaganiu. Nikt poza zespołem nie ma prawa mówić "jak" zespół ma robić coś czego się od niego oczekuje. Czyli jak zespół nie potrzebuje wyceny w story pointach, a jest w stanie dawać w miarę przewidywalne rezultaty, to nikomu nic do tego. Praktyczna rada - warto wprowadzać zmiany pojedynczo, ale często, żeby wiedzieć co przyniosło jaki skutek. Z mojego doświadczenia, po kilku miesiącach praktykowania takiego cyklu ze Scruma nie zostaje prawie nic, poza zewnętrznym interface zespołu.

@twoj_stary_pijany:

Dziwi mnie trochę, że tak ciśniesz scrum skoro sam pracowałeś w jakiejś patowersji scruma.

Jak pracowałem w tym konkretnym projekcie i jeszcze kilku następnych to akurat byłem wyznawcą scruma. Wiedziałem, że to akurat jest pseudo scrum od dnia 0. Ja przestałem SCRUMa cenić mocno dopiero jak trafiłem do takiego scrum by the book, gdzie już nie dało się uzasadnić gigantycznego marnotrawstwa czasu tym, że to nie jest prawdziwy komunizm, tylko patologia.

Kiedy u mnie architekt publicznie upokarzał na spotkaniu PO to go po prostu zgłosiłem,

W tym konkretnym projekcie też udało się wywalić (nawet 2) manadżerów niemieckich - poszły popdpierdolki (co ciekawe audyt był całkowicie przez niemców robiony, więc początkowo nie spodziewaliśmy się niczego dobrego).

Ale to wy robicie te estymaty, dlaczego nie estymowaliście tego na np. 4 dni?

Pisałem, że to był pseudo - pato scrum - nic tam nie estymowaliśmy. Estymaty były zrobione rok wcześniej przez inny zespół, przy innych założeniach. Myśmy mogli tylko się zgadzać i commitować.
Tak po prawdzie dość szybko udało się wykorzystać dziurę w systemie, architekci mieli prawo zmieniać estymaty... ktoś nieopatrznie dodał mnie do grupy architektów, więc zmieniałem kolegom estymaty zadań tuż przed tym jak je dostali i tylko ja sie musiałem z tego tłumaczyć. Jako architekt mogłem naturalnie udawać głupiego. Słaba znajomość niemieckiego powodowała, że w zasadzie to nawet niewiele musiałem udawać :-) Manadżer z Niemiec szybko dość zmęczył się tłumaczeniem mi, że rozwalam pracę zespołu i przez moje estymaty nie zdążymy zrobić projektu, bo termin i bez tego jest napięty.

Co do szacunku. Chodzi mi o to, że podstawową zaletą szacowania jest to, że trwa ono mniej niż wykonanie zadania (np, zadanie na 2 dni szacujesz w 15 minut, a nie w 4 i pół dnia). Oczywisty skutek uboczny jest taki, że szacunki mogą nie zgadzać się z realizacją. Im mniej czasu trwa szacowanie tym rozrzut większy. Dlatego też pretensje o to, że jakieś zadanie nie zgadza się z szacowaniem to brak znajomości koncepcji szacowania.
Oczywiście, w Twoim przypadku rozumiem, że dostarczyłeś informacje i przekonywałeś, że kolegów szacują ze złymi założeniami - jeśli tego nie przyjęli to problem leży w komunikacji, albo oni nie słuchają, albo Ty nie umiałes przekazać.

jarekr000000 napisał(a):

Pisałem, że to był pseudo - pato scrum - nic tam nie estymowaliśmy. Estymaty były zrobione rok wcześniej przez inny zespół, przy innych założeniach.
Myśmy mogli tylko się zgadzać i commitować.

Esencja pato scruma.

Manadżer z Niemiec szybko dość zmęczył się tłumaczeniem mi, że rozwalam pracę zespołu i przez moje estymaty nie zdążymy zrobić projektu, bo termin i bez tego jest napięty.

Na pierwszym wykładzie ze statystyki miałem podany praktycznie identyczny przykład - skoro istnieje dodatnia korelacja pomiędzy śmiertelnością a liczbą łóżek w szpitalach, to jak zlikwidujemy szpitale, to ludzie przestaną umierać. Pytanie po co komu te estymaty, skoro i tak albo będzie dowiezione na czas, albo nie.

Co do szacunku. Chodzi mi o to, że podstawową zaletą szacowania jest to, że trwa ono mniej niż wykonanie zadania (np, zadanie na 2 dni szacujesz w 15 minut, a nie w 4 i pół dnia). Oczywisty skutek uboczny jest taki, że szacunki mogą nie zgadzać się z realizacją. Im mniej czasu trwa szacowanie tym rozrzut większy. Dlatego też pretensje o to, że jakieś zadanie nie zgadza się z szacowaniem to brak znajomości koncepcji szacowania.

Szacowanie pracy w SD jest obarczone z zasady dużym błędem. Nawet jak zrobisz ten szacunek najdokładniej jak się da, to i tak się rozjedzie w realizacji, bo ktoś musi coś doczytać, komuś zdechł chomik itp. Dlatego nie warto poświęcać czasu na dokładne szacowanie. Sens tej pracy widzę w podziale dużych tasków na mniejsze, przy okazji przegadanie co trzeba zrobić, jaki jest dobry sposób wykonania zadania. Jak zespół nie jest w stanie rozbić ficzera na taski, to nie jest w stanie go zaimplementować. Później jest już łatwo - wg. mnie wystarczy policzyć takie taski i jest to równie skuteczny sposób estymowania jak jakies tam scrum pokery. Na poziomie powyżej zespołu, tak jak napisałem, lepiej mieć listę zadań na 2 lata do przodu i narysować sobie 2 kreski na burndown charcie projektu i masz pesymistyczny, optymistyczny i prawdopodobny czas zakończenia wszystkiego, oparty na rzeczywistej, zakończonej pracy a nie "mi się wydaje, że to będzie proste".

somekind napisał(a):

Scrum wręcz upośledza komunikację, bo sprawia, że nie ma sensu proszenie o pomoc w trakcie dnia pracy, trzeba czekać na daily, nie można zgłaszać problemów w momencie ich wystąpienia, trzeba czekać na retro.

Skąd to wziąłeś? :D Czyli jak jest krytyk to PO grzecznie czeka na Daily by zgłosić potrzebę jego zrobienia? :D

somekind napisał(a):

I to jest właśnie chyba najpiękniejsze. Bo w praktyce, to robienie fundamentów jednego pomieszczenia to robota dla jednej osoby. Dwie wchodzą sobie w drogę i nawzajem przeszkadzają, więc w efekcie robią dwa razy dłużej i się nie wyrabiają na czas. Ale najważniejsze, że były zgodne z religią.

No w praktyce to jest team work. W czwartek skończyłem zalewać strop piwnicy. Budowa trwa od maja. A fundamenty robiliśmy we 4 osoby. I jak ja skończyłem spiżarkę to poszedłem do kuchni :P

p_agon napisał(a):

Im dłużej o tym czytam tym mniej wiem. Scrum je programski okvir procesa, koji se koristi za upravljanje kompleksnim razvojem. Scrum nije metoda ili tehnika razvoja sooftware-a

Wszystko co trzeba zrobić wpierw ląduje w Backlogu. Później tworzone są sprinty, najczęściej 2 tygodnie. Delegowanie zadan, dodanie priorytetow, ogolnie Jira mocno. Problemy sa opisywane na "stand-upach". Zarządza tym wszystkim SM. Cyklicznosc procesu pozwala na wypracowanie lepszych schematow dzialan. Stand-upy pomagaja w komunikacji w zespole. Tyle?

Nie. Masz dwa Backlogi. Za Backlog Produktu odpowiada PO, to jest jego rzecz. Backlog Sprintu to już są rzeczy wrzucone na Planningu i to już należy do zespołu. Nie ma tu z punktu widzenia managementu delegowania zadań. Zespół sam się nimi dzieli. Nie ma standupów tak technicznie, tylko Daily Scrum. Nie wiem czemu się utarło że ma być na stojąco (tzn. cel z XP znam, aby było zwiężle ;). Ja prowadziłem Daily i na leżąco. Sprinty są różne w różnych zespołach, ramy mówią o max miesiącu. Ja osobiście pracowałem w 1, 2, 3 i 4 tygodniowych. Scrum to ramy, takie minimum. Reszte sobie wypełniasz stosując różne inne rzeczy ze świata agile, z innych metodyk czy wypracowanych rzeczy przez lata :)