ZARZĄDZANIE PROJEKTAMI INFORMATYCZNYMI W METODYCE SCRUM
|
|
- Seweryna Szczepaniak
- 10 lat temu
- Przeglądów:
Transkrypt
1 POLITECHNIKA WARSZAWSKA WYDZIAŁ ELEKTRYCZNY INSTYTUT STEROWANIA I ELEKTRONIKI PRZEMYSŁOWEJ Konrad Jędrzejewski Włodzimierz Dąbrowski ZARZĄDZANIE PROJEKTAMI INFORMATYCZNYMI W METODYCE SCRUM Draft Warszawa Warszawa, 2012
2 STRESZCZENIE Rozwój oprogramowania jest skomplikowanym zajęciem. Aby oprogramowanie to powstawało zgodnie z potrzebami klienta przy zastosowaniu odpowiedniej jakości stosuje się metodyki wspomagające zarządzanie projektami. Ich rozwój doprowadził do powstania tak zwanych zwinnych metodyk zarządzania projektami które są odpowiedzią na problemy dotyczące zwiększenia efektywności pracy, dostarczania produktu który klient naprawdę potrzebuje oraz dostarczania produktów o wysokiej jakości. Wśród takich metodyk jest metodyka Scrum która jest zbiorem zasad opisanych na zaledwie kilku stronach a które jak pokazują jej twórcy powoduje zwiększenie komunikacji w zespole a także między klientem. Została omówiona metodyka Scrum oraz jej praktyczne zastosowanie.. Strona 2 z 43
3 Spis treści SPIS TREŚCI Wprowadzenie do zarządzania projektami Czym jest zarządzanie projektem? Przyczyny niepowodzenia projektów Stosowanie metodyk projektowych... 8 Czym jest Scrum Manifest Agile podstawą Scrum Scrum jako praktyczne podejście do zasad Agile Role w projekcie Zespół ScrumMaster Właściciel produktu Artefakty w Scrumie Praktyczne podejście do Scruma Scrum Scrumów Testowanie oprogramowania z Agile Praca w tradycyjnym zespole Praca w zespole Scrumowym Porównanie tradycyjnego testowania z testowaniem w Agile Scrum i Kanban Czym jest Kanban Różnice między Kanban a Scrum Sposób połączenia Scrum i Kanban Bibliografia Strona 3 z 43
4 1. Wprowadzenie do zarządzania projektami 1.1. Czym jest zarządzanie projektem? Oprogramowanie w dzisiejszych czasach wymaga od producentów prześcigania się w rozwiązaniach technologicznych, stabilności produktu oraz innowacyjności. Czasy, kiedy systemy informatyczne były małe i proste, należą do przeszłości. Obecnie systemy są złożone, a ich budowa często trudna, długa i nieuporządkowana. Przedsięwzięcie informatyczne często nie jest tylko wytworzeniem produktu jest to także jego utrzymanie co powoduje, że może ono trwać nawet wiele lat, można je porównywać do przedsięwzięcia wielkiej budowy, np. mostów. Statystyki pokazują [1] że w około 33% przypadków przedsięwzięcia informatyczne kończą się niepowodzeniem, natomiast następne 33% wymagają zwiększonego wykorzystania zasobów przeznaczonych na projekt. Dlatego też prowadzenie projektów wymaga odpowiedniego zarządzania. Zadajmy sobie pytanie czym jest więc zarządzanie projektami? Aby odpowiedzieć sobie na to pytanie najpierw powinniśmy się zastanowić czym jest projekt. Pozwoli nam to lepiej zrozumieć pojęcie zarządzania projektami oraz ułatwi zrozumienie pojęć zawartych w dalszej mojej pracy. Definicja mówi że: Projekt to sekwencja niepowtarzalnych, złożonych i związanych ze sobą zadań, mających wspólny cel, przeznaczonych do wykonania w określonym terminie bez przekraczania ustalonego budżetu, zgodnie z założonymi wymaganiami. [2] Interpretując powyższą definicję można stwierdzić, że projekt posiada pewne swoje atrybuty, które go charakteryzują. Tak więc zarządzanie projektem polega na takim kierowaniu przebiegiem projektu aby nie przekroczyć atrybutów które posiada dany projekt i aby cel projektu został osiągnięty. Niestety jak to w życiu bywa nie zawsze się to udaje. Opierając się na wynikach badań grupy The Standlish Group [1] projektów zakończonych Strona 4 z 43
5 powodzeniem jest dość niewiele, porównaniu do ogólnej liczby projektów, dlatego też warto się zastanowić jakie są przyczyny niepowodzenia projektów Przyczyny niepowodzenia projektów Zarządzanie projektami nie jest zadaniem łatwym, spotykamy się podczas tej funkcji z wieloma przeciwnościami losu, które jak się okazują powodują, że realizacja projektu może zakończyć się niepowodzeniem. Zapewne każdy spotkał się podczas realizacji projektów z problemami przekroczenia czasu czy też budżetu. Odnosząc się do wyżej wymienionej definicji celem projektu jest dostarczenie specyficznego produktu spełniającego odpowiednie kryteria. Nie stosowanie się do ograniczeń, które są przypisane do danego projektu może spowodować niepowodzenie projektu lub też znaczne przekroczenie terminu czy też budżetu. Ograniczenie te można też zobrazować za pomocą trójkąta ograniczeń (Rys. 1.1.), który pokazuje możliwość kontrolowania projektu tak, aby równowaga trójkąta została zachowana. [2] Rys Trójkąt zakresu projektu [2] Utrzymanie trójkąta w równowadze jest niezwykle trudnym zadaniem, które wymaga poświęcenia dużej ilości czasu, w przeciwnym razie, gdy jego równowaga zostanie zachwiana powinniśmy zastanowić się nad przyczyną takiego stanu. Na świecie jest kilka organizacji badających uwarunkowania projektów, które zakończyły się sukcesem i niepowiedzeniem. Jedną z nich jest wspomniana wcześniej The Standlish Group, która przedstawiła takie uwarunkowania oraz statystyki realizacji projektów (Rys. 1.2) z branży IT w raporcie o tytule Chaos Report z 1995 roku. [1] Strona 5 z 43
6 % 20 % 40 % 60 % 80 % 100 % Zakończone Sukcesem Anulowane Zakończone nie powodzeniem Rys Wyniki powodzenia projektów w latach prowadzonych przez The Standish Group Z powyższej statystyki wynika, że na przełomie lat procent projektów zakończonych całkowicie sukcesem wzrósł, co może świadczyć o większym stopniu świadomości swojej roli w projekcie przez kierowników projektu oraz o lepszym wykonywaniu obowiązków. Fakt, że w ciągu tego okresu nieznacznie zmalał procent projektów zakończonych niepowodzeniem jest wynikiem niezadowalającym. Warto się zastanowić nad przyczynami tak dużego niepowodzenia projektów. Wyżej wymieniony raport opisuje najczęstsze przyczyny porażek oraz sukcesów projektów. Wśród sukcesów najistotniejsze są [1]: Zaangażowanie klienta 15.9% Wsparcie kierownictwa 13.9% Jasno określone wymagania 13.0% Właściwe planowanie 9.6% Realistyczne oczekiwania 8.2% Mniejsze odstępy pomiędzy kamieniami milowymi 7.7% Kompetencje pracowników 7.2% Odpowiedzialność 5.3% Strona 6 z 43
7 Jasno postawione cele i wymagania 2.9% Ciężko pracujący, skupieni pracownicy 2.4% Pozostałe 13,9% Najczęściej występujące są przyczyny związane z odpowiednim zarządzaniem (ptk. 1-6) natomiast pozostałe związane są z kompetencjami czy zaangażowaniem pracowników. The Standish Group wymienia także przyczyny niepowodzeń projektów lub niepełnych powodzeń [1]: Brak informacji wejściowych od klienta 12,8 % Niekompletne wymagania i specyfikacje projektu 12,3 Zmiana wymagań i specyfikacji projektu 11,8 Brak wsparcia ze strony kierownictwa 7,5 Brak kompetencji w danej dziedzinie 7,0 Brak zasobów ludzkich 6,4 Nierealne oczekiwania klienta 5,9 Niejasne cele 5,3 Nierealne ramy czasowe projektu 4,3 Nowe technologie 3,7 Pozostałe 23% Badania przeprowadzone przez The Standish Group opierają się na projektach z branży IT aczkolwiek można odnieść wyniki badań do innych branży, w których wykorzystuje się nowe technologie. W innym raporcie The Slience Fails sporządzonym przez firmę VirtualSmarts oraz The Concours Group przedstawionych jest pięć obszarów, które mają znaczny wpływ na powodzenie lub niepowodzenie przedsięwzięć biznesowych. Do obszarów tych zalicza się [3]: Wstępne planowanie projektu zbyt szczegółowe planowanie harmonogramu, z datami i zasobami, które nie przystają do rzeczywistości, skazując projekt na niepowodzenie Brak zaangażowania sponsora projektu sponsorzy projektów nie zapewniają odpowiedniego wsparcia grupie realizującej projekt, poświęcają za mało czasu i energii, aby doprowadzić projekt do końca Ignorowanie priorytetów ignorowanie priorytetów zadań w projektach przez członków projektu, do którego zostali przypisani Strona 7 z 43
8 Ukrywanie faktycznego stanu projektu lider projektu i członkowie zespołu nie sygnalizują występujących w projekcie problemów czekają, aż ktoś inny to powie lub zapyta Porażka zespołu członkowie zespołu nie posiadają odpowiedniej wiedzy, która wymagana jest do realizacji projektu nie chcą lub nie są w stanie zaangażować się w efektywną realizację projektu Przeprowadzone badania wykazały, że jeżeli jedna z powyższych sytuacji nie zostanie odpowiednio przeanalizowana i nie zostaną wyciągnięte z niej odpowiednie wnioski w stosunku do prowadzonego projektu, to prawdopodobieństwo zakończenia tego projektu porażką (zdefiniowaną jako przekroczenie zaplanowanego budżetu i czasu oraz niespełnienie wszystkich wymagań klienta co do jakości i funkcjonalności wytworzonego produktu) wzrasta do 85%. Według większości ankietowanych, jeśli zarządzanie krytycznymi obszarami projektu jest realizowane w sposób prawidłowy, to prawdopodobieństwo porażki spada o 50-70% [3] Stosowanie metodyk projektowych Pojawiające się projektach problemy zaczęły być uciążliwe co zmusiło firmy i instytucje do odpowiedniego zarządzania. Zaczęto tworzyć metodyki, które pomagały uporządkować realizację zadań a pierwsze metodyki powstały tuż przed II wojną światową. Dziś na temat zarządzania projektami powstało już wiele publikacji a także wyodrębniły się najbardziej tradycyjne oraz powszechne: PMBoK oraz PRINCE2. Tradycyjne podejście do zarządzania projektami opiera się na szczegółowym planowaniu i szacowaniu projektu na podstawie dostarczonych przez klienta wymagań, które jasno określają co dokładnie klient chce, na kiedy projekt ma być gotowy oraz jaki jest budżet przeznaczony na określony projekt a te zasady były podstawą do utworzenia sprawdzonego zestawu narzędzi oraz technik w metodyce PMBOK. Zupełnie inne podejście jest wykorzystywane w metodyce PRINCE2 gdzie bazuje się na opisie procesów które w ogólnym kontekście pokazują jakie czynności trzeba wykonać aby np. rozpocząć projekt czy przedwcześnie go przerwać. Oprócz tradycyjnego podejścia do projektów zrodziła się też potrzeba znalezienia metodyki która pozwoliła by na szybkie wprowadzanie zmian w Strona 8 z 43
9 projekcie. Ostatnie lata doprowadziły do określenia zwinnych metod zarządzania projektami (agile project management), które spełniają takie wymagania. Do tego właśnie typu zarządzania projektami zalicza się metodyka SCRUM o której będzie właśnie ta praca. Czym, że jest więc sam SCRUM? Jest to niezbyt skomplikowana metodyka pozwalająca zarządzać projektem przy wykorzystaniu prostego procesu, który jednak nie opisuje dokładnie co powinniśmy w każdej sytuacji wykonać przez co prostota tej metodyki może być złudna a poprawne jej zastosowanie pozwala na dostosowanie projektu w ten sposób aby osiągnąć założone wcześniej cele. Czym jest Scrum 1.1. Manifest Agile podstawą Scrum Termin Scrum (pl. młyn) zaczerpnięty został ze sportu rugby i jest rodzajem rzutu wolnego w którym dwie splecione drużyny przepychają się ze sobą nad leżącą na ziemi piłką [4]. W zarządzaniu projektami mianem Scrum określamy lekką metodyką zarządzania projektami opartą na Agile skupiającą się głownie na dostarczaniu klientowi funkcjonalności w sposób przyrostowy. Samo pojęcie Agile (The Agile Manifesto) wiąże się z deklaracją zasad tworzenia oprogramowania która została sformułowana w lutym 2010 roku [5] przez zwolenników alternatywnych metod tworzenia oprogramowania a wśród nich był uważany za jednego z twórców i propagatora Ken Schwaber. Sam manifest spisany przez uczestników został udostępniony na stronie manifestu [5]: Ludzi i ich wzajemne interakcje (współdziałanie) ponad procedury i narzędzia. Działające oprogramowanie nad wyczerpującą dokumentację. Współpracę z klientem nad negocjację umów. Reagowanie na zmiany nad realizowanie planu. Oprócz manifestu agile wprowadza także zasady które mają na celu zdefiniowanie filozofii działania. Zasady te tak samo jak manifest zostały przetłumaczone na wiele języków i są dostępne na oficjalnej stronie agile [5]: Strona 9 z 43
10 Najważniejsze dla nas jest zadowolenie Klienta wynikające z wcześnie rozpoczętego i ciągłego dostarczania wartościowego oprogramowania. Bądź otwarty na zmieniające się wymagania nawet na zaawansowanym etapie projektu. Zwinne procesy wykorzystują zmiany dla uzyskania przewagi konkurencyjnej Klienta. Często dostarczaj działające oprogramowanie od kilku tygodni do paru miesięcy, im krócej tym lepiej z preferencją krótszych terminów. Współpraca między ludźmi biznesu i programistami musi odbywać się codziennie w trakcie trwania projektu. Twórz projekty wokół zmotywowanych osób. Daj im środowisko i wsparcie, którego potrzebują i ufaj im, ze wykonają swoją pracę. Najwydajniejszym i najskuteczniejszym sposobem przekazywania informacji do i ramach zespołu jest rozmowa twarzą w twarz. Podstawową i najważniejszą miarą postępu jest działające oprogramowanie. Zwinne procesy tworzą środowisko do równomiernego rozwijania oprogramowania. Równomierne tempo powinno być nieustannie utrzymywane poprzez sponsorów, programistów oraz użytkowników. Poprzez ciągłe skupienie na technicznej doskonałości i dobremu zaprojektowaniu oprogramowania zwiększa zwinność. Prostota sztuka maksymalizacji pracy niewykonanej jest zasadnicza. Najlepsze architektury, wymagania i projekty powstają w samoorganizujących się zespołach. W regularnych odstępach czasu zespół zastanawia się jak poprawić swoją efektywność, dostosowuje lub zmienia swoje zachowanie. Twórcy definiując zasady skupili się na wypunktowaniu w jaki sposób kierować projektem, lub wytwarzaniem oprogramowania, aby dostarczyć oprogramowanie dopasowane do rzeczywistych potrzeb klienta [5]. W standardowych metodach kierowania projektami informatycznymi wprowadzenie zmiany przez klienta łączy się ze zmianą Strona 10 z 43
11 planowania projektu ze względu na kaskadowy model prowadzenia projektu jak to jest na Rys Rys Proces kaskadowy [6] Taki przypadek wymaga dodatkowych nakładów ze strony zarządzającej i uwzględnienia ryzyka zmiany wymagań przez klienta. Metodyki oparte na agile skupiają się na dostarczeniu oprogramowania, które klient rzeczywiście potrzebuje a proces tworzenia oprogramowania podąża za zmianami potrzeb klienta. W przypadku zmian w późnej fazie projektu zmiana wymagań jest odpowiednio wpisana w założenia metodyki i nie należy się jej z tego względu obawiać. Takie działanie jest możliwe dzięki częstemu dostarczaniu fragmentów produktu do klienta, w częstości od kilku tygodni do kilku miesięcy, co umożliwia klientowi udzielenie uwag lub zmiany jego wymagań. Według manifestu ważnym aspektem jest komunikacja podczas prowadzenia projektu ponieważ dzięki interakcji klienta i zespołu tworzącego jesteśmy w stanie zrozumieć potrzeby odbiorcy [5]. Najefektywniejszą metodą komunikacyjną jest spotkanie twarzą w twarz dzięki, której jesteśmy w stanie wyjaśnić wszystkie wątpliwości lub problemy napotkane podczas realizacji projektu. Taka rozmowa możne prowadzić do wspólnego rozwiązania lub zasugerować nowe możliwości funkcjonalne a w przypadku problemu z określeniem wymagań przez klienta, nakierować go na jasne zdefiniowanie potrzeb. Klient w takim wypadku jest angażowany do podjęcia współpracy której owocem jest system dopasowany do jego potrzeb a dla strony wykonującej zakończenie projektu sukcesem, jednak sama odpowiednia komunikacja nie jest jedynym czynnikiem, który będzie warunkował o Strona 11 z 43
12 sukcesie lub porażce projektu. W celu zakończenia projektu, oprócz spełnienia satysfakcji klienta z dostarczonej funkcjonalności, potrzebne jest też odpowiednie zaangażowanie zespołu a możemy tego dokonać dobierając grupę zmotywowanych osób oraz dostarczając im wszystkie potrzebne czynniki środowiskowe. Wartość dodatnia jaką otrzymamy z takiego zespołu to pewność, że zadania, które zostaną powierzone będą wykonane na czas lub w przypadku zdarzeń losowych z niewielkim opóźnieniem. Takie podejście pozwala na zachowanie zespołowi swojego stałego tempa pracy nad oprogramowaniem a spotkania z klientem na zachowanie ciągłej komunikacji w celu zrozumienia wymagań. Monitorowanie postępu prac powierzonych zespołowi powinno się odbywać poprzez ciągłe dostarczenie działających części zamówionego produktu czyli takich, które zostały odpowiednio przetestowane oraz spełniają ustalone wcześniej wymagania. Samoorganizacja zespołu ma wpływ na wiele czynników w wśród nich na architekturę, jakość czy projekt systemu. Zasady agile zobowiązują zespół do podejmowania wspólnie jak najlepszych decyzji dotyczących produktu oraz do jak najlepszego wykonania technicznego co później zmniejsza nieprawidłowości w działaniu systemu. Łatwość reagowania na zmiany jest głównym atutem agile jednak aby reakcja rzeczywiście była łatwa ilość wykonywanych zadań musi być ciągle optymalizowana tak aby zespół mógł określać ilość pracy potrzebnej na wykonanie danej funkcjonalności. Zespół powinien możliwość usprawnienia swojego działania lub ilości wykonywanych przez siebie zadań. Efektem prac całego zespołu jest w pełni zaprojektowane, zgodne z wymaganiami i jak najlepiej wykonane przez zespół oprogramowanie. Cała filozofia agile sprowadza się do dwunastu zasad które wyżej zostały opisane a które są jej teoretyczną podstawą [7]. W praktyce zostało wypracowanych kilka metodyk zarządzania projektami, które swe podstawy mają w filozofii Agile a wśród nich jest między innymi metodyka Scrum, która jest jedną z popularniejszych metodyk zwinnych i posiada zarówno całe rzesze zwolenników jak i przeciwników, a ponadto w pełni uwzględnia wszystkie dwanaście zasad Agile. Strona 12 z 43
13 1.2. Scrum jako praktyczne podejście do zasad Agile Praktycznym podejściem które odwołuje się do zasad agile jest metodyka Scrum. Historia metodyki rozpoczęła się od opublikowania artykułu The New New Product Development Game, który został napisany przez Hirotaka Takeuchi i Ikujiro Nonaka, w czasopiśmie Harward Bussines Review gdzie zostały przedstawione ogólne założenia metodyki [8]. Następnym ważnym wydarzeniem w dziejach metodyki było opublikowanie przez Kena Schwabera i Jeffa Sutherlanda artykułu Agile Development: Lessons Learned from the First Scrum w, którym został zawarty pierwszy formalny opis metodyki. Jak zostało to opisane na początku tego rozdziału Scrum wolnym tłumaczeniu oznacza młyn a wywodzi się ze sportu Rugby w którym oznacza rodzaj rzutu wolnego, gdzie dwie splecione drużyny przepychają się nad leżącą na ziemi piłką. Układ ten wymaga od zawodników szybkiej reakcji na poczynania przeciwnika aby zdobyć piłkę. W Agile oznacza praktyczną implementacją jej zasad. Podstawą Scrum jest zdefiniowany proces, który jest wykonywany iteracyjnie, aż do osiągnięcia celu przy zachowaniu odpowiedniej jakości co możemy to porównać do przyrostowego modelu tworzenia oprogramowania. Ken Schwaber w swojej książce Sprawne zarządzanie projektami metodą Scrum porównuje proces Scrum do empirycznego procesu w którym istnieją trzy filary [7]: I Filar Widoczność II Filar Inspekcja III Filar Adaptacja W empirycznym procesie kontroli jakości widoczność oznacza że rezultaty projektu wynikające z zastosowania procesu są widoczne dla zarządzających a także określenie co jest uwzględnione podczas obserwacji. Dla wykonujących zadania oznaczenie go jako wykonane wiąże się z zastosowaniem do ogólnie przyjętej definicji słowa wykonane. Drugi filar, inspekcja, w ujęciu procesu scrumowego oznacza odpowiednią kontrole podczas procesu aby wykryć nieoczekiwane odchylenia. Proces empiryczny pozostawia wolną rękę co do częstości przeprowadzanych inspekcji. Wykrycie niepożądanych odchyleń pozwala na reakcję ze strony zarządzających, które wiąże się z III filarem, Adaptacją, której zastosowanie wiąże się z podjęciem działań które mają zapobiec dalszemu pogłębianiu się wykrytego problemu przez, które było by nieakceptowane [9]. Strona 13 z 43
14 Scrum jako praktyczne podejście do zasad Agile opiera się na iteracyjnym (przyrostowym) procesie kontroli projektu jak to zostało pokazane na Rys Pierwszym elementem który podawany jest na wejściu procesu jest nazywany zaległościami produktowymi (Product Backlog) z, których następuje wybranie poszczególnych funkcjonalności, które zostaną zrealizowane w danej iteracji (Sprint Backlog). Następnym elementem procesu jest realizacja iteracji (zwanej też sprintem i reprezentującej na Rys. 0.2 większy okrąg) oraz codziennej inspekcji (mniejszy okrąg nad symbolem iteracji opisanej jako Daily Scrum meeting) w, której członkowie spotykają się by przeprowadzić inspekcję innych członków zespołu. Efektem całego procesu jest potencjalny przyrost funkcjonalności [7]. Rys Proces Scrum [10] Adaptacyjna natura tego procesu pozwala zespołowi na zmianę podejścia sposobu pracy z dnia na dzień. Także wybór wymagań jest kwestią, której podejmuje się zespół rozważając wspólnie możliwe rozwiązania problemu z, których wybierane jest najlepsze podejście. Rozważanie nad metodą rozwiązania problemu przez zespół jest praktyczne z punktu podwyższania ich kwalifikacji, rozwijając umiejętności. W Scrumie wyróżniamy tylko trzy role: zespół, ScrumMaster, właściciel produktu a których opis zostanie podany w następnym podrozdziale [9]. Iteracyjne natura projektu pozwala na rozpoczęcie projektu bez jasno określonej wizji. Z czasem trwania projektu właściciel produktu odpowiadający Strona 14 z 43
15 przed sponsorami projektu dostarcza wizję produktu którego celem będzie maksymalizacja współczynnika ROI (Return of Investment Zwrot z inwestycji) [7]. Wizja ta do procesu Scrumowego dostarczana jest za pomocą zaległości produktowych które stanowią listę wymagań z wyznaczonymi priorytetami. Lista takich wymagań służy zespołowi do wyboru funkcjonalności którą zobowiązuje się na wykonanie w najbliższym sprincie, który trwa zazwyczaj od 10 do 30 dni aczkolwiek nie ma ograniczeń co do stosowania innej długości jednak ta jest najbardziej zalecana [7]. Każdy początek iteracji rozpoczyna się od spotkania podczas, którego zespół oraz właściciel produktu ustala co zostanie wykonane podczas kolejnego sprintu. Podczas spotkania zespół dokonując wyboru funkcjonalności kieruje się sugestiami właściciela produktu odnośnie tego co należy zrobić w pierwszej kolejności a właścicielowi produktu zespół informuje co z pożądanej funkcjonalności jest wstanie wykonać. Spotkanie takie nazywane jest spotkaniem planującym sprint i nie może trwać dłużej niż osiem godzin a ponadto dzieli się na dwie części z których każda nie może trwać dłużej niż cztery godziny [7]. Pierwsza część składa się z prezentacji przez właściciela produktu zaległości produktowych wraz z priorytetami a zespół w tym czasie jest odpowiedzialny za zdobycie jak największej ilości informacji od Właściciela produktu odnoście prezentowanej wizji. Podczas tego spotkania zespół także wybiera część funkcjonalności, która zostanie zrealizowana w następnym sprincie. Jeżeli przed upływam pierwszych czterech godzin zakończy się spotkanie zespól rozpoczyna drugą część na, której dokładnie omawia i planuje swoja pracę i umieszcza zadania na zaległościach sprintu. Od początku drugiego spotkania rozpoczyna się czas trwania sprintu o określonej wcześniej długości [7]. Podczas trwania iteracji zespół zbiera się każdego dnia w ustalonym wcześniej miejscu o ustalonej godzinie na krótkie 15 minutowe spotkanie nazywane codzienną inspekcją lub codziennym spotkaniem Scrumowym [9] na, którym spotykają się ScrumMaster oraz zespół. Wszyscy uczestnicy tego spotkania zobowiązani są do stawienia się na spotkanie na czas a każde spóźnienie powinno być karane ogólnie przyjętą i zaakceptowaną przez zespół karą. Przykładem takiej kary może być np. zapłacenie jednego dolara [7] lub co można spotkać w korporacjach chodzenie przez cały dzień z tabliczką z napisem I was late jak na Rys Samo spotkanie jest organizowane w celu Strona 15 z 43
16 zsynchronizowania pracy zespołu a sam zespół jest zobowiązany do udzielenia odpowiedzi na trzy podstawowe pytania [7]: Co robiłeś/łaś w projekcie od ostatniego spotkania? Co zamierzasz zrobić pomiędzy obecnym spotkaniem a następnym? Czy są jakieś przeszkody, które przeszkadzają w realizacji założeń tego sprintu? Rys Spotkanie Scrumowe z osobą ukaraną Pod koniec sprintu przeprowadzane jest spotkanie nazywane przeglądem sprintu na, którym zespół prezentuje pracę wykonaną w danym sprincie. Spotkanie to mające charakter nieformalny, jest ograniczone do 4 godzin w, podczas którego uczestniczy właściciel produktu oraz opcjonalnie inni udziałowcy. Celem tego spotkania jest prezentacja zrealizowanej funkcjonalności oraz pomoc właścicielowi produktu w określeniu kierunku w, którym zespół powinien rozwijać produkt [7]. Po zakończeniu spotkania przeglądowego ScrumMaster powinien przeprowadzić z zespołem retrospektywne spotkanie, które dotyczy sprintów. Spotkanie to ma na celu zachęcenie zespołu do zmiany parametrów procesu tak by zwiększyć efektywność, jak na przykład czas trwania sprintu, oraz zorganizować pracę tak by stała się ona bardziej wydajna [7]. Strona 16 z 43
17 Wszystkie trzy spotkania planujące sprint, codzienna inspekcja, podsumowanie wraz z retrospekcją odzwierciedlają założenia empirycznej kontroli procesu oraz trzech filarów na, których Scrum się opiera jednocześnie zachowując zasady związane z manifestem Agile. Oprócz trzech spotkań w Scrumie możemy wyróżnić także trzy role oraz trzy artefakty. Opisując metodykę w następnej kolejności skupie się na opisie roli w projekcie a następnie na temat artefaktów Scrumowych Role w projekcie W Scrumie należy wyróżnić trzy role między które jest podzielona odpowiedzialność w projekcie. Są to [9]: Zespół ScrumMaster Właściciel Produktu Każda z wyżej wymienionych ról charakteryzuje się odpowiednim zakresem odpowiedzialności. Osoba odpowiedzialna za budowanie fundamentu i obsługę projektu po stronie klienta to właściciel produktu. Jego główną rolą jest komunikowanie się z osobami zainteresowanymi projektem lub produkowanym systemem. Poprzez komunikację z przyszłymi zainteresowanymi właściciel produktu buduje listę ogólnie sformułowanych wymagań oraz jest odpowiedzialny za budowę celów projektu. Wymagania zbierane przez właściciela produktu są umieszczane w zaległościach produktowych (Product Backlog), które powinny zostać sformułowane w ogólny sposób a każde z wymagań powinno mieć przypisany priorytet. Właściciel produktu powinien dbać o to aby na każdy następny sprint uaktualnić listę zaległości produktowych [9]. Zespół w projekcie odpowiada za przekształcenie zaległości sprintu, która została wybrana z zaległości produktowych, w przyrost funkcjonalności. Zespół decyduje o tym w jaki sposób organizować to znaczy, że zespół jest samo organizacyjny i jest odpowiedzialny za budowę przyrostu funkcjonalności. Każdy członek zespołu pracuje nad własną częścią funkcjonalności ale za sukces każdego sprintu i projektu jest odpowiedzialny cały zespół [9]. Osoba która, jest w roli ScrumMastera odpowiedzialna jest za utrzymanie ciągłości procesu scrumowego. ScrumMaster pełni także rolę nauczyciela ponieważ na nim Strona 17 z 43
18 spoczywa obowiązek nauczenia metodyki Scrum. Oprócz wyżej wymienionych funkcji ScrumMaster odpowiedzialny jest za wdrożenie procesu Scrumowego tak aby był on zgodny z kulturą organizacji a także za usprawnianie samego procesu [9]. Każda osoba zaangażowana w projekt musi mieć przypisaną jedną z wyżej wymienionych ról. Było by idealne gdyby osoby nie będące zaangażowane w projekt nie były by nim zainteresowane. W Scrumie wyróżnia się grupy zaangażowane w projekt, czyli te które mają moc władczą w projekcie oraz osoby które takiej mocy nie posiadają i nie mogą bez wyraźnej potrzeby się wtrącać. Grupy te nazywamy odpowiednio świniami (osoby realizujące projekt) oraz kurczakami (osoby zainteresowane projektem) [7] a nazwy tych grup wzięły się z pewnej historyjki, która został przedstawiony w formie komiksu na Rys Rys Komiks opisujący genezę nazewnictwa grup świnie i kurczaki [11] Podział na grupy i role w projekcie pozwala w Scrumie na wyznaczenie odpowiedzialności oraz wyznacza obszar decyzyjności poszczególnych ról [7]. Dzięki temu zabiegowi wiemy kto jest odpowiedzialny za przygotowanie zaległości produktowych a kto za wykonanie prac. W następnych podrozdziałach dokładniej opiszę poszczególne role w projekcie oraz ich zakres odpowiedzialności zaczynając od opisu zespołu Zespół Zadaniem zespołu w metodyce Scrum jest przekształcanie zadań, które zostały wybrane spośród wymagań zgromadzonych w zaległościach produktowych. Lista takich Strona 18 z 43
19 wymagań realizowanych podczas konkretnego sprintu nazywa się zaległościami Sprintu (Sprint Backlogu). Wymagania umieszczone na tej liście mają taki sam priorytet jak te, które zostały przygotowane przez właściciela produktu. Zespół jest zobowiązany do wykonywania w pierwszej kolejności zadań z wyższym priorytetem co zwiększa wydajność metodyki Scrum z tego względu, że klient w pierwszej kolejności otrzymuje przyrost funkcjonalności, który jest mu najbardziej potrzebny. Scrum zakłada że Zespół jest samoorganizującą się jednostką, która optymalizuje swoją pracę a cały plan realizacji założeń sprintu jest wykonywany przez zespół [7]. Zespół może otrzymywać rady dotyczące samoorganizacji od ScrumMastera oraz kurczaków jednak to czy sam zastosuje się do tych rad leży tylko w gestii zespołu. Czas realizacji wszystkich zadań przez zespół nie więcej niż długość sprintu a jest liczony zaraz po ich wybraniu do realizacji przez zespół zadań [7]. Po starcie odliczania do końca sprintu zespół jest zobowiązany do zrobienia wszystkiego aby spełnić swoje zobowiązania a na końcu prezentuje swoje zobowiązania w postaci przyrostu produktu przed właścicielem produktu oraz udziałowcami [7]. W praktyce dzisiejszych projektów mamy zespoły które, są zarządzanie przez osoby o odpowiednich kompetencjach podczas gdy w Scrumie mamy zespoły samo zarządzające. Jak w takim wypadku wprowadzić zespół, który był zarządzany w samoorganizację? Metodyka zakłada, że rolę wdrożenia do samoorganizowania sobie pracy zespołu powinna przejąć osoba w roli ScrumMastera która uczy zespół zasad empirycznego procesu przy pomocy codziennych spotkań i spotkaniu retrospektywnym (inspekcja i adaptacja), poprzez pomoc w rozwiązywaniu problemów, a także przejrzystością w celu zachowania odpowiedniej jakości [12]. Budowa zespołu odbywa się przed rozpoczęciem pracy nad projektem dlatego też ważne jest aby dobierać już na samym początku kompetentne osoby, które mają stworzyć zespół. Zmiany w zespole podczas trwania projektu mogą powodować niepożądane opóźnienia wynikające z komunikacji w zespole ponieważ każda grupa przechodzi w swoim rozwoju przez kolejne fazy [13]: Formowania (forming) Konfliktów (stortming) Normalizacji (norming) Współdziałania (performing) Strona 19 z 43
20 Jakiekolwiek zmiany w zespole i przechodzenie przez zespół od nowa kolejnych faz może spowodować opóźnienia w wykonaniu zaplanowanych prac dlatego też ważne jest zbudowanie zespołu składającego się z odpowiednich osób już na samym początku projektu ScrumMaster W metodyce Scrum role kierownika projektu przejmuje osoba w roli ScrumMastera. Genezę tej nazwy Ken Schwaber opisuje w swojej książce Sprawne zarządzanie projektami metodyką Scrum wyjaśniając że nazwa ScrumMaster miała zaznaczać zupełnie inny zasięg roli oraz drastyczne zmiany w prowadzeniu projektu. Osoba pełniąca tą rolę ma władzę tylko wynikającą z zasad które istnieją w metodyce Scrum i pilnuje aby wszyscy tych zasad też przestrzegali [7]. Jest to osoba która musi mieć umiejętność rozumienia tych zasad i w jasny sposób nauczania innych tak aby wszyscy zrozumieli zasady kierujące Scrumem [9]. ScrumMaster jest też odpowiedzialny za pomoc właścicielowi produktu w określaniu zaległości produktowych oraz priorytetów a zespołowi za pomoc w przemienieniu zaległości produktowych w przyrost funkcjonalności Właściciel produktu Osoba pełniąca rolę właściciela produktu jest odpowiedzialna z zbieranie wymagań dotyczących tworzonego systemu. Praca tej osoby jest związana z komunikacją z wszystkimi osobami zainteresowanymi projektem i spisywaniu wymagań. Następnie lista zebranych wymagań jest analizowana przez właściciela produktu i przedstawiana jako lista zaległości produktowych opisująca wymagania systemu wraz z przypisanymi priorytetami. Obecnie stosowane są wyrafinowane techniki analizy wymagań dzięki, którym możemy tworzyć szczegółowo opisane i przeanalizowane z dużą ilością diagramów dokumenty gdzie często przekraczają ponad 500 stron. Takie dokumenty uniemożliwiają swobodną pracę z wymaganiami z tego względu, że czytanie takiego dokumentu zajmuje dużo czasu a zapamiętanie każdego szczegółu jest prawie niemożliwe. Dzięki roli właściciela produktu Scrum pozwala na zupełne inne podejście, zamiast skupiać się na tworzeniu ogromnej ilości Strona 20 z 43
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ą
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
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
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
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:
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
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
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
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
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
Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming
Jarosław Kuchta Wymagania jakości w Agile Programming Wady klasycznych metod zapewnienia jakości Duży narzut na dokumentowanie Późne uzyskiwanie konkretnych rezultatów Trudność w odpowiednio wczesnym definiowaniu
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
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
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
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
OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA
OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA Projekt to metoda na osiągnięcie celów organizacyjnych. Jest to zbiór powiązanych ze sobą, zmierzających
Wstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
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
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
Wstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
Zarządzanie projektami w NGO
Zarządzanie projektami w NGO Warsztaty dla Grupy Nowe Technologie Federacja Organizacji Służebnych MAZOWIA 4 września 2012 Projekt współfinansowany jest ze środków Unii Europejskiej w ramach Europejskiego
4. Wprowadzanie Scruma w ImmobilienScout24 4.1. Opis sytuacji
Spis treści Przedmowa 1. Wstęp 1.1. Jak czytać tę książkę 1.2. Studia projektów 1.3. Dodatek 2. Zwinny projekt to nie bułka z masłem 2.1. Pobudka 2.2. Zespół się formuje 2.3. Właściwe zlecenie 2.4. Od
Zarządzanie projektami
Zarządzanie projektami Dr Sławomir Kotylak WYKŁAD 2 MENEDŻER PROJEKTU ODPOWIEDZIALNY ZA WSZYSTKIE ASPEKTY REALIZACJI PROJEKTU PLANOWANIE KONTAKTY Z KLIENTEM, NEGOCJACJE KIEROWANIE ZESPOŁEM: REALIZACJA
Klasyczna organizacja też może być zwinna! Zarządzaj zwinnie projektami!
Klasyczna organizacja też może być zwinna! Dynamika zmian w dzisiejszym świecie IT wymaga niezwykłej elastyczności i błyskawicznego adaptowania się do nowych warunków. Klasyczne techniki zarządzania projektami
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ść
ŚCIEŻKA: Zarządzanie projektami
ŚCIEŻKA: Zarządzanie projektami Ścieżka dedykowana jest każdej osobie, która chce rozwijać siebie i swoją organizację - w szczególności: Kadrze menedżerskiej i kierowniczej przedsiębiorstw Kierownikom
Wstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
Zarządzanie Projektami zgodnie z PRINCE2
Zarządzanie Projektami zgodnie z PRINCE2 Opis Metodyka PRINCE2 powstała na bazie doświadczeń z wielu lat dobrych praktyk zarządzania projektami. Metodyka ta oferuje elastyczne i łatwe do adaptacji podejście
Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią
Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią Marek Bieniasz Sławomir Umpirowicz Piotr Miszewski Kraków, 10 13 września 2012 Plan prezentacji Informacje
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
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ć
Temat: Zwinne Zarządzanie Projektami IT (Agile / Scrum) Data: 06-07 marca 2014 r. (2 dni, czwartek-piątek), godz. 9-16
Temat: Zwinne Zarządzanie Projektami IT (Agile / Scrum) Data: 06-07 marca 2014 r. (2 dni, czwartek-piątek), godz. 9-16 Miejsce: Eureka Technology Park, Innowatorów 8 Cena: 980 zł netto (1 osoba / 2 dni
Etapy życia oprogramowania
Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 w prezentacji wykorzystano również materiały przygotowane przez Michała Kolano
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
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
Agile Project Management
Charles G. Cobb, pmp Zrozumieć Agile Project Management Równowaga kontroli i elastyczności przekład: Witold Sikorski APN Promise Warszawa 2012 Spis treści Wstęp...vii Kto powinien przeczytać tę książkę?...
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
Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania
Etapy życia oprogramowania Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 Określenie wymagań Testowanie Pielęgnacja Faza strategiczna
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
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
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
Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka
Agile vs PRINCE2 Ewa Solecka - specjalność ogólna- 1117627 Przemysław Mrozowski specjalność ogólna- 1121130 Michał Roztoczyński specjalność ogólna - 1118910 2014/2015 I rok st. magisterskie Informatyka
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
MONITOROWANIE, KONTROLA I ZAMKNIĘCIA PROJEKTU. Dr Jerzy Choroszczak
MONITOROWANIE, KONTROLA I ZAMKNIĘCIA PROJEKTU Dr Jerzy Choroszczak Kontrola w zarządzaniu projektami Kontrola terminów przygotowania i wykonawstwa projektu Kontrola zużycia zasobów Kontrola kosztów przygotowania
Maciej Oleksy Zenon Matuszyk
Maciej Oleksy Zenon Matuszyk Jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów kontroli jakości oprogramowania. Weryfikacja oprogramowania - testowanie zgodności systemu
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ć
Skuteczne zarządzanie projektami IT w otoczeniu uczelnianym. Piotr Ogonowski
Skuteczne zarządzanie projektami IT w otoczeniu uczelnianym Piotr Ogonowski Agenda Najważniejsze elementy organizacji projektowej Agile czy klasycznie? Jak wdrożyć podejście projektowe na Uczelni? Kluczowe
RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010
RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010 Odpowiada na pytania: Jaka część projektów IT kończy się w Polsce sukcesem? Jak wiele projektów sponsorowanych jest przez instytucje publiczne? Czy kończą się
Procesowa specyfikacja systemów IT
Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office
www.omec.pl 1 Konferencja "Bezpieczny Projekt" Wrocław 22 czerwca 2010
Od kartki i ołówka do systemu informatycznego, czyli jak wdrażano zarządzanie projektami u klienta Rinf Sp. z o.o. www.omec.pl 1 Co my rozumiemy pod pojęciem: PROJEKT Projekt: Ciąg zadań nastawionych na
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
KILKA SŁÓW O ROLI PRODUCT MANAGERA
CZĘŚĆ I. KILKA SŁÓW O ROLI PRODUCT MANAGERA Product manager pracuje na styku świata IT i biznesu. Analizuje potrzeby użytkowników i klientów, współpracuje ze wszystkimi działami firmy maksymalizując wartość
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ń
Lekkie metodyki. tworzenia oprogramowania
Lekkie metodyki tworzenia oprogramowania Programowanie zwinne ( Agile software development) grupa metodyk wytwarzania oprogramowania opartego o programowanie iteracyjne (model przyrostowy). Wymagania oraz
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
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
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
SKUTECZNY PROJECT MANAGER
Elżbieta Jędrych Paweł Pietras Maciej Szczepańczyk SKUTECZNY PROJECT MANAGER JAK W SPOSÓB SPRAWNY I EFEKTYWNY REALIZOWAĆ POSTAWIONE ZADANIA O CHARAKTERZE PROJEKTOWYM Monografie Politechniki Łódzkiej 2016
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ń
Programowanie obiektowe
Programowanie obiektowe Laboratorium 1 - wprowadzenie do zarządzania projektami mgr inż. Krzysztof Szwarc krzysztof@szwarc.net.pl Sosnowiec, 22 luty 2017 1 / 29 mgr inż. Krzysztof Szwarc Programowanie
Jak uchronić architekturę i wymagania przed chaosem? Warszawa, 27 stycznia 2016 roku
Jak uchronić architekturę i wymagania przed chaosem? Warszawa, 27 stycznia 2016 roku Agenda Metafory o Zwinności i Sztywności Teza: Oszukujemy się co do sukcesów projektów Agile Objawy chaosu w projektach
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
Czynniki wpływające na porażkę projektu. 1. Niekompletne wymagania 13.1% 2. Brak zaangażowania użytkowników 12.4% 3. Brak zasobów 10.
Bez celu ani rusz Karolina Zmitrowicz Niepowodzenia projektów informatycznych to nieustannie wdzięczny temat pojawia się na konferencjach, szkoleniach, w prasie i innych publikacjach. Badaniem przyczyn
Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010
Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................
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ś
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
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
Spis treści. 00 Red. Spis tresci. Wstep..indd 5 2009 12 02 10:52:08
Spis treści Wstęp 9 Rozdział 1. Wprowadzenie do zarządzania projektami 11 1.1. Istota projektu 11 1.2. Zarządzanie projektami 19 1.3. Cykl życia projektu 22 1.3.1. Cykl projektowo realizacyjny 22 1.3.2.
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
Metodyki zwinne wytwarzania oprogramowania
Metodyki zwinne wytwarzania oprogramowania Wykład 1 Marcin Młotkowski 7 października 2014 Plan wykładu Sprawy organizacyjne Organizacja pracowni 1 Sprawy organizacyjne Organizacja pracowni 2 3 Marcin Młotkowski
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
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
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)
Zarządzanie projektami IT
Zarządzanie projektami IT Źródła Zarządzanie projektami, J. Betta, Politechnika Wrocławska, 2011 Zarządzanie projektami IT, P. Brzózka, CuCamp, styczeń 2011 Zarządzanie projektami IT w przedsiębiorstwie
Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Fundation
Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Fundation Opis Progress Project zaprasza do zapoznania się z programem szkolenia organizowanego przez partnera szkoleniowego,
AL 1302 ZARZĄDZANIE PROJEKTAMI W OPARCIU O METODYKĘ PRINCE2
AL 1302 ZARZĄDZANIE PROJEKTAMI W OPARCIU O METODYKĘ PRINCE2 1. Definicja projektu: cechy projektu, przyczyny porażek projektów, czynniki sukcesu projektów, cele projektu, produkty projektu, cykl życia
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
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
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
Opis metodyki i procesu produkcji oprogramowania
Opis metodyki i procesu produkcji oprogramowania Rational Unified Process Rational Unified Process (RUP) to iteracyjny proces wytwarzania oprogramowania opracowany przez firmę Rational Software, a obecnie
( SZKOŁA ZARZĄDZANIA PROJEKTAMI W KOMUNIKACJI
( SZKOŁA ZARZĄDZANIA PROJEKTAMI W KOMUNIKACJI Szkoła powstała z myślą o ludziach odpowiedzialnych za realizację kompleksowych projektów komunikacyjnych przy wykorzystaniu dostępnych zasobów, zarówno w
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
Usługa: Audyt kodu źródłowego
Usługa: Audyt kodu źródłowego Audyt kodu źródłowego jest kompleksową usługą, której głównym celem jest weryfikacja jakości analizowanego kodu, jego skalowalności, łatwości utrzymania, poprawności i stabilności
Programowanie zwinne
Programowanie zwinne Wykład 1 Marcin Młotkowski 10 października 2012 Plan wykładu Sprawy organizacyjne Organizacja pracowni 1 Sprawy organizacyjne Organizacja pracowni 2 3 Marcin Młotkowski Programowanie
I Twój zespół może być zwinny (choć to może trochę potrwać) Paweł Lipiński
I Twój zespół może być zwinny (choć to może trochę potrwać) Paweł Lipiński pawel@warsjawa:/etc$whoami Ja: ponad 10 lat pracy w Javie SCJP, SCWCD, SCBCD, SCEA brałem udział w: rozwój oprogramowania, consulting,
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
Data: 06-07 marzec 2014 r. (2 dni, czwartek-piątek), godz. 9-16. Miejsce: Eureka Technology Park, Innowatorów 8
Szkolenie Scrum w projektach IT (Agile) METRYCZKA: Szkolenie Scrum Data: 06-07 marzec 2014 r. (2 dni, czwartek-piątek), godz. 9-16 Miejsce: Eureka Technology Park, Innowatorów 8 Temat: Zwinne Zarządzanie
Usługa: Testowanie wydajności oprogramowania
Usługa: Testowanie wydajności oprogramowania testerzy.pl przeprowadzają kompleksowe testowanie wydajności różnych systemów informatycznych. Testowanie wydajności to próba obciążenia serwera, bazy danych
Czym się kierować przy wyborze systemu ERP? poradnik
Czym się kierować przy wyborze systemu ERP? poradnik Inwestycja w system ERP to decyzja wiążąca na lata, generująca w pierwszym momencie koszty, ale przede wszystkim mająca decydujący wpływ na przebieg
Szkolenie Scrum w projektach IT (Agile)
METRYCZKA: Szkolenie Scrum Szkolenie Scrum w projektach IT (Agile) Data: 06-07 marzec 2014 r. (2 dni, czwartek-piątek), godz. 9-16 Miejsce: Eureka Technology Park, Innowatorów 8 Temat: Zwinne Zarządzanie
Wprowadzenie dosystemów informacyjnych
Wprowadzenie dosystemów informacyjnych Projektowanie antropocentryczne i PMBoK Podejście antropocentryczne do analizy i projektowania systemów informacyjnych UEK w Krakowie Ryszard Tadeusiewicz 1 Właściwe
PODYPLOMOWE STUDIA ZARZĄDZANIA PROJEKTAMI KATOWICE
PODYPLOMOWE STUDIA ZARZĄDZANIA PROJEKTAMI KATOWICE Dobre narzędzia, które pomogą Ci w planowaniu i realizacji projektu TERMIN od: 04.11.2017 TERMIN do: 04.11.2018 CZAS TRWANIA:21 dni MIEJSCE: Katowice
SKUTECZNE ZARZĄDZANIE PROJEKTEM
SKUTECZNE ZARZĄDZANIE PROJEKTEM Zarządzanie projektami to nie jest takie skomplikowane! TERMIN od: 02.10.2017 TERMIN do: 04.10.2017 CZAS TRWANIA:3 dni MIEJSCE: Gdańsk CENA: 1500 zł + 23% VAT Jak sprawniej
Dwie szkoły oceny 360 stopni. Sprawdź różnicę pomiędzy klasycznym a nowoczesnym podejściem
Sprawdź różnicę pomiędzy klasycznym a nowoczesnym podejściem Czy stosowanie tradycyjnego podejścia do metody 360 stopni jest jedynym rozwiązaniem? Poznaj dwa podejścia do przeprowadzania procesu oceny
Zarządzanie projektami w otoczeniu uczelnianym. Piotr Ogonowski
Zarządzanie projektami w otoczeniu uczelnianym Piotr Ogonowski 1 Agenda Kluczowe elementy organizacji projektowej Jak wdrożyć organizację projektową na uczelni? Dobre praktyki z wdrożeń W czym pomoże nam
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
PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK
KLUCZ ODPOWIEDZI Część DODATEK 8.1 9.4 PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB Na podstawie: Syllabus REQB Certified Professional for Requirements Engineering, Advanced Level, Requirements
Projekt Kompetencyjny - założenia
Projekt Kompetencyjny - założenia sem. V 2013 kgrudzi.kis.p.lodz.pl projekt kompetencyjny 1 System informatyczny zbiór powiązanych ze sobą elementów, którego funkcją jest przetwarzanie danych przy użyciu
"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