Mateusz Kapica
9 POSTY 2 KOMENTARZE
CTO w firmie Widelab, Agile Project Manager z dużym doświadczeniem w międzynarodowych projektach IT. Aktywnie działa w branży IT od ponad 13 lat. Po trzech latach spędzonych w Danii przy projekcie rewolucjonizującym duńskie koleje, obecnie rozwija Widelab - Product Design and Development Studio. Ponad 700 godzin na sali szkoleniowej jako trener. Na pierwszy rzut oka wydawałoby się, że Product Owner może się skupić na roadmapie, pielęgnowaniu backlogu produktu i pracy z interesariuszami mając obok siebie zespół wytwórczy, który cyklicznie dostarcza wartości biznesowe. I teraz, żeby PO mógł się skupić na „produktowych” obszarach, dobrze by było, aby „maszyna dostarczająca wartość” była odpowiednio naoliwiona. Dzisiaj przyjrzymy się kilku niuansom, o których istnieniu każdy...
Na blogu ProductVision mieliśmy już kilka artykułów dotyczących retrospektywy: Maciej Biegajewski we wpisie „14 błędów, których należy unikać podczas retrospektywy” podsumował, jak ustrzec się podstawowych błędów podczas organizacji retrospektyw.
„Nie daj się rutynie, czyli jak przeprowadzić ciekawą i angażującą retrospektywę?” to z kolei bardzo fajny wpis Grzegorza Wenca, jak w prosty i skuteczny sposób poprowadzić retro.
Z kolei artykuł...
Mottem naszego bootcampa „Product Management Academy” nie bez powodu jest hasło: „Przestań robić projekty, zacznij rozwijać produkty! Rób tylko to co ma sens!”. Prowadząc szkolenia i doradzając firmom, zauważam dość często, że osobom, które przez wiele lat pracowały w projektowym środowisku, niezwykle ciężko jest z dnia na dzień przestawić się na inny sposób myślenia. Żebyście mnie źle nie zrozumieli –...
„Douglas to najgorszy pracownik, jakiego możesz sobie wyobrazić. To ktoś, kto ucieleśnia wszystkie złe cechy, które czasem widzimy u ludzi. To twój złodziej, twój oszust, gaduła, obibok”. - Fabiola Eyholzer
Wiele organizacji tworzy zasady HR z myślą o Douglasie - aby go kontrolować i sprawdzać. Aby upewniać się, że swoim zachowaniem nie będzie powodował strat zakładając przy tym najgorszy scenariusz...
Prowadząc warsztaty lub doradzając zespołom wytwarzającym oprogramowanie często spotykam się z błędnymi przekonaniami na temat szacowania pracochłonności. Na początku chciałbym tutaj rozdzielić dwie, jakże różne, sytuacje: Szacowanie pracochłonności całego projektu przed jego rozpoczęciem, najczęściej w celu oszacowania budżetu i czasu potrzebnego na jego realizację (go – no-go, kwestie formalne, kontrakty, przetargi, itp.).
Szacowanie pracochłonności bieżącej pracy na potrzeby zaplanowania pracy...
W lutym tego roku Michael Küsters opublikował „Scream Guide” – doskonały antyporadnik Scruma napisany w podobnym stylu co Scrum Guide z tą różnicą, że uwypukla całą masę antywzorców. Antywzorców, które możemy spotkać w firmach na co dzień. Zacznijmy od początku: Scream - ramy postępowania (ang. framework), w których organizacja tworzy iluzję zaimplementowania Scruma, bez rozwiązywania znaczących problemów. Scream zapewnia złudzenie „Agile”,...
Retrospektywa jest odpowiedzią na 12. zasadę Manifestu Agile:
W regularnych odstępach czasu zespół analizuje możliwości
poprawy swojej wydajności, a następnie dostraja i dostosowuje
swoje działania do wyciągniętych wniosków.
Potężne narzędzie, które wykonane dobrze może przynieść nam wiele dobrego, ale jednocześnie, gdy wykonane zbyt mechanicznie i bez przemyślenia, może przynieść nam więcej szkody niż pożytku.
Wstęp
Dzisiaj chciałbym się z Wami podzielić Retrospektywą, którą miałem niedawno...
Jakiś czas temu Igor Springer w artykule Gdzie Scrum nie może tam Kanban pośle opisywał czym jest Kanban i jakie są jego podstawowe zasady. Dzisiaj chciałbym przyjrzeć się 7 marnotrawstwom, które definiuje Kanban.
Domyślnie są to: Zapasy (Inventory), Nadprodukcja (Overproduction), Zbędne przetwarzanie (Extra processing), Transport(Transportation), Oczekiwanie (Waiting), Zbędny Ruch (Motion), Braki oraz ich naprawa (Defects). Mary and Tom Poppendieck w niezłej książce...
W latach 60 i 70 ubiegłego wieku programiści musieli czekać nawet i 24 godziny na to, aby dowiedzieć się, czy ich program nie zawiera błędów. Wystąpienie błędu oznaczało, że trzeba było ten błąd znaleźć, naprawić i czekać kolejne 24 godziny na wynik. A teraz wyobraź sobie, że wciskasz pedał hamulca w swoim samochodzie, a pojazd reaguje 30 minut później. Albo...