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 (tomek@poddrzewem.pl), Krzysztof Kosacki (@krzysiekkosacki), Michał Michałowski (michal@poddrzewem.pl), Łukasz Orawski (orawski@mikolow.org) i Tomek Pawlak (tomekpawlak@poddrzewem.pl). Copyright Scrum.org, 2015 Wszystkie prawa zastrzeżone Strona 12 (Wersja 1.1)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Warsztaty FRAME. Sygnatura warsztatu: W1 (W3) Czas trwania: 3 dni

Warsztaty FRAME. Sygnatura warsztatu: W1 (W3) Czas trwania: 3 dni Sygnatura warsztatu: W1 (W3) Czas trwania: 3 dni Warsztaty FRAME I. Cel Zapoznanie uczestników z możliwościami wykorzystania Europejskiej Ramowej Architektury ITS FRAME (zwanej dalej FRAME ) oraz jej narzędzi

Bardziej szczegółowo

Rozdział 5: Zarządzanie testowaniem. Pytanie 1

Rozdział 5: Zarządzanie testowaniem. Pytanie 1 Pytanie 1 Dlaczego niezależne testowanie jest ważne: A) Niezależne testowanie jest w zasadzie tańsze niż testowanie własnej pracy B) Niezależne testowanie jest bardziej efektywne w znajdywaniu defektów

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

Zaplanować projekt fundraisingowy i przeprowadzić go przez wszystkie etapy realizacji nie tracąc z pola widzenia założonych efektów;

Zaplanować projekt fundraisingowy i przeprowadzić go przez wszystkie etapy realizacji nie tracąc z pola widzenia założonych efektów; Celem szkolenia Zarządzanie projektem fundraisingowym jest nabycie przez uczestników wiedzy, umiejętności oraz kompetencji w zakresie planowania i osiągania celów projektowych. Uczestnik pozna i nauczy

Bardziej szczegółowo

KIERUNKOWE EFEKTY KSZTAŁCENIA KIERUNEK STUDIÓW INFORMATYCZNE TECHNIKI ZARZĄDZANIA

KIERUNKOWE EFEKTY KSZTAŁCENIA KIERUNEK STUDIÓW INFORMATYCZNE TECHNIKI ZARZĄDZANIA KIERUNKOWE EFEKTY KSZTAŁCENIA KIERUNEK STUDIÓW INFORMATYCZNE TECHNIKI ZARZĄDZANIA Nazwa kierunku studiów: Informatyczne Techniki Zarządzania Ścieżka kształcenia: IT Project Manager, Administrator Bezpieczeństwa

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

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

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

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

ISO 9000/9001. Jarosław Kuchta Jakość Oprogramowania

ISO 9000/9001. Jarosław Kuchta Jakość Oprogramowania ISO 9000/9001 Jarosław Kuchta Jakość Oprogramowania Co to jest ISO International Organization for Standardization największa międzynarodowa organizacja opracowująca standardy 13700 standardów zrzesza narodowe

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

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

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

PODEJŚCIE STRATEGICZNE >>

PODEJŚCIE STRATEGICZNE >> Nasze wartości oraz niniejszy Kodeks Współpracy z Interesariuszami są przewodnikiem w zakresie naszych zasad i naszych zachowań. Odbieramy zaangażowanie Interesariuszy jako związek równych sobie oparty

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

KARTA PRZEDMIOTU. 1. Informacje ogólne. 2. Ogólna charakterystyka przedmiotu. Projekt zespołowy D1_10

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

Bardziej szczegółowo

Sytuacyjne Przywództwo Zespołowe STL

Sytuacyjne Przywództwo Zespołowe STL Sytuacyjne Przywództwo Zespołowe STL Opis szkolenia Warsztat szkoleniowy Sytuacyjne Przywództwo Zespołowe STL opracowany został przez Kenetha Blancharda - światowy autorytet w dziedzinie zarządzania, m.in.

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

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

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

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

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

Tworzenie szablonów użytkownika

Tworzenie szablonów użytkownika Poradnik Inżyniera Nr 40 Aktualizacja: 12/2018 Tworzenie szablonów użytkownika Program: Plik powiązany: Stratygrafia 3D - karty otworów Demo_manual_40.gsg Głównym celem niniejszego Przewodnika Inżyniera

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

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

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

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

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

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

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

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

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

Program szkolenia: Wprowadzenie do Domain Driven Design dla biznesu (część 0)

Program szkolenia: Wprowadzenie do Domain Driven Design dla biznesu (część 0) Program szkolenia: Wprowadzenie do Domain Driven Design dla biznesu (część 0) Informacje: Nazwa: Wprowadzenie do Domain Driven Design dla biznesu (część 0) Kod: Kategoria: Grupa docelowa: Czas trwania:

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

Jak zostać dobrym analitykiem? Wpisany przez RR Nie, 21 paź 2012

Jak zostać dobrym analitykiem? Wpisany przez RR Nie, 21 paź 2012 Analityk systemów informatycznych to zawód cieszący się w ostatnich latach rosnącą popularnością. Młodych ludzi zachęcają liczne oferty pracy, perspektywa wysokich zarobków i możliwość podnoszenia kwalifikacji.

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

SEKTOROWE RAMY KWALIFIKACJI jako jeden z elementów ZINTEGROWANEGO SYSTEMU KWALIFIKACJI

SEKTOROWE RAMY KWALIFIKACJI jako jeden z elementów ZINTEGROWANEGO SYSTEMU KWALIFIKACJI Dominika Czajak Warszawa, 18.03.2019r. SEKTOROWE RAMY KWALIFIKACJI jako jeden z elementów ZINTEGROWANEGO SYSTEMU KWALIFIKACJI Plan prezentacji 1 Idea Zintegrowanego Systemu Kwalifikacji (ZSK) 2 Idea Sektorowych

Bardziej szczegółowo

Inżynieria oprogramowania II

Inżynieria oprogramowania II Wymagania funkcjonalne, przypadki użycia Inżynieria oprogramowania II Problem i cel Tworzenie projektów bez konkretnego celu nie jest dobre Praktycznie każdy projekt informatyczny powstaje z uwagi na jakiś

Bardziej szczegółowo

Jak budować markę? Zestaw praktycznych porad

Jak budować markę? Zestaw praktycznych porad Budowa marki 2018 Jak budować markę? Zestaw praktycznych porad Kto jest kim w markowym zespole? Wybrany członek zarządu: pełni rolę sponsora projektu, ułatwia promocję projektu w organizacji i nadaje mu

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

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

Efekty uczenia się na kierunku Ekonomia (studia pierwszego stopnia o profilu ogólnoakademickim)

Efekty uczenia się na kierunku Ekonomia (studia pierwszego stopnia o profilu ogólnoakademickim) Załącznik nr 2 do uchwały nr 414 Senatu Uniwersytetu Zielonogórskiego z dnia 29 maja 2019 r. Efekty na kierunku Ekonomia (studia pierwszego stopnia o profilu ogólnoakademickim) Tabela 1. Kierunkowe efekty

Bardziej szczegółowo

PROGRAM WARSZTATÓW DLA MENTORÓW/ TUTORÓW

PROGRAM WARSZTATÓW DLA MENTORÓW/ TUTORÓW PROGRAM WARSZTATÓW DLA MENTORÓW/ TUTORÓW PROGRAM WARSZTATÓW DLA MENTORÓW/ TUTORÓW Project LLP-LDV-TOI-12-AT-0015 Koordynator projektu: Schulungszentrum Fohnsdorf Instytucje partnerskie: University of Gothenburg

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

Podsumowanie wyników ankiety

Podsumowanie wyników ankiety SPRAWOZDANIE Kierunkowego Zespołu ds. Programów Kształcenia dla kierunku Informatyka dotyczące ankiet samooceny osiągnięcia przez absolwentów kierunkowych efektów kształcenia po ukończeniu studiów w roku

Bardziej szczegółowo

ORGANIZACJA Z CHARAKTEREM OFERTA WSZECHNICY UJ. Jak świadomie kształtować kulturę organizacyjną firmy?

ORGANIZACJA Z CHARAKTEREM OFERTA WSZECHNICY UJ. Jak świadomie kształtować kulturę organizacyjną firmy? OFERTA WSZECHNICY UJ Z CHARAKTEREM Jak świadomie kształtować kulturę organizacyjną firmy? Jak poprzez kulturę organizacyjną wspierać efektywność? Jak odpowiadać na oczekiwania pracowników dotyczące kultury

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

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

Załącznik do Uchwały nr 20/2015/2016 Senatu Akademickiego Ignatianum z dnia 1 marca 2016 r.

Załącznik do Uchwały nr 20/2015/2016 Senatu Akademickiego Ignatianum z dnia 1 marca 2016 r. Załącznik do Uchwały nr 20/2015/2016 Senatu Akademickiego Ignatianum z dnia 1 marca 2016 r. KIERUNKOWE EFEKTY KSZTAŁCENIA Nazwa kierunku studiów: Zarządzanie i nowe technologie Określenie obszaru kształcenia/obszarów

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

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

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

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

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

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

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

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

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

Procedura zarządzania ryzykiem w Urzędzie Miejskim w Radomiu

Procedura zarządzania ryzykiem w Urzędzie Miejskim w Radomiu Załącznik nr 1 do Zarządzenia Nr 2808/2018 Prezydenta Miasta Radomia z dnia 18 stycznia 2018 r. Procedura zarządzania ryzykiem w Urzędzie Miejskim w Radomiu 1 1. Określenia stosowane w niniejszej procedurze:

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

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

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