#4 AGILE: Co to jest SCRUM?

[@zarzadzanieprojektami-mkapusta]

Więcej filmów o Agile znajdziesz na playliście: bit.ly/30HjfCl 💡 Nie zapomnij też o subskrypcji kanału :)

[@chadkarsyn4452]

instablaster

[@cwozy4esjm]

Najlepsze polskojęzyczne tłumaczenie SCRUMa, serio, jasno zwięźle czytelnie bez zbędnej motywacji i couchingu !

[@zarzadzanieprojektami-mkapusta]

Bardzo dziękuję :)

[@JolantaKulik-s9x]

dziekuje. Lubie proste tlumaczenia. Daja duzo wiecej niz czytanie slajdow

[@yourSOULismy]

Bardzo dobrze wytłumaczone. Dopiero zaczynam pracę w systemie scrum i pojawiły się słowa takie jak backlog i retrospekcje. Każdy powiedział kilka zdań co robi i po spotkaniu.

[@izasoma5550]

Pana filmiki są super 😍 właśnie jestem w trakcie pisania pracy magisterskiej na temat zwinnych metod zarządzania projektami, filmiki bardzo mi pomagają zrozumieć te metody, o co w nich chodzi.

[@zarzadzanieprojektami-mkapusta]

Super :). Jak idzie pisanie?

[@kamilove7416]

Te wykłady to złoto !

[@zarzadzanieprojektami-mkapusta]

Dzięki. Też tak myślę :)

[@marekchudy8893]

Dziękuję za przedstawienie istoty tej metodologii.

[@piotr5398]

Super wytłumaczony temat Panie Mariuszu, dziękuję!

[@piotrm795]

Niesamowite, że tego kanału nie znalazłem wcześniej :-| Fantastyczne wytłumaczone :-)

[@krzychob44]

Czas mija, odcinek nie traci na wartości. Bardzo przystępne i wizualne chwytliwe wytłumaczenie zasad i frameworku. Dzięki!

[@jakkowalik6134]

super. teraz to jest dla mnie bardzo jasne i proste. dziękuje

[@marek-kulczycki-8286]

Super filmik. Rozsyłam przyjaciołom i znajomym! Btw - kilka propozycji dla luźnego tłumaczenia "stand up" na polski: 1. "przy kawie o projekcie" 2. "przystanek" (ma coś ze stania i że ma krótko trwać) 3. "peryskopowa" (najbardziej abstrakcyjne - wynurzamy się na chwilę, aby sprawdzić, gdzie jesteśmy). I nie, żebym był fanatykiem unikania angielskiej terminologii. Ba, jako realista jestem pewien, że zostanie stand-up :)

[@dorotaczerniec1683]

w Scrum Guide nie ma mowy o Daily Standup - Jest Daily Scrum

[@Mactryb]

Super filmik, prosto, jasno i konkretnie. Bardzo dziękuję

[@zuzannamarzec9191]

Wreszcie to rozumiem, a przedstawienie graficzne zdecydowanie bardzo w tym pomogło! Świetny cykl filmików😁

[@zarzadzanieprojektami-mkapusta]

Bardzo się cieszę :)

[@maciekjutrzenka3844]

Konkretnie wyjaśnione. Dzieki

[@sawomircabajewski1139]

Niezwykle przejrzyście przedstawione. Dzięki!

[@kubuspuchatek1654]

Fajnie wytłumaczone, od razu poleciała łapka i sub

[@karolinakrajewska1973]

Świetnie przedstawione, życzyłabym sobie, żeby nauka była zawsze taka przyjemna ;)

[@zarzadzanieprojektami-mkapusta]

Cieszę się. Też sobie i Tobie tego życzę :)

[@lekkoiprzyjemnie]

Z tego co opisałeś, SCRUM jest dużo bardziej intuicyjny niż cały PRINCE2. Jak tylko pomyślę o prowadzeniu projektu w PRINCE to odrazu robi mi się słabo, tak SCRUM, to wręcz prosi się by to robić w ten sposób. Fajny materiał, dużo wyjaśniłeś, dzięki!

[@zarzadzanieprojektami-mkapusta]

No Prince ma swoje plusy, ale mocno ukryte ;).

[@lekkoiprzyjemnie]

@@zarzadzanieprojektami-mkapusta mocno ukryte i ukrywane przez wszystkich trenerów i szkoleniowców:)

[@maxjarzabek9360]

Świetny materiał, zaczynam studia w Październiku. Mam nadzieje, że twoje materiały pomogą jak najlepiej się przygotować do przebiegu studiów ;) Pozdrawiam.

[@zarzadzanieprojektami-mkapusta]

Super. Gdzie będziesz studiować?

[@maxjarzabek9360]

@@zarzadzanieprojektami-mkapusta Niestety praca nie pozwala podjąć studiów dziennych, natomiast jestem zainteresowany ofertą studiów zaocznych na jednej z Warszawskich uczelni ;)

[@karolas98]

Wszystko jasno wyjaśnione, dziękuję! :D

[@ukaszposmyk3431]

Super film, bardzo dobrze przekazana wiedza. Przydałby się jednak jeden moment w którym mogę sobie zrobić screen-a całej tablicy i wrcucić taką ściągę do notatek.

[@aniaju7138]

ale super!

[@tomaszpawowski2688]

Super 👌🏻👍🏻

[@piotrpietruszewski8367]

Bardzo ciekawy podcast. Dziękuję !:)

[@mkotpriv]

w końcu, ktoś mi to dobrze wytłumaczył :) dziękuję !!!

[@zarzadzanieprojektami-mkapusta]

Bardzo proszę :) Z ciekawości - wielu już próbowało tłumaczyć?

[@wielkie1ucho1slonia1]

Odpowiadasz na moje pytania zanim zdążę je zadać! Świetnie tłumaczysz, od razu wiedza zostaje w głowie. Czy znajdę jakieś Twoje filmy o testowaniu?

[@IDIOTEQTube]

Bardzo fajny materiał. Dzięki 👌

[@elizacieslewicz3358]

Świetnie przekazane, bardzo pomocny materiał!!!

[@dorotastyczynska8295]

Cześć , super prosto opowiadasz, ale skoro juz przygotowałeś workflow to może fajnie by było go przynajmniej raz odsłonić, zebry można było zobaczyć całość:) Czasem po prostu można stanąć z boku ( jka Pan Pogodynka) i pokazać te tablicę:)

[@oakmarek]

Dobra robota

[@ZythaarDarksoul]

Świetna robota. Jak widać, nie wszyscy dorośli jeszcze do nowego podejścia do pracy, a część ludzi przygląda się opakowaniu, bez zaglądania do środka. Inna część ludzi, jeszcze preferuje stary PRL-owski sposób pracy pt. "dniówka leci". Bez znaczenia jest, czy to co robię ma sens czy nie - ważne, że płacą. Czy SCRUM można zastosować w projekcie opartym o harmonogram i kamienie milowe do realizacji poszczególnych etapów harmonogramu przy założeniu, że dany etap jest odrębnym projektem? Co się tyczy zaś określeń angielskich to uważam, że jest to błąd. Język polski (choć za nim nie przepadam) jest na tyle bogaty, że bez problemu potrafi to wszystko opisać. To po prostu jakaś moda, że "angielskie brzmi mądrzej". Jako odpowiednik "Daily stand-up" proponunę "Narada na stojąco", "narada na postoju" lub bardziej slangowo "Codzienna postojówka" przez analogię do "nasiadówek", czyli spotkań na siedząco i to będzie najbliższe dosłownemu tłumaczeniu "Daily stand-up". Możliwości jest wiele.

[@zarzadzanieprojektami-mkapusta]

Możliwości nazywania po polsku jest sporo, ale jeżeli pewne terminy się przyjęły to nie chcę wprowadzać zamieszania. Moim celem jest propagowanie tej wiedzy i umiejętności. Ktoś może mieć misję ponazywania wszystkiego po polsku - będę wspierał, ale to nie moja bitwa :) Można skorzystać ze SCRUM jako sposobu dostarczania etapów w projekcie.

[@ZythaarDarksoul]

@@zarzadzanieprojektami-mkapusta Przekazanie wiedzy jest najistotniejsze, a jeszcze bardziej wtedy, gdy jest ona przystępnie przekazana. To, że po angielsku, ma znaczenie któreś-tam-rzędne. Nawiązałem do angielskiego dlatego, że niedawno byłem w pewnej firmie, w której Pan Menadżer używał owego przyjętego języka na tyle często, że po pewnym czasie słuchanie go było uciążliwe i niestety odciągało uwagę od przekazywanej treści, która jak się zgodziliśmy jest najważniejsza. Rozumiem, że są pewne słowa unikalne (np. wspomniany stand-up). Z drugiej strony jestem przekonany, że "Performance pracownika impactuje, poprzez indirecty na overall efficiency i targety spółki, co z kolei ma direct impact na image firmy" można powiedzieć normalnie. Słowo target zamiast celu? Impact zamiast wpływu? Proszę mi wierzyć, że na prawdę starałem się z uwagą słuchać tego, co mówił. Kosztowało to jednak wiele wysiłku, bo mówił prawie przez 2 godziny. Wolałbym już słuchać całości po angielsku. Było by prościej...

[@chromek9812]

Kawał solidnej roboty, dzięki :D

[@zarzadzanieprojektami-mkapusta]

Dzięki :)

[@rafasoinski6034]

Super wideo, wielkie dzięki!

[@nataliadziedzic9278]

Bardzo fajnie wytłumaczone od podstaw, dzięki!

[@RedLittleEvil]

Super! :)

[@maocackao7604]

super film

[@andrzejjabonowski1730]

Prosto, praktycznie, super! Wszystko i tak "wychodzi w praniu" :-)

[@justpaulinka]

super wytłumaczone wszystko, oby jak najwiecej tak pomocnych filmów!

[@powersroyale837]

dobry film

[@AndrzejA335]

Swietny film, bardzo obrazowo i konkretnie, pytanie tylko, gdzie w tym jast Kierownik produktu ??

[@zarzadzanieprojektami-mkapusta]

W Scrum takiej roli nie ma. Bo Scrum służy wytwarzaniu i jest albo elementem procesu projektowego albo niezależnie służy do wytwarzania produktu. Nie znaczy to, że PMowie nie są potrzebni. Co niektorzy sugerowali :)

[@lukaszstepien953]

Jako ciekawostka. Podejście scrum jest bardzo efektywne przy prowadzeniu zespołu analizującego poważne wypadki - pożary /awarie przemysłów / wypadki śmiertelne.

[@zarzadzanieprojektami-mkapusta]

Podeślesz link do case'u?

[@lukaszstepien953]

@@zarzadzanieprojektami-mkapusta będzie ciężko ponieważ nigdy się nie spotkałem z taką publikacją. :) Bazuje na swoim doświadczeniu / obserwacjach. W przypadku takich dochodzeń nikt nie mówi "teraz robimy scrum". Pewnie większość uczestników procesu nawet nie wie że taka metodyka istnieje. Ja pełnię na ogół funkcję facylitatora / sekretarza zespołu (nazwijmy to scrum mastera) i moim zadaniem jest organizacja pracy zespołu. Przechodząc na język scruma - backlog to 10-12 obszarów (zależnie od sytuacji) które są bazą do analizy przy takich zdarzeniach. Kwestie techniczne / pogoda/ przeszkolenie pracowników / kultura organizacji/ itd. Na podstawie tego zespół organizuje sobie sprinty (na ogół 4h - 8h) I wieczorem podsumowanie co wiemy, czego się nauczyliśmy i luźny plan na kolejny dzień. Rano spotkanie co na dany dzień i kolejny sprint na podstawie danych z dnia poprzedniego. Lider zespołu (PO) na podstawie tego co się dowiedzieliśmy wytacza w razie potrzeby nowe kierunki, bo rozpoczynając pracę nie mamy pojęcia gdzie dojdziemy. W przypadku poważniejszych zdarzeń, nawet jeżeli już produkt jest gotowy (znamy bezpośrednią przyczynę) to i tak backlog jest czyszczony do "0", żeby zanalizować wszystkie elementy i mieć pewność, że niczego nie pominięto i że udało nam się dogrzebać to samego spodu góry lodowej. Nie jest to na pewno scrum, który zyskałby nagrodę na konkursie kynologicznym ale robi robotę. :)

[@filipgrydz]

#zasieg

[@tommylub]

Pojawia się zespół. A kto dobiera zespół? Product Owner czy następuje to w jakiś inny sposób?

[@zarzadzanieprojektami-mkapusta]

Najczęściej dostajesz tych, którzy są dostępni. Product Owner jako taki nie dysponuje zasobami. Tutaj się zaczyna ta magia, która jest poza SCRUMem, czyli projekt albo organizacja i istniejaca struktura. W niewielu organizacjach można sobie zbudować zespół samemu. Mam nadzieję, że nie zamierzałem ;)

[@tommylub]

@@zarzadzanieprojektami-mkapusta Odpowiedź jest precyzyjna i jasna, dziękuję. Natomiast sama tematyka jest dla mnie nowa, dlatego zastanawiam się czy dałoby się wykorzystać Scrum w sytuacji gdy: 1./ Musimy sami dobrać ludzi różnych umiejętności do danego projektu. 2./ Organizacja jest niewielka i czy wówczas Product Ownerem i/lub Scrum Masterem może być ta sama osoba (np. szef, oczywiście z odpowiednimi umiejętnościami).

[@zarzadzanieprojektami-mkapusta]

@@tommylub Moja odpowiedź- da się. Łamie to kanon, bo role Product Ownera i Scrum Mastera są inne, ale dla mnie wykonalne jak najbardziej. W sytuacji, o ktorej piszesz jest jeszcze to, że szef ma dużo do powiedzenia i warto zadbać o to, żeby system i zasady obejmowały też szefa, bo tutaj kryje się największe zagrożenie :)

[@piotrpietruszewski8367]

A co jeśli na sprint planningu wyjdzie, że sprawniej będzie zrealizować punkt będący niżej na dole listy? Przykład: w product backlogu mamy takie priorytety 1. Strona Główna 2. Blog 3. Galeria, a na sprint planningu developerzy zasugerują, żeby odwrócić kolejność co usprawni wdrożenie?

[@zarzadzanieprojektami-mkapusta]

Usprawni w jakim sensie? Całość zajmie krócej? Która z tych opcji dostarczy większą wartość? Na koniec to decyzja PO.

[@piotrpietruszewski8367]

@@zarzadzanieprojektami-mkapusta The Team zasugeruje, że najpierw lepiej zrobić galerię, bo można ja tez użyć na blogu, a komponenty użyte przy punktach 2 i 3 można użyć przy SG. Czyli jeśli ma się coś wydarzyć w innej sekwencji niż jest w product backlogu to musi to klepnąć PO?

[@zarzadzanieprojektami-mkapusta]

@@piotrpietruszewski8367 Tak. Backlog wyznacza priorytety. I czasem np. Team mówi - jak zrobimybw odwrotnej kolejności to zajmie nam 2 sprinty a nie 3. Co Ty na to? O wtedy to PO decycuje w zależności co ważniejsze - szybko mieć stronę główną, czy mieć całość taniej.

[@MichaLipek]

Hej, KZbin podpowiedział mi ten film. Ale jako, że jestem programistą i scrum masterem, i pracuję na codzień w scrumie, chciałem kilka rzeczy sprostować, bo jest ok, ale nie do końca. Co do backlogu. "Ta lista może mieć kilkaset elementów, nie ma to większego znaczenia". Nie, to nie prawda. Backlog powinien być mały i powinien zawierać dość dobrze podzielone, małe i przegadane zadania na następną iterację, może na dwie. I trochę planów na przyszłość, ale im jesteśmy niżej w backlogu, tym bardziej zgadujemy kiedy coś zostanie dostarczone i czy w ogóle. Powiedziałbym, że jeżeli zespół robi około 5 zadań na sprint, to w backlogu powinniśmy mieć około 20 elementów. Dlaczego? Bo zarządzanie długim backlogiem to straszna strata czasu. W pewnym momencie nie wiesz czy coś już tam jest, czy trzeba dodać. Trudno się też priorytetyzuje, robi się bałagan (brak przejrzystości). Wracając do powyższego przykładu, jeżeli zespół robi średnio 5 zadań na sprint, to kiedy zrobimy te 150 od góry? Czy za kilka lat ono będzie miało sens? Duży backlog to marnotrawstwo. Im mniejszy, tym lepszy.

[@MichaLipek]

Co do planowania, to nie wspomniałeś o najważniejszym - o sprint goalu. Każdy sprint musi mieć cel i ten cel powinien być wartościowy. To czy się iteracja udała czy nie zależy też od tego czy dostarczyliśmy cel sprintu. W drugą stronę, jeżeli cel sprintu staje się nieaktualny, powinniśmy przerwać sprint i wrócić do planowania. To co nam daje cel sprintu, to skupienie na najważniejszej rzeczy, często wpływa na to jakie elementy backlogu produktu weźmiemy (czyli wybranie celu sprintu na planowaniu czasami zmienia priorytety). Idąc bardziej wgłąb zespołu, dobry cel sprint ma korzystny wpływ na context switching. Nie chcemy przecież, żeby każdy z zespołu pracował nad innym zadaniem. Celem tu jest, żeby zespół pracował razem nad najważniejszą rzeczą. Celem sprintu nie jest jedno zadanie, to często coś innego. Bywa, że to się jakoś mapuje, że np. dowiezienie 3 zadań realizuje cel, ale widziałem sytuację, że cel udało się zrealizować bez dostarczenia wszystkich zadań, bo cel to trochę coś innego.

[@MichaLipek]

Daily stand-up? Skąd ten stand-up? Po prostu daily meeting, nikt nie musi stać. O ile się nie mylę, daily na stojąco to była praktyka eXtreme Programmingu (XP). Ale reszta o daily to szczera prawda. Bardzo dobrze opisałeś to zdarzenie i cieszę się, że nie mówiłeś o 3 słynnych pytaniach, które są bez sensu.

[@MichaLipek]

Podsumowująć, świetny film opisujący scruma. :) A to co opisałem, to naprawdę detale.

[@zarzadzanieprojektami-mkapusta]

Tak, masz rację, że za duży wskazuje na pewne problemy. I czasem można je zaadresować. A czasem nie ma co się kopać z koniem i po prostu pracujesz na tych góra 20 elementach z góry. Ja wolę sobie co jakiś czas wyczyścić taką listę, bo często tam są historyczne pomysły, które nie mają racji bytu, żeby backlog był czytelny i prosty. Dzięki za zwrócenie uwagi na to.

[@KondzioTVstudio]

szkoda ze nie dales linku do zdjecia tego calego twoje tla bo by sie przydalo.

[@zarzadzanieprojektami-mkapusta]

Pokombinujemy może nad takimi materialami. To dobry pomysł. 👍

[@MichaLipek]

Jako praktyk tej metody, dorzucę kilka słów od siebie. Pamiętajmy skąd się Scrum wziął. Został zbudowany na bazie Toyota Production System, Leana i eXtreme Programmingu i Agile Manifesto, ale też serii experymentów twórców scruma w prawdziwych organizacjach. Scrum jest metodą zwinną, więc warto w pierwszej kolejności przeczytać te kilka punktów manifestu zwinnego. Scrum ostatnio ma zły PR. Moim zdaniem powodem tego jest, że wygląda prosto, ale w rzeczywistości jest trudny do ogarnięcia. Dużym problemem w organizacjach, które wdrożyły Scrum jest kult cargo. Ludzie zaczynają stosować praktyki Scruma, powstają nazwy stanowisk jak PO i SM, natomiast nie widać z tego wiele korzyści, ponieważ ciągle działamy po staremu, tylko dołożyliśmy sobie proces, który wręcz pogorszył tempo pracy. Często nadal mamy menedżerów sterujących tym co będzie robione, brak wiedzy PMa przerobionego w Scrum Mastera, i brak pozwolenia na bycie prawdziwie samozarządzającym się zespołem scrumowym. Często też widać, że organizacje rozliczają developerów z ich oszacowań. To co moim zdaniem jest w scrumie najważniejsze i generalnie w każdym zwinnym podejsciu, to że w przeciwieństwie do klasycznych metod zarządzania, akceptujemy, że nie wiemy co się stanie i staramy się zarządzać nieznanym. Dlatego z góry można odrzucić Scruma, jeżeli nasz projekt jest oczywisty i wiemy co dokładnie na końcu powstanie. Ale też, jeżeli to co robimy jest kompletnie nieprzewidywalne, Scrum też nie ma sensu (np. organizacja pracy w izbie przyjęć). Jak już się pewnie niektórzy domyślają, nawiązuję do frameworku Cynefin. Zwinne podejście ma sens w przypadku problemów z ćwiartki nazwanej complex (problemy złożone). I w związku z tym można spojrzeć na zwinne podejście trochę jak na metodę naukową: mamy problem do rozwiązania (użytkownicy chcą coś móc zrobić), stawiamy hipotezę (robi to zespół), wdrażamy, testujemy jak działa nasze rozwiązanie, analizujemy wyniki (warto mieć dane i metryki!) i poprawiamy hipotezę albo uznajemy, że to nam wystarcza. Eksperymentowanie jest wpisane w zwinne podejście, bo z założenia nie wiemy jak rozwiązać problem zanim nie przejdziemy do fazy realizacji. Mamy pomysł, ale często niekomplenty, albo zły. Bardzo często wychodzą rzeczy w trakcie, o których nie pomyśleliśmy. Albo w trakcie realizacji trafiamy na lepsze rozwiazanie. Dlatego szacowanie długoterminowe tak często nie działa, bo po prostu jest niemożliwe. Niektórzy po prostu oszukują się, że to się da zrobić. Innym moim zdaniem świetnym opisem zwinnego podejścia, a więc i scruma, jest skracanie pętli feedbacku. I warto tu na scruma spojrzeć, że to co on opisuje, to jest minimum. Nie musimy czekać na opinię klienta do sprint review, jeżeli mamy z nim stały kontakt, to lepiej. A jeżeli siedzi z nami w jednym pokoju (jak to opisuje XP), to jeszcze lepiej. Natomiast nie chodzi tylko o tę pętle feedbacku, ale o każdą. W przypadku software developmentu będzie to szybki feedback, że aplikacja działa (czyli chcemy mieć szybkie testy automatyczne), szybki feedback od innych członków zespołu, że nasz kod jest ok (czyli będziemy preferować synchroniczne code review lub wręcz pair/mob programming), szybki feedback od specjalisty QA (czyli tester jest członkiem zespołu scrumegi i będzie uczestniczył w budowie aplikacji przez cały czas), itp, itd.

[@zarzadzanieprojektami-mkapusta]

Zgadzam się z tym, co piszesz. Tylko co donklasycznego zarządzania to nie wiem dlaczego tak się utarło, że nie było tam niczego z zarządzania ryzykiem. Beznadziejne zarządzanie faktycznie nie zakłada ryzyka. Klasyczne jak najbardziej je uwzględnia. Marketingowa dyskusja skierowała uwagę nie w tę stronę co trzeba. Na szczęście Twoje komwntarze dają mi nadzieję na to, że można podejść do tematu niereligijnie :).

[@yes_temp_sem]

pozdro z ueka xdd

[@spideredek]

Cześć. Czy jest ok to aby produkt owner pełnił tez role scrum mastera?

[@zarzadzanieprojektami-mkapusta]

To jest mocno ryyzkowne, bo kto będzie Coachował Product Ownera ;). Wg. najlepszych praktyk warto to rodzielić. Czasem nie ma wyjścia i można to pogodzić. Ja sobie to wyobrażam. Warunek to spora samoświadomość PO w tej roli, żeby potrafił sam siebie skontrolować.

[@MatiGentelman]

Brakuje mi jednego elementu: w początkowej fazie projektu większość klientów chce wiedzieć kiedy otrzyma 100 % produktu. Kiedy i jak to oszacować?

[@zarzadzanieprojektami-mkapusta]

Jest kilka tematów do ogarnięcia. Bo sytuacja złożona. Na co zwrócić uwagę A. Jakiego typu to jest projekt - Jeżeli to projekt R&D lub pilotażowy to mamy spore ryzyko, że zakres nie jest możliwy do podania i będzie to "lekka ściema" - kzbin.info/www/bejne/nmjUcn6rg6ZsoKs B. Jeżeli nie chcemy ściemniać to tego typu projekt trzeba poprowadzić na zasadzie Time Material, a nie fixed-price. Bo nie wiemy jak naprawdę będzie C. Jeżeli jednak mamy do czynienia z klientem, który koniecznie chce mieć obiecane co i na kiedy, to taki projekt ma spore ryzyko, które trzeba uwzględnić w cenie. I wtedy najlepiej zrobić to korzystając z którejś z technik szacowania (kzbin.info/www/bejne/oXmbcnyoqKh_iMU) + policzenie tego ryzyka (kzbin.info/www/bejne/bJ6TfomgbpaiZ6M) Czysto kontrakty "zwinne" powinny być time & material. Rzeczywistość jest taka, że klienci chcą stałą cenę i robi się łączenie dwóch rzeczywistości. Wtedy to oznacza standardowe wykłócanie się o change requesty i zwinność potrafi szlag trafić. Stąd pomysł na różne hybrydy, bo nikt nie chce wziąć na siebie ryzyka. To tak w skrócie, mam nadzieję, że dało jakiś kierunek rozwiązania :)

[@MatiGentelman]

@@zarzadzanieprojektami-mkapusta Nooo! To dużo wyjaśnia. :) Zaczynam rozumieć co u nas nie działa i dlaczego... :) Dzięki!

[@czipendejs]

film trwa 15 minut, skomplikowane to nie jest a kurs scrum kosztuje kilka tysięcy. Jak to jest?

[@zarzadzanieprojektami-mkapusta]

Jak nie wiadomo o co chodzi to chodzi o coś. Na poważnie to istnieje sporo niuansów we wdrażaniu, tylko one już nie są stricte Scrumowe. W szkoleniach płacisz za skupienie ludzi w jedynm czasie na nauce i przekazaniu wiedzy. Dla mnie w tym ważniejsze jest skupienie się na tym "jak tego użyć" i chciałbym wierzyć, że większość kursów na tym się skupia.

[@vezzosetto]

"product owner jest w stanie powiedzieć na czym mu bardziej zależy" - czyli musi być mężczyzną?

[@zarzadzanieprojektami-mkapusta]

Tak. Musi. Bo w przypadku "product owner kobiety" oczywiste jest, że usłyszysz, zresztą bardzo słusznie, "domyśl się". Powinienem był o tym wspomnieć.

[@sebb1728]

W praktyce SCRUM to zwykle tasowanie ticketami w JIRA, niekonczace sie bezsensowne "scrum meetings" i "sprint retrospective" z ktorych nic nie wynika, bo nigdy nie ma czasu na wdrozenie proponowanych "ulepszen". Jest tylko narastajacy "technical debt", frustracja i ciagle przenoszenie calego stada niedokonczonych ticketow z jednego sprintu do kolejnego. Agile i SCRUM przerabialem (jako programista) w 3 firmach (2 sredniej wielkosci i 1 duze korpo), nigdy nie spotkalem scrum mastera, za ktorym bym tesknil gdyby wywalili go z projektu. Jak dla mnie Daily scrum to zawsze byl najgorszy moment dnia. Oczywiscie moje doswiadczenia ze SCRUM moga po prostu wynikac z pecha - trafilem na mega zle zarzadzane projekty i tyle.

[@adamfatyga7977]

Szukam informacji: kto to jest Scrum Master Każdy mówi co innego :(

[@zarzadzanieprojektami-mkapusta]

A co już wiesz? W Scrum Guide jest wykładania jedyna prawdziwa - Scrum Master Scrum Master ponosi odpowiedzialność za to, aby Scrum był stosowany zgodnie z tym, co zostało opisane w tym Przewodniku. Realizuje to zadanie, pomagając wszystkim w zrozumieniu teorii i praktyki Scruma, zarówno w samym Scrum Teamie, jak i w organizacji. Scrum Master ponosi odpowiedzialność za efektywność Scrum Teamu. Czyni to poprzez stwarzanie mu odpowiednich warunków do poprawy stosowanych przez niego praktyk, zgodnie z regułami Scruma. Scrum Masterzy to prawdziwi liderzy działający na rzecz Scrum Teamu, jak i szerzej rozumianej organizacji. Scrum Master wspiera Scrum Team na kilka sposobów, m.in.: ● instruuje członków zespołu, na czym polega samozarządzanie i interdyscyplinarność; ● pomaga Scrum Teamowi skupić się na wytwarzaniu wartościowych Incrementów zgodnych z Definicją Ukończenia; ● sprawia, że przyczyny ograniczające postępy Scrum Teamu zostają usunięte; oraz ● dba o to, aby wszystkie wydarzenia scrumowe się odbywały, były konstruktywne i produktywne oraz by mieściły się w wyznaczonych ramach czasowych. Scrum Master wspiera Product Ownera na kilka sposobów, m.in.: ● pomaga znajdować techniki pozwalające na skuteczne określenie Celu Produktu oraz zarządzanie Product Backlogiem; ● pomaga Scrum Teamowi zrozumieć potrzebę jasnego i zwięzłego formułowania elementów Product Backlogu; ● pomaga wprowadzać empiryczne podejście do planowania pracy nad produktem w złożonym środowisku; oraz ● wspomaga współpracę z interesariuszami, kiedy zostanie o to poproszony lub kiedy zachodzi taka potrzeba. Scrum Master wspiera organizację na różne sposoby, m.in.: ● przewodzi organizacji, szkoli i instruuje ją w procesie wdrażania Scruma; ● planuje i doradza w wykorzystaniu Scruma w organizacji; ● pomaga pracownikom i interesariuszom w zrozumieniu oraz stosowaniu empirycznego podejścia do złożonych problemów; oraz ● usuwa bariery pomiędzy interesariuszami a Scrum Teamami.

[@adamfatyga7977]

@@zarzadzanieprojektami-mkapusta Ok, z czasem staje się to coraz jaśniejsze. Czy Scrum Master musi znać się na zarządzaniu projektami? Czy tylko "po łebkach", tyle co programiści?

[@zarzadzanieprojektami-mkapusta]

Teoretycznie to nie musi, ale praktycznie jak się nie zna to wg. mnie wartość z niego niewielka. Ale na 100% znajdzisz kogoś, kto się ze mną nie zgodzi :). Scrum Master wg. mnie to rola dla wymiatacza docelowo, a nie kogoś, kto tylko udaje, że wie co robi.

[@wBacz]

wiem, że naganiasz na szkolenia, ale scrum to syf, a scrum masterzy to najzbędniejsza osoba w organizacji. Jestem programistą i wiem co mówię.

[@zarzadzanieprojektami-mkapusta]

Mocne słowa odnośnie SCRUM :) I Scrum Masterów. Może Cię zaskoczę, ale są sytuacje, gdy się z Tobą zgodzę :). Tak, SCRUM nie jest lekiem na wszystko. I tak wielu Scrum Masterów nie jest tak dobra jak być powinna. Ale to, co piszesz jest tak samo niesprawiedliwe jak mówienie, że programiści to rozpieszczone primadonny, które nie słuchają potrzeb klientów ;). Nie fair. Mam nadzieję, że da się odczytać na kanale jakie mam podejście do szkoleń, projektów, agile i zarządzania. Nie ma idealnych rozwiązań, SCRUM nie jest moim pierwszym wyborem, który proponuję i nie najważniejszym obszarem szkoleń. Ale nie skreślam rzeczy, które są pomyślane z sensem. A SCRUM mimo wszystko jest. Chociaż wdrażanie w życie to inna sprawa.

[@wBacz]

@@zarzadzanieprojektami-mkapusta programista dostarcza produkt czasem lepiej czasem gorzej, to jest robol, a scrum master, całe to stanowisko jako idea, nie dostarcza nic pożytecznego.

[@zarzadzanieprojektami-mkapusta]

@wBacz Jako idea może nie jest aż tak źle :) Nie sądziłem, że będę bronił SCRUMa, bo sam mam wiele "ale". To jest bardzo wymagająca rola, żeby robić ją dobrze. Potrzeby rynku sprawiły, że powstała jak zwykle "nadprodukcja" Scrum Masterów, którzy nie mają dość doświadczenia, charyzmy, żeby to dźwignąć. Wszystko ma swój sens w swoim kontekście.

[@synterr]

Niektórzy mówią, że dobrze wdrożony scrum czyni cuda i się sprawdza. Prawda jest taka, że scrum w założeniu to miał być tryb awaryjny dla firmy, kiedy np. trzeba było poprawiać jakieś krytyczne błędy w aplikacjach. Korporacje i janusze biznesu aspirujący do miana "korporacji", używają jednak tego po to, by wyciskać pracowników jak cytryny. Przychodzi jakiś programista, to wiadomo że to taki "robol", nie to co jakaś "scrum masterka". Jeszcze jak się to połączy z mikrozarządzaniem i innymi uwłaczającymi praktykami, to nic tylko uciekać z tak toksycznej firmy. W każdym razie ja uważam, że wystarczy normalnie porozmawiać, zwłaszcza w małych i średnich firmach o tym co robimy, następnie dać mądrym ludziom pole do działania. Każdy człowiek ma inny styl pracy. Ja np. "opierdzielam się" przez 4 dni a w piąty dzień koduję, jak mi się już wszystko ułoży w głowie. Kod się rozwija naturalnie, można dużo przemyśleć, porozmawiać z innymi ludźmi na luzie. Rzecz w tym, że są firmy które działają z powodzeniem bez wdrażania zamordyzmu i są to firmy bardzo innowacyjne, w których panuje wysoka kultura. Nie trzeba jej wymuszać korporacyjnymi wymysłami, ponieważ ludzie na poziomie wiedzą jak się zachować. Innymi słowy, ważny jest dobrze dobrany zespół, ważny jest normalny, ludzki szef a wtedy cała reszta po prostu funkcjonuje w zdrowy sposób. Może wyciska się jedynie 50% z pracowników, może proces trwa wolniej, ale przynajmniej finalny produkt jest lepszy, widać w nim serce i zaangażowanie pracowników. Jestem za naturalnymi metodami pracy.

[@wBacz]

@@synterr popieram

[@MadBunnyRabbit]

Ja nic nie rozumiem. To jest tylko jakiś głupi sposób organizacji pracy? To jak wymagają ode mnie znajomości tego, gdzie nawet nie będę żadnym team leaderem to co to znaczy? Czego ja mam się tutaj niby nauczyć? Jak będę w zespole i będziemy mieli spotkania, czy te standupy no to będę tam, tak? To jest jakieś bezsensowne wymyślanie jakiś bzdur. Przychodzę do pracy, mamy spotkanie, team leader coś tam pogada, dostaje zadanie i robię, a nie jakieś agile, scrum i inne gówna. To już się nich ci team leaderzy martwią jak najlepiej organizować ludziom pracę.

[@zarzadzanieprojektami-mkapusta]

Jeżeli grasz z kimś w jakąś grę zespołową to oczekujesz, że rozumie zasady, prawda? Jest pewien poziom gry, na który nie wejdziesz, jeśli będziesz stawiał się w pozycji "organizacja pracy zespołu to nie mój problem". Nie ma przymusu zrozumienia jak działa firma, jak działa zespół, czy jak działa klient, dla którego tworzy się rozwiązanie. Naturalna selekcja rozwija!uje temat. Nie wiem jak Ty, ale ja lubię pracować z ludźmi, którzy chcą brać na siebie odpowiedzialność za sukces zespołu. To "coś tam lider pogada" maga znaczenie dla Ciebie. Dlaczego? Bo albo mówi z sensem i dzięki temu Ty osiągniesz lepsze rezultaty, albo pierd..... bzdury i wiesz, że z takiego zespołu trzeba się ewakuować. Ale to już Ty wybierasz swoją scieżkę. Ten kanał i filmy są dla tych, którzy biorą na siebie rolę lidera.

[@oziesiek666]

seplenisz i nie da sie ciebie sluchac

[@zarzadzanieprojektami-mkapusta]

Dziękuję za Twoją opinię.

[@zlyandrzej]

daruj sobie chamstwo

[@zarzadzanieprojektami-mkapusta]

@@zlyandrzej Ale ja tylko podziękowałem za opinię :(

[@danielhojo395]

@@zarzadzanieprojektami-mkapusta zlyandrzej chciał pewnie odpowiedzieć oziesiek666 a nie Tobie PS. film super! Dzięki

[@zarzadzanieprojektami-mkapusta]

@@danielhojo395 Wiem, taki żart z czapki. Dzięki :)