Więcej filmów o Agile znajdziesz na playliście: bit.ly/30HjfCl 💡 Nie zapomnij też o subskrypcji kanału :)
@chadkarsyn44523 жыл бұрын
instablaster
@cwozy4esjm Жыл бұрын
Najlepsze polskojęzyczne tłumaczenie SCRUMa, serio, jasno zwięźle czytelnie bez zbędnej motywacji i couchingu !
@zarzadzanieprojektami-mkapusta Жыл бұрын
Bardzo dziękuję :)
@user-yl4mb6kn6m3 ай бұрын
dziekuje. Lubie proste tlumaczenia. Daja duzo wiecej niz czytanie slajdow
@krzychob442 ай бұрын
Czas mija, odcinek nie traci na wartości. Bardzo przystępne i wizualne chwytliwe wytłumaczenie zasad i frameworku. Dzięki!
@kamilove7416 Жыл бұрын
Te wykłady to złoto !
@zarzadzanieprojektami-mkapusta Жыл бұрын
Dzięki. Też tak myślę :)
@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?
@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.
@piotr5398 Жыл бұрын
Super wytłumaczony temat Panie Mariuszu, dziękuję!
@marek-kulczycki-82863 жыл бұрын
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
@piotrm7952 жыл бұрын
Niesamowite, że tego kanału nie znalazłem wcześniej :-| Fantastyczne wytłumaczone :-)
@marekchudy88933 жыл бұрын
Dziękuję za przedstawienie istoty tej metodologii.
@jakkowalik61343 жыл бұрын
super. teraz to jest dla mnie bardzo jasne i proste. dziękuje
@zuzannamarzec91913 жыл бұрын
Wreszcie to rozumiem, a przedstawienie graficzne zdecydowanie bardzo w tym pomogło! Świetny cykl filmików😁
@zarzadzanieprojektami-mkapusta3 жыл бұрын
Bardzo się cieszę :)
@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:)
@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ę:)
@Mactryb3 жыл бұрын
Super filmik, prosto, jasno i konkretnie. Bardzo dziękuję
@maciekjutrzenka38444 жыл бұрын
Konkretnie wyjaśnione. Dzieki
@ukaszposmyk34313 жыл бұрын
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.
@karolinakrajewska19735 жыл бұрын
Świetnie przedstawione, życzyłabym sobie, żeby nauka była zawsze taka przyjemna ;)
@zarzadzanieprojektami-mkapusta5 жыл бұрын
Cieszę się. Też sobie i Tobie tego życzę :)
@sawomircabajewski11395 жыл бұрын
Niezwykle przejrzyście przedstawione. Dzięki!
@kubuspuchatek1654 Жыл бұрын
Fajnie wytłumaczone, od razu poleciała łapka i sub
@maxjarzabek93602 жыл бұрын
Świetny materiał, zaczynam studia w Październiku. Mam nadzieje, że twoje materiały pomogą jak najlepiej się przygotować do przebiegu studiów ;) Pozdrawiam.
@zarzadzanieprojektami-mkapusta2 жыл бұрын
Super. Gdzie będziesz studiować?
@maxjarzabek93602 жыл бұрын
@@zarzadzanieprojektami-mkapusta Niestety praca nie pozwala podjąć studiów dziennych, natomiast jestem zainteresowany ofertą studiów zaocznych na jednej z Warszawskich uczelni ;)
@mkotpriv3 жыл бұрын
w końcu, ktoś mi to dobrze wytłumaczył :) dziękuję !!!
@zarzadzanieprojektami-mkapusta3 жыл бұрын
Bardzo proszę :) Z ciekawości - wielu już próbowało tłumaczyć?
@ZythaarDarksoul4 жыл бұрын
Ś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-mkapusta4 жыл бұрын
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.
@ZythaarDarksoul4 жыл бұрын
@@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...
@aniaju71382 жыл бұрын
ale super!
@oakmarek3 жыл бұрын
Dobra robota
@karolas983 жыл бұрын
Wszystko jasno wyjaśnione, dziękuję! :D
@IDIOTEQTube2 жыл бұрын
Bardzo fajny materiał. Dzięki 👌
@wielkie1ucho1slonia12 жыл бұрын
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?
@tomaszpawowski2688 Жыл бұрын
Super 👌🏻👍🏻
@piotrpietruszewski83673 жыл бұрын
Bardzo ciekawy podcast. Dziękuję !:)
@elizacieslewicz33584 жыл бұрын
Świetnie przekazane, bardzo pomocny materiał!!!
@rafasoinski60344 жыл бұрын
Super wideo, wielkie dzięki!
@nataliadziedzic92783 жыл бұрын
Bardzo fajnie wytłumaczone od podstaw, dzięki!
@chromek98124 жыл бұрын
Kawał solidnej roboty, dzięki :D
@zarzadzanieprojektami-mkapusta4 жыл бұрын
Dzięki :)
@andrzejjabonowski17304 жыл бұрын
Prosto, praktycznie, super! Wszystko i tak "wychodzi w praniu" :-)
@maocackao76042 жыл бұрын
super film
@lukaszstepien9533 жыл бұрын
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-mkapusta3 жыл бұрын
Podeślesz link do case'u?
@lukaszstepien9533 жыл бұрын
@@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ę. :)
@justpaulinka4 жыл бұрын
super wytłumaczone wszystko, oby jak najwiecej tak pomocnych filmów!
@powersroyale8373 жыл бұрын
dobry film
@RedLittleEvil4 жыл бұрын
Super! :)
@yes_temp_sem3 жыл бұрын
pozdro z ueka xdd
@DoubleShare3 жыл бұрын
Pozdro XD
@kremuwczan3 жыл бұрын
POZDRO OD DISA
@AndrzejA3353 жыл бұрын
Swietny film, bardzo obrazowo i konkretnie, pytanie tylko, gdzie w tym jast Kierownik produktu ??
@zarzadzanieprojektami-mkapusta3 жыл бұрын
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 :)
@MichaLipek2 жыл бұрын
Hej, KZfaq 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.
@MichaLipek2 жыл бұрын
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.
@MichaLipek2 жыл бұрын
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.
@MichaLipek2 жыл бұрын
Podsumowująć, świetny film opisujący scruma. :) A to co opisałem, to naprawdę detale.
@zarzadzanieprojektami-mkapusta2 жыл бұрын
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.
@MichaLipek2 жыл бұрын
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-mkapusta2 жыл бұрын
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 :).
@piotrpietruszewski83673 жыл бұрын
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-mkapusta3 жыл бұрын
Usprawni w jakim sensie? Całość zajmie krócej? Która z tych opcji dostarczy większą wartość? Na koniec to decyzja PO.
@piotrpietruszewski83673 жыл бұрын
@@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-mkapusta3 жыл бұрын
@@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.
@tommylub5 жыл бұрын
Pojawia się zespół. A kto dobiera zespół? Product Owner czy następuje to w jakiś inny sposób?
@zarzadzanieprojektami-mkapusta5 жыл бұрын
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 ;)
@tommylub5 жыл бұрын
@@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-mkapusta5 жыл бұрын
@@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 :)
@MeggaFelipe3 жыл бұрын
#zasieg
@MatiGentelman4 жыл бұрын
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-mkapusta4 жыл бұрын
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" - kzfaq.info/get/bejne/np2hdK6ms6edmn0.html 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 (kzfaq.info/get/bejne/oa5odKyj2Kmwgpc.html) + policzenie tego ryzyka (kzfaq.info/get/bejne/bNNggLmbnpfTYXU.html) 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 :)
@MatiGentelman4 жыл бұрын
@@zarzadzanieprojektami-mkapusta Nooo! To dużo wyjaśnia. :) Zaczynam rozumieć co u nas nie działa i dlaczego... :) Dzięki!
@KondzioTVstudio2 жыл бұрын
szkoda ze nie dales linku do zdjecia tego calego twoje tla bo by sie przydalo.
@zarzadzanieprojektami-mkapusta2 жыл бұрын
Pokombinujemy może nad takimi materialami. To dobry pomysł. 👍
@spideredek2 жыл бұрын
Cześć. Czy jest ok to aby produkt owner pełnił tez role scrum mastera?
@zarzadzanieprojektami-mkapusta2 жыл бұрын
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ć.
@czipendejs2 жыл бұрын
film trwa 15 minut, skomplikowane to nie jest a kurs scrum kosztuje kilka tysięcy. Jak to jest?
@zarzadzanieprojektami-mkapusta2 жыл бұрын
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.
@vezzosetto11 ай бұрын
"product owner jest w stanie powiedzieć na czym mu bardziej zależy" - czyli musi być mężczyzną?
@zarzadzanieprojektami-mkapusta11 ай бұрын
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.
@adamfatyga79779 ай бұрын
Szukam informacji: kto to jest Scrum Master Każdy mówi co innego :(
@zarzadzanieprojektami-mkapusta9 ай бұрын
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.
@adamfatyga79779 ай бұрын
@@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-mkapusta9 ай бұрын
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.
@wBacz3 жыл бұрын
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-mkapusta3 жыл бұрын
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.
@wBacz3 жыл бұрын
@@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-mkapusta3 жыл бұрын
@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.
@synterr3 жыл бұрын
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.
@wBacz3 жыл бұрын
@@synterr popieram
@MadBunnyRabbit5 жыл бұрын
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-mkapusta5 жыл бұрын
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.
@oziesiek6664 жыл бұрын
seplenisz i nie da sie ciebie sluchac
@zarzadzanieprojektami-mkapusta4 жыл бұрын
Dziękuję za Twoją opinię.
@zlyandrzej4 жыл бұрын
daruj sobie chamstwo
@zarzadzanieprojektami-mkapusta4 жыл бұрын
@@zlyandrzej Ale ja tylko podziękowałem za opinię :(
@danielhojo3954 жыл бұрын
@@zarzadzanieprojektami-mkapusta zlyandrzej chciał pewnie odpowiedzieć oziesiek666 a nie Tobie PS. film super! Dzięki
@zarzadzanieprojektami-mkapusta4 жыл бұрын
@@danielhojo395 Wiem, taki żart z czapki. Dzięki :)