Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (14)
En vedette
En vedette (15)
Similaire à Michał Koniewicz - "SCRUM - jak ugryźć i nie połamać sobie zębów - doświadczalnie"
Similaire à Michał Koniewicz - "SCRUM - jak ugryźć i nie połamać sobie zębów - doświadczalnie" (20)
Plus de PMI Szczecin
Plus de PMI Szczecin (7)
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
- 5. Szybkie wprowadzenie do SCRUM Teoria Teoretyczna czyli szybkie wprowadzenie do SCRUM
- 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!
- 15. Szybkie wprowadzenie do SCRUM „Wydarzenia SCRUM (Events)” •Planowanie Sprintu (Sprint Planning) •Sprint •Codzienny SCRIM (Daily) •Przegląd Sprintu (Sprint Review) •Retrospektywa Sprintu (Sprint Retrospective)
- 16. Teoria Praktyczna Teoria Praktyczna aby lepiej zrozumieć SCRUM
- 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ę?
- 19. Teoria Praktyczna Jak działa SCRUM? Źródło: http://deanhume.com/home/blogpost/the--ideal--sprint-length/90
- 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
- 56. Zderzenie Teorii z PRAKTYKĄ Finalizacja Sprintu – Sprint Review
- 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ół
- 60. Zderzenie Teorii z PRAKTYKĄ I możemy starować kolejny Sprint
- 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”)
- 70. Podsumowanie
- 72. Podsumowanie Linkownia: www.scrumguides.org scrummethodology.com www.mountaingoatsoftware.com Scrum Practitioners (grupa linkedin) http://www.slideshare.net/PMI_Szczecin/michael-kacprzak- agile-project-management-dowiadczenia-z-okopw-na-wesoo (świetna prezentacja Michaela dot. Agile) Coś na odreagowanie: http://devopsreactions.tumblr.com
- 73. Podsumowanie Dziękuję za uwagę Michał Koniewicz marzec 2016
Notes de l'éditeur
- 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.