Prezentacja Michała Koniewicza z 9. spotkania PMI Szczecin w dn. 22 marca 2016 r., pn. "SCRUM - jak ugryźć i nie połamać sobie zębów - doświadczalnie".
Krzysztof Moskwa - Podstawy metod zwinnych: jak to działa? Story points, czyl...PMI Szczecin
Krzysztof Moskwa. Krzysztof ma ponad dziesięć lat doświadczenia w prowadzeniu projektów produkcji oprogramowania. Obecnie pracuje w firmie Orad (część Avid Technology). Absolwent Politechniki Wrocławskiej oraz Studium MBA US. Posiadacz certyfikatu PMP Project Managment Institute. Wspiera lokalny oddział PMI Szczecin jako wolontariusz.
Temat wystąpienia to "Podstawy Metod Zwinnych: Jak to działa? Story Points, czyli Jednostki Wartości."
Prezentacja z pierwszego Jesiennego Wieczoru Scrum organizowanego przez Fluid Circle (fluidcircle.net).
Uwaga: nowsza wersja tej prezentacji pochodzące z Wiosennych Wieczorów ze Scrum znajduje się tutaj: http://www.slideshare.net/FluidCircle/wiosenne-wieczory-ze-scrum-1-rzut-okiem-na-scrum
"Gram w Scrum - Zaprojektuj centrum" to gra symulacyjna, w trakcie której gracze, projektując przestrzeń wokół Pałacu Kultury, przyswajają sobie założenia metodyki Scrum, które będą mogli wykorzystać w realizowanych przez siebie projektach.
Ostatnia - szósta - prezentacja z kursu zarządzania działaniem według metody Getting Things Done. Prezentacja podsumowuje najważniejsze wiadomości z kursu oraz pokazuje, jakie zmiany można wprowadzić w życiu dzięki zastosowaniu metody GTD.
E-kurs zorganizowany przez sekcję PR konferencji Giełda Prac Dyplomowych.
Pierwsza cześć kursu zarządzania działaniem według metody Getting Things Done. Podstawy i motywacja do zarządzania działaniem.
E-kurs zorganizowany przez sekcję PR konferencji Giełda Prac Dyplomowych.
Krzysztof Moskwa - Podstawy metod zwinnych: jak to działa? Story points, czyl...PMI Szczecin
Krzysztof Moskwa. Krzysztof ma ponad dziesięć lat doświadczenia w prowadzeniu projektów produkcji oprogramowania. Obecnie pracuje w firmie Orad (część Avid Technology). Absolwent Politechniki Wrocławskiej oraz Studium MBA US. Posiadacz certyfikatu PMP Project Managment Institute. Wspiera lokalny oddział PMI Szczecin jako wolontariusz.
Temat wystąpienia to "Podstawy Metod Zwinnych: Jak to działa? Story Points, czyli Jednostki Wartości."
Prezentacja z pierwszego Jesiennego Wieczoru Scrum organizowanego przez Fluid Circle (fluidcircle.net).
Uwaga: nowsza wersja tej prezentacji pochodzące z Wiosennych Wieczorów ze Scrum znajduje się tutaj: http://www.slideshare.net/FluidCircle/wiosenne-wieczory-ze-scrum-1-rzut-okiem-na-scrum
"Gram w Scrum - Zaprojektuj centrum" to gra symulacyjna, w trakcie której gracze, projektując przestrzeń wokół Pałacu Kultury, przyswajają sobie założenia metodyki Scrum, które będą mogli wykorzystać w realizowanych przez siebie projektach.
Ostatnia - szósta - prezentacja z kursu zarządzania działaniem według metody Getting Things Done. Prezentacja podsumowuje najważniejsze wiadomości z kursu oraz pokazuje, jakie zmiany można wprowadzić w życiu dzięki zastosowaniu metody GTD.
E-kurs zorganizowany przez sekcję PR konferencji Giełda Prac Dyplomowych.
Pierwsza cześć kursu zarządzania działaniem według metody Getting Things Done. Podstawy i motywacja do zarządzania działaniem.
E-kurs zorganizowany przez sekcję PR konferencji Giełda Prac Dyplomowych.
Piąta - przedostatnia - prezentacja z kursu zarządzania działaniem według metody Getting Things Done. Prezentacja przedstawia praktyczne przykłady zastosowania metody oraz zasady prowadzenia systemu.
E-kurs zorganizowany przez sekcję PR konferencji Giełda Prac Dyplomowych.
Trzecia cześć kursu zarządzania działaniem według metody Getting Things Done. W prezentacji szczegóły procesu zbierania spraw w trakcie inicjacji i funkcjonowania systemu GTD.
E-kurs zorganizowany przez sekcję PR konferencji Giełda Prac Dyplomowych.
Druga cześć kursu zarządzania działaniem według metody Getting Things Done. W prezentacji przedstawiono metody identyfikacji celów i planowania ich realizacji.
E-kurs zorganizowany przez sekcję PR konferencji Giełda Prac Dyplomowych.
Czwarta cześć kursu zarządzania działaniem według metody Getting Things Done. W tej prezentacji poznacie algorytm analizy spraw zgromadzonych w skrzynce spraw przychodzących oraz dowiecie się, dlaczego ważne jest regularne przeglądanie systemu GTD.
E-kurs zorganizowany przez sekcję PR konferencji Giełda Prac Dyplomowych.
Pasja, cierpliwość i zaufanie. Agile@GetResponse – historia zmianySławek Łukjanow
Podobno na mieście krążą informacje o udanych zmianach w GetResponse IT. Nadszedł zatem najwyższy czas, aby o nich opowiedzieć!
W czerwcu 2015 roku w GetResponse pojawiło się dwoje zaprawionych w bojach Scrum Masterów. Misja: wsparcie wdrożenia Scruma na poziomie całego IT.
Po 1.5 roku jest już nas pięcioro i uważamy, że wspólnie udało nam się sporo osiągnąć. Opowiem o tym jak podeszliśmy do procesu zmiany, co zrealizowaliśmy, na jakie problemy natrafiliśmy i jak je rozwiązaliśmy, co nas zaskoczyło, jakie popełnialiśmy błędy i czego nas to nauczyło. I jak wersję „wzorowy Scrum” zmieniliśmy na podążanie za zasadami kultury agile.
To będzie też historia o tym jak istotna w pracy Scrum Mastera jest pasja i wewnętrzny ogień, połączony z anielską cierpliwością. I jak bardzo pomaga zaufanie. Zarówno to otrzymane, jak i dawane.
Prezentował: Maciej Wilmiński
Scrum Master w GetResponse, mający niemałe doświadczenie we wprowadzaniu kultury i pracy agile, zarówno na poziomie zespołów deweloperskich, działów IT jak i całych organizacji.
Jego dużym atutem jest praktyka zdobyta w sporej ilości projektów, w których pełnił różne role: programisty, architekta oprogramowania czy lidera zespołu. W efekcie niewiele w IT jest go w stanie zaskoczyć lub przestraszyć.
Wierzy w moc pracy zespołowej, a jako wielki fan sportu, dostrzega sporo podobieństw pomiędzy pracą zespołu programistycznego, a budowaniu dobrej drużyny sportowej. Rolę Scrum Mastera postrzega jako kombinację kapitana, trenera, a czasem i zawodnika.
O Scrumie i agile’u pisze na blogu mlynarze.com, jest też założycielem Encyklopedii Rocka rockers.com.pl.
Prezentacja dotycząca wykorzystania Scruma w procesie reorientacji firmy na dostarczanie wartości. Przedstawiona na konferencji Zarządzanie Projektami: Agile w biznesie, organizowanej przez Computerworld, 19-20 czerwca 2012 w Warszawie.
The Agile Cincinnati Conference 2016 was in the format of a Scrum Sprint. This slide deck was used during the Sprint Review and helped stage the following Sprint Retrospective. We had a solid line up of break presenters and two incredible keynote speakers - James Grenning and Robert Tipton.
Piąta - przedostatnia - prezentacja z kursu zarządzania działaniem według metody Getting Things Done. Prezentacja przedstawia praktyczne przykłady zastosowania metody oraz zasady prowadzenia systemu.
E-kurs zorganizowany przez sekcję PR konferencji Giełda Prac Dyplomowych.
Trzecia cześć kursu zarządzania działaniem według metody Getting Things Done. W prezentacji szczegóły procesu zbierania spraw w trakcie inicjacji i funkcjonowania systemu GTD.
E-kurs zorganizowany przez sekcję PR konferencji Giełda Prac Dyplomowych.
Druga cześć kursu zarządzania działaniem według metody Getting Things Done. W prezentacji przedstawiono metody identyfikacji celów i planowania ich realizacji.
E-kurs zorganizowany przez sekcję PR konferencji Giełda Prac Dyplomowych.
Czwarta cześć kursu zarządzania działaniem według metody Getting Things Done. W tej prezentacji poznacie algorytm analizy spraw zgromadzonych w skrzynce spraw przychodzących oraz dowiecie się, dlaczego ważne jest regularne przeglądanie systemu GTD.
E-kurs zorganizowany przez sekcję PR konferencji Giełda Prac Dyplomowych.
Pasja, cierpliwość i zaufanie. Agile@GetResponse – historia zmianySławek Łukjanow
Podobno na mieście krążą informacje o udanych zmianach w GetResponse IT. Nadszedł zatem najwyższy czas, aby o nich opowiedzieć!
W czerwcu 2015 roku w GetResponse pojawiło się dwoje zaprawionych w bojach Scrum Masterów. Misja: wsparcie wdrożenia Scruma na poziomie całego IT.
Po 1.5 roku jest już nas pięcioro i uważamy, że wspólnie udało nam się sporo osiągnąć. Opowiem o tym jak podeszliśmy do procesu zmiany, co zrealizowaliśmy, na jakie problemy natrafiliśmy i jak je rozwiązaliśmy, co nas zaskoczyło, jakie popełnialiśmy błędy i czego nas to nauczyło. I jak wersję „wzorowy Scrum” zmieniliśmy na podążanie za zasadami kultury agile.
To będzie też historia o tym jak istotna w pracy Scrum Mastera jest pasja i wewnętrzny ogień, połączony z anielską cierpliwością. I jak bardzo pomaga zaufanie. Zarówno to otrzymane, jak i dawane.
Prezentował: Maciej Wilmiński
Scrum Master w GetResponse, mający niemałe doświadczenie we wprowadzaniu kultury i pracy agile, zarówno na poziomie zespołów deweloperskich, działów IT jak i całych organizacji.
Jego dużym atutem jest praktyka zdobyta w sporej ilości projektów, w których pełnił różne role: programisty, architekta oprogramowania czy lidera zespołu. W efekcie niewiele w IT jest go w stanie zaskoczyć lub przestraszyć.
Wierzy w moc pracy zespołowej, a jako wielki fan sportu, dostrzega sporo podobieństw pomiędzy pracą zespołu programistycznego, a budowaniu dobrej drużyny sportowej. Rolę Scrum Mastera postrzega jako kombinację kapitana, trenera, a czasem i zawodnika.
O Scrumie i agile’u pisze na blogu mlynarze.com, jest też założycielem Encyklopedii Rocka rockers.com.pl.
Prezentacja dotycząca wykorzystania Scruma w procesie reorientacji firmy na dostarczanie wartości. Przedstawiona na konferencji Zarządzanie Projektami: Agile w biznesie, organizowanej przez Computerworld, 19-20 czerwca 2012 w Warszawie.
The Agile Cincinnati Conference 2016 was in the format of a Scrum Sprint. This slide deck was used during the Sprint Review and helped stage the following Sprint Retrospective. We had a solid line up of break presenters and two incredible keynote speakers - James Grenning and Robert Tipton.
A motorcycle jacket or vest that functions as a cycle wearable but has a more considered design for the female rider.
A vest less, baggy, sexualized or stereotyped with particular imagery or use of pink and more captured by the pangolin pattern it its design.
KMT-aamu 3.11.2015: Mitä aikakauslehtien uusi KMT parhaimmillaan tarjoaaA-lehdet Oy
A-lehtien suunnittelujohtaja Tuuli Toivainen kertoi KMT-aamussa 3.11.2015, mitä uudistunut Kansallinen Mediatutkimus antaa aikakausmedioiden mediasuunnitteluun, kohderyhmien määrittämiseen ja ostoprosessin hyödyntämiseen.
Scrum Studio - Lukasz Filut@Scrum Experience Day 2020Łukasz Filut
Scrum Studio i wyzwania, które napotyka w czerwonych i pomarańczowych organizacjach. Dzielę się swoimi doświadczeniami i receptami, które w tym przypadku uruchomiły Scruma w niełatwym środowisku.
Scrum (Polish version) - wprowadzenie do frameworkaalbrzykowski
Prezentacja zawiera podstawowe informacje na temat Agile i głównie frameworka Scrum. Znajdziecie w niej wiadomości dotyczące wartości Scruma, Zespołu Scrumowego, Zdarzeń w Scrumie oraz Artefaktów Scruma. Ponadto dodałem też dodatkowe informacje związane z kilkoma praktykami Agile.
Prezentacja jest okrojoną wersją używanej przeze mnie podczas szkoleń warsztatowych stąd znajdziecie w niej informacje w większości teoretyczne.
Prezentacja przygotowana na konferencje 4Developers, Warszawa, 07/04/2014
Używasz Scruma, ale brakuje Ci magii obiecanej na szkoleniu? Spodziewałeś się działającego produktu co każdy sprint, a zamiast tego dostajesz co iterację niezbywalne kawałki produktu? Wszystko miało być gotowe na czas, a Ty znów słyszysz, że zespół potrzebuje jeszcze kilka Sprintów, aby dokończyć pracę? Użytkownicy po raz kolejny rozczarowali się, kiedy okazało się, że produkt, który dla nich stworzyłeś, nie jest tym, czego oczekiwali?
Brzmi znajomo? Bez wątpienia. Tworzenie oprogramowania to nieustanna przeprawa przez złożone środowisko, które zachowuje się nieprzewidywalnie i trudno być czegokolwiek pewnym. Właściwie stosowany Scrum jest narzędziem, które pomaga dostarczać wartościowe produkty, pomimo nieuchronnej zmienności otoczenia. W prezentacji opowiem o swoich doświadczeniach, jak przy pomocy sprawdzonych praktyk i narzędzi sprawić, aby niepewność towarzysząca rozwojowi produktu była na minimalnym, akceptowalnym przez nas poziomie.
Wyjaśnienie jakie są fundamentalne różnice pomiędzy metodykami zwinnymi a iteracyjną kaskadą, czym się różni iteracja od inkrementu i jak empiryzm realizowany jest przez Scruma.
Agile - metodyki zwinne.
Spis treści:
1. Wstęp do metodyk zwinnych – manifest i zasady Agile.
2. Dostarczanie oparte na wartości – ocena, planowanie, dostarczanie, weryfikowanie i monitorowanie wartości.
3. Zaangażowanie interesariuszy – współpraca i komunikacja, przywództwo (rozdział w opracowaniu).
4. Wydajność zespołów – co to jest, od czego zależy i jak ją poprawiać.
5. Planowanie adaptacyjne – koncepcje planowania, estymacja, planowanie zwinne.
6. Problemy – jakość, wykrywanie, zapobieganie i rozwiązywanie problemów.
7. Ciągłe doskonalenie – retrospekcje i udoskonalanie procesów.
8. Opis najpopularniejszych metodyk – SCRUM.
Prezentacja z gościnnego wystąpienia na spotkaniu Project Management Institute (PMI) w Krakowie. Prezentacje punktuje najczęstsze problemy występujące podczas wdrożeń metodyki Scrum w środowisku średniej i dużej organizacji, powodów tych problemów upatrując w przyzwyczajeniach, kulturze organizacyjnej i obawie przed zmianą.
Podzielę się z Wami zaobserwowanymi praktykami, które są kluczowe dla każdego zespołu dostarczającego produkt w oparciu o moje doświadczenia jako deweloper, system inżynier i leader zespołu.
Prezentacja z wykładu na temat roli analityka IT w zespole stosującym metodyki Agile takich jak SCRUM, XP czy Kanban. Prezentacja pokazuje także jak budować kompetencje zwinnego analityka. Wykład został wygłoszony podczas konferencji beIT 2015 na Politechnice Gdańskiej, a także na spotkaniu gdańskiej grupy SPIN.
Scrum - iteracyjna metodyka prowadzenia projektów, zaliczana do metodyk zwinnych, zgodnych z manifestem Agile.
Prezentacja znaleziona w śmieciach na dysku :) Wykonana w 2004 roku
Prezentacja na temat Lean Startup poprzedzajaca 3-godzinny warsztat przeprowadzony przeze mnie dla InnoShare 2016 - konferencji zorganizowanej przez Polska Innowacyjna.
Jestem project managerem, a jakie są Twoje supermoce?mamopracuj
Prezentacja Eweliny Leszczyńskiej, Project Manager w firmie Atos Poland Global Services z webinaru organizowanego w ramach programu #MamoPracujwIT - 28.11.2020.
Similar to Michał Koniewicz - "SCRUM - jak ugryźć i nie połamać sobie zębów - doświadczalnie" (20)
Marek Więcek - Stakeholder Management, Komunikacja z ludźmi, którzy mogą zniw...PMI Szczecin
Prezentacja Marka Więcka z 10. Spotkania PMI Szczecin w dn. 26.04.2016 pn. "Stakeholder Management, Komunikacja z ludźmi, którzy mogą zniweczyć Twój projekt
Gaweł Biedunkiewicz - "Project Manager a kontrakty budowlane"PMI Szczecin
Gaweł Biedunkiewicz - "Project Manager a kontrakty budowlane"
Gaweł Biedunkiewicz - z wykształcenia architekt. Od ponad 11 lat pracuje w sektorze budownictwa.
W latach 2007-2009 w Irlandii zdobywał specjalistyczną wiedzę z zakresu kontraktów budowlanych. Od 2009 roku prowadzi firmę zajmującą się zarządzaniem w budownictwie aktywną na rynku europejskim. Specjalizuje się budownictwie użyteczności publicznej i przemysłowym.
Michael Kacprzak - Agile Project Management, doświadczenia z okopów na wesołoPMI Szczecin
Prezentacja z 8. Spotkania PMI Szczecin, z dn. 23 lutego 2016 r.
Michael Kacprzak - Agile Project Management, doświadczenia z okopów na wesoło
Michael jest współtwórcą Spotbeans oraz twórcą Switch2Agile. Pierwsze doświadczenia jako kierownik projektu zdobywał w projektach sektora publicznego w IBM. Do niedawna pracował jako lead agile coach w jednym z najprężniej rozwijających się startupów w Berlinie – Babbel. Od prawie roku zacumował ponownie w Szczecinie, gdzie jako współtwórca Spotbeans rozwija innowacyjną aplikację dla dietetyków TiqDiet. Ponadto jest doświadczonym mówcą i trenerem z zakresu lean i agile zarówno w Polsce jak i zagranicą. Jest pierwszą osobą w Polsce, która zdobyła certyfikat SPC (Scaled Agile Program Consultant) uprawniającą do akredytowanych szkoleń Scaled Agile Framework.
Michał Żuchowski - Project Management, że aż wióry lecą!PMI Szczecin
Michał Żuchowski - Project Management, że aż wióry lecą
Prowadzenie projektów w największej firmie meblarskiej na świecie.
Michał Żuchowski, Kierownik Centrum Rozwoju Produktów w IKEA Industry Poland Sp. z o.o..
Michał ma za sobą blisko 10 lat doświadczenia w międzynarodowych firmach z branży manufacturing, product development czy shared services. Specjalizuje się w zarządzaniu zespołami lokalnymi i rozproszonymi, kierowaniem projektami rozwijającymi nowe produkty, rozwojem ludzi w zespole oraz zarządzaniem zmianą.
Temat prelekcji to "Project Management, że aż wióry lecą. Prowadzenie projektów w największej firmie meblarskiej na świecie".
Michał Żuchowski - Project Management, że aż wióry lecą!
Michał Koniewicz - "SCRUM - jak ugryźć i nie połamać sobie zębów - doświadczalnie"
1. SCRUM
jak ugryźć i nie połamać sobie zębów -
doświadczalnie
Michał Koniewicz
marzec 2016
2. Cele do osiągnięcia
• Jakie są główne założenia SCRUM?
• Jakie są praktyczne zagadnienia do uwzględnienia w
SCRUM?
• Jak działa SCRUM w praktyce?
• A kiedy nie działa i jak uniknąć typowych problemów?
3. Agenda
• Teoria Teoretyczna - szybkie wprowadzenie do
SCRUM
• Teoria Praktyczna – podbudowa doświadczalna
• Zderzamy Teorie i Praktykę - czyli jak robimy
SCRUMem
• Aspekty - Udany (i nieudany) SCRUM
• Podsumowanie
4. O mnie
• Firma: Profi-Data
• Od 15 lat zawodowo w IT
• Od 13 lat zarządzanie projektami IT
• Duże, średnie, małe projekty IT, pełny zakres
• PRINCE2 Practitioner (CN# P2R/870526)
• Zapalony fan Agile i szczecińskiego PMI
• Kontakt www.linkedin.com/in/michalkoniewicz
6. Szybkie wprowadzenie do SCRUM
• Historia powstania SCRUM
• Problemy metod „klasycznych” / Waterfall
• Ken Schwaber & Jeff Sutherland
• The SCRUM Guide (PL)
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-PL.pdf
• (zachęcam do przeczytania – tylko 18 stron wraz z tytułowa i spisem treści)
7. Szybkie wprowadzenie do SCRUM
Główne założenia SCRUM
•Lekki
•Łatwy do zrozumienia
•Bardzo trudny do opanowania (ale mam nadzieję, że
prezentacja trochę pomoże )
MK: A na dodatek SCRUM jest darmowy
Źródło: The SCRUM Guide (PL) http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-PL.pdf
8. Szybkie wprowadzenie do SCRUM
SCRUM jest metodyką wytwórczą!
a nie zarządczą, czy „jakąś inną” do przekładania
papierów z biurka na biurko.
W każdej iteracji ma być konkretny Przyrost naszego
„Produktu”
9. Szybkie wprowadzenie do SCRUM
Główne założenia SCRUM
•SPRINTy o stałej długości trwania
•Każdy SPRINT ma dostarczać ukończony przyrost
Produktu.
•Stałość zakresu SPRINTU
•Przejrzystość
•Inspekcja
•Adaptacja
•Timeboxing!
10. Szybkie wprowadzenie do SCRUM
Role w SCRUM – z kogo składa się Zespół SCRUMowy?
•Product Owner (PO) – odpowiedzialność, wizja, rządzi
BackLogiem. Tylko 1 osoba!
•Zespół (Deweloperski) – zwany dalej Zespołem
•Scrum Master (SM) – coach, dba aby SCRUM był
rozumiany i stosowany
11. Szybkie wprowadzenie do SCRUM
Role – Zespół (Deweloperski)
•Odpowiada za przekształcanie BackLogu w Przyrost
Produktu
•Odpowiedzialność zespołowa
•Samoorganizujący się
•Równość – brak hierarchii
•Min. 3, Maks. 9 osób
•Interdyscyplinarny – komplet kompetencji niezbędny
do wytworzenia przyrostu Produktu
•„Zespół złożony z profesjonalistów”
12. Szybkie wprowadzenie do SCRUM
Sprint
•SPRINT = „Projekt” (trwający maksymalnie miesiąc)
•Sztywny okres czasu, zazwyczaj 1 do maks. 4 tygodni –
Timeboxing!!!
•Dostarcza ukończony Przyrost Produktu
13. Szybkie wprowadzenie do SCRUM
Artefakty SCRUM - BackLogi
•„Worki” na rzeczy, które są do zrobienia
•Product Backlog
•Sprint Backlog
•Backlog Item, Historyjki Użytkownika (User Stories)
•Zadania (Tasks)
14. Szybkie wprowadzenie do SCRUM
Definition of Done (DoD)
•Kryterium Ukończenia, do oceny czy nasz Produkt /
przyrost Produktu / element BackLogu jest „Done”
•Gotowość „do użycia”
•Wszyscy muszą rozumieć
•Pomaga Zespołowi zaplanować prace
•Współdzielone przez Zespoły pracujące na jednym
Produktem
•DoD nie jest sztywne – dojrzewa w czasie aby jakość
naszego Produktu była jeszcze lepsza!
17. Teoria Praktyczna
• Problemy z klasycznymi metodami wytwarzania
(rozwiązań informatycznych)
• „Analiza klasyczna” – silosowy wertykal
• Wady klasycznego Waterfall’a
• Oporność i odporność Waterfall na wprowadzanie
zmian
• Brak namacalności Produktu do ostatnich etapów, to
jak mam stwierdzić czy to jest to co chcę?
20. Teoria Praktyczna
Aby robić, trzeba wiedzieć co …
Trzeba zmienić sposób myślenia - Minimum Viable
Product
Źródło: Henrik Kniberg http://blog.crisp.se/author/henrikkniberg
21. Teoria Praktyczna
Aby robić, trzeba wiedzieć co
•Historyjki Użytkownika (US)
•Historyjki mają reprezentować konkretne potrzeby
„Klienta”
•W dobre Historyjki trzeba ZaINVESTować
•Ale cały czas mają być lekkie i przyjemne
22. Teoria Praktyczna
Historyjki (US) – jak definiować?
•Horyzontalne podejście
•Przekrojowe
•Sposób definiowania
•Cały czas pilnujemy aby były dobrą INVESTycją
•User Stories – reprezentują potrzeby klienta
MK: Historyjki powinny cały czas odzwierciedlać potrzebę/-y
Klienta
23. Teoria Praktyczna
Historyjki – zaINVESTujmy
I – Independent (niezależne)
N – Negotiable (negocjowalne)
V – Valuable (dostarczają konkretną korzyść)
E - Estimable (estymowalne)
S – Small (wystarczająco małe do zaplanowania)
T – Testable (testowalne)
Źródło: https://en.wikipedia.org/wiki/INVEST_(mnemonic)
24. Teoria Praktyczna
Historyjki – jak zdefiniować?
Jako <rola> chcę <potrzeba, funkcja>, aby <cel,
uzasadnienie>
Jako Administrator chcę mieć możliwość zablokowania
konta użytkownika, aby osoby nieuprawnione nie
mogły korzystać z Systemu
25. Teoria Praktyczna
Historyjki – Kryteria Akceptacji
•Historyjki *powinny* mieć Kryteria Akceptacji
•Kryteria Akceptacji doprecyzowują jak Historyjki mają
być zrobione
•Nie mylić Kryteriów Akceptacji z Definition of Done
•Kryteria Akceptacji to mega Pomoc dla „Testerów”
•Najlepiej gdy definiowane (negocjowane) przez PO i
Zespół
Przykład: Blokowanie kont z listy i dla pojedynczego rekordu
użytkownika, tylko dla aktywnych. Potwierdzenie blokowania np.
dialogiem.
26. Teoria Praktyczna
Historyjki – i co jeszcze?
•Dobrze zapisana Historyjka Użytkownika:
Tytuł + Opis + Kryteria Akceptacji
•Historyjki mogą mieć dodatkowe „specyfikacje” (opisy,
screeny, etc.), ale należy pamiętać, że sama Historyjka
to nie 50 stron dokumentacji!
•KISS (Keep It Simple Stupid)
27. Teoria Praktyczna
Historyjki – szacowanie
•„Understand that the accuracy of an estimate is more
important than the precision of the estimate”
„Celność” oszacowania vs Precyzja
•Techniki szacowania Złożoności
•Szacowanie przez porównanie
•Często używane miarki
•SCRUM Poker
28. Teoria Praktyczna
Historyjki – szacowanie - problem wzorca
Źródło: http://slideplayer.pl/slide/60560/ POMIAR I MIARA. I Liceum Ogólnokształcące im. Marii Skłodowskiej-Curie w Pile ID grupy: - 97/70_MF_G1 Kompetencja
29. Teoria Praktyczna
Historyjki - A po co w ogóle szacować?
Czy szacowanie historyjek w Story Pointach służy do:
a)przedstawieniu przez PO zarządowi lub klientowi informacji, że produkt
będą mieli na 15 czerwca?
b)dokładnemu wyliczeniu ile roboczogodzin lub roboczodni poświęci zespół
na realizację?
c)wyzwoleniu dyskusji w zespole odnośnie realizowalności historyjki?
d)przydzieleniu historyjki do osoby, która "wyceniła" historyjkę najniżej?
e)uzgodnieniu z PO podejścia do realizacji albo dekompozycji historyjki?
f)uzyskaniu pięknych wykresików Sprint Burndown, Product/Release
Burndown?
(można wybrać więcej niż jedną odpowiedź )
30. Teoria Praktyczna
Historyjki – Szacowanie - dlaczego nie należy szacować
w rbh/rbd/md.?
•Szacowanie Złożoności
•Złożoność to nie to samo co Pracochłonność
•Oderwanie się od księgowo-kadrowo-rozliczeniowej
rutyny
•Szacowanie to nie jest deklaracja Zespołu na
rzeczywistą pracochłonność !!!
31. Teoria Praktyczna
Zespół SCRUM - Kim robić?
•Obsada wszystkich „ról”
•Nie łączyć ról PO i SM
•W zespole ma być komplet Kompetencji
•Zespół profesjonalistów
•„Zasoby” zaalokowane w 100% do „naszego” SCRUMa!
•Jedna lokalizacja - MK: „Zdalny” SCRUM sprawdza się
„średnio”
32. Teoria Praktyczna
SCRUM Tablica - przykład
Źródło: http://programmers.stackexchange.com/questions/21436/managing-production-issues-during-a-scrum-sprint
33. Teoria Praktyczna
BackLog (BL)
•Ciągłe zarządzanie BL (a nie na ostatnią chwilę)
•Agregacja, podział, usuwanie BackLog Items/Historyjek
•BackLog Item a User Stories
•Product Backlog, Sprint Backlog
•„Historyjki techniczne”
34. Teoria Praktyczna
Definition of Done (DoD)
•Ogólne (Uniwersalne) reguły „ukończenia”
•Dobrze mieć przygotowane przed pierwszym Sprintem
•Warto unikać „szczególaryzmu”
•Jak najbardziej zmieniać i dostosowywać DoD (ale z
głową )
•DoD vs Kryteria Akceptacji
35. Teoria Praktyczna
Narzędzia, techniki (IT), agile development
•Wszystkie zwinne: TDD, XP, Pair Programming
•Wczesny commit do VCS, codzienny commit i build
•Continuous Integration
•Testy jednostkowe, automatyzacja testów
Po co?
Aby mieć wczesny „feedback”, a nie dopiero na koniec Sprintu.
Automatyzacja zamiast „ręcznego dziobania”, aby była lekkość i
zwinność
36. Aspekt - Udany SCRUM
Timeboxing (SM)
Długość Sprintu →
Wydarzenie ↓
1 w. 2 w. 3 w. 4 w.
Planning 2h 4h 6h max. 8h
Daily max. 15 min max. 15 min max. 15 min max. 15 min
Review 1h 2h 3h 4h
Retrospective 0,75h 1,5h 2,25h 3h
37. Teoria Praktyczna
MK: W SCRUMie nic oprócz timeboxów nie jest „na
sztywno”
(bo przecież miała być elastyczność, lekkość i zwinność )
38. Teoria Praktyczna
Jeszcze warto zapamiętać:
•PO – reprezentuje „wartość dla biznesu”, dba aby
Backlog / priorytety prac odzwierciedlały korzyść /
wartość dla biznesu.
•Konsensus zakresu Backlogu Sprintu pomiędzy PO i
Zespołem jest zawsze możliwy (ale czasem trzeba
ponegocjować )
39. Zderzenie Teorii z PRAKTYKĄ
SCRUM doświadczalnie
z doświadczeń praktycznych
40. Zderzenie Teorii z PRAKTYKĄ
Planowanie Sprintu (PO)
•Uporządkowany BackLog przed Planningiem to jest
„must have”!
•Daj Zespołowi czas „przed” na zapoznanie się z BL
•Przygotuj zarys Definition of Done
•Zrób Sprint Planning Meeting
41. Zderzenie Teorii z PRAKTYKĄ
Planowanie Sprintu – Sprint Planning Meeting
•Prezentacja Historyjek przez PO
•Rzutnik, tablica, karteczki, bardzo się przydają
•Burza mózgów, pomysły na „ugryzienie”
•Dekompozycja na Zadania
•Szacowanie Zadań przez Zespół
•Zatwierdzenie BackLogu (Sprintu) do realizacji w
Sprincie
42. Zderzenie Teorii z PRAKTYKĄ
Definition of Done (DoD)
•„Could we ship it?”
•Nie checklisty!
•Nie drobiazgowo!
•Dobrze gdy wskazuje kluczowe Produkty lub kluczowe
działania
•Zespół pomaga uzupełnić DoD
•Pamiętajmy, że DoD nie jest „niezmienne” i ustalone
raz na zawsze!
43. Zderzenie Teorii z PRAKTYKĄ
Planowanie Sprintu
•Nie „statyczne” zrzucenie BackLogu na Zespół
•Historyjki vs Zadania
•Szacowanie Historyjek
•Dynamicznie i elastycznie - dekompozycja, agregacja,
usuwanie Historyjek
•Bez dużego nakładu – zasada Łatwo dodać,
zmodyfikować, usunąć, poprawić.
•Timeboxing! (SM)
44. Zderzenie Teorii z PRAKTYKĄ
Planowanie Sprintu
•2 Przebiegi zamiast „książkowej” 1 iteracji
•Pytania, wątpliwości – omawianie
•Wstępna koncepcja podziału prac
•Druga iteracja
•Docelowa koncepcja podziału prac / dekompozycja na
Zadania
•Timeboxing!!!
45. Zderzenie Teorii z PRAKTYKĄ
Planowanie Sprintu – Zadania
•Definiowanie Zadań (Kryteria i DoD są pomocne) – to
Zespół ustala optymalne podejście!
•Wszystkie „role” powinny mieć Zadania w Sprincie
•Szacowanie pracochłonności zadań
•Nie wszystkie Zadania muszą być zdefiniowane!
(kryterium 60% zdefiniowanych Zadań jest ok)
•Ilość zadań a pojemność zespołu
•Kryterium 75% FTE (np. 6 z 8 rbh)
46. Zderzenie Teorii z PRAKTYKĄ
Planowanie Sprintu
•To Zespół ustala ile i jakich Historyjek (lub Backlog
Item) „bierze na klatę”
•PO nie może naciskać Zespołu
•Zatwierdzony Sprint Backlog jest kontraktem między
PO i Zespołem
•Określony zostaje Cel Sprintu
•Prac. Zadań < pojemność Zespołu (kryterium 75% FTE)
•Zamrożony Backlog Sprintu
47. Zderzenie Teorii z PRAKTYKĄ
Kryterium 75%
Pytanie: Czemu mam „płacić” za „nieproduktywne” 2 rbh w ciągu 1
rbd?
Odpowiedź: Po to abyś nie musiał płacić:
•Za terminy, bo tylko „jeden ktoś” widział o co chodzi
•Za terminy, bo ktoś coś pominął, niedoszacował
•Za koszty szkoleń dedykowanych / transferu wiedzy
•Za koszty jakości
•Za odejścia pracowników, którym nie zapewnia się czasu na rozwój /
samodoskonalenie
Ludzie nie są z gumy!
48. Zderzenie Teorii z PRAKTYKĄ
Zaplanowaliśmy Sprint, no to lecimy!
Źródło: https://xpda.com/junkmail/junk166/military/
49. Zderzenie Teorii z PRAKTYKĄ
Realizacja Sprintu
•Sprint startuje od razu po Planningu
•Pobieranie (przypisywanie się do) Zadań
•TODO, IN PROGRESS, DONE
•Nie przypisywanie się osób do Historyjek!
•Codzienne spotkania - Daily Meeting
•PO i SM są zawsze dostępni dla Zespołu!
•BackLog Sprintu się nie zmienia w trakcie Sprintu!
50. Zderzenie Teorii z PRAKTYKĄ
Realizacja Sprintu (Zespół)
•Żadnych „mikro waterfall’i” w Zespole
•Pracuje cały Zespół (wszystkie „role”) od początku
Sprintu nad dowiezieniem zakontraktowanych
Historyjek
•PO trzyma się z dala od „mikromanagementu”
•SM pomaga Zespołowi „dowieźć” zakontraktowane
Historyjki
51. Zderzenie Teorii z PRAKTYKĄ
Realizacja Sprintu (Zespół) – Daily Meetings
•Daily Meeting to podstawa
•Stałe miejsce i czas.
•Max. 15 minut – Timeboxing!
•Na stojąco
•PO i SM są opcjonalni (ale SM ma dbać, że Daily się
odbywają)
•To nie jest „status prac dla: PO*, SM*, Zarządu*
(*-niepotrzebne skreślić)”!
52. Zderzenie Teorii z PRAKTYKĄ
Realizacja Sprintu (Zespół) – Daily cd.
•3 tematy: co robiłem, co będę robił, jakie są problemy
•Aktualizacja Zadań na SCRUM Tablicy
•Tematy grube, dodatkowe pytania, kwestie do
wyjaśnienia, wątpliwości – omawiane osobno
(Timeboxing!)
53. Zderzenie Teorii z PRAKTYKĄ
Realizacja Sprintu (PO)
A co robi Product Owner (PO) w trakcie Sprintu?
•Jest cały czas dostępny dla Zespołu, odpowiada na
pytania, klaryfikuje tematy.
•Pracuje nad BackLogiem Produktu dla kolejnych
Sprintów (co nie oznacza, ze robi to sam)
•Jest „on-line” z SM
54. Zderzenie Teorii z PRAKTYKĄ
Realizacja Sprintu (SM)
A co robi Scrum Master w trakcie Sprintu?
•Wspiera Zespół
•Dba o stosowanie reguł SCRUMa
•Usuwa przeszkody (organizacyjne)
•Jest na bieżąco z PO
55. Zderzenie Teorii z PRAKTYKĄ
Realizacja Sprintu – Minimalizacja „Work in Progress”
•Nie rozgrzebywać zbyt dużej liczby historyjek
•Optymalnie gdy Zespół koncentruje się na 1-2
Historyjkach „na raz” (zależy mocno od wielkości
zespołu, doświadczenia, zakresu prac)
•Dowiezienie vs rozgrzebanie
57. Zderzenie Teorii z PRAKTYKĄ
Finalizacja Sprintu – Sprint Review
•Uczestniczą wszyscy: PO, SM, Zespół
•Review to nie są testy, Produkt ma być gotowy!
•Formuła – prezentacja przez Zespół co zostało
wykonane
•PO zatwierdza co jest „Done” w oparciu o DoD
•Zespół jest gratyfikowany *tylko* za ukończone
(„Done”) Historyjki, nie ma „zaliczeń” częściowych,
połowicznych, etc.
58. Zderzenie Teorii z PRAKTYKĄ
Finalizacja Sprintu – Sprint Review – c.d.
•Klasyfikacja „optymistyczna” i „pesymistyczna”
•Aktualizacja BackLogu
•Omówienie planu dalszych działań
•Wynikiem jest Backlog (do kolejnego Sprintu)
•Weryfikacja funkcjonalności przez PO przed Review
(Timeboxing!)
59. Zderzenie Teorii z PRAKTYKĄ
Finalizacja Sprintu – Retrospektywa Sprintu (SM)
•Inspekcja i Adaptacja
•Co poszło dobrze, co poszło źle, co możemy poprawić?
•Nie „obwinianie” się wzajemne
•Dbaj o dowartościowany, obdarzony zaufaniem Zespół
61. Aspekty - Udany SCRUM
Tip of the day
MK: Umiejętność mieszczenia się Zespołu w
Timeboxach jest bardzo dobrym wskaźnikiem
sprawności całego Zespołu.
Jeżeli się nie mieścimy, to coś jest do poprawy.
62. Aspekty - Udany SCRUM
Dostosowuj SCRUM!
•Adaptacyjność – są różne poziomy „startu” dla różnych
projektów / różnej specyfiki projektów.
•Nie warto „na siłę” zawsze robić „tak samo”. SCRUM
musi być zaadaptowany do specyfiki / celu Projektu.
Przykłady: Mały projekt „technologiczny” vs Średni
projekt „biznesowy”
63. Aspekty - Udany SCRUM
Co robić aby SCRUM się udawał?
•Bramki jakościowe do „wystartowania” kolejnego
„zdarzenia” SCRUM
•To co nam „wyłazi” poza SCRUM – wypychaj poza
SCRUM (i nie przejmować się Organizacją)
•Przygotowania, szkolenia – przez pierwszym Sprintem
•Szerszy kontekst projektu (SCRUM – metodyka
wytwórcza, nie wpychać wszystkiego w SCRUM)
64. Aspekty – Udany SCRUM
Antywzorce
•„Sprint 0”
•Łączenie ról PO i SM
•Za mały Zespół / za duży Zespół
•Brak alokacji 100% osób w Zespole
•Wystartowanie projektu SCRUM na zasadzie „jakoś to
będzie”
•Inni szacują, a jeszcze inni realizują
65. Aspekty – Udany SCRUM
Antywzorce
•Ponazywanie Wymagań klasycznej specyfikacji
„Historyjkami”
•Nienegocjowalne historyjki (problem SIWZ)
•Przywiązywanie się do metryk SCRUM
•SINO (SCRUM in Name Only) – grzeszki robienia
„scrum” na pokaz
[Propozycje ?]
66. Aspekty – Udany SCRUM
„Często zadawane pytania”
•Słyszałem, że w SCRUMie nie trzeba tworzyć
dokumentacji, czy to prawda?
•Słyszałem, że w SCRUMie nie trzeba się przemęczać,
czy to prawda?
•Czy Product Owner lub Scrum Master powinni mieć
wiedzę techniczną?
67. Podsumowanie
Jeżeli jest tak pięknie to czemu nie wszyscy stosują
SCRUM?
•Małe i średnie projekty
•Problem dużych projektów (SCRUM of SCRUM)
•Nie wszystkie projekty się nadają,
•Brak zaangażowania Klienta
•Brak zaufania
•Niezrozumienie korzyści
•Opór Klienta w zaakceptowaniu modelu finansowego
68. Podsumowanie
Jeżeli jest tak pięknie to czemu nie wszyscy stosują
SCRUM?
Moje „top 3” przyczyny:
1.Zaufanie, zaufanie, zaufanie
2.Brak elastyczności Organizacji/Klienta
3.Brak zaangażowania Organizacji/Klienta
69. Podsumowanie
A co wg mnie daje SCRUM?
(perspektywa ciężkometodycznego PMa )
1.„Wydobycie” najlepszych umiejętności osób w
Zespole
2.Uniknięcie Mikrozarządzania
3.Najskuteczniejsze przejście do Dobrze Wykonanej
Pracy (zrobienie software’u „Done”)
I Independent - The user story should be self-contained, in a way that there is no inherent dependency on another user story.
N Negotiable - User stories, up until they are part of an iteration, can always be changed and rewritten.
V Valuable - A user story must deliver value to the end user.
E Estimable - You must always be able to estimate the size of a user story.
S Small - User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
T Testable - The user story or its related description must provide the necessary information to make test development possible.
Żeby wyjąć, trzeba włożyć
Michael i jego wytrych w postaci „projektu SCRUm/agile”
Przykład „klienta” co nie chciał Eksperymentować
Mam nadzieję, że ci którzy już korzystają dzięki prezentacji będę mieli więcej czasu (na np. uczestnictwo w PMI Szczecin)
A ci którzy nie korzystają – spróbują bez obaw tego SCRUMa.