Projektowy młyn. Jarosław Milewski
|
|
- Elżbieta Baran
- 8 lat temu
- Przeglądów:
Transkrypt
1 Projektowy młyn Klasyczne, ciężkie metodyki zarządzania projektami, oparte na dokładnym planowaniu wszystkich działań, niezbyt przystają do projektów o wysokim stopniu niepewności, do których należą projekty programistyczne. Tutaj bardzo ciekawym rozwiązaniem jest metodyka Scrum. Czy czujesz się na tyle lekki i zwinny, aby zagrać w rugby? Zespoły zajmujące się wytwarzaniem oprogramowania już dawno przekonały się, jak ważne jest wczesne dostarczanie kolejnych wersji systemu - być może mocno okrojonego, ale mimo wszystko działającego (wówczas odbiorca może ocenić, czy prace postępują we właściwym kierunku). Dlatego powstały iteracyjne techniki produkcyjne, takie jak metoda spiralna, wczesne prototypowanie czy programowanie ekstremalne (extreme programming, XP). Metody te są jednak ściśle związane ze specyficzną dziedziną wytwarzania oprogramowania, a ponadto nie obejmują pełnego cyklu życia produktu. Klasyczne sposoby zarządzania projektami są zbyt kaskadowe w przypadku przedsięwzięć o wysokim stopniu niepewności i innowacyjności, do jakich z natury rzeczy należą projekty programistyczne, koniecznym stało się opracowanie alternatywnych metodyk prowadzenia projektów, które byłyby bardziej odpowiednie dla tego typu przedsięwzięć. W ten sposób narodził się Scrum, który jest jedną z lekkich (zwinnych) metodyk zarządzania projektami, realizowaną zgodnie z zasadami The Agile Manifesto. Jest stosowany z powodzeniem od połowy lat 90-tych przez różne firmy zajmujące się wytwarzaniem oprogramowania, w tym przez Microsoft. Sam termin scrum wywodzi się z gry w rugby i oznacza młyn, czyli rodzaj rzutu wolnego, w którym dwie splecione ze sobą drużyny przepychają się nad leżącą na murawie piłką. Jak przystało na metodykę lekką, Scrum koncentruje się na dostarczaniu wyników projektu metodą kolejnych przybliżeń, bezpośrednim zaangażowaniu przyszłego użytkownika w proces wytwórczy oraz na samoorganizacji zespołu projektowego. 1
2 Zespół projektowy we młynie Ścisły zespół Młyna liczy zwykle od 5 do 9 osób (magiczne 7±2) i ma zwykle charakter interdyscyplinarny, to znaczy poza programistami może w nim uczestniczyć również kontroler jakości, dokumentalista, grafik, a także specjalista biznesowy lub psycholog. Wszyscy członkowie zespołu są zaangażowani w stu procentach i nie mogą uczestniczyć w żadnych innych pracach. Jedynym wyjątkiem mogą być pracownicy usługowi, np. administrator zajmujący się obsługą komputerów członków zespołu, który jest wzywany w miarę potrzeb. Co ciekawe, struktura taka odpowiada dokładnie zespołowi chirurgicznemu, postulowanemu ponad 30 lat temu przez Freda Brooksa w jego znanym Mitycznym osobo-miesiącu. Rolę kierownika projektu pełni Mistrz Młyna (Scrum Master), którego zadaniem nie jest jednak ani planowanie, ani przydzielanie, ani kontrolowanie wykonania zadań, lecz przede wszystkim usuwanie wszelkich przeszkód w pracy zespołu, a także zapewnianie zgodności wyników prac z celami biznesowymi sponsora projektu. Mistrz pilnuje również przestrzegania obowiązujących reguł gry (np. dba o samoorganizację zespołu, ale zwalcza kliki) oraz reprezentuje zespół na zewnątrz. Ważną rolę pełni odbiorca aplikacji, zwany też właścicielem produktu. W przypadku projektu realizowanego na zamówienie zewnętrzne będzie nim reprezentant klienta, natomiast w przypadku wewnętrznego projektu mającego na celu wytworzenie nowego produktu na rynek masowy, właścicielem jest zwykle ktoś z działu marketingu. Jednostką pracy zespołu projektowego jest przebieg (sprint), który trwa zwykle od 2 do 6 tygodni. Zaleca się jednak stosowanie przebiegów o stałym czasie trwania (np. 1 miesiąc), co pomaga zespołowi w wypracowaniu regularnego rytmu pracy. Naczelną zasadą pracy młyna jest to, że każdy przebieg musi dostarczyć użytkownikowi kolejną działającą wersję produktu, którą byłby w stanie dotknąć i ocenić. Nie jest przy tym ważne, jak wiele nowych funkcji systemu zostanie dodanych w ciągu miesiąca. Liczy się to, że każde kolejne wydanie musi dodawać nową wartość, którą daje się zweryfikować w praktycznym użytkowaniu, nie zaś na papierze. Do biegu... Każdy przebieg jest poprzedzony fazą przygotowawczą, w której uaktualniana jest lista wymagań użytkownika. Poprawniej byłoby zresztą mówić o liście życzeń, ponieważ wymagania gromadzone są w postaci historyjek (stories), mówiących o tym, jak właściciel wyobraża sobie swój przyszły produkt. Opowiadanie sensownych historyjek nie jest jednak wcale takie łatwe, w związku z czym wielu praktyków zaleca wcześniejsze szkolenie użytkowników w sztuce ciekawego opowiadania. Historyjki muszą być krótkie i treściwe najlepiej, aby z jednej historyjki wynikała wprost jedna cecha systemu. Pomysły użytkownika można gromadzić na zwykłych kartonikach, albo wpisywać je do kolejnych wierszy arkusza kalkulacyjnego. Zanim zespół przystąpi do pracy, właściciel produktu proszony jest jeszcze o ustalenie priorytetów wymagań oraz o wyznaczenie głównego celu przebiegu. 2
3 Jeśli chodzi o priorytety, to nie muszą być one ułożone według bardzo wyrafinowanej skali. W wielu przypadkach wystarczy wskazanie tych cech, bez których realizacja systemu w ogóle mija się z celem (must be), tych, których obecność bardzo ułatwiłaby pracę (should be) i wreszcie tych, których obecność sprawiłaby właścicielowi niekłamaną przyjemność (nice to have). Jak wiadomo, użytkownicy mają naturalną skłonność do początkowego zaliczania prawie wszystkich swoich pomysłów do najwyższej kategorii, w związku z czym tu także potrzebna jest odrobina treningu i negocjacji. Lista czekających na spełnienie życzeń wraz z ustalonymi priorytetami tworzy rejestr wymagań na produkt (product backlog). Konieczność dodatkowego wyznaczenia głównego celu przebiegu wynika z tego, że mechaniczne wybranie cech o najwyższym priorytecie mogłoby prowadzić do realizacji słabo skorelowanych, czy nawet wzajemnie sobie przeszkadzających zadań. Podobnie jak wymagania cząstkowe, główny cel przebiegu musi być krótki i jasny. Przykładowo, w dziedzinie usług finansowych mogłoby to być hasło zapewnić dostęp do bieżących notowań giełdowych w czasie poniżej 1 minuty, w dziedzinie badań psychologicznych stworzyć koncepcję badania samooceny działającego na telefonie komórkowym, czy też po prostu przenieść centralną bazę danych z platformy MS SQL Server na platformę Oracle. Jak widać, niektóre cele mogą mieć charakter czysto techniczny, wynikający z bieżącego stanu rozwoju systemu, są więc wówczas proponowane przez sam zespół wykonawczy. Cel przebiegu zaakceptowany wspólnie przez właściciela produktu i przez zespół powinien zostać wypisany dużymi literami i przymocowany na ścianie pokoju Młyna. Rysunek 1: Cykl Pracy Młyna 3
4 Gotowi... Teraz następuje kluczowy moment: zespół projektowy zdejmuje z wierzchu stosu dokładnie tyle wymagań, ile będzie w stanie zrealizować w czasie najbliższego przebiegu. Wybierane są zadania o najwyższym priorytecie, zgodne z wyznaczonym celem. Prawidłowe wykonanie tej czynności wymaga przejścia przez krótką - co wcale nie znaczy, że mało precyzyjną - fazę wewnętrznego planowania. Najpierw życzenia klienta zostają rozbite na bardziej elementarne czynności techniczne niezbędne dla ich realizacji. Pracochłonność każdej czynności jest szacowana z dokładnością do pojedynczej roboczogodziny, a zespół sam ustala, kto jest najbardziej odpowiedni do wykonania każdego z zadań. W przypadku uzyskania zbyt dużej lub zbyt małej łącznej liczby roboczogodzin, zespół dodaje lub zwraca wymagania do rejestru w ten sposób, by zmieścić się możliwie dokładnie w ramach czasu trwania przebiegu. Ostatecznie ustalona lista zadań wraz z szacowaną pracochłonnością nosi nazwę rejestru zadań przebiegu (sprint backlog). Do jego implementacji także wystarcza zwykły arkusz kalkulacyjny. W sumie, uaktualnienie rejestru wymagań oraz stworzenie rejestru zadań stanowią główne wyniki jednego wspólnego spotkania planistycznego, w którym uczestniczy zespół Młyna, właściciel produktu, doradcy biznesowi i techniczni, przedstawiciele wyższego kierownictwa, itd. Obecność sponsora projektu i innych przedstawicieli biznesu wpływa na określenie celu przebiegu, natomiast eksperci techniczni mogą pomóc w uściśleniu rejestru zadań i dokładniejszym oszacowaniu pracochłonności. Spotkanie planistyczne trwa zwykle kilka godzin, maksimum 1 dzień. Start! Zespół rzuca się do pracy. Każdy wykonuje swoje zadania z największą efektywnością, na jaką go stać, co wcale nie znaczy, że zespół ma pracować ponad siły. Przeciwnie w celu utrzymania na dłuższą metę wysokiej jakości wyników praca w nadgodzinach (podobnie jak w XP) traktowana jest jako wyjątek, którego należy unikać. W trakcie przebiegu właścicielowi produktu nie wolno wtrącać się do pracy zespołu, a w szczególności zmieniać wymagań lub ich priorytetu. Zabronione jest także zmienianie składu Młyna. Wszelkie zmiany koncepcji produktu i składu osobowego zespołu dozwolone są jedynie pomiędzy przebiegami. Podstawowym narzędziem kontroli postępów jest wykres spalania dla przebiegu (sprint burndown chart). Jednostką spalania są godziny pracy zespołu: na wykresie codziennie jest odnotowywana szacowana liczba roboczogodzin, jaka jeszcze pozostała do realizacji zadań. Za pomocą prostej aproksymacji liniowej ocenia się, czy dotychczasowa linia wykresu trafia w punkt zakończenia przebiegu. Jeśli przewidywany punkt przecięcia znajduje się poza dniem zakończenia, zespół ma prawo obciąć zakres prac przewidzianych dla przebiegu. I odwrotnie - jeśli przewidywana data całkowitego zakończenia prac wypada przed planowaną datą oddania wyników, zespół może dołożyć więcej wymagań z rejestru produktowego, 4
5 tak, aby nie siedzieć bezczynnie pod koniec przebiegu. Należy jedynie pamiętać o tym, że zarówno jedna jak i druga modyfikacja jest dozwolona tylko pod warunkiem, że końcowy efekt przebiegu będzie zamkniętą, nadającą się do oceny wersją produktu. Wykres spalania również powinien wisieć na honorowym miejscu w pokoju Młyna. Niektórzy nazywają go wręcz sygnaturą zespołu projektowego, ponieważ okazuje się, że już po kilku przebiegach każdy z zespołów wypracowuje sobie typowy styl obciążenia zadaniami, prowadzący do charakterystycznego kształtu wykresu. Jak widać, opisana metoda kontroli postępów bardzo się różni od metod śledzenia harmonogramu w ujęciu klasycznym. Interesująca jest natomiast analogia do wykresów zużycia buforów czasowych, które są podstawą kontroli projektu w metodzie łańcucha krytycznego. Rysunek 2: Przykładowy wykres spalania 5
6 Codzienne spotkanie Obowiązkowym elementem metodyki Scrum jest codzienne spotkanie całego zespołu, na którym każdy wstaje i odpowiada na podstawowe 3 pytania: Co robiłem wczoraj?, Co będę robić dziś? i Co mi przeszkadza w pracy?. Odpowiedź na trzecie pytanie stanowi ewidentne zadanie dla Mistrza Młyna. Dwa pierwsze są równie ważne, ponieważ pozwalają członkom zespołu zorientować się na bieżąco w postępie prac i w indywidualnych problemach każdego z kolegów. Ponadto, odpowiedź na pytanie Co będę robił dzisiaj? nosi cechy publicznej deklaracji wobec pozostałych członków zespołu, co bardzo mobilizuje do dotrzymania słowa na następnym spotkaniu. Zebranie nie służy natomiast do rozwiązywania problemów te omawia się poza kadrem. Wystarcza, że uczestnicy zorientowali się sytuacji i ustalili, kto danym problemem powinien się zająć. Odprawa powinna odbywać się codziennie o tej samej porze (najlepiej rano) i nie zajmować więcej niż 15 minut. Uświęconą tradycją odpraw Młyna jest podział uczestników na Prosiaki i Kurczaki. Prosiaki to ścisły zespół projektowy i tylko on ma prawo głosu. Kurczaki to wszyscy ci, którzy maja ochotę przyjść i posłuchać, ale nie mogą wypowiadać się na jakikolwiek temat. Nawet, jeśli na odprawie zjawi się Prezes Zarządu, to musi zrozumieć, że jest Kurczakiem i nie powinien zakłócać przebiegu spotkania kwadrans wyjęty z pracy zespołu jest zbyt cenny, aby go przeciągać w nieskończoność. Koniec przebiegu Ukoronowaniem przebiegu jest spotkanie przeglądowe, na którym zespół Młyna prezentuje kolejne wydanie swojego produktu. Ponieważ istotą spotkania jest demonstracja działającego systemu, zespół nie powinien poświęcać zbyt wiele czasu na przygotowania do prezentacji (maksimum 2 godziny) bowiem produkt powinien mówić sam za siebie. W spotkaniu przeglądowym uczestniczy rzecz jasna właściciel produktu, a także sponsor, przedstawiciele wyższego kierownictwa, koledzy z innych projektów. Tym razem prawo głosu mają wszyscy, a produkt zostaje poddany wszechstronnej ocenie zewnętrznej. Nie zastępuje to oczywiście standardowych testów i innych procedur kontroli jakości, które powinny były zostać uwzględnione w rejestrze zadań właśnie zakończonego przebiegu. Spotkanie przeglądowe trwa zwykle kilka godzin. W jego trakcie powinno się zmierzać do tego, by rozwiać wszelkie wątpliwości dotyczące najnowszego wydania produktu. Ostatnim punktem spotkania przeglądowego jest ustalenie terminu spotkania planistycznego dla następnego przebiegu. Zawodnicy młyna ponownie zwierają szeregi... 6
7 Zakres stosowalności metodyki W naszej skróconej prezentacji metodyki Scrum zabrakło miejsca dla takich jej elementów, jak analiza ryzyka, skalowalność ( młyn młynów ), czy specyfika zarządzania zespołem projektowym. Warto jednak zastanowić się nad szerszym kontekstem stosowalności tej metodyki. Po pierwsze, Scrum jest metodyką zarządzania projektami, a nie metodą wytwarzania oprogramowania, co odróżnia go w szczególności od XP, również wywodzącego się wprost z filozofii Agile. Każdy przebieg zamyka w sobie pełen cykl rozwoju oprogramowania od planowania, poprzez kodowanie i integrację aż po testowanie a Scrum nie zakłada z góry żadnej konkretnej metody wytwarzania oprogramowania, która będzie leżała pod spodem każdego z przebiegów. Ze względów kulturowych rzeczywiście często wybierane jest programowanie ekstremalne, jednakże niektóre jego cechy stoją wręcz w sprzeczności z zaleceniami Młyna. Przykładowo, w metodyce Scrum przyszły użytkownik jest pytany o zdanie tylko pomiędzy przebiegami, natomiast w XP niemalże śpi on w pokoju programistów. Jako szersza metodyka zarządzania projektami, Scrum znajduje zastosowanie nie tylko w IT, lecz również we wszelkich przedsięwzięciach o słabo zdefiniowanych wymaganiach, takich jak projekty badawczo-rozwojowe, a także usługi medialne (np. projektowanie kampanii reklamowych). Porównując Scrum z klasycznymi metodykami zarządzania projektami, takimi jak chociażby PMI/PMBOK czy PRINCE2, przekonujemy się, że metodyki lekkie wcale nie są mniej precyzyjnie zdefiniowane niż metodyki ciężkie po prostu gdzie indziej leżą ich priorytety. Zamiast koncentrować się na planowaniu i kontroli projektu w ramach potrójnego ograniczenia, czyli zakresu, harmonogramu i budżetu, metodyki takie jak Scrum koncentrują się na dynamicznym definiowaniu zakresu projektu, opartym na serii kolejnych eksperymentów, oraz na udrożnieniu kanałów komunikacyjnych - zarówno pomiędzy odbiorcą i dostawcą, jak i wewnątrz samego zespołu wykonawczego. Na pewno jednak stosowanie metodyk zwinnych nie powinno być zastępczą nazwą na brak stosowania jakiejkolwiek metodyki. Mimo, że wywodzą się one z teorii chaosu (a może właśnie dlatego!), ich stosowanie wymaga od uczestników nawet większej dyscypliny niż w metodach klasycznych. W dziedzinie metodyki Scrum można się zresztą certyfikować zawodowo (Certified Scrum Master), podobnie jak ma to miejsce z certyfikatem PMP czy PRINCE2 Practitioner. Nie można jednak zaprzeczyć, że metodyki lekkie posiadają również swoje ograniczenia. Nie nadają się dla zespołów słabo zintegrowanych oraz rozproszonych geograficznie codzienny bezpośredni kontakt jest jednym z kluczowych czynników sukcesu. Niektórzy twierdzą również, że Scrum nie nadaje się do tworzenia aplikacji o znaczeniu krytycznym. Z tą akurat opinią można polemizować uzyskanie aplikacji o wymaganym poziomie niezawodności może być sprawą leżącej na niższym poziomie technologii wytwarzania oprogramowania. Nikt przecież nie zabrania włączenia do każdego przebiegu Młyna sformalizowanych metod kontroli poprawności programu czy dowolnie zaawansowanych procedur testowych. 7
8 Umowa z klientem Oddzielnym problemem jest przekonanie odbiorcy do wytworzenia zamówionego systemu metodą kolejnych przybliżeń. Zwróćmy uwagę, że harmonogramu oczekiwanego przez większość klientów właściwie nie ma. Projekt prowadzony metodyką Scrum jest planowany każdorazowo w horyzoncie czasowym tylko jednego przebiegu, natomiast liczbę przebiegów ogranicza w zasadzie tylko cierpliwość inwestora. W przypadku projektów programistycznych prowadzonych na zewnętrzne zamówienie można próbować namówić klienta na kontrakt typu time & material zamiast ustalania stałej ceny, a jeśli się nie uda, to można po prostu zaproponować zadaną z góry liczbę przebiegów (czyli pseudo-harmonogram). Innym rozwiązaniem jest przejście z metodyki lekkiej na ciężką po uzyskaniu pierwszej wersji systemu, po której klient jest już w stanie precyzyjnie określić kierunek jej dalszego rozwoju. W przypadku wewnętrznych projektów programistycznych, których celem jest np. opracowanie nowego produktu na rynek masowy, również można ograniczyć całkowity horyzont czasowy prac (co sprowadza się do ograniczenia z góry liczby dopuszczalnych przebiegów), a także zarezerwować sobie prawo do przerwania projektu w przypadku braku zadowalających postępów. Istotne jest również planowanie co pewien czas tzw. przebiegów stabilizujących, których celem jest nie tyle dalsze rozwijanie funkcjonalności aplikacji, co wygładzenie kantów i doprowadzenie produktu do poziomu kolejnej beta-wersji. Przykładem jest rozszerzenie metodyki Scrum stosowane przez Microsoft, określane mianem synchronizuj i stabilizuj (synchronize and stabilize). Nazwa pochodzi stąd, że przebiegi stabilizujące służą zarazem do integracji wyników prac kilku równolegle pracujących zespołów. Drogi Czytelniku, czy ten artykuł przekonał Ciebie do zmierzenia się z Młynem? Scrum, podobnie jak rugby, jest ostrą grą dla dżentelmenów. Kto raz poznał jej smak, już nigdy nie powróci do żmudnego planowania przebiegu rozgrywki, której rezultatu i tak nie da się przewidzieć. Jarosław Milewski pracuje w Instytucie Społecznej Psychologii Informatyki i Komunikacji Wyższej Szkoły Psychologii Społecznej. Posiada tytuł doktora uzyskany w Instytucie Informatyki na Uniwersytecie Warszawskim oraz tytuł MBA Francuskiego Instytutu Zarządzania w Warszawie i certyfikat Project Management Professional (PMP). Członek-założyciel i sekretarz pierwszego zarządu warszawskiego oddziału Project Management Institute (PMI WPC). Praktyczne doświadczenia zdobywał w trakcie pracy w kilku firmach z branży IT. Artykuł ukazał się 1 sierpnia 2005 w COMPUTERWORLD nr
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ółowoZarzą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ółowoScrum. 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ółowoSCRUM 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ółowoPodejś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ółowoJarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming
Jarosław Kuchta Wymagania jakości w Agile Programming Wady klasycznych metod zapewnienia jakości Duży narzut na dokumentowanie Późne uzyskiwanie konkretnych rezultatów Trudność w odpowiednio wczesnym definiowaniu
Bardziej szczegółowoSCRUM. 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ółowoFeature 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ółowoZarządzanie projektami w NGO
Zarządzanie projektami w NGO Warsztaty dla Grupy Nowe Technologie Federacja Organizacji Służebnych MAZOWIA 4 września 2012 Projekt współfinansowany jest ze środków Unii Europejskiej w ramach Europejskiego
Bardziej szczegółowoKILKA SŁÓW O ROLI PRODUCT MANAGERA
CZĘŚĆ I. KILKA SŁÓW O ROLI PRODUCT MANAGERA Product manager pracuje na styku świata IT i biznesu. Analizuje potrzeby użytkowników i klientów, współpracuje ze wszystkimi działami firmy maksymalizując wartość
Bardziej szczegółowoAnaliza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz
Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz Promotor dr inż. Szymon Supernak Warszawa, 22.05.2014 Plan prezentacji 1. Cel i
Bardziej szczegółowoProgramowanie 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ółowoKlasyczna organizacja też może być zwinna! Zarządzaj zwinnie projektami!
Klasyczna organizacja też może być zwinna! Dynamika zmian w dzisiejszym świecie IT wymaga niezwykłej elastyczności i błyskawicznego adaptowania się do nowych warunków. Klasyczne techniki zarządzania projektami
Bardziej szczegółowoSpis 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.
Bardziej szczegółowoGłó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ółowoSYSTEMY 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ółowoLekkie metodyki. tworzenia oprogramowania
Lekkie metodyki tworzenia oprogramowania Programowanie zwinne ( Agile software development) grupa metodyk wytwarzania oprogramowania opartego o programowanie iteracyjne (model przyrostowy). Wymagania oraz
Bardziej szczegółowoTemat: Zwinne Zarządzanie Projektami IT (Agile / Scrum) Data: 06-07 marca 2014 r. (2 dni, czwartek-piątek), godz. 9-16
Temat: Zwinne Zarządzanie Projektami IT (Agile / Scrum) Data: 06-07 marca 2014 r. (2 dni, czwartek-piątek), godz. 9-16 Miejsce: Eureka Technology Park, Innowatorów 8 Cena: 980 zł netto (1 osoba / 2 dni
Bardziej szczegółowoAgile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka
Agile vs PRINCE2 Ewa Solecka - specjalność ogólna- 1117627 Przemysław Mrozowski specjalność ogólna- 1121130 Michał Roztoczyński specjalność ogólna - 1118910 2014/2015 I rok st. magisterskie Informatyka
Bardziej szczegółowoEtapy ż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
Bardziej szczegółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
Bardziej szczegółowoEtapy ż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
Bardziej szczegółowoRAPORT 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ę
Bardziej szczegółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
Bardziej szczegółowoProwadzący: Bartosz Górczyński, CTPartners S.A, itsmf Polska. Miedzeszyn, wrzesień 2010
Jak nie stracić efektów synergii usługi systemów krajowych i globalnych Prowadzący: Bartosz Górczyński, CTPartners S.A, itsmf Polska Miedzeszyn, wrzesień 2010 Bartosz Górczyński Prezes Zarządu CTPartners
Bardziej szczegółowo4. Wprowadzanie Scruma w ImmobilienScout24 4.1. Opis sytuacji
Spis treści Przedmowa 1. Wstęp 1.1. Jak czytać tę książkę 1.2. Studia projektów 1.3. Dodatek 2. Zwinny projekt to nie bułka z masłem 2.1. Pobudka 2.2. Zespół się formuje 2.3. Właściwe zlecenie 2.4. Od
Bardziej szczegółowoWprowadzenie w tematykę zarządzania projektami/przedsięwzięciami
Wprowadzenie w tematykę zarządzania projektami/przedsięwzięciami punkt 2 planu zajęć dr inż. Agata Klaus-Rosińska 1 DEFINICJA PROJEKTU Zbiór działań podejmowanych dla zrealizowania określonego celu i uzyskania
Bardziej szczegółowoZarządzanie projektem wdrożeniowym systemu klasy ERP autorska metodyka
Zarządzanie projektem wdrożeniowym systemu klasy ERP autorska metodyka 1 Plan prezentacji Dlaczego potrzebna jest metodyka wdrożeń systemów ERP? Źródła metodyki Założenia metodyki Cykl życia projektu Kastomizacja
Bardziej szczegółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
Bardziej szczegółowoProgramowanie 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ółowoOpisy 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ółowoTematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, Zofia Kruczkiewicz
Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004 Zofia Kruczkiewicz 1. Przedstaw znaczenie oprogramowania we współczesnym świecie x 1 2. Jaki wpływ na ludzi, komunikację
Bardziej szczegółowoMSF. Microsoft Solution Framework
MSF Microsoft Solution Framework MSF a PMI PMI - metodyka podobna dla każdego rodzaju projektów MSF metodyka przeznaczona dla projektów informatycznych mająca cechy PMI MSF metodyka utworzona na podstawie
Bardziej szczegółowoData: 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
Bardziej szczegółowoOFERTA. Zarządzanie projektami O K R E Ś L E N I E Z A S O B Ó W
OFERTA OFERTA Każdy projekt, realizowany bez profesjonalnego przygotowania i nadzoru, zawsze narażony jest na znaczne opóźnienia a nawet ryzyko całkowitego zatrzymania jego realizacji Podstawowe problemy,
Bardziej szczegółowoKoszty związane z tworzeniem aplikacji on demand versus zakup gotowych rozwiązań
2012 Koszty związane z tworzeniem aplikacji on demand versus zakup gotowych rozwiązań Mateusz Kurleto NEOTERIC Wdrożenie systemu B2B Lublin, 25 października 2012 Mateusz Kurleto Od 2005 r. właściciel NEOTERIC,
Bardziej szczegółowoSzkolenie 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ółowoSzkolenie 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
Bardziej szczegółowoOrganizacja 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
Bardziej szczegółowo( 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
Bardziej szczegółowo... (Nazwa i adres Wykonawcy lub jego pieczęć firmowa, adresowa)
Wykaz osób, skierowanych przez Wykonawcę do realizacji zamówienia publicznego, w szczególności odpowiedzialnych za świadczenie usług, kontrolę jakości lub kierowanie robotami budowlanymi, wraz z informacjami
Bardziej szczegółowoKomputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście. Rozdział pochodzi z książki:
Rozdział pochodzi z książki: Zarządzanie projektami badawczo-rozwojowymi. Tytuł rozdziału 6: Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście adaptacyjne
Bardziej szczegółowoZARZĄDZANIE PROJEKTAMI. Tomasz Janka KFDZOM Kołobrzeg, 21 września 2017
ZARZĄDZANIE PROJEKTAMI Tomasz Janka KFDZOM Kołobrzeg, 21 września 2017 A CO JA Z TEGO BĘDĘ MIAŁ? Oszczędność pieniędzy Zwiększenie wydajności Szybsze wdrożenie Skrócenie procesu decyzyjnego Osiągnięcie
Bardziej szczegółowoSTUDIA PODYPLOMOWE ZARZĄDZANIE PROJEKTAMI INFORMATYCZNYMI
Zeszyty Naukowe Wydziału Informatycznych Technik Zarządzania Wyższej Szkoły Informatyki Stosowanej i Zarządzania Współczesne Problemy Zarządzania Nr 1/2011 STUDIA PODYPLOMOWE ZARZĄDZANIE PROJEKTAMI INFORMATYCZNYMI
Bardziej szczegółowoMetodyki 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
Bardziej szczegółowoCzęść I - Załącznik nr 7 do SIWZ. Warszawa. 2011r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA
CSIOZ-WZP.65.48.20 Część I - Załącznik nr 7 do SIWZ Warszawa. 20r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA Wykonawca oświadcza, że do realizacji zamówienia
Bardziej szczegółowoWprowadzenie w tematykę zarządzania przedsięwzięciami/projektami. dr inż. Agata Klaus-Rosińska
Wprowadzenie w tematykę zarządzania przedsięwzięciami/projektami dr inż. Agata Klaus-Rosińska 1 DEFINICJA PROJEKTU Zbiór działań podejmowanych dla zrealizowania określonego celu i uzyskania konkretnego,
Bardziej szczegółowoMetody wytwarzania oprogramowania. Metody wytwarzania oprogramowania 1/31
Metody wytwarzania oprogramowania Metody wytwarzania oprogramowania 1/31 Metody wytwarzania oprogramowania 2/31 Wprowadzenie Syndrom LOOP Late Późno Over budget Przekroczono budżet Overtime nadgodziny
Bardziej szczegółowoMarta 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ółowoPRINCE Foundation
PRINCE2 2009 Foundation Istota PRINCE2 Metodyka PRINCE2 stanowi doskonałą podstawę do realizacji wszelkich projektów w przedsiębiorstwach i organizacjach dowolnej wielkości i branży. Pozwala w zorganizowany
Bardziej szczegółowoAgile Project Management
Charles G. Cobb, pmp Zrozumieć Agile Project Management Równowaga kontroli i elastyczności przekład: Witold Sikorski APN Promise Warszawa 2012 Spis treści Wstęp...vii Kto powinien przeczytać tę książkę?...
Bardziej szczegółowoZarządzanie i realizacja projektów systemu Microsoft SharePoint 2010
Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................
Bardziej szczegółowoZARZĄDZANIA PROJEKTAMI W KOMUNIKACJI
( SZKOŁA ZARZĄDZANIA PROJEKTAMI W KOMUNIKACJI Stworzyliśmy unikatową okazję do przekazania praktycznej wiedzy i doświadczeń osób, które odpowiadają za wielkie i małe projekty marketingowe, z sukcesem stosując
Bardziej szczegółowoInne spojrzenie na wytwarzanie SI ZWINNE METODOLOGIE.
Inne spojrzenie na wytwarzanie SI ZWINNE METODOLOGIE. Maciej Socha Instytut Elektroniki i Technik Informacyjnych Politechnika Warszawska msocha@stud.elka.pw.edu.pl Streszczenie: Klasyczne metody wytwarzania
Bardziej szczegółowoPRINCE2 czy PMI? Czyli o wyŝszości Świąt Wielkanocnych, nad Świętami BoŜego Narodzenia 11 maja 2010. Autor: Jolanta Łabędzka-Benisz. www.omec.
PRINCE2 czy PMI? Czyli o wyŝszości Świąt Wielkanocnych, nad Świętami BoŜego Narodzenia 11 maja 2010 Autor: Jolanta Łabędzka-Benisz www.omec.pl W A R S Z A W A R Z E S Z Ó W W R O C Ł A W 1 Agenda Wstęp
Bardziej szczegółowoPraktyka testowania dla początkujących testerów
Praktyka testowania dla początkujących testerów Warsztaty stanowią 100% praktykę testowania i skupiają się zwłaszcza na tych aspektach, które przydatne są w codziennej pracy testera. Przeznaczone są dla
Bardziej szczegółowoPiotr Ślęzak. Gdzie się podziała jakość
Piotr Ślęzak Gdzie się podziała jakość Działamy na styku Biznesu i IT Analiza biznesowa Kontrola jakości Doradztwo Projekty Szkolenia ForProgress spółka z ograniczoną odpowiedzialnością sp.k. kontakt@forprogress.com.pl
Bardziej szczegółowoSystemy Open Source w zarządzaniu projektami, na przykładzie Redmine i OpenProject. Rafał Ciszyński
IT can be done! Systemy Open Source w zarządzaniu projektami, na przykładzie Redmine i OpenProject Rafał Ciszyński Agenda Wstęp Krótki opis funkcjonalności dwóch rozwiązań: Redmine i OpenProject Prezentacja
Bardziej szczegółowoModel 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ółowoJak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia. Click Piotr Kałuski to edit Master subtitle style
Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia Click Piotr Kałuski to edit Master subtitle style Punkty widzenia Zespół Testów Manager Projektu Użytkownik końcowy Zespół Testów
Bardziej szczegółowoWskazó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ółowoScrum 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ółowoProgramowanie 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
Bardziej szczegółowoProgramowanie 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ółowokompetencji 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ółowo1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem.
1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem. 2/ Wykonawcy: Konsorcjum: Netline Group wraz z Premium Technology
Bardziej szczegółowoSZKOLENIE. Jak zarządzać projektem z wykorzystaniem MS Project. tel: ; fax: ;
SZKOLENIE Jak zarządzać projektem z wykorzystaniem MS Project tel: +48 22 100-48-96; fax: +48 22 300-52-79; e-mail: biuro@akademiaasap.pl TRENERZY DORADCY TRENERZY i KONSULTANCI NASZA MISJA DOSTARCZENIE
Bardziej szczegółowoJak uchronić architekturę i wymagania przed chaosem? Warszawa, 27 stycznia 2016 roku
Jak uchronić architekturę i wymagania przed chaosem? Warszawa, 27 stycznia 2016 roku Agenda Metafory o Zwinności i Sztywności Teza: Oszukujemy się co do sukcesów projektów Agile Objawy chaosu w projektach
Bardziej szczegółowoKoordynacja projektów inwestycyjnych
Koordynacja projektów inwestycyjnych OLSZTYN 2015 OPIS PRODUKTU Koordynacja projektu inwestycyjnego jest produktem skierowanym do przedsiębiorstw pragnących stworzyć nowe produkty lub procesy w ramach
Bardziej szczegółowoe 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ółowoAnalityk i współczesna analiza
Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura
Bardziej szczegółowoMiędzynarodowa Rada Inżynierii Wymagań. The International Requirements Engineering Board (IREB e.v.) Szkolenia IREB w CTS.
Międzynarodowa Rada Inżynierii Wymagań The International Requirements Engineering Board (IREB e.v.) Szkolenia IREB w CTS www.cts.com.pl MISJA IREB Misją IREB jest udoskonalenie praktyki inżynierii wymagań
Bardziej szczegółowoUmowy w branży IT. Jak je konstuować, żeby uniknąć późniejszych nieporozumień. Tomasz Wiese Łukasz Marszał
Umowy w branży IT Jak je konstuować, żeby uniknąć późniejszych nieporozumień Tomasz Wiese Łukasz Marszał Cel prezentacji Pokazanie różnic pomiędzy zakupem oprogramowania w pudełku a stworzeniu go na zamówienie
Bardziej szczegółowoAcceptance 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ółowoZarządzanie Projektami IT. - Nowoczesny Project Manager Nowość
Zarządzanie Projektami IT - Nowoczesny Project Manager Nowość Unikalność studiów Zarządzanie Projektami IT polega nie tylko na zgodności programu standardem PMI ale również na kompleksowym ujęciu problematyki
Bardziej szczegółowoPodejś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ółowoPodstawy Zarządzania Projektami w Organizacjach
Podstawy Zarządzania Projektami w Organizacjach JAK DOBRZE ROZPOCZĄĆ PROJEKT 2010-05-14 Krzysztof Kamiński Przemysław Kotecki AGENDA Wprowadzenie do Zarządzania Projektami Rola rozpoczynania projektów
Bardziej szczegółowoPlanowanie 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ółowoSzkoła Project Managerów Kurs przygotowujący do certyfikacji IPMA na poziomie D 176 godzin
Szkoła Project Managerów Kurs przygotowujący do certyfikacji IPMA na poziomie D 176 godzin Cel zajęć: Celem szkolenia jest przygotowanie uczestników do pełnienia funkcji kierownika zespołu/ project managera
Bardziej szczegółowoTechniki komputerowe w robotyce
Techniki komputerowe w robotyce Wykład V Adaptacyjne zarządzanie projektami Robert Muszyński KCiR, W4, PWr Skład FoilTEX c R. Muszyński 2009-2015 Metodologie prowadzenia projektu Dążenie do opracowania
Bardziej szczegółowoScaling 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ółowoZarządzanie budowlanym projektem inwestycyjnym dla inwestycji publicznych i komercyjnych
I miejsce w rankingu firm szkoleniowych wg. Gazety Finansowej 5 6 lipca 2018r., Warszawa Centrum Zarządzanie budowlanym projektem inwestycyjnym Możliwe warianty inwestycji dla inwestorów Zarządzanie ryzykiem
Bardziej szczegółowoLokalizacja Oprogramowania
mgr inż. Anton Smoliński anton.smolinski@zut.edu.pl Lokalizacja Oprogramowania 18/11/2016 Wykład 4 Zarządzanie projektem lokalizacyjnym Agenda Projekty lokalizacyjne Metodyki zarządzania projektami Zadania
Bardziej szczegółowoZarządzanie projektów
Zarządzanie projektów Część 3 Etapy projektów Rozpoczęcie projektu Planowanie projektu Współpraca z zarządem Tworzenie budżetu Organizacja zespołu projektowego Tworzenie planu projektu Optymalizacja projektu
Bardziej szczegółowoMS Project 2010 w harmonogramowaniu - planowanie zadań, działań, operacji i przedsięwzięć
MS Project 2010 w harmonogramowaniu - planowanie zadań, działań, operacji i przedsięwzięć Opis Czy narzędzia informatyczne są trudne w opanowaniu? My uważamy, że nie - sądzimy, że opanowanie ich obsługi
Bardziej szczegółowo( 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
Bardziej szczegółowoDlaczego warto zarządzać projektem informatycznym
Dlaczego warto zarządzać projektem informatycznym Każdy realizuje projekty Jakkolwiek je nazwiemy: - złożoną sytuacją, - skomplikowanym zadaniem, - zaplanowaną zmianą, - skoordynowanym działaniem Każdy
Bardziej szczegółowoSZKOŁ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, zarówno w agencjach, jak w działach marketingu przedsiębiorstw.
Bardziej szczegółowoProjekty IT w praktyce biznesowej
Projekty IT w praktyce biznesowej Wojciech Murzyn wojciech@murzyn.pl (501) 217 547 1 Korzyści z inwestycji w IT 10% szefów firm uważa, że inwestycje w IT przyniosły planowane, duże korzyści 10% 47% 43%
Bardziej szczegółowoZarzą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ółowoPriorytetyzacja przypadków testowych za pomocą macierzy
Priorytetyzacja przypadków testowych za pomocą macierzy W niniejszym artykule przedstawiony został problem przyporządkowania priorytetów do przypadków testowych przed rozpoczęciem testów oprogramowania.
Bardziej szczegółowoZarządzanie projektem prawnym w praktyce
Zarządzanie projektem prawnym w praktyce Program 2 dniowy Po raz pierwszy kompleksowe szkolenie dla prawników Definiowanie, planowanie i skuteczna realizacja w pracy prawnika Terminy: Wrocław, 6-7 grudnia
Bardziej szczegółowoLeszno 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ółowoInnowacje w IT czyli dlaczego to takie trudne? Jakub Dąbkowski
2011 Innowacje w IT czyli dlaczego to takie trudne? Jakub Dąbkowski Projekt Projekt - to zbiór aktywności charakteryzujący się następującymi cechami: są ze sobą powiązane w złożony sposób, zmierzają do
Bardziej szczegółowoDYPLOM POST-MBA: STRATEGICZNE ZARZĄDZANIE PROJEKTAMI
DYPLOM POST-MBA: STRATEGICZNE ZARZĄDZANIE PROJEKTAMI TERMIN od: TERMIN do: CZAS TRWANIA:12 dni MIEJSCE: CENA: 7600 zł netto Tempo i złożoność funkcjonowania organizacji sprawia, że udana realizacja firmowych
Bardziej szczegółowoSTUDIA PODYPLOMOWE Zarządzanie Projektami
STUDIA PODYPLOMOWE Zarządzanie Projektami (Program studiów) Opracowanie: dr inż. Jacek Jakieła Program studiów Zarządzanie projektami 2 CEL STUDIÓW, ADRESAT I PROFIL ABSOLWENTA Studia podyplomowe Zarządzanie
Bardziej szczegółowoBudowa systemu wspomagającego podejmowanie decyzji. Metodyka projektowo wdrożeniowa
Budowa systemu wspomagającego podejmowanie decyzji Metodyka projektowo wdrożeniowa Agenda Systemy wspomagające decyzje Business Intelligence (BI) Rodzaje systemów BI Korzyści z wdrożeń BI Zagrożenia dla
Bardziej szczegółowoSzukanie rozwiązań funkcji uwikłanych (równań nieliniowych)
Szukanie rozwiązań funkcji uwikłanych (równań nieliniowych) Funkcja uwikłana (równanie nieliniowe) jest to funkcja, która nie jest przedstawiona jawnym przepisem, wzorem wyrażającym zależność wartości
Bardziej szczegółowo