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

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

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

Transkrypt

1 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

2 Spis treści Przegląd Nexusa... 2 Cel przewodnika... 2 Definicja Nexusa... 2 Tło powstania Nexusa... 2 Ramy Nexusa... 3 Kolejność zdarzeń Nexusa... 4 Praktyki inżynierskie... 5 Nexus... 5 Role Nexusa... 5 Zespół Integracyjny Nexusa... 5 Zdarzenia Nexusa... 7 Planowanie Sprintu Nexusa... 7 Codzienny Scrum Nexusa... 7 Przegląd Sprintu Nexusa... 8 Retrospektywa Sprintu Nexusa... 8 Doskonalenie Backlogu Produktu... 9 Artefakty Nexusa Backlog Produktu Cel Nexusa Backlog Sprintu Nexusa Zintegrowany Przyrost Przejrzystość artefaktów Definicja Ukończenia Informacje końcowe Wyróżnienie Tłumaczenie Copyright Scrum.org, 2015 Wszystkie prawa zastrzeżone Strona 1 (Wersja 1.1)

3 Przegląd Nexusa Cel przewodnika Nexus to model postępowania pomocny w wytwarzaniu i utrzymaniu produktów oraz w prowadzeniu inicjatyw związanych z produkcją oprogramowania dużej skali. U jego podstaw leży Scrum. Niniejszy przewodnik zawiera definicję tego modelu, na którą składają się: role, zdarzenia, artefakty oraz zestaw reguł spajających te elementy w jedną, nierozerwalną całość. Twórcami Nexusa są Ken Schwaber i zespół Scrum.org; oni również przygotowali i udostępnili niniejszy Przewodnik po Nexusie. Definicja Nexusa Nexus (rzecz.): Podstawowa komórka wytwórcza w procesie profesjonalnego wytwarzania oprogramowania w dużej skali przy zastosowaniu Scruma (Scaled Professional Scrum). Nexus to model postępowania składający się z ról, zdarzeń, artefaktów i technik, które łączą i splatają pracę około trzech do dziewięciu Zespołów Scrumowych (ang. Scrum Teams) pracujących nad jednym Backlogiem Produktu (ang. Product Backlog) i wspólnie wytwarzających Zintegrowany Przyrost (ang. Integrated Increment) spełniający założony cel. Tło powstania Nexusa Wytwarzanie oprogramowania jest czynnością złożoną, a proces integracji prowadzący do uzyskania działającego, Ukończonego oprogramowania wiąże się z koordynowaniem wielu działań i wykorzystaniem wielu składowych. Aktywności te powinny być odpowiednio ze sobą zorganizowane i zestrojone, zależności między nimi rozwiązane, a ich wyniki odpowiednio ze sobą połączone. Dodatkową trudność stanowi fakt, że oprogramowanie nie jest produktem materialnym. Wielu twórców oprogramowania używa Scruma by kolektywnie, zespołowo, wytwarzać Przyrosty działającego oprogramowania. Jednak jeśli w ramach tego samego Backlogu Produktu i z tym samym kodem źródłowym pracuje więcej niż jeden Zespół Scrumowy, skala trudności znacznie wzrasta. Jeśli deweloperzy nie są członkami tego samego, zlokalizowanego w jednym miejscu zespołu, w jaki sposób mają się komunikować, gdy efekty ich pracy wpływają na siebie wzajemnie? Jeśli pracują w różnych zespołach, w jaki sposób mają integrować wyniki swojej pracy i testować Zintegrowany Przyrost? Takie wyzwania pojawiają się już podczas integracji dwóch zespołów, a zwiększenie ich liczby powoduje znaczne spotęgowanie trudności. Pomiędzy współpracującymi ze sobą zespołami, dążącymi do wytworzenia pełnego i Ukończonego Przyrostu przynajmniej raz na Sprint, pojawia się wiele zależności. Dotyczą one następujących obszarów: 1. Wymagania: Zakres poszczególnych wymagań może się nakładać, również sposoby ich implementacji mogą na siebie oddziaływać. Należy wziąć to pod uwagę podczas porządkowania elementów Backlogu Produktu i wybierania wymagań. 2. Wiedza domenowa: Członkowie zespołów mają różnorodną wiedzę biznesową oraz wiedzę na temat budowy i działania systemów informatycznych. Wiedza ta powinna mieć swoje odzwierciedlenie w Zespołach Scrumowych, aby zapewnić jej Copyright Scrum.org, 2015 Wszystkie prawa zastrzeżone Strona 2 (Wersja 1.1)

4 odpowiednią dostępność oraz ograniczać zakłócenia w pracy pomiędzy zespołami podczas Sprintu. 3. Oprogramowanie i zestawy testów: Poszczególne wymagania są lub będą odzwierciedlane w kodzie źródłowym i zestawach testów. 4. Na tyle na ile wymagania, wiedza członków zespołów, kod źródłowy oraz zestawy testów będą dopasowane do siebie w ramach Zespołów Scrumowych, na tyle zredukowane zostaną zależności pomiędzy tymi zespołami. Kiedy wykorzystuje się Scruma w środowisku wymagającym skalowania, zależności powinny wpływać na sposób w jaki zorganizowane są zespoły. Ich produktywność będzie bowiem związana ze stopniem w jakim uda się te zależności ograniczyć. Ramy Nexusa Nexus to rozszerzenie Scruma wspomagające pracę wielu Zespołów Scrumowych pracujących wspólnie nad stworzeniem Zintegrowanego Przyrostu. Nexus jest spójny ze Scrumem, a jego elementy nie będą niespodzianką dla osób, które wcześniej uczestniczyły w projektach scrumowych. Różnica polega na tym, że więcej uwagi poświęca się tu zależnościom i współdziałaniu Zespołów Scrumowych, dostarczających Ukończony Zintegrowany Przyrost przynajmniej raz na Sprint. Jak pokazano na poniższym rysunku, Nexus składa się z następujących elementów: Role: Nowa rola Zespół Integracyjny Nexusa (ang. Nexus Integration Team) istnieje by koordynować, uczyć i nadzorować stosowanie Nexusa i Scruma w celu osiągania jak najlepszych wyników. Zespół Integracyjny Nexusa składa się z Właściciela Produktu (ang. Product Owner), Scrum Mastera i członków Zespołu Integracyjnego Nexusa. Artefakty: Wszystkie Zespoły Scrumowe używają tego samego, wspólnego Backlogu Produktu. Podczas doskonalenia elementów Backlogu Produktu do stanu gotowości następuje uwidocznienie przyporządkowania ich do zespołu, który będzie nad nimi pracował w Sprincie. Nowy artefakt, Backlog Sprintu Nexusa (ang. Nexus Sprint Backlog), ułatwia zachowanie przejrzystości podczas Sprintu. Niezależnie od istnienia Backlogu Sprintu Nexusa, wszystkie Zespoły Scrumowe utrzymują swoje własne Backlogi Sprintu (ang. Sprint Backlog). Zdarzenia: Zdarzenia Nexusa rozszerzają, otaczają lub w przypadku Przeglądu Sprintu (ang. Sprint Review) zastępują standardowe zdarzenia Scruma, tak aby dostosować je do wymogów dużej skali. Po zmodyfikowaniu będą służyć zarówno wspólnej pracy wszystkich Zespołów Scrumowych w Nexusie, jak i każdemu pojedynczemu zespołowi. Copyright Scrum.org, 2015 Wszystkie prawa zastrzeżone Strona 3 (Wersja 1.1)

5 Nexus : rozszerzenie Scruma dla przedsięwzięć dużej skali Kolejność zdarzeń Nexusa Nie ma ograniczeń związanych z uczestnictwem członków Zespołów Scrumowych w zdarzeniach Nexusa. Mając na uwadze zależności pomiędzy zespołami, zespoły mogą dobierać członków najbardziej odpowiednich do wykonania konkretnych zadań. Doskonalenie Backlogu Produktu (ang. Refinement): Backlog Produktu należy zdekomponować w taki sposób, aby można było łatwo zidentyfikować, a następnie usunąć lub ograniczyć zależności. Elementy Backlogu Produktu dzielone są na wąskie wycinki funkcjonalności, a następnie tak wcześnie jak to tylko możliwe identyfikuje się zespoły, które najprawdopodobniej będą nad danym wycinkiem pracować. Planowanie Sprintu Nexusa (ang. Nexus Sprint Planning): Wyznaczeni przedstawiciele każdego Zespołu Scrumowego spotykają się aby przejrzeć i omówić przygotowany Backlog Produktu. Wybierają oni elementy Backlogu Produktu dla każdego z zespołów. Następnie, każdy Zespół Scrumowy planuje swój własny Sprint, współdziałając z innymi zespołami jeśli zachodzi taka konieczność. Wynikiem jest zestaw Celów Sprintu, zgodnych z nadrzędnym Celem Nexusa (ang. Nexus Goal), z Backlogami Sprintu wszystkich Zespołów Scrumowych oraz z Backlogiem Sprintu Nexusa. Backlog Sprintu Nexusa powoduje, że wybrane przez Zespół Scrumowy elementy Backlogu Produktu i wszystkie zależności stają się widoczne. Wytwarzanie Przyrostu: Wszystkie zespoły wytwarzają oprogramowanie, często integrując swoją pracę we wspólnym (międzyzespołowym) środowisku, w którym może ono być testowane w celu zapewnienia jego pełnej integracji. Codzienny Scrum Nexusa (ang. Nexus Daily Scrum): Wyznaczeni przedstawiciele każdego Zespołu Deweloperskiego spotykają się codziennie, aby identyfikować wszelkie problemy związane z integracją. W przypadku gdy takie problemy istnieją, informacja o nich przekazywana jest podczas Codziennego Scruma każdego Copyright Scrum.org, 2015 Wszystkie prawa zastrzeżone Strona 4 (Wersja 1.1)

6 Zespołu Scrumowego. Zespoły Scrumowe wykorzystują Codzienny Scrum, aby utworzyć plan dnia i upewnić się, że w pierwszej kolejności rozwiązane zostaną problemy zidentyfikowane podczas Codziennego Scruma Nexusa. Przegląd Sprintu Nexusa (ang. Nexus Sprint Review): Wszystkie zespoły spotykają się z Właścicielem Produktu, aby przejrzeć Zintegrowany Przyrost. Jeśli zachodzi taka potrzeba, w trakcie tego zdarzenia aktualizowany jest Backlog Produktu. Retrospektywa Sprintu Nexusa (ang. Nexus Sprint Retrospective): Wyznaczeni przedstawiciele każdego Zespołu Scrumowego spotykają się, aby zidentyfikować wspólne wyzwania. Następnie każdy Zespół Scrumowy przeprowadza swoją własną Retrospektywę Sprintu. Po jej zakończeniu wyznaczeni przedstawiciele każdego z zespołów spotykają się ponownie, aby omówić działania, których realizacja jest niezbędna w obliczu wspólnych wyzwań. Takie działanie jest przejawem wykorzystania oddolnej inteligencji (ang. bottom-up intelligence). Praktyki inżynierskie Do scalenia pracy Zespołów Scrumowych współpracujących podczas tworzenia Zintegrowanego Przyrostu, potrzeba wielu praktyk inżynierskich. Większość z nich wymaga automatyzacji, która pomaga radzić sobie z liczbą i poziomem złożoności zadań i wytwarzanych artefaktów w skalowanych środowiskach. Nexus Role, zdarzenia i artefakty Nexusa korespondują z celowością i przeznaczeniem odpowiadających im ról, zdarzeń i artefaktów Scruma, opisanych w Przewodniku po Scrumie. Role Nexusa Nexus składa się z Zespołu Integracyjnego Nexusa i około trzech do dziewięciu Zespołów Scrumowych. Zespół Integracyjny Nexusa Zespół Integracyjny Nexusa jest odpowiedzialny za upewnienie się, że Zintegrowany Przyrost (wspólna praca wykonana w ramach Nexusa) powstaje przynajmniej raz na Sprint. Zespoły Scrumowe są odpowiedzialne za wytwarzanie gotowych do potencjalnego wydania Przyrostów, jak zaleca Scrum. Wszystkie role członków Zespołów Scrumowych zostały opisane w Przewodniku po Scrumie. Zespół Integracyjny Nexusa to Zespół Scrumowy, do którego należą: Właściciel Produktu Scrum Master Jeden lub więcej członków Zespołu Integracyjnego Nexusa Członkowie Zespołu Integracyjnego Nexusa mogą być jednocześnie członkami Zespołów Scurmowych w danym Nexusie, jeśli jest to celowe i konieczne. Jeśli tak jest, praca w Zespole Integracyjnym Nexusa ma wyższy priorytet. Członkostwo w Zespole Integracyjnym Nexusa ma pierwszeństwo nad członkostwem w Zespole Scrumowym. W ten sposób pierwszeństwo udzielane jest rozwiązywaniu problemów dotyczących wielu zespołów. Copyright Scrum.org, 2015 Wszystkie prawa zastrzeżone Strona 5 (Wersja 1.1)

7 Skład Zespołu Integracyjnego Nexusa może się zmieniać w zależności od bieżących potrzeb Nexusa. Typowe działania Zespołu Integracyjnego Nexusa mogą obejmować coaching, konsultacje oraz zwracanie uwagi na zależności i problemy międzyzespołowe. Zespół Integracyjny Nexusa może również wykonywać pracę wynikającą z Backlogu Produktu. Zespół Integracyjny Nexusa jest właścicielem wszystkich problemów związanych z integracją. Jest odpowiedzialny za zapewnienie, że integracja może zostać pomyślnie przeprowadzona przez wszystkie Zespoły Scrumowe w Nexusie. Integracja oznacza w tym wypadku rozwiązanie wszystkich technicznych i pozatechnicznych międzyzespołowych zależności, które mogą ograniczać zdolność Nexusa do dostarczania stale Zintegrowanego Przyrostu. W znajdowaniu rozwiązań członkowie Zespołu Integracyjnego Nexusa powinni wykorzystywać oddolną inteligencję (ang. bottom-up intelligence) płynącą z zespołów Nexusa. Właściciel Produktu w Zespole Integracyjnym Nexusa Nexus pracuje w oparciu o pojedynczy Backlog Produktu oraz jak opisano w Przewodniku po Scrumie Backlog Produktu ma jednego Właściciela Produktu, który ma decydujący głos odnośnie jego zawartości. Właściciel Produktu jest odpowiedzialny za maksymalizację wartości produktu i pracy wykonywanej i integrowanej przez Zespoły Scrumowe. Właściciel Produktu jest członkiem Zespołu Integracyjnego Nexusa. Właściciel Produktu jest odpowiedzialny za porządkowanie i doskonalenie Backlogu Produktu, tak aby na jego podstawie uzyskiwać jak największą wartość Zintegrowanego Przyrostu stworzonego przez Nexusa. Sposoby osiągania tego rezultatu przez Właściciela Produktu mogą być różne dla różnych organizacji, Nexusów, Zespołów Scrumowych i poszczególnych osób. Scrum Master w Zespole Integracyjnym Nexusa Scrum Master w Zespole Integracyjnym Nexusa jest odpowiedzialny za upewnienie się, aby Nexus był rozumiany a jego reguły przestrzegane. Scrum Master Zespołu Integracyjnego Nexusa może być jednocześnie Scrum Masterem w jednym lub wielu Zespołach Scrumowych w danym Nexusie. Członkowie Zespołu Integracyjnego Nexusa Tworzenie oprogramowania w środowisku dużej skali wymaga specyficznych narzędzi i praktyk, nie zawsze wykorzystywanych przez pracujące indywidualnie Zespoły Scrumowe. Zespół Integracyjny Nexusa składa się ze specjalistów w dziedzinie oprogramowania, mających doświadczenie w stosowaniu tych praktyk, narzędzi i ogólnie pojętej inżynierii systemów. Członkowie Zespołu Integracyjnego Nexusa zapewniają, że te praktyki i narzędzia są wykorzystywane, rozumiane i używane do odkrywania zależności, oraz częstej integracji wszystkich artefaktów, zgodnie z definicją Ukończenia (ang. definition of Done ). Członkowie Zespołu Integracyjnego Nexusa są odpowiedzialni za coaching i takie prowadzenie Zespołów Scrumowych Nexusa, aby te przyswajały, stosowały i uczyły się wspomnianych praktyk i narzędzi. Dodatkowo prowadzą oni coaching Zespołów Scrumowych w zakresie standardów wytwarzania (np. standardów dotyczących Copyright Scrum.org, 2015 Wszystkie prawa zastrzeżone Strona 6 (Wersja 1.1)

8 infrastruktury i architektury) wymaganych przez organizację do zapewnienia jakości Zintegrowanych Przyrostów. Jeśli obowiązki wynikające z członkostwa w Zespole Integracyjnym Nexusa zostaną zaspokojone, osoby te mogą także pracować jako członkowie Zespołów Deweloperskich w jednym lub kilku Zespołach Scrumowych. Zdarzenia Nexusa Czas trwania zdarzeń Nexusa koresponduje z czasem trwania odpowiednich zdarzeń opisanych w Przewodniku po Scrumie. Rozszerzają one ramy czasowe odpowiadających im zdarzeń w Scrumie. Planowanie Sprintu Nexusa Celem Planowania Sprintu Nexusa jest skoordynowanie działań wszystkich Zespołów Scrumowych w Nexusie na czas pojedynczego Sprintu. Właściciel Produktu dostarcza wiedzę domenową i przewodzi procesowi doboru prac i ustalania priorytetów. Aby rozpocząć Planowanie Sprintu Nexusa, wybrani przedstawiciele każdego z Zespołów Scrumowych potwierdzają i dostosowują kolejność prac ustaloną podczas Doskonalenia Backlogu Produktu. Aby zminimalizować problemy komunikacyjne, w Planowaniu powinni uczestniczyć wszyscy członkowie Zespołów Scrumowych. Cel Sprintu Nexusa jest formułowany podczas Planowania Sprintu Nexusa. Opisuje rezultat, który zostanie osiągnięty przez Zespoły Scrumowe podczas Sprintu. Gdy ogólny zakres pracy do wykonania w nadchodzącym Sprincie będzie dla wszystkich zrozumiały, każdy Zespół Scrumowy przeprowadza własne Planowanie Sprintu. Jeśli Planowania Sprintu poszczególnych Zespołów Scrumowych odbywają się w tej samej lokalizacji, mogą one na bieżąco przekazywać sobie informacje o nowo odkrytych zależnościach. Planowanie Sprintu Nexusa uznaje się za zakończone, gdy wszystkie Zespoły Scrumowe zakończą swoje Planowania Sprintu. Podczas Planowania Sprintu Nexusa mogą się pojawić nowe zależności. Należy je wizualizować i ograniczać. Należy również dostosowywać kolejność wykonywania prac pomiędzy zespołami. Odpowiednio dopracowany Backlog Produktu powinien ograniczać pojawianie się nowych zależności podczas Planowania Sprintu Nexusa. Wszystkie elementy Backlogu Produktu wybrane do Sprintu i zależności między nimi należy uwidocznić w Backlogu Sprintu Nexusa. Przed Planowaniem Sprintu Nexusa należy odpowiednio przygotować Backlog Produktu identyfikując i następnie usuwając lub ograniczając zależności. Codzienny Scrum Nexusa Codzienny Scrum Nexusa to zdarzenie, w którym uczestniczą wybrani przedstawiciele każdego Zespołu Deweloperskiego, by wspólnie dokonać inspekcji bieżącego stanu Copyright Scrum.org, 2015 Wszystkie prawa zastrzeżone Strona 7 (Wersja 1.1)

9 Zintegrowanego Przyrostu oraz zidentyfikować problemy związane z integracją i nowo powstałe zależności pomiędzy zespołami. Podczas Codziennego Scruma Nexusa uczestnicy powinni się skupić na wpływie każdego zespołu na Zintegrowany Przyrost. Czy praca wykonana poprzedniego dnia została pomyślnie zintegrowana? Jeśli nie - dlaczego tak jest? Jakie nowe zależności odkryto? Jakie informacje należy przekazać wszystkim zespołom działającym w ramach Nexusa? W trakcie Codziennego Scruma Nexusa wizualizowanie i zarządzanie bieżącymi zależnościami powinno odbywać się z wykorzystaniem Backlogu Sprintu Nexusa. Praca zidentyfikowana podczas Codziennego Scruma Nexusa zasila planowanie odbywające się na Codziennym Scrumie każdego z Zespołów Scrumowych. Przegląd Sprintu Nexusa Przegląd Sprintu Nexusa jest przeprowadzany na zakończenie Sprintu, aby dostarczyć informacje zwrotne na temat Zintegrowanego Przyrostu, stworzonego przez Nexusa w trakcie Sprintu. Przegląd Sprintu Nexusa zastępuje indywidualne Przeglądy Sprintu Zespołów Scrumowych, ponieważ przedmiotem oceny interesariuszy jest Zintegrowany Przyrost. Zaprezentowanie całej wykonanej pracy w szczegółach może okazać się niemożliwe. Być może w celu uzyskania od interesariuszy lepszej jakościowo informacji zwrotnej konieczne będzie zastosowanie specjalnych technik. Retrospektywa Sprintu Nexusa Retrospektywa Sprintu Nexusa to formalna sposobność do skupienia się na inspekcji i adaptacji. Składa się z trzech części: 1. Pierwsza część to miejsce, w którym spotykają się wyznaczeni przedstawiciele całego Nexusa i identyfikują kwestie mające wpływ na więcej niż jeden zespół. Celem jest spowodowanie, aby wspólne sprawy stały się jednoznacznie widoczne dla wszystkich Zespołów Scrumowych. 2. Druga część polega na przeprowadzeniu przez Zespoły Scrumowe własnych Retrospektyw Sprintu tak, jak zostało to opisane w Przewodniku po Scrumie. Mogą one skorzystać z zagadnień będących wynikiem pierwszej części Retrospektywy Nexusa i potraktować je jako wkład do dyskusji w zespole. Każdy Zespół Scrumowy powinien określić jakie działania zamierza podjąć, aby te problemy rozwiązać. 3. Trzecia, ostatnia część, to ponowne spotkanie wyznaczonych przedstawicieli Zespołów Scrumowych i ustalenie, w jaki sposób należy zwizualizować i monitorować wykonanie zidentyfikowanych działań. W ten sposób może zaistnieć proces adaptacji w ramach całego Nexusa. Copyright Scrum.org, 2015 Wszystkie prawa zastrzeżone Strona 8 (Wersja 1.1)

10 Ponieważ niektóre dysfunkcje związane ze skalowaniem są dość powszechne, każda Retrospektywa powinna zawierać następujące elementy: Czy jakakolwiek praca pozostała niewykonana? Czy Nexus wygenerował w tym Sprincie dług techniczny? Czy wszystkie artefakty, a szczególnie kod źródłowy, są często (najlepiej codziennie) pomyślnie integrowane? Czy oprogramowanie jest pomyślnie budowane (kompilowane, konsolidowane), testowane i wdrażane na środowiska na tyle często, aby zapobiec nadmiernemu kumulowaniu się nierozwiązanych zależności? Do powyższych pytań można dodać następujące: Dlaczego tak się dzieje? Jak można spłacić zaciągnięty dług techniczny? Jak można zapobiec nawrotom problemów? Doskonalenie Backlogu Produktu W skali Nexusa istnieje wiele poziomów doskonalenia Backlogu Produktu. Tylko gdy elementy Backlogu Produktu są wystarczająco od siebie odseparowane, można je podjąć do realizacji i pracować nad nimi bez powodowania nadmiernych konfliktów między Zespołami Scrumowymi w Nexusie. Liczba i częstotliwość spotkań, czas ich trwania i poziom uczestnictwa są pochodną zależności, których występowanie jest charakterystyczną cechą każdego Backlogu Produktu. Im większa złożoność i im więcej zależności, tym więcej pracy trzeba włożyć w doskonalenie elementów Backlogu Produktu, aby te zależności usunąć. Elementy Backlogu Produktu przechodzą przez różne poziomy dekompozycji, od bardzo ogólnych i nieprecyzyjnych żądań wykonania pracy, do poziomu szczegółowości pozwalającego pojedynczemu Zespołowi Scrumowemu na wykonanie całości prac w ramach Sprintu. Doskonalenie Backlogu Produktu na skalę Nexusa ma dwojaki cel: służy przewidywaniu, który z Zespołów Scrumowych będzie realizował poszczególne elementy Backlogu Produktu, oraz identyfikowaniu zależności między zespołami. Wizualizacja umożliwia zespołom monitorowanie i zmniejszanie do minimum liczby i wpływu zależności. Pierwsza część międzyzespołowego Doskonalenia Backlogu Produktu powinna polegać na dekomponowaniu elementów Backlogu Produktu do takiego poziomu szczegółowości, aby można było określić, który zespół i w jakiej kolejności może je dostarczyć w ramach przyszłych Sprintów. W drugiej części Doskonalenia Backlogu Produktu należy skoncentrować się na zależnościach. Należy je zidentyfikować i zadbać o ich widoczność w odniesieniu do różnych zespołów i Sprintów. Zespoły będą potrzebowały tych informacji, aby dostosować kolejność i przydział prac w celu zminimalizowania zależności między nimi. Copyright Scrum.org, 2015 Wszystkie prawa zastrzeżone Strona 9 (Wersja 1.1)

11 W trakcie Sprintu należy zorganizować tyle spotkań poświęconych Doskonaleniu Backlogu Produktu, aby elementy Backlogu Produktu były gotowe i możliwe do podjęcia przez zespoły podczas Planowania Sprintu, przy minimalnej liczbie zależności. Artefakty Nexusa Artefakty reprezentują pracę lub wartość. Zapewniają przejrzystość oraz stanowią sposobność do dokonywania inspekcji i adaptacji tak, jak zostało to opisane w Przewodniku po Scrumie. Backlog Produktu Dla całego Nexusa i wszystkich jego Zespołów Scrumowych istnieje tylko jeden Backlog Produktu. Odpowiedzialność za Backlog Produktu, w tym za jego zawartość, dostępność i kolejność, ponosi Właściciel Produktu. W dużej skali, Backlog Produktu musi być zrozumiały na takim poziomie, aby umożliwiał wykrywanie i minimalizowanie zależności. W tym celu, elementy Backlogu Produktu są często dzielone na tak zwane cienkie plasterki (ang. thinly sliced), które są niewielkimi fragmentami funkcjonalności. Elementy Backlogu Produktu są uznawane za gotowe do Planowania Sprintu Nexusa, kiedy Zespoły Scrumowe mogą podjąć się ich wykonania w Sprincie bez lub z minimalnymi zależnościami od innych Zespołów Scrumowych. Cel Nexusa Podczas spotkania Planowania Sprintu Nexusa formułowany jest cel całego Sprintu. Jest on nazywany Celem Nexusa i stanowi sumę pracy i Celów Sprintu wszystkich Zespołów Scrumowych w Nexusie. Nexus powinien być w stanie zademonstrować podczas Przeglądu Sprintu Nexusa funkcjonalności, które zostały przez niego wytworzone, aby ten cel osiągnąć. Backlog Sprintu Nexusa Backlog Sprintu Nexusa to zestawienie wszystkich elementów Backlogu Produktu, które znalazły się w Backlogach Sprintu poszczególnych Zespołów Scrumowych. Służy uwidocznieniu zależności i przepływu pracy podczas Sprintu. Jest aktualizowany przynajmniej raz dziennie, często podczas Codziennego Scruma Nexusa. Zintegrowany Przyrost Zintegrowany Przyrost stanowi sumę całej zintegrowanej pracy wykonanej przez Nexusa. Zintegrowany Przyrost musi nadawać się do użytku i być gotowym do potencjalnego wydania, co oznacza, że musi być zgodnym z przyjętą definicją Ukończenia. Zintegrowany Przyrost jest poddawany inspekcji podczas Przeglądu Sprintu Nexusa. Przejrzystość artefaktów Nexus jest oparty na przejrzystości, podobnie, jak jego podstawa Scrum. Zespół Integracyjny Nexusa współpracuje z Zespołami Scrumowymi i z organizacją, aby zapewnić Copyright Scrum.org, 2015 Wszystkie prawa zastrzeżone Strona 10 (Wersja 1.1)

12 odpowiedni poziom przejrzystości wszystkich artefaktów i powszechne zrozumienie stanu zintegrowania Przyrostu. Efektywność decyzji podejmowanych na podstawie stanu artefaktów zależy od poziomu ich przejrzystości. Niepełne lub wybiórcze informacje mogą prowadzić do podejmowania błędnych lub nie dość dobrych decyzji. Konsekwencje takich decyzji mogą być spotęgowane skalą Nexusa. Brak pełnej przejrzystości artefaktów powoduje, że efektywne wykorzystanie Nexusa do minimalizowania ryzyka i maksymalizowania wartości będzie niemożliwe. Oprogramowanie należy rozwijać w taki sposób, aby zależności były wykrywane i usuwane zanim dług techniczny osiągnie poziom niemożliwy do zaakceptowania. Ten stan ma miejsce, gdy podczas integracji nie ma pewności, czy wszystkie zależności zostały rozwiązane. W takich przypadkach nierozwiązane zależności pozostaną ukryte w kodzie źródłowym i zestawach testów obniżając ogólną wartość oprogramowania. Definicja Ukończenia Zespół Integracyjny Nexusa jest odpowiedzialny za definicję Ukończenia, możliwą do zastosowania wobec Zintegrowanego Przyrostu wytworzonego w Sprincie. Wszystkie Zespoły Scrumowe w Nexusie przestrzegają tej definicji Ukończenia. Przyrost jest Ukończony tylko wtedy, gdy Właściciel Produktu uzna, że jest on gotowy do użycia i potencjalnego wydania. Element Backlogu Produktu można nazwać Ukończonym, jeśli opisana przez ten element funkcjonalność została bez przeszkód dodana do produktu i zintegrowana w Przyrost. Wszystkie Zespoły Scrumowe są odpowiedzialne za wytwarzanie i integrowanie swojej pracy w Przyrost tak, aby spełnić zapisy definicji Ukończenia. Poszczególne Zespoły Scrumowe mogą zdecydować o zastosowaniu bardziej rygorystycznych zapisów definicji Ukończenia, ale nie mogą stosować kryteriów mniej rygorystycznych niż te zdefiniowane dla Przyrostu. Informacje końcowe Nexus jest bezpłatny i udostępniany za pośrednictwem tego Przewodnika. Podobnie jak w przypadku Scruma, role, artefakty, zdarzenia oraz reguły Nexusa są niezmienialne. Można stosować jedynie wybrane elementy Nexusa, ale wynikiem takiego postępowania nie będzie Nexus. Wyróżnienie Nexus i Scaled Professional Scrum to wynik współpracy zespołu, w skład którego wchodzą: Ken Schwaber, David Dame, Richard Hundhausen, Patricia Kong, Rob Maher, Steve Porter, Christina Schwaber i Gunther Verheyen. Tłumaczenie Copyright Scrum.org, 2015 Wszystkie prawa zastrzeżone Strona 11 (Wersja 1.1)

13 Tłumaczenie przewodnika z wersji oryginalnej przygotowali: Tomek Włodarek Krzysztof Kosacki Michał Michałowski Łukasz Orawski i Tomek Pawlak Copyright Scrum.org, 2015 Wszystkie prawa zastrzeżone Strona 12 (Wersja 1.1)

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

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

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

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

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

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

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

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

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

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

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

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

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

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 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

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

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

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

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

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

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 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

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

Asynchroniczne interfejsy WWW

Asynchroniczne interfejsy WWW Asynchroniczne interfejsy WWW Metodyki zwinnego wytwarzania oprogramowania mgr inż. Rafał Grycuk Strona służbowa: http://iisi.pcz.pl/~rgrycuk/ Kontakt: rafal.grycuk@iisi.pcz.pl Konsultacje: Środa, 12-14

Bardziej szczegółowo

Model referencyjny doboru narzędzi Open Source dla zarządzania wymaganiami

Model referencyjny doboru narzędzi Open Source dla zarządzania wymaganiami Politechnika Gdańska Wydział Zarządzania i Ekonomii Katedra Zastosowań Informatyki w Zarządzaniu Zakład Zarządzania Technologiami Informatycznymi Model referencyjny Open Source dla dr hab. inż. Cezary

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

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

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

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

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy

Bardziej szczegółowo

Projektowanie systemów informatycznych. wykład 6

Projektowanie systemów informatycznych. wykład 6 Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany

Bardziej szczegółowo

KARTA PRZEDMIOTU. Projekt zespołowy D1_10

KARTA PRZEDMIOTU. Projekt zespołowy D1_10 KARTA PRZEDMIOTU 1. Informacje ogólne Nazwa przedmiotu i kod (wg planu studiów): Projekt zespołowy D1_10 Nazwa przedmiotu (j. ang.): Team Project Kierunek studiów: Specjalność/specjalizacja: Poziom kształcenia:

Bardziej szczegółowo

PROJEKTOWANIE ZORIENTOWANE NA UŻYTKOWNIKA W METODYCE SCRUM. Hubert Wawrzyniak Grupa Allegro

PROJEKTOWANIE ZORIENTOWANE NA UŻYTKOWNIKA W METODYCE SCRUM. Hubert Wawrzyniak Grupa Allegro PROJEKTOWANIE ZORIENTOWANE NA UŻYTKOWNIKA W METODYCE SCRUM Hubert Wawrzyniak Grupa Allegro PLAN PREZENTACJI 1. Projektowanie zorientowane na użytkownika 2. Model kaskadowy 3. Metodyka scrum 4. UCD w scrumie

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

Program szkolenia: Continuous Integration i Git

Program szkolenia: Continuous Integration i Git Program szkolenia: Continuous Integration i Git Informacje: Nazwa: Kod: Kategoria: Grupa docelowa: Czas trwania: Forma: Continuous Integration i Git tools-git-ci Narzędzia developerzy testerzy 2 dni 50%

Bardziej szczegółowo

INSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH

INSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH Załącznik Nr 3 do Zarządzenia Nr 52/2014 Rektora UMCS INSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH Spis treści Słownik pojęć... 1 Wprowadzenie... 2 Kroki zarządzania ryzykiem

Bardziej szczegółowo

Professional Scrum Foundations

Professional Scrum Foundations Professional Scrum Foundations O szkoleniu Kluczowymi czynnikami sukcesu w stosowaniu Scruma są dogłębne rozumienie reguł i nabycie odpowiednich nawyków na poziomie całego zespołu. Warsztat Professional

Bardziej szczegółowo

ZARZĄDZANIE DOKUMENTACJĄ. Tomasz Jarmuszczak PCC Polska

ZARZĄDZANIE DOKUMENTACJĄ. Tomasz Jarmuszczak PCC Polska ZARZĄDZANIE DOKUMENTACJĄ Tomasz Jarmuszczak PCC Polska Problemy z zarządzaniem dokumentacją Jak znaleźć potrzebny dokument? Gdzie znaleźć wcześniejszą wersję? Która wersja jest właściwa? Czy projekt został

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

SKZ System Kontroli Zarządczej

SKZ System Kontroli Zarządczej SKZ System Kontroli Zarządczej KOMUNIKAT Nr 23 MINISTRA FINANSÓW z dnia 16 grudnia 2009 r. w sprawie standardów kontroli zarządczej dla sektora finansów publicznych Na podstawie art. 69 ust. 3 ustawy z

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

Teambuilding budowanie zespołu

Teambuilding budowanie zespołu Teambuilding budowanie zespołu Opis szkolenia: Praca zespołowa jest to jedna z najbardziej cenionych i potrzebnych umiejętności pracowników w większości firm. Zgrany i zaangażowany zespół nie może pracować

Bardziej szczegółowo

Dokumentacja systemu zarządzania bezpieczeństwem pracy i ochroną zdrowia

Dokumentacja systemu zarządzania bezpieczeństwem pracy i ochroną zdrowia Dokumentacja systemu zarządzania bezpieczeństwem pracy i ochroną zdrowia Dariusz Smoliński Część 1 Prezentacja dostępna na: http://sites.google.com/site/dariuszromualdsmolinski/home/politechnika-gdanska

Bardziej szczegółowo

Standardy kontroli zarządczej

Standardy kontroli zarządczej Standardy kontroli zarządczej Na podstawie Komunikatu nr 23 Ministra Finansów z 16 grudnia 2009 r. w sprawie standardów kontroli zarządczej dla sektora finansów publicznych by Antoni Jeżowski, 2014 Cel

Bardziej szczegółowo

AUREA BPM HP Software. TECNA Sp. z o.o. Strona 1 z 7

AUREA BPM HP Software. TECNA Sp. z o.o. Strona 1 z 7 AUREA BPM HP Software TECNA Sp. z o.o. Strona 1 z 7 HP APPLICATION LIFECYCLE MANAGEMENT Oprogramowanie Application Lifecycle Management (ALM, Zarządzanie Cyklem życia aplikacji) wspomaga utrzymanie kontroli

Bardziej szczegółowo

CZYNNIKI SUKCESU PPG

CZYNNIKI SUKCESU PPG CZYNNIKI SUKCESU PPG STOSOWANIE UMIEJĘTNOŚCI ZAWODOWYCH Wiedza o biznesie Wiedza specjalistyczna Wiedza o produktach i usługach Wiedza przemysłowa ZARZĄDZANIE REALIZACJĄ ZADAŃ Działanie w perspektywie

Bardziej szczegółowo

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Kierunek: Informatyka Modeling and analysis of computer systems Forma studiów: Stacjonarne Rodzaj przedmiotu: obowiązkowy w ramach specjalności:

Bardziej szczegółowo

bo od managera wymaga się perfekcji

bo od managera wymaga się perfekcji bo od managera wymaga się perfekcji MODELOWANIE PROCESÓW Charakterystyka modułu Modelowanie Procesów Biznesowych (BPM) Modelowanie procesów biznesowych stanowi fundament wdroŝenia systemu zarządzania jakością

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

EXIN Agile Scrum Foundation. Przewodnik egzaminacyjny

EXIN Agile Scrum Foundation. Przewodnik egzaminacyjny EXIN Agile Scrum Foundation Przewodnik egzaminacyjny Wydanie czerwiec 2016 Copyright 2016 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data

Bardziej szczegółowo

2.3 Jakie procesy zarządzanie bezpieczeństwem i higieną pracy można zidentyfikować i opisać w przedsiębiorstwie?

2.3 Jakie procesy zarządzanie bezpieczeństwem i higieną pracy można zidentyfikować i opisać w przedsiębiorstwie? 2.3 Jakie procesy zarządzanie bezpieczeństwem i higieną pracy można zidentyfikować i opisać w przedsiębiorstwie? Zastosowanie podejścia procesowego sprowadza się do trzech podstawowych etapów (Rys. 5),

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

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.

Bardziej szczegółowo

Projekty edukacyjne -jedna z ciekawszych form organizowania procesu kształcenia Realizacja programu edukacyjnego metodą projektu

Projekty edukacyjne -jedna z ciekawszych form organizowania procesu kształcenia Realizacja programu edukacyjnego metodą projektu Projekty edukacyjne -jedna z ciekawszych form organizowania procesu kształcenia Realizacja programu edukacyjnego metodą projektu Opracowała Janina Nowak WOM Gorzów Wlkp. 2006 Co to jest projekt edukacyjny

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering)

Inżynieria oprogramowania (Software Engineering) Inżynieria oprogramowania (Software Engineering) Wykład 3 Studium wykonalności Definicja wymagań Studium wykonalności (feasibility study) Prowadzone przed rozpoczęciem projektu, krótkie, niekosztowne badanie

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

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

Leszno 14.03.2013. Jakie są i będą oczekiwania biznesu wobec IT?

Leszno 14.03.2013. Jakie są i będą oczekiwania biznesu wobec IT? Leszno 14.03.2013 Jakie są i będą oczekiwania biznesu wobec IT? Banki stoją w obliczu zmian Uwarunkowania ekonomiczne Regulacje prawne Trendy społeczne Nowe technologie Dzisiaj otoczenie oczekuje innego

Bardziej szczegółowo

AKADEMIA DLA MŁODYCH PRZEWODNIK TRENERA. PRACA ŻYCIE UMIEJĘTNOŚCI

AKADEMIA DLA MŁODYCH PRZEWODNIK TRENERA.  PRACA ŻYCIE UMIEJĘTNOŚCI PRACA ŻYCIE UMIEJĘTNOŚCI www.akademiadlamlodych.pl PODRĘCZNIK WPROWADZENIE Akademia dla Młodych to nowa inicjatywa mająca na celu wspieranie ludzi młodych w rozwijaniu umiejętności niezbędnych w ich miejscu

Bardziej szczegółowo

ZARZĄDZANIE I INŻYNIERIA PRODUKCJI

ZARZĄDZANIE I INŻYNIERIA PRODUKCJI ZARZĄDZANIE I INŻYNIERIA PRODUKCJI STUDIA PIERWSZEGO STOPNIA PROFIL OGÓLNOAKADEMICKI Załącznik nr 2 Odniesienie efektów kierunkowych do efektów obszarowych i odwrotnie Załącznik nr 2a - Tabela odniesienia

Bardziej szczegółowo

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:

Bardziej szczegółowo

Zarządzanie testowaniem wspierane narzędziem HP Quality Center

Zarządzanie testowaniem wspierane narzędziem HP Quality Center Zarządzanie testowaniem wspierane narzędziem HP Quality Center studium przypadku Mirek Piotr Szydłowski Ślęzak Warszawa, 17.05.2011 2008.09.25 WWW.CORRSE.COM Firma CORRSE Nasze zainteresowania zawodowe

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

KONTROLA ZARZĄDCZA. Ustawa z dnia 17 grudnia 2004 r. o odpowiedzialności za naruszenie dyscypliny finansów publicznych (Dz. U. z 2013 r. poz.

KONTROLA ZARZĄDCZA. Ustawa z dnia 17 grudnia 2004 r. o odpowiedzialności za naruszenie dyscypliny finansów publicznych (Dz. U. z 2013 r. poz. KONTROLA ZARZĄDCZA Podstawa prawna Ustawa z dnia 27 sierpnia 2009 r. o finansach publicznych (Dz. U. z 2013 r. poz. 885, ze zm.) Ustawa z dnia 17 grudnia 2004 r. o odpowiedzialności za naruszenie dyscypliny

Bardziej szczegółowo

Testowanie oprogramowania

Testowanie oprogramowania Testowanie oprogramowania 1/17 Testowanie oprogramowania Wykład 01 dr inż. Grzegorz Michalski 13 października 2015 Testowanie oprogramowania 2/17 Dane kontaktowe: Kontakt dr inż. Grzegorz Michalski pokój

Bardziej szczegółowo

8 Przygotowanie wdrożenia

8 Przygotowanie wdrożenia 1 Krok 8 Przygotowanie wdrożenia Wprowadzenie Przed rozpoczęciem wdrażania Miejskiego Programu Energetycznego administracja miejska powinna dokładnie przygotować kolejne kroki. Pierwszym jest powołanie

Bardziej szczegółowo

"Projektowanie - wdrożenie - integracja - uruchomienie, czyli jak skutecznie zrealizować projekt inwestycyjny".

Projektowanie - wdrożenie - integracja - uruchomienie, czyli jak skutecznie zrealizować projekt inwestycyjny. "Projektowanie - wdrożenie - integracja - uruchomienie, czyli jak skutecznie zrealizować projekt inwestycyjny". CZYNNIKI PROJEKTU Cel (zakres) projektu: wyznacza ramy przedsięwzięcia, a tym samym zadania

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

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

Kontrola zarządcza w szkołach i placówkach oświatowych. Ewa Halska, Andrzej Jasiński, OSKKO

Kontrola zarządcza w szkołach i placówkach oświatowych. Ewa Halska, Andrzej Jasiński, OSKKO Kontrola zarządcza w szkołach i placówkach oświatowych. Ewa Halska, Andrzej Jasiński, OSKKO Istotną kwestią podjętą w w Ustawie z 27 sierpnia 2009 r. o finansach publicznych (Dz. U. Nr 157 poz. 1240) jest

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

Inżynieria oprogramowania (Software Engineering)

Inżynieria oprogramowania (Software Engineering) Inżynieria oprogramowania (Software Engineering) Wykład 2 Proces produkcji oprogramowania Proces produkcji oprogramowania (Software Process) Podstawowe założenia: Dobre procesy prowadzą do dobrego oprogramowania

Bardziej szczegółowo

SYSTEM TWORZENIA I KONTROLI ZESPOŁÓW W PROJEKTACH

SYSTEM TWORZENIA I KONTROLI ZESPOŁÓW W PROJEKTACH SYSTEM TWORZENIA I KONTROLI ZESPOŁÓW W PROJEKTACH Celem systemu tworzenia i kontroli zespołów jest wsparcie decydenta w podejmowaniu decyzji przy tworzeniu zespołów, ze szczególnym uwzględnieniem fazy

Bardziej szczegółowo

Szczegółowe warunki realizacji projektu edukacyjnego w Gimnazjum nr 10 z Oddziałami Dwujęzycznymi we Wrocławiu.

Szczegółowe warunki realizacji projektu edukacyjnego w Gimnazjum nr 10 z Oddziałami Dwujęzycznymi we Wrocławiu. Szczegółowe warunki realizacji projektu edukacyjnego w Gimnazjum nr 10 z Oddziałami Dwujęzycznymi we Wrocławiu. 1. Uczniowie gimnazjum mają obowiązek realizowania projektu edukacyjnego na podstawie 21a

Bardziej szczegółowo

SCRUM. jak pracować wydajniej i scalić zespół

SCRUM. jak pracować wydajniej i scalić zespół SCRUM jak pracować wydajniej i scalić zespół Spis treści 1 Wstęp Używaj Scruma, bo warto! 2 3 Zwinny Scrum Scalony zespół Czym jest Scrum? Zespół scrumowy Zdarzenia w Scrumie Test Driven Development Tradycyjna

Bardziej szczegółowo

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski Autor: Artur Lewandowski Promotor: dr inż. Krzysztof Różanowski Przegląd oraz porównanie standardów bezpieczeństwa ISO 27001, COSO, COBIT, ITIL, ISO 20000 Przegląd normy ISO 27001 szczegółowy opis wraz

Bardziej szczegółowo

KIERUNKOWE EFEKTY KSZTAŁCENIA

KIERUNKOWE EFEKTY KSZTAŁCENIA WYDZIAŁ INFORMATYKI I ZARZĄDZANIA Kierunek studiów: INFORMATYKA Stopień studiów: STUDIA II STOPNIA Obszar Wiedzy/Kształcenia: OBSZAR NAUK TECHNICZNYCH Obszar nauki: DZIEDZINA NAUK TECHNICZNYCH Dyscyplina

Bardziej szczegółowo

SPRAWOZDANIE KOMISJI DLA PARLAMENTU EUROPEJSKIEGO I RADY. Europejski program bezpieczeństwa lotniczego

SPRAWOZDANIE KOMISJI DLA PARLAMENTU EUROPEJSKIEGO I RADY. Europejski program bezpieczeństwa lotniczego KOMISJA EUROPEJSKA Bruksela, dnia 7.12.2015 r. COM(2015) 599 final SPRAWOZDANIE KOMISJI DLA PARLAMENTU EUROPEJSKIEGO I RADY Europejski program bezpieczeństwa lotniczego PL PL 1. KOMUNIKAT KOMISJI Z 2011

Bardziej szczegółowo

DLA SEKTORA INFORMATYCZNEGO W POLSCE

DLA SEKTORA INFORMATYCZNEGO W POLSCE DLA SEKTORA INFORMATYCZNEGO W POLSCE SRK IT obejmuje kompetencje najważniejsze i specyficzne dla samego IT są: programowanie i zarządzanie systemami informatycznymi. Z rozwiązań IT korzysta się w każdej

Bardziej szczegółowo

Zasady realizacji projektu edukacyjnego w Gimnazjum Nr 1 w Zespole Szkół Sportowych w Siemianowicach Śląskich

Zasady realizacji projektu edukacyjnego w Gimnazjum Nr 1 w Zespole Szkół Sportowych w Siemianowicach Śląskich Zasady realizacji projektu edukacyjnego w Gimnazjum Nr 1 w Zespole Szkół Sportowych w Siemianowicach Śląskich Podstawa prawna: Rozporządzenie Ministra Edukacji Narodowej z dnia 10 czerwca 2015 r. w sprawie

Bardziej szczegółowo

Compuware Changepoint. Portfolio Management Tool

Compuware Changepoint. Portfolio Management Tool Compuware Changepoint Portfolio Management Tool Compuware Changepoint Zintegrowane Zarządzanie Portfelem IT W dzisiejszym świecie czołowi użytkownicy IT podejmują inicjatywy dopasowania IT do strategii

Bardziej szczegółowo

TOUCAN Team Evaluator OPIS FUNKCJONALNOŚCI

TOUCAN Team Evaluator OPIS FUNKCJONALNOŚCI TOUCAN Team Evaluator OPIS FUNKCJONALNOŚCI SPIS TREŚCI Funkcje... 4 Ocena celów... 4 Definicja celów... 4 Procesowy model akceptacji -... 5 Ocena stopnia realizacji celu... 5 Ocena kompetencji... 5 Definicja

Bardziej szczegółowo

Zarządzenie Nr 24/2012 Rektora Uniwersytetu Wrocławskiego z dnia 28 marca 2012 r. w sprawie Polityki zarządzania ryzykiem

Zarządzenie Nr 24/2012 Rektora Uniwersytetu Wrocławskiego z dnia 28 marca 2012 r. w sprawie Polityki zarządzania ryzykiem Zarządzenie Nr 24/2012 Rektora Uniwersytetu Wrocławskiego z dnia 28 marca 2012 r. w sprawie Polityki zarządzania ryzykiem Na podstawie art. 66 ust. 2 ustawy z dnia 27 lipca 2005 r. - Prawo o szkolnictwie

Bardziej szczegółowo

ZARZĄDZANIE WDRAŻANIEM INNOWACJI W FIRMIE

ZARZĄDZANIE WDRAŻANIEM INNOWACJI W FIRMIE GRY STRATEGICZNE ZARZĄDZANIE WDRAŻANIEM INNOWACJI W FIRMIE Warsztaty z wykorzystaniem symulacyjnych gier decyzyjnych TERMIN od: TERMIN do: CZAS TRWANIA:2-3 dni MIEJSCE: CENA: Symulacyjne gry decyzyjne

Bardziej szczegółowo

Analityk i współczesna analiza

Analityk i współczesna analiza Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura

Bardziej szczegółowo

Kryteria wyboru. Lp. Kryterium Opis kryterium

Kryteria wyboru. Lp. Kryterium Opis kryterium Załącznik nr 1 do Regulaminu okresowej oceny pracownikçw Starostwa Powiatowego w Środzie Wlkp. Kryteria wyboru Lp. Kryterium Opis kryterium 1. Umiejętność obsługi urządzeń technicznych lub narzędzi informatycznych

Bardziej szczegółowo

Mariusz Nowak Instytut Informatyki Politechnika Poznańska

Mariusz Nowak Instytut Informatyki Politechnika Poznańska Inteligentne budynki (2) Źródła Loe E. C., Cost of Intelligent Buildings, Intelligent Buildings Conference, Watford, U. K., 1994 Nowak M., Zintegrowane systemy zarządzania inteligentnym budynkiem, Efektywność

Bardziej szczegółowo

SYSTEM ZARZĄDZANIA RYZYKIEM W DZIAŁALNOŚCI POLITECHNIKI WARSZAWSKIEJ FILII w PŁOCKU

SYSTEM ZARZĄDZANIA RYZYKIEM W DZIAŁALNOŚCI POLITECHNIKI WARSZAWSKIEJ FILII w PŁOCKU P OLITECHNIK A W AR S Z AWSKA FILIA W PŁOCKU ul. Łukasiewicza 17, 09-400 Płock SYSTEM ZARZĄDZANIA RYZYKIEM W DZIAŁALNOŚCI POLITECHNIKI WARSZAWSKIEJ FILII w PŁOCKU Opracowano na podstawie załącznika do

Bardziej szczegółowo

Tworzenie efektywnych programów współpracy z udziałem pracodawców, studentów i Uczelni

Tworzenie efektywnych programów współpracy z udziałem pracodawców, studentów i Uczelni Tworzenie efektywnych programów współpracy z udziałem pracodawców, studentów i Uczelni w doświadczeniu Wydziału Matematyki i Informatyki UMK Podstawowe tematy współpracy WMiI UMK środowisko gospodarcze

Bardziej szczegółowo

Uchwała Nr 11/2013/II Senatu Politechniki Lubelskiej z dnia 21 marca 2013 r.

Uchwała Nr 11/2013/II Senatu Politechniki Lubelskiej z dnia 21 marca 2013 r. Uchwała Nr 11/2013/II Senatu Politechniki Lubelskiej z dnia 21 marca 2013 r. w sprawie określenia efektów kształcenia dla menedżerskich studiów podyplomowych Master of Business Administration (MBA) prowadzonych

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

ZARZĄDZANIE ZESPOŁEM

ZARZĄDZANIE ZESPOŁEM Z przyjemnością odpowiemy na wszystkie pytania. Prosimy o kontakt: e-mail: kontakt@mr-db.pl tel. +48 606 356 999 www.mr-db.pl MRDB Szkolenie otwarte: ZARZĄDZANIE ZESPOŁEM jak go tworzyć, rozwijać i nim

Bardziej szczegółowo

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy

Bardziej szczegółowo

Efekty kształcenia wymagane do podjęcia studiów 2 stopnia na kierunku Informatyka

Efekty kształcenia wymagane do podjęcia studiów 2 stopnia na kierunku Informatyka Efekty kształcenia wymagane do podjęcia studiów 2 stopnia na kierunku Informatyka Test kwalifikacyjny obejmuje weryfikację efektów kształcenia oznaczonych kolorem szarym, efektów: K_W4 (!), K_W11-12, K_W15-16,

Bardziej szczegółowo

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji

Bardziej szczegółowo

PROJEKT EDUKACYJNY Szczegółowe zasady realizacji projektów edukacyjnych w gimnazjum. I. Wstęp. 1. Uczniowie mają obowiązek udziału w realizacji

PROJEKT EDUKACYJNY Szczegółowe zasady realizacji projektów edukacyjnych w gimnazjum. I. Wstęp. 1. Uczniowie mają obowiązek udziału w realizacji PROJEKT EDUKACYJNY Szczegółowe zasady realizacji projektów edukacyjnych w gimnazjum. I. Wstęp. 1. Uczniowie mają obowiązek udziału w realizacji projektu edukacyjnego na podstawie 21a Rozporządzenia Ministra

Bardziej szczegółowo

Dlaczego modele architektoniczne to zamało? Wprowadzeniedo ładu architekturykorporacyjnej

Dlaczego modele architektoniczne to zamało? Wprowadzeniedo ładu architekturykorporacyjnej Dlaczego modele architektoniczne to zamało? Wprowadzeniedo ładu architekturykorporacyjnej Dr hab. Andrzej Sobczak, prof. SGH, Kierownik Zakładu Systemów Informacyjnych, Katedra Informatyki Gospodarczej

Bardziej szczegółowo

SZKOLENIA. ul. Sienna 72/16 00-833 Warszawa Tel./Fax. (022) 890 21 35

SZKOLENIA. ul. Sienna 72/16 00-833 Warszawa Tel./Fax. (022) 890 21 35 ul. Sienna 72/16 00-833 Warszawa Tel./Fax. (022) 890 21 35 Adresaci szkolenia Budowanie Modeli Kompetencji Szkolenie to przeznaczone jest dla menedżerów i pracowników działów zarządzania zasobami ludzkimi,

Bardziej szczegółowo

5. Planowanie działań w systemie zarządzania bezpieczeństwem i higieną pracy

5. Planowanie działań w systemie zarządzania bezpieczeństwem i higieną pracy 5. Planowanie działań w systemie zarządzania bezpieczeństwem i higieną pracy 5.1. Jakie znaczenie ma planowanie działań w systemie zarządzania bezpieczeństwem i higieną pracy? Planowanie jest ważnym elementem

Bardziej szczegółowo