Agile w praktyce. Podręcznik metod zwinnych. Andy Brandt. Ta książka jest do kupienia

Wielkość: px
Rozpocząć pokaz od strony:

Download "Agile w praktyce. Podręcznik metod zwinnych. Andy Brandt. Ta książka jest do kupienia"

Transkrypt

1

2 Agile w praktyce Podręcznik metod zwinnych Andy Brandt Ta książka jest do kupienia Wersja opublikowana ISBN This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do Andy Brandt

3 Tweet nij tę książkę Proszę pomóż Andy Brandt rozpowszechniać informację o tej książce na Twitter ze! Sugerowany tweet o tej książce to: A teraz będę czytać Agile w praktyce Sugerowany tag do tej książki to #agilewpraktyce. Sprawdź co inni ludzie mówią o tej książce i kliknij na ten link, żeby poszukać tego tagu na Twitter ze: #agilewpraktyce

4 Also By Andy Brandt Environment for Agile Teams

5 Spis treści 1. Scrum Scrum w pigułce Elementy Scruma Wymagania, backlog produktu Role w Zespole Scrum Proces Sprint Planowanie Sprintu Daily Scrum Pielęgnacja backlogu Produkt i kryteria ukończenia Przegląd Sprintu Retrospekcja Podsumowanie i uwagi końcowe

6 1. Scrum Scrum został stworzony przez Kena Schwabera i Jeffa Sutherlanda na przełomie ubiegłego i bieżącego wieku. Bardzo szybko zdobył sobie popularność i jest obecnie wiodącą 1, podstawową metodą z rodziny agile. Początkowo metoda 2 ta była przekazywana ustnie, następnie w postaci szkoleń (pierwsze takie szkolenie odbyło się w 2001 roku). W 2006 roku ukazała się książka Software development with Scrum 3 napisana przez Kena Schwabera i Mikea Beedle. Znana wśród praktyków Scruma jako mała czarna książeczka była to pierwsza kompletna prezentacja metody w formie książkowej. Od 2010 roku metoda jest zdefiniowana w Scrum Guide - niezwykle zwięzłym bo zaledwie 17-o stronicowym dokumencie napisanym i utrzymywanym wspólnie przez obu twórców metody. Ostatnia jego wersja ukazała się 1 sierpnia 2013 roku. Poniżej przedstawiam samą metodę w sposób maksymalnie zwięzły, by następnie omówić niektóre praktyczne jej aspekty. Szczegółowe omówienie głównych praktyk znajduje się w innych rozdziałach. Niektóre z nich są używane także w innych metodach agile, a wiele z nich jest technikami samymi w sobie 1 W najróżniejszych badaniach, w których respondenci proszeni są o wskazanie metody czy też procesu stosowanego w ich firmie do budowy oprogramowania Scrum jest wskazywany najczęściej jeśli respondent twierdzi, że jego firma używa metod agile. 2 Za Słownikiem Języka Polskiego PWN: metodyka [gr.], metodol. zbiór zasad dotyczących sposobów postępowania, efektywnych ze względu na określony cel. Scrum wyczerpuje słownikową definicję metodyki, jednak ze względu na skojrzenia jakie niesie ze sobą to słowo (duże, ciężkie, zbiurokratyzowane metodyki takie jak Prince2) oraz na osobistą prośbę twórców Scruma stosuje się raczej na jego określenie słowo metoda. 3

7 Scrum 2 czyli można je stosować także pojedyńczo. Siła Scruma polega na połączeniu ich w spójny, sprawnie działający system. Na końcu tego rozdziału znajduje się także krótkie omówienie ostatnich zmian w Scrumie (zarówno tych z 2011 r. jak i z 2013 r.). Może ono być pożyteczne dla osób, które szkoliły się ze Scruma przed ich wprowadzeniem. 1.1 Scrum w pigułce Scrum to metoda organizacji pracy nad wytwarzaniem produktu (oprogramowania - aplikacji, systemu itp.), w której nacisk kładzie się na dostarczanie maksymalnej wartości poprzez działające oprogramowane oraz elastyczność umożliwiającą szybką reakcję na zmiany. Scrum opisuje w jaki sposób przetwarzać pewną listę wymagań na gotowy produkt w regularnych interwałach z pomocą jednego, niewielkiego zespołu. Oficjalna definicja metody jest następująca: Scrum: sposób organizacji ludzkiego działania, w ramach którego możliwe jest rozwiązywanie skomplikowanych problemów oraz budowa produktów o najwyższej możliwej wartości. Elementy Scruma Scrum składa się z następujących elementów: Trzech ról: Zespół Developerski (Development Team), Scrum Master, Product Owner tworzący razem Zespół Scrum (Team, Scrum Team). Iteracji zwanych Sprintami oraz następujących podczas nich pięciu spotkań: Planowania Sprintu (Sprint Planning), codziennego Daily Scrum, Pielęgnacji Backlogu

8 Scrum 3 (Backlog Refining), Przeglądu Sprintu (Sprint Review) oraz Retrospekcji (Sprint Retrospective). Dwóch list: backlogu produktu (Product Backlog) oraz backlogu sprintu (Sprint Backlog). Wymagania, backlog produktu W Scrumie wymagania gromadzone są na liście zwanej backlogiem produktu. Product Backlog jest jedynym źródłem wymagań, nad którymi może pracować zespół. Wymagania te są uszeregowane w kolejności, w jakiej będą realizowane. Za kolejność na backlogu produktu odpowiada Product Owner. Kolejność ta jest zmienna w czasie, istota roli PO polega na takim zmienianiu backlogu produktu by co sprint praca zespołu dostarczała maksymalnej wartości. Scrum nie definiuje formatu w jakim mają być opisane wymagania, stwierdza natomiast, że backlog powinien być przejrzysty - a więc widoczny i zrozumiały dla wszystkich zainteresowanych. Scrum zakłada, że wymagania na backlogu mają sens - Scrum jako proces nie dostarcza narzędzi do oceny sensowności i wartości wymagań jak i całego przedsięwzięcia. Więcej na temat backlogu produktu piszę w poświęconym mu rozdziale. Role w Zespole Scrum W Zespole Scrum (ang. Scrum Team) wyróżniamy następujące role: Zespół deweloperski (ang. Development Team lub krótko Team) - to liczący od 3 do 9 osób zespół osób posiadających wspólnie wszystkie kompetencje niezbędne, aby

9 Scrum 4 dostarczać co iterację (Sprint) kompletny, działający, gotowy produkt. Scrum nie narzuca ani nie zaleca żadnej wewnętrznej struktury tego zespołu. Nie ma więc żadnych zdefiniowanych ról w zespole - wszyscy członkowie zespołu to developerzy (ang. developers), przy czym określenie stosowane jest także w stosunku do członków zespołu nie będących programistami. Innymi słowy jest to interdyscyplinarny, samoorganizujący się zespół. Product Owner - osoba odpowiedzialna za porządkowanie backlogu produktu, a przez to decydowanie o kolejności realizacji wymagań czyli kształcie produktu. Product Owner ma za zadanie maksymalizować wartość dostarczaną przez zespół za każdą iteracją (sprintem). Szerzej o roli Product Ownera piszę w poświęconym mu rozdziale. Scrum Master - osoba odpowiedzialna za proces. Scrum Master ma dbać o to, by Scrum był prawidłowo zrozumiany i stosowany zarówno w samym zespole jak i w organizacji. Scrum Master odpowiada także za zespół, jego produktywność i zaangażowanie. Dba o zespół pomagając mu w rozwiązywaniu problemów i usuwaniu przeszkód (w metodyce nazywanych impediments) oraz wspomagając jego samoorganizację. Nie jest jednak kierownikiem zespołu ani liderem technicznym, nie może bezpośrednio polecać członkom zespołu wykonania takiej czy innej pracy, karać ich czy nagradzać ani określać jaką rolę będą pełnić w zespole. Sposób działania Scrum Mastera jest w metodzie definiowany jako servant leadership, co można przetłumaczyć jako przywództwo służebne. Często stosowaną analogią

10 Scrum 5 jest porównywanie Scrum Mastera do trenera drużyny sportowej - pomaga on graczom, formuje z nich zespół, ale nie wybiega na boisko by brać udział w grze. Jak z tego widać Zespół Scrum może liczyć maksymalnie 11 osób. Choć każdy zespół powinien mieć jasno określonego Product Ownera i Scrum Mastera, to jednak na każdą z tych osób może przypadać kilka zespołów. I tak w przypadku pracy kilku zespołów na raz nad jednym produktem mogą one mieć wspólny backlog produktu, a co za tym idzie wspólnego Product Ownera. Jeśli zespół pracuje nad kilkoma produktami przełączając się pomiędzy nimi na granicy sprintu (a więc poświęcając jeden sprint na jeden produkt a kolejny na następny) może mieć innych Product Ownerów dla każdego z tych produktów. Liczba zespołów przypadających na Scrum Mastera zależy od etapu wprowadzania Scruma (i agile w ogóle) oraz dojrzałości zespołu. Przy świeżym zespole, dopiero co uczącym się pracy z tą metodą (a więc często walczącym ze starymi nawykami) Scrum Master może być rolą wymagającą poświęcenia pełni czasu jednemu zespołowi. Przy dojrzałym zespole, który już od dłuższego czasu pracuje w Scrumie (i używa innych metod agile) jeden Scrum Master może przypadać nawet na 3 zespoły. Scrum kategorycznie zakazuje łączenia roli Scrum Mastera i Product Ownera w jednej osobie. Wynika to z tego, że pomiędzy rolami tymi wstępuje naturalne napięcie - Scrum Master dba o proces (a więc np. o to by produkt był zawsze takiej jakości jaką wyznacza Definition of Done) zaś Product Owner chce zrealizować jak najwięcej wartościowej funkcjonalności w każdym sprincie. Jest wartościowe aby napięcie między nimi było eksternalizowane i mogło prowadzić do twórczych, otwartych

11 Scrum 6 dyskusji. Scrum nie zakazuje natomiast łączenia roli Scrum Mastera i developera. Stwierdza jednak, że osoba pełniąca taką rolę będzie wówczas mniej efektywna w którejś z nich lub w obu. Jest to dość intuicyjne - jeśli praca Scrum Mastera wymaga czasu, to członek zespołu ją wykonujący będzie miał odpowiednio mniej czasu na pracę nad produktem w sprincie. Drugi problem z takim łączeniem ról wynika z tego, że inni - zwłaszcza inni członkowie zespołu - mogą nie mieć jasności kiedy dana osoba wypowiada się jako członek zespołu, developer, a kiedy jako Scrum Master. Jest to szczególnie widoczne w przypadku konfliktu między developerami - Scrum Masterowi, który jest jednym z nich trudniej funkcjonować jako mediatorowi. Analogicznie Scrum traktuje łączenie ról Product Ownera i developera. Dodatkowe zagrożenie w przypadku takiego połączenia jest takie, że wówczas PO może zacząć dyktować zespołowi nie tylko co ma być zaimplementowane, ale również jak. Proces Scrum to metoda opisująca proces przetwarzania wymagań zebranych na backlogu produktu (Product Backlog) na gotowy do użycia produkt (potentially shippable product increment) podczas krótkich iteracji zwanych sprintami.

12 Scrum 7 Schemat procesu Scrum Wszystkie zdarzenia opisywane w Scrumie odbywają się wewnątrz sprintu. Każdy sprint rozpoczyna się od spotkania zwanego planowaniem sprintu (Sprint Planning) podczas którego zespół deweloperski przedstawia prognozę jakie wymagania zaimplementuje w ciągu sprintu. Następnie podczas trwania sprintu zespół deweloperski synchronizuje się podczas 15- o minutowych spotkań zwanych Daily Scrum, w których nie bierze udziału nikt spoza tego zespołu. Ponadto, w miarę potrzeb odbywają się spotkania z udziałem Product Ownera poświęcone pielęgnacji backlogu (backlog refining). Na zakończenie sprintu zespół oddaje produkt (increment) - kolejną, gotową wersję rozwijanego przezeń systemu/aplikacji. W produkcie znajdują się tylko te implementacje wymagań, które spełniają kryteria ukończenia (Definition of Done - DoD). Na zakończenie sprintu zespół wraz z Product Ownerem współpracuje z interesariuszami podczas przeglądu sprintu (Sprint Review), którego celem jest sprawdzenie stanu produktu i podjęcie decyzji co do dalszych jego losów. Bezpośrednio po przeglądzie

13 Scrum 8 zespół odbywa retrospekcję (Sprint Retrospective) - spotkanie z udziałem Scrum Mastera i Product Ownera, podczas którego zespół analizuje swój sposób pracy, zastanawia się w jaki sposób mógłby go poprawić i planuje jakie konkretne usprawnienia (actionable improvements) będzie próbował wprowadzić do swej pracy w następnym sprincie. Koniec retrospekcji jest końcem sprintu. Cykl ten powtarzany jest w kolejnych sprintach aż do ukończenia prac z tego czy innego powodu. Poniżej omawiam w szczegółach każdy z tych elementów procesu Scrum. Sprint Wszystkie zdarzenia w Scrumie odbywają się wewnątrz iteracji o stałej długości zwanych sprintami. Sprint może mieć długość do 1 miesiąca i jest wskazane, aby w obrębie jednego przedsięwzięcia długość sprintu pozostawała stała. Należy bardzo dokładnie i stanowczo przestrzegać ustalonej długości sprintu. Sprintu nie wolno skracać ani wydłużać choćby o parę godzin. Celem takiego podejścia jest umożliwienie działania empiryzmu poprzez wyznaczenie stałego, obiektywnego interwału, po którym produkt jest poddawany sprawdzeniu (inspect) i może nastąpić dostosowanie (adapt). Co sprint interesariusze poznają rzeczywisty stan produktu. Wyznaczają go wymagania, które zespół całkowicie ukończył podczas ostatniego sprintu. Ponieważ długość sprintu jest sztywna jest zarazem znana rzeczywista prędkość (velocity) zespołu - wydłużanie sprintu np. o 6 godzin by coś dokończyć prowadziłoby do zafałszowania rzeczywistych możliwości zespołu. Ponadto celem sprintu o niezmiennej długości jest wytworzenie stałego rytmu pracy. Rytm ten będzie istotny nie tylko

14 Scrum 9 dla zespołu, ale i dla całej organizacji. Wszyscy będą wiedzieć, że co dwa albo trzy tygodnie pojawia się nowa wersja produktu oraz rozpoczyna praca nad następną. Długość sprintu ustala się podczas rozpoczynania pracy nad danym przedsięwzięciem, nie powinna być ona potem pochopnie zmieniana. Jeśli z jakichś powodów zmiana jest konieczna nie powinna ona dotyczyć jednego sprintu, lecz winna być następnie stosowana przez dłuższy czas. Planowanie Sprintu Każdy sprint rozpoczyna się od planowania sprintu. Jest to spotkanie, w którym bierze udział cały Zespół Scrum (a więc Product Owner, Scrum Master i Zespół Developerski). Jego celem jest zastanowienie się co można zrobić w nadchodzącym sprincie a także jak to zrobić. Produktem planowania jest backlog sprintu (Sprint Backlog) oraz cel sprintu (Sprint Goal). Maksymalny czas trwania planowania to 8h dla sprintu miesięcznego, jest zalecane aby planowanie dla krótszych sprintów było odpowiednio krótsze. Dobry wskaźnik to max. 2h na tydzień sprintu. By odpowiedzieć na pytanie co można zrobić w tym sprincie Product Owner przedstawia backlog produktu w jego aktualnej 4 kolejności, omawia jakie cele chciałby osiągnąć kolejną wersją produktu (inkrementem) oraz które wymagania powinny być zrealizowane by osiągnąć ten cel. Zespół Scrum wspólnie dyskutuje i ustala zakres pracy. Zespół Developerski kolejno, od góry analizuje wymagania z backlogu produktu, a następnie prognozuje ile z nich zrobi w najbliższym sprincie. O wymaganiach, 4 Do ostatniej chwili przed planowaniem Product Owner ma prawo zmieniać kolejność i zawartość backlogu produktu.

15 Scrum 10 które zmieściły się w tej prognozie mówimy potocznie, że zostały wzięte na sprint. Następnie, cały Zespół Scrum wypracowuje cel sprintu (Sprint Goal). Cel sprintu zostanie osiągnięty poprzez implementację wybranych wymagań z backlogu produktu, jest on zarazem celem do osiągnięcia jak i uzasadnieniem dlaczego ten sprint warto wykonać. Po ustaleniu celu sprintu Zespół Developerski buduje na swój użytek konkretny plan pracy nad wymaganiami wziętymi do sprintu. Wymagania te wraz z owym planem to Sprint Backlog. Scrum nie narzuca konkretnej formy tego planu poza tym, że powinien on umożliwiać śledzenie postępów pracy. Często stosowaną praktyką jest tworzenie dla każdego z wymagań na sprint backlogu zadań (tasks), a więc opisów czynności jakie zespół zamierza wykonać aby dane wymaganie zaimplementować. Są one szacowane w godzinach, co służy następnie do monitorowania postępu prac. Są jednak zespoły, które nie praktykują stosowania zadań lub ich szacowania i monitorują postęp prac w sprincie w inny sposób. Najczęściej zespoły takie stosują tablice kanbanowe i śledzenie na nich jedynie stanu zadań lub całych wymagań (PBI). Niezależnie od przyjętej formy planu tworzenie go oznacza zazwyczaj dalszą dekompozycję wymagań - Product Owner może pomagać w tym odpowiadając na pytania itp. Nie wymaga się, aby w trakcie planowania powstał na cały sprint plan o równym poziomie szczegółowości. Plan na najbliższe dni powinien być szczegółowy - tak, by zaraz po zakończeniu planowania można było przystąpić do pracy. Plan na dalsze dni może być ogólny. Zostanie on doprecyzowany w miarę postępów prac.

16 Scrum 11 Daily Scrum Jest to codzienne, krótkie spotkanie mające na celu synchronizację zespołu, a więc uzyskanie stanu, w którym wszyscy w zespole wiedzą jak wygląda sytuacja w kontekście postępu prac w sprincie. Spotkanie to ma następujące cechy: trwa maksymalnie 15 minut (czas ten nie zależy ani od długości sprintu ani liczebności zespołu), odbywane jest na stojąco, odbywane jest zawsze w tym samym miejscu i o tej samej godzinie, w spotkaniu tym bierze udział wyłącznie Zespół Developerski oraz opcjonalnie Scrum Master. Udział innych osób - choćby bierny - jest niedopuszczalny. Podczas Daily Scrum członkowie Zespołu Developerskiego omawiają następujące kwestie: - co wczoraj zrobiłem/am, co pomogło w osiągnięciu celu sprintu? - co zamierzam zrobić dziś by pomóc w osiągnięciu celu sprintu? - czy dostrzegam jakieś problemy, bariery, które przeszkadzają mi lub całemu Zespołowi Developerskiemu w osiągnięciu celu sprintu? Zatem, podczas tego spotkania Zespół Developerski dokonuje sprawdzenia (inspect) jak wygląda postęp prac nad osiągnięciem celu sprintu oraz dostosowuje się (adapt) poprzez odpowiednie, wspólne zaplanowanie kolejnego dnia. Przyjmuje się zarazem, że przynajmniej raz dziennie, właśnie w okolicach tego spotkania zespół powinien uaktualnić sprint backlog i narzędzie, z pomocą krótego monitoruje postępy swojej pracy. A więc jeśli używane są zadania i wykres burndown, to powinny one być aktualne przed kolejnym Daily

17 Scrum 12 Scrum. W praktyce nie nastręcza to problemu, bo większość zespołów uaktualnia to na bieżąco w miarę postępów prac. Pielęgnacja backlogu Aby zachować płynność pracy jest wskazane aby backlog produktu był wypielęgnowany 5, a więc aby wymagania były przedyskutowane zawczasu między Zespołem Developerskim a Product Ownerem, a także oszacowane i zdekomponowane odpowiednio do swojej pozycji na backlogu. Wymagania, które są na początku backlogu powinny być mniejsze, dokładniejsze i lepiej zrozumiane niż te poniżej. Wymagania, które są tak zdekomponowane, że mogą być przez Zespół Developerski całkowicie zrealizowane w czasie jednego sprintu określane są jako Gotowe (ang. Ready). W Scrumie na pracę Zespołu Scrum nad przyszłym backlogiem produktu przeznaczono do 10% czasu trwania sprintu. Tak więc przykładowo dla dwutygodniowego sprintu jest to maksymalnie jeden cały dzień pracy. Scrum Guide nie określa czy czas ten ma zostać spożytkowany jako jedno długie spotkanie czy kilka mniejszych pozostawiając to decyzji zespołów. Wydaje się, że czynienie z pielęgnacji backlogu jednej sesji, mogącej potencjalnie trwać cały dzień nie byłoby sensowne. Dlatego większość zespołów korzysta z tego czasu podczas kilku krótszych spotkań z Product Ownerem zwanych potocznie groomingami. Podczas tych spotkań zespół i Product Owner wspólnie pracują nie nad wymaganiami bieżącego sprintu, lecz nad backlogiem produktu przygotowując go do kolejnych planowań sprintu. 5 Więcej na temat pielęgnacji backlogu w rozdziale o backlogu produktu.

18 Scrum 13 Produkt i kryteria ukończenia Na zakończenie każdego sprintu zespół dostarcza kolejnej wersji rozwijanego produktu, czasem zwanej inkrementem (od potentially shippable product increment). Produkt ów musi być tak dobry (takiej jakości), by mógł być zastosowany produkcyjnie - by użytkownicy mogli z niego korzystać. Innymi słowy produkt nie może wymagać wykonywania nad nim żadnej dodatkowej pracy poza ewentualną instalacją. W praktyce rzeczywiście zespoły wydają często produkt każdego sprintu na produkcję. Żądanie co sprint w pełni zintegrowanego, działającego produktu, który może być natychmiast wdrożony i używany ma następujące przyczyny: tylko produkt, który jest zdatny do użytku (co do jego jakości) przedstawia jakąkolwiek wartość dla użytkownika/klienta, ponieważ Scrum kładzie nacisk na dostarczanie wartości konieczne jest aby co sprint dostarczany był zdatny do użytku produkt, jedynie informacja o tym jakie funkcje są już w produkcie zaimplementowane i dostępne jest informacją pewną, wszelkie inne informacje to jedynie prognozy - aby więc na poziomie produktu mógł działać empiryzm konieczne jest przedstawianie podczas przeglądu klientowi (lub jego reprezentantowi PO) tylko tego, co jest naprawdę ukończone, konieczność oddawania w pełni zintegrowanego, działającego produktu co sprint wymusza podnoszenie poziomu praktyk technicznych zespołu zarazem wykluczając możliwość pojawienia się nieprzewidzianego okresu stabilizacji, kiedy to okazuje się że integracja zbudowanych na

19 Scrum 14 przestrzeni długiego czasu fragmentów nie daje działającego produktu, praktyka ta podnosi jakość produktu, ponieważ kod napisany na początku przedsięwzięcia jest cały czas testowany i sprawdzany w każdym kolejnym sprincie - jako że zaczynamy od elementów najważniejszych dzięki temu podejściu są one najlepiej sprawdzone. Aby mieć pewność, że produkt co sprint jest w istocie zdatny do użytku definiuje się listę wymagań, które musi on spełniać. Lista ta jest znana jako kryteria ukończenia (Definition of Done, w skrócie DoD). Powstaje ona w wyniku współpracy Product Ownera i Zespołu Developerskiego, który to jest jej właścicielem i decyduje ostatecznie o jej kształcie. Znajdują się tam zarówno kryteria wydajnościowe czy inne wymagania niefunkcjonalne wynikające z potrzeb (te zwykle dostarcza Product Owner) jak i kryteria pozwalające utrzymać jakość strukturalną produktu (te zwykle określa zespół). Jeśli w danej organizacji obowiązują jakieś standardy co do tego co to oznacza, że produkt jest ukończony, to wówczas są one minimalnym - podstawowym - DoD. Tylko wymagania, których implementacja spełnia DoD mogą wejść do produktu (inkrementu) na końcu sprintu. Jeśli implementacja jakiegoś wymagania nie spełnia DoD jest uznawana za nie zrobioną i nie wchodzi do produktu (inkrementu) sprintu. W takiej sytuacji samo wymaganie powraca do backlogu produktu (potocznie mówimy, że zrzuca się je ze sprintu ) do decyzji Product Ownera co do jego dalszych losów. Warto podkreślić, że kryteria ukończenia muszą być tak określone, by miały charakter obiektywnego, binarnego testu (tak - spełnia, nie - nie spełnia). Nie ma tu miejsca na dowolność,

20 Scrum 15 a już szczególnie niewłaściwe jest stosowanie tu odbioru przez Product Ownera, który wedle uznania przyjmuje albo nie daną implementację. Powoduje to rozmycie tego co właściwie jest zrobione, a co nie jak również brak pewności co do tego czy ten sam poziom jakości był utrzymany w całym produkcie. Kryteria ukończenia (DoD) mogą ewoluować podczas pracy nad danym systemem/produktem, przy czym naturalne jest raczej podnoszenie wyrażonych tak wymagań jakościowych wraz ze wzrostem oczekiwań klienta jak i możliwości zespołu niż ich obniżanie. Przegląd Sprintu Gdy produkt (increment) jest już przygotowany odbywa się Przegląd Sprintu (Sprint Review). Jest to spotkanie, w którym uczestniczy Zespół Deweloperski, Product Owner, Scrum Master oraz wszyscy zainteresowani interesariusze i użytkownicy. Jego maksymalny czas trwania to 4 godziny, przy sprintach krótszych niż miesiąc zazwyczaj jest ono krótsze (dobry wskaźnik to 1h na tydzień sprintu). Chociaż Zespół Developerski może opowiedzieć jak przebiegała praca w sprincie - co poszło dobrze, jakie problemy napotkano i jak je rozwiązano - to niejako wbrew swej nazwie spotkanie to nie koncentruje się na analizowaniu przebiegu sprintu, lecz skupia się na aktualnym stanie produktu. Podczas Przeglądu Sprintu zespół przedstawia ukończony właśnie inkrement, często pokazując (demonstrując) jego działanie. Przegląd Sprintu nie ma jednak charakteru demo - celem ewentualnego pokazu jest zapoznanie uczestników (przede wszystkim interesariuszy) z aktualnym stanem produktu poprzez pokazanie jakie funkcje są w nim obecnie dostępne. Poza pokazem Product Owner omawia także aktualny stan backlogu produktu, a także - jeśli jest to

21 Scrum 16 potrzebne - prognozy co do dalszego postępu prac. Istotą przeglądu sprintu jest następująca na kanwie zapoznania się ze stanem produktu dyskusja co do dalszych losów przedsięwzięcia. Najczęściej jej owocem jest dodanie do backlogu produktu nowych pomysłów i wymagań oraz zmiany w kolejności na nim. Mogą jednak być podjęte inne decyzje, na przykład takie jak o wydaniu produktu (jeśli nie dzieje się to automatycznie dla każdej nowej wersji - wówczas wydanie następuje jeszcze przed przeglądem sprintu), o zwiększeniu lub zmniejszeniu zespołu albo liczby zespołów czy wreszcie o przerwaniu przedsięwzięcia. W dyskusji tej bierze się pod uwagę nie tylko stan produktu i projektu (backlog), ale także posiadane informacje o czynnikach zewnętrznych wpływających na produkt (np. reakcja klientów/użytkowników na wprowadzone zmiany, zmiana budżetu itp.). Także i tutaj widzimy empiryzm w działaniu - interesariusze dokonują przeglądu (inspect) produktu i całego przedsięwzięcia, by następnie dokonać dostosowania (adapt) dalszych prac nad nim. Retrospekcja Bezpośrednio po zakończeniu przeglądu zespół odbywa już we własnym gronie Retrospekcję Sprintu (Sprint Retrospective). Jest to spotkanie, w którym udział bierze cały Zespół Scrum (Zespół Developerski, Scrum Master i Product Owner), i podczas którego analizuje się sposób pracy zespołu podczas dobiegającego końca sprintu. Celem jest zastanowienie się w jaki sposób pracę tą można by było usprawnić w przyszłości. Efektem spotkania jest lista konkretnych usprawnień (actionable improvements), które zespół będzie próbował wprowadzić w życie w następnym sprincie. Retrospekcja Sprintu trwa maksymalnie 3 godziny dla

22 Scrum 17 miesięcznych sprintów, zazwyczaj jest krótsza przy krótszych sprintach (dobry wskaźnik to 45 min na tydzień sprintu). Scrum nie określa sposobu prowadzenia retrospekcji, która jest praktyką samą w sobie. Scrum wymaga jednak, aby zespół co sprint analizował swoją pracę i szukał usprawnień. Dzięki temu można powiedzieć, że coraz lepszy zespół jest drugim produktem (po inkremencie) każdego sprintu. Określenie konkretne usprawnienia (actionable improvements) oznacza, że oczekujemy nie ogólnych życzeń ale konkretnych działań - i to takich, których wprowadzenie jest realne w czasie jednego sprintu. Tak więc zamiast np. chcemy pisać więcej testów (życzenie) powinno to być raczej w kolejnym sprincie dla jednego z wymagań zaimplementujemy komplet testów (konkretne działanie, realistycznie realizowalne w jednym sprincie). Podejście to wynika ze słusznej obserwacji, że wszelkie usprawnienia są osiągane nie metodą przełomów i wielkich postanowień lecz systematycznych, małych kroków ku lepszemu. Konieczność realizowania retrospekcji co sprint ma zapewnić, że zespół będzie owe kroki co sprint podejmował. Więcej o retrospekcji piszę w rozdziale poświęconym w całości temu tematowi. Podsumowanie i uwagi końcowe Scrum jest zatem metodą, która opisuje sposób organizacji pracy zespołu, który przetwarza pewne życzenia (wymagania, problemy) uszeregowane w postaci listy (backlogu) na gotowy produkt. Produkt ów powstaje stopniowo, iteracyjnie - w kolejnych sprintach powstają jego kolejne wersje, zawsze technicznie ukończone i działające.

23 Scrum 18 Warto zauważyć, że wbrew dość rozpowszechnionemu przekonaniu Scrum zdecydowanie nie jest metodą zarządzania projektami. Projekt - z definicji - jest przedsięwzięciem, które ma określony z góry zakres i cel. Scrum niczego takiego nie oczekuje ani nie wymaga - jest procesem ciągłym, o nie zakreślonych granicach. Tworzy potok przetwarzania strumienia wymagań na produkt, który może działać tak długo jak są nowe wymagania do zaimplementowania. Dobrze odpowiada to zresztą rzeczywistości pracy większości zespołów, które nie realizują de facto projektów, lecz nie kończący się ciąg zmian w jakimś systemie/produkcie. Scrum jest także metodą, która ma wąski zakres. Scrum nie zajmuje się tym skąd wzięły się wymagania albo zespół - czasem podkreślam to mówiąc, że Scrum jest metodą organizacji pracy, która już jest. Scrum nie zajmuje się również analizowaniem sensowności przedsięwzięcia, aczkolwiek dzięki dostarczaniu działającego oprogramowania co sprint umożliwia wcześniejsze sprawdzenie przydatności produktu czy to jako oferty rynkowej czy narzędzia na własne potrzeby. Wszystkie wydarzenia w Scrumie - począwszy od sprintu po spotkania - mają wyznaczone sztywne ramy czasowe. W oryginale Scrum Guide stosowane jest tutaj określenie timebox. Sugeruje ono sztywność owego czasu - i tak rzeczywiście jest. W prawidłowym stosowaniu Scruma bardzo ważne jest ścisłe i stanowcze przestrzeganie maksymalnych limitów czasu na wszystkie spotkania i inne zdarzenia. Oznacza to, że zdarzenie kończy się wraz z końcem czasu na niego przeznaczonym niezależnie od tego czy znajdujemy się właśnie w trakcie jakiejś dyskusji czy pracy. Poniżej podsumowanie maksymalnych czasów trwania poszczególnych spotkań w Scrumie:

24 Scrum 19 Spotkanie Planowanie sprintu Pielęgnacja backlogu produktu Przegląd sprintu Retrospekcja Daily Scrum Maksymalny czas trwania 8h 10% sprintu 4h 3h 15 minut Wszystkie powyższe czasy to czasy maksymalne. Oznacza to, że wymienione spotkania mogą trwać krócej jeśli temat zostanie wyczerpany. Jedyne zdarzenie Scruma, które nie może trwać ani dłużej ani krócej to sprint. Jest także zalecane proporcjonalne skracanie spotkań dla sprintów krótszych niż miesięczne. W poprzednich wersjach Scruma było to wręcz wymagane - maksymalny czas trwania spotkań był określony właśnie w proporcji do długości sprintu. Ograniczenie to zostało zniesione od wersji Scrum Guide wydanej 1 sierpnia 2013.

SCRUM. Metodyka prowadzenia projektów. Na podstawie prezentacji B. Kuka i W. Sidora

SCRUM. Metodyka prowadzenia projektów. Na podstawie prezentacji B. Kuka i W. Sidora SCRUM Metodyka prowadzenia projektów Na podstawie prezentacji B. Kuka i W. Sidora Wprowadzenie. Scrum jest metodyką prowadzenia projektów zaliczaną do metodyk zwinnych, zgodnych z Agile Manifesto. Scrum

Bardziej szczegółowo

SYSTEMY INFORMATYCZNE ćwiczenia praktyczne

SYSTEMY INFORMATYCZNE ćwiczenia praktyczne SYSTEMY INFORMATYCZNE ćwiczenia praktyczne 12.03.2019 Piotr Łukasik p. 373 email: plukasik@agh.edu.pl / lukasik.pio@gmail.com www.lukasikpiotr.com Zakres tematyczny implementacji projektu informatycznego

Bardziej szczegółowo

Scrum. Zwinna metodyka prowadzenia projektów

Scrum. Zwinna metodyka prowadzenia projektów Scrum Zwinna metodyka prowadzenia projektów Plan prezentacji 1. Ogólna idea 2. Najważniejsze elementy 3. Role 4. Czynności 5. Artefakty 6. Wnioski 7. Literatura Źródło ilustracji: http://commons.wikimedia.org/wiki/file:scrum.jpg

Bardziej szczegółowo

Wprowadzenie do metodyki SCRUM. mgr inż. Remigiusz Samborski Instytut Informatyki Politechnika Wrocławska

Wprowadzenie do metodyki SCRUM. mgr inż. Remigiusz Samborski Instytut Informatyki Politechnika Wrocławska Wprowadzenie do metodyki SCRUM mgr inż. Remigiusz Samborski Instytut Informatyki Politechnika Wrocławska SCRUM Scrum (skrót od scrummage) - metoda ponownego uruchomienia gry w rugby zwana również formacją

Bardziej szczegółowo

Programowanie Zespołowe

Programowanie Zespołowe Programowanie Zespołowe Programowanie zwinne dr Rafał Skinderowicz mgr inż. Michał Maliszewski Programowanie zwinne Grupa metodyk wytwarzania oprogramowania oparta na modelu iteracyjno-obiektowym Powstała

Bardziej szczegółowo

EMPIRYZMSCRUM DOŚWIADCZENIE + PODEJMOWANIE DECYZJI = WIEDZA

EMPIRYZMSCRUM DOŚWIADCZENIE + PODEJMOWANIE DECYZJI = WIEDZA SCRUM ramy postępowania (ang. framework), dzięki którym ludzie mogą adaptacyjnie rozwiązywać złożone problemy tak, by w produktywny i kreatywny sposób wytwarzać produkty o najwyższej możliwej wartości

Bardziej szczegółowo

Planowanie i realizacja zadań w zespole Scrum

Planowanie i realizacja zadań w zespole Scrum MetaPack IT Academy Uniwersytet Zielonogórski Planowanie i realizacja zadań w zespole Scrum Paweł Przybyła Professional Scrum Master (www.scrum.org) Planowanie i realizacja zadań w zespole Scrum Agenda:

Bardziej szczegółowo

Podejście tradycyjne. plan wykonanie sekwencyjna natura wykonywanych zadań

Podejście tradycyjne. plan wykonanie sekwencyjna natura wykonywanych zadań Metodyka Scrum Podejście tradycyjne plan wykonanie sekwencyjna natura wykonywanych zadań analiza i definiowanie wymagań projektowanie rozwiązań kodowanie rozwiązań testowanie odstępstwo od planu jest kosztowne

Bardziej szczegółowo

SCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny

SCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny SCRUM niełatwe wdrażanie metodyki w praktyce Adam Krosny 1 Czym się zajmujemy Realizujemy projekty informatyczne średniej wielkości Ilość osób w projekcie 10-50 Architektura SOA, EBA Wiele komponentów

Bardziej szczegółowo

Główne założenia XP. Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness)

Główne założenia XP. Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness) Extreme programming Główne założenia XP Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness) Praktyki Planowanie: Planowanie releasu Planowanie iteracji

Bardziej szczegółowo

Scrum w praktyce. Michał Piórek

Scrum w praktyce. Michał Piórek Scrum w praktyce Michał Piórek Slajd 2 z 28 Plan prezentacji Scrum metodyka prowadzenia projektów Opis projektu systemu do rozliczania podatków Struktura zespołu i jego role Zespół w firmie Podatnik.info

Bardziej szczegółowo

Zarządzanie projektami. Porównanie podstawowych metodyk

Zarządzanie projektami. Porównanie podstawowych metodyk Zarządzanie projektami Porównanie podstawowych metodyk Porównanie podstawowych metodyk w zarządzaniu projektami PRINCE 2 PMBOK TENSTEP AGILE METODYKA PRINCE 2 Istota metodyki PRINCE 2 Project IN Controlled

Bardziej szczegółowo

SCRUM - FRAMEWORK DO ZWINNEGO PROWADZENIA PROJEKTÓW. Ilona Ławniczak-Tomczak

SCRUM - FRAMEWORK DO ZWINNEGO PROWADZENIA PROJEKTÓW. Ilona Ławniczak-Tomczak SCRUM - FRAMEWORK DO ZWINNEGO PROWADZENIA PROJEKTÓW Ilona Ławniczak-Tomczak AGENDA WPROWADZENIE DO TEMATYKI AGILE OMÓWIENIE METODYKI SCRUM I JEJ ISTOTY ĆWICZENIA WYJAŚNIENIE POWIĄZANIA SCRUM I ZAAWANSOWANYCH

Bardziej szczegółowo

Oferta szkoleń firmy Code Sprinters

Oferta szkoleń firmy Code Sprinters Oferta szkoleń firmy Code Sprinters Code Sprinters sp z o.o. Królewska 2/2 Kraków Telefon +48 12 379 34 14 Fax +48 12 379 34 11 info@codesprinters.com www.codesprinters.com Jako liderzy na rynku szkoleń

Bardziej szczegółowo

e R gulamin Kuźni Talentów

e R gulamin Kuźni Talentów Regulamin Kuźni Talentów Misja Kuźnia powstała by dostarczać młodym Talentom wiedzę, doświadczenie oraz miejsce i środki do ich rozwoju, w tak wielu aspektach tyczących się przyszłej pracy zawodowej, jak

Bardziej szczegółowo

Scaling Scrum with SAFe. Małgorzata Czerwińska

Scaling Scrum with SAFe. Małgorzata Czerwińska Scaling Scrum with SAFe Małgorzata Czerwińska Agenda 1. Wstęp 2. Współpraca zespołów scrumowych 3. Zarządzanie Programem 4. Podsumowanie Wstęp Skuteczność zespołów developerskich, realizujących projekty

Bardziej szczegółowo

DLACZEGO TO DZIAŁA? 21. marca 2012r.

DLACZEGO TO DZIAŁA? 21. marca 2012r. TO DZIAŁA? 21. marca 2012r. PLAN DZIAŁANIA Wprowadzenie Garstka teorii (Agile, Scrum, Kanban) Ćwiczenie 1 Wesele Ćwiczenie 2 Agencja reklamowa Ćwiczenie 3 Obraz Podsumowanie 2 / 25 O MNIE KRZYSZTOF ZALASA

Bardziej szczegółowo

Dobry Product Backlog Oferta szkolenia dla Product Ownerów

Dobry Product Backlog Oferta szkolenia dla Product Ownerów Dobry Product Backlog Oferta szkolenia dla Product Ownerów Spis treści Dobry Product Backlog w 1 dzień... 1 Dobry Product Backlog w 2 dni... 3 Informacje o prowadzącej... 5 Dobry Product Backlog w 1 dzień

Bardziej szczegółowo

Programowanie Zespołowe

Programowanie Zespołowe Programowanie Zespołowe Scrum+ dr Rafał Skinderowicz mgr inż. Michał Maliszewski Przeznaczenie metodyk Agile Metodyki zwinne Pomagają w projektach osadzonych w dynamicznym środowisku Kiedy konkurencja

Bardziej szczegółowo

Programowanie zespołowe

Programowanie zespołowe Programowanie zespołowe Laboratorium 5 - scrum cz. 1 mgr inż. Krzysztof Szwarc krzysztof@szwarc.net.pl Sosnowiec, 21 marca 2017 1 / 30 mgr inż. Krzysztof Szwarc Programowanie zespołowe Filary scruma Przejrzystość

Bardziej szczegółowo

Programowanie zespołowe

Programowanie zespołowe Programowanie zespołowe Laboratorium 4 - modele tworzenia oprogramowania, manifest Agile i wstęp do Scruma mgr inż. Krzysztof Szwarc krzysztof@szwarc.net.pl Sosnowiec, 14 marca 2017 1 / 21 mgr inż. Krzysztof

Bardziej szczegółowo

SCRUM. Wprowadzenie Role Zdarzenia Artefakty KANBAN SCRUM-BAN

SCRUM. Wprowadzenie Role Zdarzenia Artefakty KANBAN SCRUM-BAN Anna Kulig SCRUM Wprowadzenie Role Zdarzenia Artefakty KANBAN SCRUM-BAN Przypomnienie różnica miedzy tradycyjnym a zwinnym podejściem SCRUM - metoda przy użyciu której ludzie mogą z powodzeniem rozwiązywać

Bardziej szczegółowo

Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki

Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework Edyta Tomalik Grzegorz Ziemiecki 1 Nokia Siemens Networks 2013 Tradycyjne podejście analityk programista tester implementacja

Bardziej szczegółowo

Programowanie zwinne - wprowadzenie. Programowanie ekstremalne. Wstęp Reguły i praktyki SCRUM. Wprowadzenie Role Zdarzenia Artefakty

Programowanie zwinne - wprowadzenie. Programowanie ekstremalne. Wstęp Reguły i praktyki SCRUM. Wprowadzenie Role Zdarzenia Artefakty Anna Kulig Programowanie zwinne - wprowadzenie Programowanie ekstremalne Wstęp Reguły i praktyki SCRUM Wprowadzenie Role Zdarzenia Artefakty Agile Manifesto 2001 rok, Snowbird w stanie Utah w USA Najważniejsi

Bardziej szczegółowo

Programowanie obiektowe

Programowanie obiektowe Programowanie obiektowe Laboratorium 7 i 8 - wstęp do scruma mgr inż. Krzysztof Szwarc krzysztof@szwarc.net.pl Sosnowiec, 19 kwietnia 2017 1 / 46 mgr inż. Krzysztof Szwarc Programowanie obiektowe Scrum

Bardziej szczegółowo

Oferta usług coachingowych firmy Code Sprinters

Oferta usług coachingowych firmy Code Sprinters Oferta usług coachingowych firmy Code Sprinters Code Sprinters sp z o.o. Królewska 2/2 Kraków Telefon +48 12 379 34 14 Fax +48 12 379 34 11 info@codesprinters.com www.codesprinters.com Zakres i sposób

Bardziej szczegółowo

SCRUM Product Owner - wstęp do zarządzania produktami

SCRUM Product Owner - wstęp do zarządzania produktami SCRUM Product Owner - wstęp do zarządzania produktami Oferta szkolenia Kontakt: Tomasz Tomaszewski t.tomaszewski@productvision.pl 505 448 703 PRODUCT VISION Wierzymy, że innowacyjne produkty technologiczne

Bardziej szczegółowo

PRINCE2 Foundation & Practitioner - szkolenie z egzaminem certyfikacyjnym

PRINCE2 Foundation & Practitioner - szkolenie z egzaminem certyfikacyjnym Kod szkolenia: Tytuł szkolenia: H6C26S PRINCE2 Foundation & Practitioner - szkolenie z egzaminem certyfikacyjnym Dni: 5 Opis: Metodyka PRINCE2 jest akceptowana na poziomie międzynarodowym i uznana za wiodące

Bardziej szczegółowo

Zwinne metodyki - Scrum

Zwinne metodyki - Scrum Zwinne metodyki - Scrum Kamil Maraś kamil.maras@gmail.com @KamilMaras Kaskadowy Agile Grupa metod wytwarzania oprogramowania opartego na programowaniu iteracyjno-przyrostowym, powstałe jako alternatywa

Bardziej szczegółowo

Wskazówki projektowe. Programowanie Obiektowe Mateusz Cicheński

Wskazówki projektowe. Programowanie Obiektowe Mateusz Cicheński Wskazówki projektowe Programowanie Obiektowe Mateusz Cicheński Przydatne zasady SOLID Wzorce struktury aplikacji MVC MVP MVVM Metody wytwarzania oprogramowania Manifest Zwinnego Wytwarzania Oprogramowania

Bardziej szczegółowo

Szkolenie 1. Zarządzanie projektami

Szkolenie 1. Zarządzanie projektami UNIWERSYTET MARII CURIE-SKŁODOWSKIEJ W LUBLINIE Projekt Nowoczesny model zarządzania w UMCS umowa nr UDA-POKL.04.01.01-00-036/11-00 Pl. Marii Curie-Skłodowskiej 5, 20-031 Lublin, www.nowoczesny.umcs.lublin.pl

Bardziej szczegółowo

Szybkość w biznesie. Zwinne testowanie oprogramowania (Agile) Mateusz Morawski (mateusz.morawski@hp.com) 14 kwietnia 2015

Szybkość w biznesie. Zwinne testowanie oprogramowania (Agile) Mateusz Morawski (mateusz.morawski@hp.com) 14 kwietnia 2015 Szybkość w biznesie Zwinne testowanie oprogramowania (Agile) Mateusz Morawski (mateusz.morawski@hp.com) 14 kwietnia 2015 Klient Wykonawca...wprowadzamy nowy typ przelewów do aplikacji internetowej. Dodam

Bardziej szczegółowo

AGILE SOFTWARE HOUSE SCRUM PRAKTYCZNIE SCRUM BOOK

AGILE SOFTWARE HOUSE SCRUM PRAKTYCZNIE SCRUM BOOK AGILE SOFTWARE HOUSE SCRUM PRAKTYCZNIE SCRUM BOOK 10 LAT DOŚWIADCZENIA W SCRUMIE 40 OSÓB W ZESPOLE 100 WDROŻONYCH PROJEKTÓW 6 TECHNOLOGII OPEN SOURCE MACOPEDIA.COM BUSINESS VALUE PRODUCT OWNER PROXY PRODUCT

Bardziej szczegółowo

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka Agile vs PRINCE2 Ewa Solecka - specjalność ogólna- 1117627 Przemysław Mrozowski specjalność ogólna- 1121130 Michał Roztoczyński specjalność ogólna - 1118910 2014/2015 I rok st. magisterskie Informatyka

Bardziej szczegółowo

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming Jarosław Kuchta Wymagania jakości w Agile Programming Wady klasycznych metod zapewnienia jakości Duży narzut na dokumentowanie Późne uzyskiwanie konkretnych rezultatów Trudność w odpowiednio wczesnym definiowaniu

Bardziej szczegółowo

Feature Driven Development

Feature Driven Development Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami

Bardziej szczegółowo

Wstęp do zarządzania projektami

Wstęp do zarządzania projektami Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.

Bardziej szczegółowo

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. 1. Cel szkolenia

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. 1. Cel szkolenia 1. Cel szkolenia m szkolenia jest nauczenie uczestników stosowania standardu PRINCE2 do Zarządzania Projektami Informatycznymi. Metodyka PRINCE2 jest jednym z najbardziej znanych na świecie standardów

Bardziej szczegółowo

I Twój zespół może być zwinny (choć to może trochę potrwać) Paweł Lipiński

I Twój zespół może być zwinny (choć to może trochę potrwać) Paweł Lipiński I Twój zespół może być zwinny (choć to może trochę potrwać) Paweł Lipiński pawel@warsjawa:/etc$whoami Ja: ponad 10 lat pracy w Javie SCJP, SCWCD, SCBCD, SCEA brałem udział w: rozwój oprogramowania, consulting,

Bardziej szczegółowo

Wstęp do zarządzania projektami

Wstęp do zarządzania projektami Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.

Bardziej szczegółowo

Jak być agile w projekcie utrzymaniowym? JOANNA SIEMIŃSKA

Jak być agile w projekcie utrzymaniowym? JOANNA SIEMIŃSKA Jak być agile w projekcie utrzymaniowym? JOANNA SIEMIŃSKA Joanna Siemińska o mnie Absolwentka Politechniki Warszawskiej Orange Outbox Europejska Organizacja Badań Jądrowych w Genewie (CERN) TouK Certyfikat

Bardziej szczegółowo

Agile Project Management

Agile Project Management Charles G. Cobb, pmp Zrozumieć Agile Project Management Równowaga kontroli i elastyczności przekład: Witold Sikorski APN Promise Warszawa 2012 Spis treści Wstęp...vii Kto powinien przeczytać tę książkę?...

Bardziej szczegółowo

MAJ 2015 CASE STUDY

MAJ 2015 CASE STUDY MAJ 2015 CASE STUDY WWW.FUTURE-PROCESSING.PL 1 EUROMONEY INSTITUTIONAL INVESTOR PLC www.euromoneyplc.com SPIS TREŚCI 1. O KLIENCIE 2 2. PROBLEM BIZNESOWY, KTÓRY ROZWIĄZALŚMY 3 3. ROLA FUTURE PROCESSING

Bardziej szczegółowo

4. Wprowadzanie Scruma w ImmobilienScout24 4.1. Opis sytuacji

4. Wprowadzanie Scruma w ImmobilienScout24 4.1. Opis sytuacji Spis treści Przedmowa 1. Wstęp 1.1. Jak czytać tę książkę 1.2. Studia projektów 1.3. Dodatek 2. Zwinny projekt to nie bułka z masłem 2.1. Pobudka 2.2. Zespół się formuje 2.3. Właściwe zlecenie 2.4. Od

Bardziej szczegółowo

Klasyczna organizacja też może być zwinna! Zarządzaj zwinnie projektami!

Klasyczna organizacja też może być zwinna! Zarządzaj zwinnie projektami! Klasyczna organizacja też może być zwinna! Dynamika zmian w dzisiejszym świecie IT wymaga niezwykłej elastyczności i błyskawicznego adaptowania się do nowych warunków. Klasyczne techniki zarządzania projektami

Bardziej szczegółowo

SKUTECZNY PROJECT MANAGER

SKUTECZNY PROJECT MANAGER Elżbieta Jędrych Paweł Pietras Maciej Szczepańczyk SKUTECZNY PROJECT MANAGER JAK W SPOSÓB SPRAWNY I EFEKTYWNY REALIZOWAĆ POSTAWIONE ZADANIA O CHARAKTERZE PROJEKTOWYM Monografie Politechniki Łódzkiej 2016

Bardziej szczegółowo

Estimation and planing. Marek Majchrzak, Andrzej Bednarz Wroclaw, 06.07.2011

Estimation and planing. Marek Majchrzak, Andrzej Bednarz Wroclaw, 06.07.2011 Estimation and planing Marek Majchrzak, Andrzej Bednarz Wroclaw, 06.07.2011 Story points Story points C D B A E Story points C D 100 B A E Story points C D 2 x 100 100 B A E Story points C D 2 x 100 100

Bardziej szczegółowo

Wstęp do zarządzania projektami

Wstęp do zarządzania projektami Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.

Bardziej szczegółowo

PRINCE Foundation

PRINCE Foundation PRINCE2 2009 Foundation Istota PRINCE2 Metodyka PRINCE2 stanowi doskonałą podstawę do realizacji wszelkich projektów w przedsiębiorstwach i organizacjach dowolnej wielkości i branży. Pozwala w zorganizowany

Bardziej szczegółowo

Wprowadzenie do Behaviordriven

Wprowadzenie do Behaviordriven Wprowadzenie do Behaviordriven development Jakub Kosiński Email: ja@ghandal.net Czym jest BDD? praktyka, powstała na podstawie TDD, wykorzystywana w zwinnych metodykach stworzona przez Dana Northa w 2003

Bardziej szczegółowo

Spis Treści. Cel podręcznika. Definicja SCRUMa. Teoria SCRUMa. Zespół SCRUMowy. Właściciel Produktu. Zespół Deweloperski.

Spis Treści. Cel podręcznika. Definicja SCRUMa. Teoria SCRUMa. Zespół SCRUMowy. Właściciel Produktu. Zespół Deweloperski. Spis Treści Cel podręcznika Definicja SCRUMa Teoria SCRUMa Zespół SCRUMowy Właściciel Produktu Zespół Deweloperski SCRUM Master Zdarzenia w SCRUMie Sprint Planowanie Sprintu Cel Sprintu Codzienny SCRUM

Bardziej szczegółowo

Temat: Zwinne Zarządzanie Projektami IT (Agile / Scrum) Data: 06-07 marca 2014 r. (2 dni, czwartek-piątek), godz. 9-16

Temat: Zwinne Zarządzanie Projektami IT (Agile / Scrum) Data: 06-07 marca 2014 r. (2 dni, czwartek-piątek), godz. 9-16 Temat: Zwinne Zarządzanie Projektami IT (Agile / Scrum) Data: 06-07 marca 2014 r. (2 dni, czwartek-piątek), godz. 9-16 Miejsce: Eureka Technology Park, Innowatorów 8 Cena: 980 zł netto (1 osoba / 2 dni

Bardziej szczegółowo

Lekkie metodyki. tworzenia oprogramowania

Lekkie metodyki. tworzenia oprogramowania Lekkie metodyki tworzenia oprogramowania Programowanie zwinne ( Agile software development) grupa metodyk wytwarzania oprogramowania opartego o programowanie iteracyjne (model przyrostowy). Wymagania oraz

Bardziej szczegółowo

Opisy szkoleń dla certyfikatów Agile Scrum. www.cts.com.pl

Opisy szkoleń dla certyfikatów Agile Scrum. www.cts.com.pl Opisy szkoleń dla certyfikatów Agile Scrum www.cts.com.pl SPIS TREŚCI Opisy szkoleń dla certyfikatów Agile Scrum...2 Istniejące certyfikacje agile...2 Szkolenia oferowane przez CTS...3 Agile Tester (zgodne

Bardziej szczegółowo

Scrum Guide. Przewodnik po Scrumie: Reguły Gry. Lipiec 2013. Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda

Scrum Guide. Przewodnik po Scrumie: Reguły Gry. Lipiec 2013. Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda Scrum Guide Przewodnik po Scrumie: Reguły Gry Lipiec 2013 Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda Spis treści Cel przewodnika... 3 Definicja Scruma... 3 Teoria Scruma... 3 Zespół

Bardziej szczegółowo

KILKA SŁÓW O ROLI PRODUCT MANAGERA

KILKA SŁÓW O ROLI PRODUCT MANAGERA CZĘŚĆ I. KILKA SŁÓW O ROLI PRODUCT MANAGERA Product manager pracuje na styku świata IT i biznesu. Analizuje potrzeby użytkowników i klientów, współpracuje ze wszystkimi działami firmy maksymalizując wartość

Bardziej szczegółowo

Zarządzanie projektami w NGO

Zarządzanie projektami w NGO Zarządzanie projektami w NGO Warsztaty dla Grupy Nowe Technologie Federacja Organizacji Służebnych MAZOWIA 4 września 2012 Projekt współfinansowany jest ze środków Unii Europejskiej w ramach Europejskiego

Bardziej szczegółowo

Generacja Y o mediach społecznościowych w miejscu pracy

Generacja Y o mediach społecznościowych w miejscu pracy Generacja Y o mediach społecznościowych w miejscu pracy Raport z badania Szymon Góralski Wrocław, 2013 ul. Więzienna 21c/8, 50-118 Wrocław, tel. 71 343 70 15, fax: 71 343 70 13, e-mail: biuro@rrcc.pl,

Bardziej szczegółowo

KOMPLEKSOWE ZARZĄDZANIE JAKOŚCIĄ MODELOWANIE PROCESÓW

KOMPLEKSOWE ZARZĄDZANIE JAKOŚCIĄ MODELOWANIE PROCESÓW KOMPLEKSOWE ZARZĄDZANIE JAKOŚCIĄ MODELOWANIE PROCESÓW Cel szkolenia: Przekazanie wiedzy na temat kompleksowego zarządzania jakością w tym modelowania procesów. Podnoszenie kompetencji i umiejętności związanych

Bardziej szczegółowo

Agile - Transformacje

Agile - Transformacje Agile - Transformacje Historia pewnej transformacji Wiktor Żołnowski This book is for sale at http://leanpub.com/agile-transformacje This version was published on 2014-01-15 This is a Leanpub book. Leanpub

Bardziej szczegółowo

Projektowanie oprogramowania. Termin zajęć: poniedziałek, 18.00-19.45. a podstawie materiału ze strony. http://gromit.iiar.pwr.wroc.

Projektowanie oprogramowania. Termin zajęć: poniedziałek, 18.00-19.45. a podstawie materiału ze strony. http://gromit.iiar.pwr.wroc. Projektowanie oprogramowania Termin zajęć: poniedziałek, 18.00-19.45 a podstawie materiału ze strony http://gromit.iiar.pwr.wroc.pl/p_inf/ Przebieg realizacji projektu (tabela 1) Nr tygo dnia Spotkanie

Bardziej szczegółowo

Opis realizacji dla czterech zespołów (4 przypadki użycia)

Opis realizacji dla czterech zespołów (4 przypadki użycia) Projektowanie oprogramowania Termin zajęć: czwartek, sala L2.6, C16 7.30-9.00, 9.15-10.45 Na podstawie materiału ze strony http://gromit.iiar.pwr.wroc.pl/p_inf/ Przebieg realizacji projektu (tabela 1)

Bardziej szczegółowo

Priorytetyzacja przypadków testowych za pomocą macierzy

Priorytetyzacja przypadków testowych za pomocą macierzy Priorytetyzacja przypadków testowych za pomocą macierzy W niniejszym artykule przedstawiony został problem przyporządkowania priorytetów do przypadków testowych przed rozpoczęciem testów oprogramowania.

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

Scrum Guide. Przewodnik po Scrumie: Reguły Gry. Lipiec 2013. Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda

Scrum Guide. Przewodnik po Scrumie: Reguły Gry. Lipiec 2013. Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda Scrum Guide Przewodnik po Scrumie: Reguły Gry Lipiec 2013 Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda Spis treści Cel przewodnika... 3 Definicja Scruma... 3 Teoria Scruma... 3 Zespół

Bardziej szczegółowo

Podejście zwinne do zarządzania projektami

Podejście zwinne do zarządzania projektami Podejście zwinne do zarządzania projektami na przykładach projektów wytwarzania oprogramowania Wojciech Czujowski, Łukasz Sienkiewicz Tieto Poland Agenda CZĘŚĆ I-sza: Kilka słów o Tieto SCRUM w organizacji

Bardziej szczegółowo

Maciej Piotr Jankowski

Maciej Piotr Jankowski Reduced Adder Graph Implementacja algorytmu RAG Maciej Piotr Jankowski 2005.12.22 Maciej Piotr Jankowski 1 Plan prezentacji 1. Wstęp 2. Implementacja 3. Usprawnienia optymalizacyjne 3.1. Tablica ekspansji

Bardziej szczegółowo

kompetencji zawodowych Professional Scrum Master I, Certified Scrum Master I Mirosław Dąbrowski zespół Indeed wprowadzenie Scruma

kompetencji zawodowych Professional Scrum Master I, Certified Scrum Master I Mirosław Dąbrowski zespół Indeed wprowadzenie Scruma POZNAJ SCRUM WSTĘP Zdajemy sobie sprawę, że każdą organizację tworzą ludzie, dlatego bardzo przykładamy się do rozwoju ich kompetencji zawodowych. Dziękujemy za zaufanie. Nasze autorskie szkolenie przeznaczone

Bardziej szczegółowo

Wszystkie problemy leżą w testach. ForProgress spółka z ograniczoną odpowiedzialnością sp.k.

Wszystkie problemy leżą w testach. ForProgress spółka z ograniczoną odpowiedzialnością sp.k. Wszystkie problemy leżą w testach O czym będziemy rozmawiać Coś nie wyszło Jak wygląda proces wytwórczy Każdy widzi to inaczej Jakie wnioski wyciągamy z testów Analiza problemów Możliwe rozwiązania O czym

Bardziej szczegółowo

MODEL KOMPETENCYJNY DYREKTORA

MODEL KOMPETENCYJNY DYREKTORA MODEL KOMPETENCYJNY DYREKTORA JAKO NARZĘDZIE WSPOMAGAJĄCE ZARZĄDZANIE PLACÓWKĄ ZARZĄDZANIE PO WROCŁAWSKU prof. UWr Kinga Lachowicz-Tabaczek Instytut Psychologii Uniwersytetu Wrocławskiego, HR Projekt Wrocław

Bardziej szczegółowo

Programowanie zespołowe

Programowanie zespołowe Programowanie zespołowe Laboratorium 1 - wprowadzenie do zarządzania projektami mgr inż. Krzysztof Szwarc krzysztof@szwarc.net.pl Sosnowiec, 21 lutego 2017 1 / 28 mgr inż. Krzysztof Szwarc Programowanie

Bardziej szczegółowo

SZKOLENIE. Jak zarządzać projektem z wykorzystaniem MS Project. tel: ; fax: ;

SZKOLENIE. Jak zarządzać projektem z wykorzystaniem MS Project. tel: ; fax: ; SZKOLENIE Jak zarządzać projektem z wykorzystaniem MS Project tel: +48 22 100-48-96; fax: +48 22 300-52-79; e-mail: biuro@akademiaasap.pl TRENERZY DORADCY TRENERZY i KONSULTANCI NASZA MISJA DOSTARCZENIE

Bardziej szczegółowo

Testujemy dedykowanymi zasobami (ang. agile testers)

Testujemy dedykowanymi zasobami (ang. agile testers) Testujemy dedykowanymi zasobami (ang. agile testers) - wspólne standupy; - ten sam manager; - duży przepływ informacji; - po pewnym czasie zanika asertywność; - pojawia się tendencja do nie zgłaszania

Bardziej szczegółowo

Marta Ożóg 183858 Agnieszka Pastusińska 183875

Marta Ożóg 183858 Agnieszka Pastusińska 183875 Marta Ożóg 183858 Agnieszka Pastusińska 183875 Mistrz młyna to osoba, która pomaga wszystkim zaangażowanym osobom w zrozumieniu i przestrzeganiu wartości, zasad i praktyk Scruma. Scrum Master może kojarzyć

Bardziej szczegółowo

Zarządzanie Projektami Plan kursu

Zarządzanie Projektami Plan kursu Zarządzanie Projektami Plan kursu opracował Wojciech Walczak Dokument ten przedstawia plan kursu Zarządzanie projektami. Uczestnicy kursu zobowiązują się do przeprowadzenia wybranego przez siebie projektu

Bardziej szczegółowo

Techniki komputerowe w robotyce

Techniki komputerowe w robotyce Techniki komputerowe w robotyce Wykład V Adaptacyjne zarządzanie projektami Robert Muszyński KCiR, W4, PWr Skład FoilTEX c R. Muszyński 2009-2015 Metodologie prowadzenia projektu Dążenie do opracowania

Bardziej szczegółowo

Zarządzanie projektami. Wykład 2 Zarządzanie projektem

Zarządzanie projektami. Wykład 2 Zarządzanie projektem Zarządzanie projektami Wykład 2 Zarządzanie projektem Plan wykładu Definicja zarzadzania projektami Typy podejść do zarządzania projektami Cykl życia projektu/cykl zarządzania projektem Grupy procesów

Bardziej szczegółowo

Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz

Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz Promotor dr inż. Szymon Supernak Warszawa, 22.05.2014 Plan prezentacji 1. Cel i

Bardziej szczegółowo

Zarządzanie Projektami zgodnie z PRINCE2

Zarządzanie Projektami zgodnie z PRINCE2 Zarządzanie Projektami zgodnie z PRINCE2 Opis Metodyka PRINCE2 powstała na bazie doświadczeń z wielu lat dobrych praktyk zarządzania projektami. Metodyka ta oferuje elastyczne i łatwe do adaptacji podejście

Bardziej szczegółowo

The Scrum Guide. Przewodnik po Scrumie: Reguły Gry. Lipiec 2011. Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda

The Scrum Guide. Przewodnik po Scrumie: Reguły Gry. Lipiec 2011. Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda The Scrum Guide Przewodnik po Scrumie: Reguły Gry Lipiec 2011 Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda Spis treści Cel przewodnika... 3 Scrum informacje ogólne... 3 Struktura

Bardziej szczegółowo

Program New Way of Working (NWoW) źródłem motywacji do zmiany postaw. innogy Polska Dorota Kuprianowicz-Legutko

Program New Way of Working (NWoW) źródłem motywacji do zmiany postaw. innogy Polska Dorota Kuprianowicz-Legutko Program New Way of Working (NWoW) źródłem motywacji do zmiany postaw innogy Polska Dorota Kuprianowicz-Legutko 1 NWoW New Way of Working 2 LDNA Leadership DNA 3 AL Akademia Lidera Jaka jest definicja NWoW?

Bardziej szczegółowo

Omówienie założeń procesu Design Thinking i przeprowadzenie wstępnego warsztatu. Mariusz Muraszko i Mateusz Ojdowski Logisfera Nova

Omówienie założeń procesu Design Thinking i przeprowadzenie wstępnego warsztatu. Mariusz Muraszko i Mateusz Ojdowski Logisfera Nova Dzień 1 PONIEDZIAŁEK 1.09.2014 8:00-10:00 Wprowadzenie do UX Otwarcie szkoły letniej wraz z wprowadzeniem do User Experience, przedstawienie struktury UX, narzędzi używanych przez specjalistów i dobrych

Bardziej szczegółowo

NOWE METODYKI PROWADZENIA PROJEKTU

NOWE METODYKI PROWADZENIA PROJEKTU Dr inż. Dariusz RODZIK Mgr inż. Paweł SIERGIEJUK Mgr inż. Stanisław GRZYWIŃSKI Wojskowa Akademia Techniczna Wydział Mechatroniki i Lotnictwa NOWE METODYKI PROWADZENIA PROJEKTU Streszczenie: W pracy opisano

Bardziej szczegółowo

SKUTECZNE ZARZĄDZANIE PROJEKTEM

SKUTECZNE ZARZĄDZANIE PROJEKTEM SKUTECZNE ZARZĄDZANIE PROJEKTEM Zarządzanie projektami to nie jest takie skomplikowane! TERMIN od: 02.10.2017 TERMIN do: 04.10.2017 CZAS TRWANIA:3 dni MIEJSCE: Gdańsk CENA: 1500 zł + 23% VAT Jak sprawniej

Bardziej szczegółowo

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................

Bardziej szczegółowo

SCENARIUSZ LEKCJI. Streszczenie. Czas realizacji. Podstawa programowa

SCENARIUSZ LEKCJI. Streszczenie. Czas realizacji. Podstawa programowa Autorzy scenariusza: SCENARIUSZ LEKCJI OPRACOWANY W RAMACH PROJEKTU: INFORMATYKA MÓJ SPOSÓB NA POZNANIE I OPISANIE ŚWIATA. PROGRAM NAUCZANIA INFORMATYKI Z ELEMENTAMI PRZEDMIOTÓW MATEMATYCZNO-PRZYRODNICZYCH

Bardziej szczegółowo

2016/2017. Zarządzanie projektami. Kiełbus Anna. Szablon projektu semestralnego

2016/2017. Zarządzanie projektami. Kiełbus Anna. Szablon projektu semestralnego Zarządzanie projektami Kiełbus Anna 2016/2017 Szablon projektu semestralnego Politechnika Krakowska al. Jana Pawła II 37 +48 12 374 32 83 kielbus@mech.pk.edu.pl I. Informacje wstępne Temat, Nr grupy, kierunek/specjalność,

Bardziej szczegółowo

Nexus Przewodnik. Definitywny przewodnik po Nexusie: Rozszerzenie Scruma dla przedsięwzięć dużej skali

Nexus Przewodnik. Definitywny przewodnik po Nexusie: Rozszerzenie Scruma dla przedsięwzięć dużej skali Nexus Przewodnik Definitywny przewodnik po Nexusie: Rozszerzenie Scruma dla przedsięwzięć dużej skali Przygotowany i utrzymywany przez Kena Schwabera i Scrum.org Sierpień 2015 Spis treści Przegląd Nexusa...

Bardziej szczegółowo

Jak uchronić architekturę i wymagania przed chaosem? Warszawa, 27 stycznia 2016 roku

Jak uchronić architekturę i wymagania przed chaosem? Warszawa, 27 stycznia 2016 roku Jak uchronić architekturę i wymagania przed chaosem? Warszawa, 27 stycznia 2016 roku Agenda Metafory o Zwinności i Sztywności Teza: Oszukujemy się co do sukcesów projektów Agile Objawy chaosu w projektach

Bardziej szczegółowo

Scrum Guide. Przewodnik po Scrumie: Reguły gry. Lipiec Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda

Scrum Guide. Przewodnik po Scrumie: Reguły gry. Lipiec Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda Scrum Guide Przewodnik po Scrumie: Reguły gry Lipiec 2016 Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda Spis tres ci Cel przewodnika... 3 Definicja Scruma... 3 Teoria Scruma... 3

Bardziej szczegółowo

Zarządzanie projektami a zarządzanie ryzykiem

Zarządzanie projektami a zarządzanie ryzykiem Ewa Szczepańska Zarządzanie projektami a zarządzanie ryzykiem Warszawa, dnia 9 kwietnia 2013 r. Agenda Definicje Wytyczne dla zarządzania projektami Wytyczne dla zarządzania ryzykiem Miejsce ryzyka w zarządzaniu

Bardziej szczegółowo

Informacje i materiały dotyczące wykładu będą publikowane na stronie internetowej wykładowcy, m.in. prezentacje z wykładów

Informacje i materiały dotyczące wykładu będą publikowane na stronie internetowej wykładowcy, m.in. prezentacje z wykładów Eksploracja danych Piotr Lipiński Informacje ogólne Informacje i materiały dotyczące wykładu będą publikowane na stronie internetowej wykładowcy, m.in. prezentacje z wykładów UWAGA: prezentacja to nie

Bardziej szczegółowo

MSF. Microsoft Solution Framework

MSF. Microsoft Solution Framework MSF Microsoft Solution Framework MSF a PMI PMI - metodyka podobna dla każdego rodzaju projektów MSF metodyka przeznaczona dla projektów informatycznych mająca cechy PMI MSF metodyka utworzona na podstawie

Bardziej szczegółowo

Akademia ADB Wykład I Praca w grupie i jakość kodu

Akademia ADB Wykład I Praca w grupie i jakość kodu Akademia ADB Wykład I Praca w grupie i jakość kodu Ale zanim zaczniemy... https://www.adbglobal.com/adb-tech-talk/ Wtorek, 24 X 2017, 18:00 w Filharmonii Zielonogórskiej Kto pracuje nad projektem? Nad

Bardziej szczegółowo

Poniższy program może być skrócony do 1 dnia lub kilkugodzinnej prezentacji.

Poniższy program może być skrócony do 1 dnia lub kilkugodzinnej prezentacji. ZARZĄDZANIE PROJEKTAMI JAK ZAKOŃCZYĆ PROJEKT Z SUKCESEM Beata Kozyra 2018 2 dni Poniższy program może być skrócony do 1 dnia lub kilkugodzinnej prezentacji. Każdy projekt musi mieć cel, który można zmierzyć,

Bardziej szczegółowo

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej Wykład VII - semestr III Kierunek Informatyka Wydział Matematyki Stosowanej Politechniki Śląskiej Gliwice, 2014 c Copyright 2014 Janusz Słupik Wytwarzanie oprogramowania Model tworzenia oprogramowania

Bardziej szczegółowo

Metodyki programowania. Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl

Metodyki programowania. Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl Metodyki programowania Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl Wybrane metodyki zwinne TRADYCYJNE: RUP (Rational Unified Process) spiralny, rozbudowany PRINCE2 (Projects In Controlled Environments)

Bardziej szczegółowo

Piotr Ślęzak. Gdzie się podziała jakość

Piotr Ślęzak. Gdzie się podziała jakość Piotr Ślęzak Gdzie się podziała jakość Działamy na styku Biznesu i IT Analiza biznesowa Kontrola jakości Doradztwo Projekty Szkolenia ForProgress spółka z ograniczoną odpowiedzialnością sp.k. kontakt@forprogress.com.pl

Bardziej szczegółowo