Scrum i Kanban. Analiza lekkich metod wytwarzania oprogramowania. Kamil Dowlaszewicz

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

Download "Scrum i Kanban. Analiza lekkich metod wytwarzania oprogramowania. Kamil Dowlaszewicz"

Transkrypt

1 Scrum i Kanban. Analiza lekkich metod wytwarzania oprogramowania Kamil Dowlaszewicz

2 SPIS TREŚCI Spis treści... 2 Wstęp... 5 Inspiracja metod... 5 Zarys metod... 5 Scrum... 6 Kanban... 7 Podsumowanie... 8 Perspektywa: Wdrożenie Koncepcji... 9 Scrum... 9 Kanban... 9 Podsumowanie Perspektywa: Podział pracy i ograniczenie pracy w toku Scrum Podział pracy Praca w toku Kanban Podział pracy Praca w toku Podsumowanie Perspektywa: Sposób pracy Scrum praca iteracyjna Rytm Skupienie na celu Gwarancja realizacji aktywności Gwarancja częstego odbioru pracy Zaangażowanie członków zespołu w aktywności Poziom wykorzystania możliwości zespołu

3 Czas nie w pełni wykorzystany w szerszej perspektywie Efekt ściśle określonego zakresu pracy i czasu pracy Kanban praca ciągła Asynchroniczność Czas odpowiedzi na zmiany Praca ad-hoc Możliwość pełnego wykorzystania specjalistów Pełne wykorzystanie możliwości zespołu Utrzymanie wydajności zespołu w dalszej perspektywie Efekt braku ograniczenia czasowego, konkretnego celu i skupienia na specjalizacji Podsumowanie Perspektywa: Definicja gotowości Scrum Kanban Podsumowanie Perspektywa: Definicja ukończenia Scrum Kanban Podsumowanie Perspektywa: Estymacja, planowanie i metryki Scrum Zarządzanie zadaniami Estymacja Planowanie sprintu Monitorowanie postępu w ramach sprintu Planowanie długoterminowe Długoterminowe monitorowanie postępu Kanban Zarządzanie zadaniami Estymacja Monitorowanie postępu

4 Planowanie Podsumowanie Perspektywa: Adaptacja i organizacja pracy Scrum Adaptacja produktu i czas odpowiedzi na zmianę Organizacja pracy i rozwiązywanie problemów Adaptacja sposobu pracy mająca na celu jego doskonalenie Kanban Adaptacja produktu i czas odpowiedzi na zmianę Organizacja pracy i rozwiązywanie problemów Adaptacja procesu Podsumowanie Obserwacje Zespół a proces Subiektywność danych wejściowych adaptacji Zróżnicowanie charakteru zadań Czas odpowiedzi systemu i zadania krytyczne Poziom regulowania sposobu wytwarzania produktu i organizacji pracy Podsumowanie Bibliografia

5 WSTĘP Wytwarzanie oprogramowania w oparciu o koncepcje Agile Software Development i Lean Software Development cieszy się na przestrzeni ostatnich lat rosnącą popularnością. Są one wynikiem poszukiwań efektywnych sposobów wytwarzania i rozwoju systemów informatycznych, które zostały podjęte ze względu na problemy, z którymi spotykano się stosując podejścia klasyczne. Szczególnie silnie na poszukiwanie nowych metod wpłynęło rosnące tempo zmian zachodzących w środowisku biznesowym oraz charakterystyka innowacyjnych projektów. Nowe metody charakteryzują się odmiennym spojrzeniem na proces wytwarzania oprogramowania i są aktualnie alternatywą dla klasycznych metod wytwarzania oprogramowania. Do najpopularniejszych lekkich technik wykorzystywanych w celu organizacji i wspomagania procesu wytwarzania oprogramowania należą Scrum i Kanban. Stopień podobieństwa i zależności pomiędzy tymi metodami rozumiany jest jednak różnie. Postrzegane bywają, jako dwie delikatnie tylko różniące się odmiany lekkiej koncepcji wytwarzania oprogramowania, jako kolejne kroki kierujące do celu, jakim jest zwiększanie efektywności i zwinności procesu wytwarzania oprogramowania, jako osobne koncepcje pozwalające efektywnie organizować różniące się zadania, lub nawet, jako będące względem siebie w całkowitej opozycji spojrzenia na zagadnienie organizacji pracy. Problemy w rozumieniu różnic pomiędzy Scrum i Kanban spowodowane mogą być między innymi przenikaniem się środowisk stosujących i promujących te koncepcje, charakterystycznym słownictwem i terminami wykorzystywanymi do ich opisu, pewną liczbą analogicznych założeń i terminów wykorzystywanych w obu przypadkach, możliwością wykorzystywania ich w różnych domenach, oraz wreszcie czynnikami społecznymi takimi jak trendy. Praca ta jest próbą obiektywnego spojrzenia na obie koncepcje, oraz w miarę możliwości nie emocjonalnego rozważenia podobieństw i różnic, jakie je w rzeczywistości cechują. INSPIRACJA METOD Zarówno Scrum jak i Kanban oparte są o strategię dostarczania produktu w oparciu o rzeczywiste zapotrzebowanie (ang. pull strategy). Koncepcje te charakteryzują się także w pewnym stopniu pobieraniem nowych zadań tylko wtedy, gdy nie spowoduje to przeładowania opartego o nie systemu, a więc dopiero, gdy istnieje możliwość faktycznego rozpoczęcia pracy. Ze względu na aspiracje obu metod dotyczące umożliwienia efektywnej pracy w szybko zmieniającym się środowisku skupiają się one w mniejszym lub większym stopniu na prostocie, przejrzystości, częstym dostarczaniu małych elementów produktu, oraz adaptacji do zmieniających się warunków i wymagań. Pozwala to dokonywać częstych i szybkich zmian zarówno w wytwarzanym produkcie jak i wykorzystywanym w tym celu procesie. ZARYS METOD Dokonanie sensownej analizy podobieństw i różnic pomiędzy Scrum i Kanban oraz próba wyciągania na tej podstawie wniosków wymaga określenia poziomu zależności pomiędzy problemami, które starają się rozwiązać. Pomocne jest także określenie poziomu 5

6 szczegółowości, jaki zapewniają w konkretnych dziedzinach. Daje to możliwość określenia tego, co w zasadzie poddane jest porównaniu i wybór odpowiednich perspektyw, które będą w tym celu wykorzystywane. Inaczej realizowane będzie porównanie łyżki z widelcem w kontekście spożywania pokarmu, łyżki z widelcem w kontekście wybierania wody z tonącej łodzi, oraz łyżki ze scyzorykiem szwajcarskim w kontekście naprawy szafki. SCRUM Scrum definiowany jest jako iteracyjna metodyka, lub z angielskiego framework, prowadzenia projektów zgodnie z zasadami Agile Software Development których podstawą jest opublikowany w 2001 roku manifest zwinnego wytwarzania oprogramowania (ang. Agile Manifesto). Scrum skupia się mocno na dostarczanym produkcie, bliskiej kooperacji z klientem biznesowym i zespole, który odpowiada za dostarczenie tego produktu. Organizuje on pracę za pomocą powtarzających się w równych odstępach czasu, ograniczonych czasowo iteracji zwanych sprintami. Praca w trakcie sprintów wykonywana jest przez zespół złożony z osób dysponujących wszystkimi potrzebnymi do dostarczenia produktu umiejętnościami, a więc mogący składać się z osób o różnych specjalnościach. Zespół ten w każdym sprincie odpowiedzialny jest za dostarczenie części produktu, do której dostarczenia zobowiązał się przed jego rozpoczęciem. Realizacja celu sprintu nie jest w żaden sposób regulowana, dzięki czemu zespół pracuje w warunkach sprzyjających samoorganizacji. Co więcej cel sprintu nie powinien ulegać zmianie w trakcie jego trwania. Po zakończeniu sprintu stworzony produkt przedstawiany jest przez zespół klientowi biznesowemu, a zespół dokonuje retrospekcji dotyczącej sprintu i sposobu pracy. Sposób realizacji powyższego scenariusza określony jest bardziej szczegółowo w formie zasad Scrum, których podstawowym zbiorem jest Scrum Guide. Określa on dodatkowo role zespołu Scrum, o różnych odpowiedzialnościach, spotkania poświęcone odpowiednim zagadnieniom, oraz opis i sposób wykorzystywania artefaktów związanych z metodyką. Role definiowane przez Scrum to Scrum Master, Product Owner i zespół. Scrum Master odpowiedzialny jest za to, aby przestrzegane były zasady Agile Software Development i praca wykonywana była zgodnie z nimi. Organizuje on także aktywności i pomaga w usuwaniu problemów. Product Owner stanowi dla zespołu jedno spójne źródło informacji na temat wymagań i priorytetów związanych z wytwarzaniem produktu. Pozostali członkowie zespołu Scrum odpowiedzialni są za takie zorganizowanie się w trakcie sprintu, aby zatwierdzona przez nich praca, wciągnięta do iteracji, została w pełni wykonana. Scrum określa też spotkania, które powinny się odbywać w trakcie każdej iteracji. Są to, zgodnie z kolejnością, planowanie zakresu sprintu, planowanie sposobu realizacji pracy, przedstawienie wykonanej pracy, oraz retrospekcja. Co więcej każdego dnia zespół zobowiązany jest odbyć krótkie spotkanie kontrolne poświęcone problemom i synchronizacji. Wszystkie aktywności definiowane przez Scrum począwszy od Sprintu do codziennego spotkania posiadają maksymalny czas trwania, który nie powinien być przekraczany. Sprint powinien trwać maksymalnie 4 tygodnie, planowanie 8 godzin, prezentacja i retrospekcja 8 godzin, a spotkanie codzienne 15 minut. 6

7 Scrum określa sposób zarządzania zadaniami, a w przypadku projektów informatycznych, wymaganiami. Przewidywane jest użycie rejestru produktu, który zorganizowany jest w postaci listy priorytetowej, w której elementy o najwyższym priorytecie są wyestymowane przez zespół i przygotowane do wciągnięcia do iteracji. Powyższy zarys obrazuje liczbę ograniczeń i zasad wprowadzanych przez Scrum. W rzeczywistych implementacjach zasady te wzbogacane są o dalsze praktyk i reguły. Istnieją, na przykład, zalecenia dotyczące sposobu przedstawiania informacji na temat zaawansowania prac w ramach sprintu, wydania a nawet projektu. Dotyczą one wykorzystania sprawdzonego w praktyce rozwiązania, jakim są wykresy spalania, obrazujące ilość pracy, jaka pozostaje do wykonania względem kolejnych dni sprintu, lub kolejnych sprintów w wydaniu. Wprowadza się także specyficzne mechanizmy estymacji, praktyki techniczne, reguły dotyczące zadań i wykonanej pracy, czy zasady precyzujące sposobu realizacji pracy w trakcie sprintu. KANBAN Przedstawienie definicji Kanban nie jest tak proste jak w przypadku Scrum. Problem z przedstawieniem jednej definicji oparty jest o to, że termin kanban nie jest aktualnie jednoznaczny. Słowo kanban pochodzi z języka japońskiego i oznacza tablicę sygnałową. Związane jest ono z koncepcją produkcji opracowaną w latach pięćdziesiątych w zakładach firmy Toyota, opartą o wytwarzanie produktu w sposób sterowany zapotrzebowaniem. W celu realizacji tej koncepcji wykorzystywane są tak zwane karty kanban, które umożliwiają przekazanie informacji o zapotrzebowaniu z węzłów znajdujących się niżej w łańcuchu produkcyjnym do węzłów znajdujących się wyżej. Termin kanban lub system kanban wykorzystywany jest także jako nazwa systemu produkcji opartego o tę koncepcję i wykorzystującego w tym celu karty kanban. Systemy produkcji oparte o koncepcje wywodzące się z pomysłu firmy Toyota (ang. Toyota Production System) i kładące nacisk na efektywność zyskiwały na przestrzeni lat rosnącą popularność. W latach dziewięćdziesiątych koncepcje te stały się znane pod nazwami odchudzonego wytwarzania (ang. Lean Manufacturing) i odchudzonej produkcji (ang. Lean Production). Kolejną fazą było adaptowanie tych podejść do domeny wytwarzania oprogramowania i tym samym określenie koncepcji odchudzonego wytwarzania oprogramowania (ang. Lean Software Development). Termin ten został rozpropagowany przez Mary i Toma Poppendieck, którzy opublikowali książkę o tej samej nazwie. Analiza i adaptacja koncepcji odchudzonej produkcji do domeny systemów informatycznych wpłynęła naturalnie na zaadoptowanie systemu kanban. Prekursorem i jedną z osób, które wpłynęły na popularyzację tej koncepcji jest David J. Anderson, który dalej precyzuje definicję Kanban jako opartą o system kanban metodę stopniowej optymalizacji procesu. Jako metodę Kanban (ang. Kanban Method) definiuje on z kolei zaawansowany system adaptacyjny, który cechuje się wizualizacją procesu, ograniczeniem pracy w toku, pomiarem i zarządzaniem przepływem pracy, określonymi regułami postępowania i wykorzystaniem modeli wprowadzania zmian w procesie jako narzędzia optymalizacji. David J. Anderson w swojej książce o Kanban wspomina o modelach opartych o analizę wąskich gardeł, analizę zmienności, oraz analizę ilości pracy nieprowadzącej do uzyskania wartości biznesowej. 7

8 W środowisku IT termin Kanban rozumiany jest najczęściej zgodnie z ostatnią przytoczoną definicją, a więc odpowiada stworzonej przez Andersona koncepcji metody Kanban. Wydaje się, że jest to też koncepcja najdokładniej zdefiniowana i określająca wszystkie zasadnicze reguły pozwalające na jej praktyczne wykorzystanie. Na potrzeby tej pracy Kanban rozumiany będzie właśnie w ten sposób. Zgodnie z przyjętym rozumieniem, Kanban wykorzystuje narzędzie wizualizacji procesu i określonych explicite reguł w celu adaptacji i optymalizacji procesu mającą na celu zwiększenie efektywności pracy. Najczęściej wiąże się on także z wykorzystaniem limitów dotyczących ilości pracy wykonywanej w kolejnych krokach procesu, ale teoretycznie nie zawsze jest to wymagane. Oczywiście podobnie jak w przypadku metody Scrum w rzeczywistości podczas wykorzystywania Kanban stosowane są także liczne inne rozwiązania zwiększające liczbę ograniczeń i zasad. Różnice pomiędzy implementacjami Kanban mogą być ogromne, gdyż określa on minimalną liczbę warunków początkowych. Jeden proces Kanban może opierać się na podziale procesu na analizę, pracę w toku i pracę wykonaną przy określeniu limitu ilości wykonywanej pracy jedynie dla stanu praca w toku, podczas gdy inny proces może bardzo szczegółowo odzwierciedlać cały proces biznesowy przedsiębiorstwa posiadając empirycznie i szczegółowo wyznaczane limity, klasy zadań, korzystać z technik prognozowania, oraz metryk a jego działanie może być opisane kontraktami określającymi sposób świadczenia usług. PODSUMOWANIE Scrum i Kanban są koncepcjami skupionymi w mniejszym lub większym stopniu na wspomaganiu procesu wytwarzania produktu, poprzez zapewnienie określonej organizacji sposobu pracy lub samego procesu jej wykonywania, oraz powiązanych z tym zagadnieniach. Zaznaczyć też trzeba, iż, pomimo, że opracowywane były z myślą o systemach informatycznych, to ich zastosowanie nie jest ograniczone jedynie do tej domeny. Scrum określa większą liczbę warunków początkowych związanych z jego wykorzystaniem, podczas gdy Kanban, nawet przyjmując definicję opartą o metodę Kanban narzuca znacznie mniej wstępnych ograniczeń. Scrum jest stosunkowo szczegółową receptą dotyczącą organizacji i prowadzenia projektów IT, podczas gdy Kanban jest metodą pozwalającą w odpowiednim środowisku taką receptę zdefiniować. Różnice pomiędzy tym, czym są Scrum i Kanban, oraz fakt, iż wzbogacane są one w najróżniejszy sposób innymi koncepcjami powoduje, iż nawet po doprecyzowaniu tych bytów, ich porównanie wiąże się raczej z zestawieniem permutacji koncepcji z permutacją koncepcji. Z tego względu w kolejnych rozdziałach Scrum i Kanban porównywane będą w oparciu o jedną, konkretną, perspektywę. 8

9 PERSPEKTYWA: WDROŻENIE KONCEPCJI SCRUM Wdrożenie Scrum w zależności od środowiska może wymagać niewielkiego nakładu pracy, lub znacznego wysiłku i zmian obejmujących bardzo szeroki zakres działalności przedsiębiorstwa. Ich liczba i zakres zależy od sposobu, w jaki praca wykonywana była wcześniej. W przypadku, gdy wytwarzanie produktu nie jest objęte szczegółowymi regułami możliwe może być przyjęcie Scrum oddolnie bez konieczności dokonywania większych zmian. W przypadku procesów ściśle zdefiniowanych i organizacji operujących w oparciu o skodyfikowane ramy postępowania konieczne bywa natomiast określenie całego planu zmiany procesu i sposobu zarządzania tą zmianą. W obu przypadkach pomocne będzie także poznanie i zrozumienie koncepcji Agile Software Development. Może to wymagać udziału zespołów produkcyjnych i kierownictwa w szkoleniach dotyczących tej koncepcji, lub ściągnięcie do firmy osób już biegłych w tej tematyce. Liczba i zakres koniecznych zmian, a także różnica w sposobie zarządzania zespołem, oraz ogólnie koncepcji pracy może powodować, iż ich realizacja w niektórych organizacjach spotykać się może ze znacznym oporem. Jego źródłem może być inercja samej organizacji, jak i dążenia pojedynczych jej członków. Z drugiej strony, jeśli już uda się zmian tych dokonać należycie, to konstrukcja Scrum, będąca dość szczegółową receptą zapewnia możliwość wykorzystania charakterystyki Agile Software Development. Wpłynąć to może na efektywny rozwój wytwarzanych produktów, zapewniając możliwość wprowadzania zmian i czerpania korzyści z wytworzonej pracy tak szybko jak jest to możliwe. Podsumowując, w celu skorzystania z właściwości Scrum konieczne może być wykonanie pewnej rewolucji. Uzyskanie tego stanu pozwala jednak nawet zespołom niedoświadczonym w Agile Software Development, uczących się dopiero samoorganizacji, uzyskiwać niezłe rezultaty w stosunkowo krótkim czasie. Wynika to z tego, iż Scrum oparty jest o sprawdzoną heurystykę wytwarzania oprogramowania zgodną z Agile Software Development. KANBAN Kanban, ze względu na minimalizm wymaganych warunków początkowych, pozwala na zamodelowanie istniejącego procesu, pozostanie przy zdefiniowanych w organizacji rolach i jego stopniową empiryczną adaptację opartą o obserwację. Cecha ta powodować może, iż jego przyjęcie w organizacjach bardziej konserwatywnych lub skupionych na specjalizacji pracowników, będzie znacznie łatwiejsze niż w przypadku Scrum. Co więcej, adaptacja procesu w Kanban oparta jest o obserwowane problemy specyficzne dla każdego przypadku. Dzięki temu zmiana i jej przyczyna może być rozumiana bez konieczności jakichkolwiek szkoleń i wspierana przez tych, których bezpośrednio dotyka, lub wprowadzana właśnie przez te osoby. Przy założeniu braku konfliktu interesów wewnątrz przedsiębiorstwa związanych z tą zmianą przekłada się to na zmniejszenie oporu względem wprowadzanych zmian. Z powodu wystąpienia wspomnianego konfliktu opór taki jest jednak zawsze możliwy. 9

10 Niestety niewielka liczba warunków i wymaganych zmian związanych z wykorzystaniem Kanban, może wpłynąć na niezrozumienie celu Kanban, jakim jest między innymi sterowanie i wspieranie zmian. Może to skutkować brakiem możliwości ich dokonywania w wyniku czego proces i organizacja może pozostać w punkcie wyjścia. Podobnie w przypadku, gdy koncepcja Kanban zostanie zrozumiana i zaakceptowana jedynie przez część organizacji, możliwe jest, iż zgłaszane propozycje odbierane będą jako problemy wynikające z zastosowania Kanban a nie jedynie wizualizowane przez to narzędzie. Kanban można wprowadzić wprowadzając pewną liczbę zmian od razu jak i poprzez stopniową ewolucję. W obu przypadkach wymagać to może dogłębnego rozumienia celu, do którego się zmierza, oraz szerokiej akceptacji dążenia do tego celu poprzez wprowadzanie rozmaitych zmian, a więc dojrzałości pewnej, najczęściej szerokiej, części organizacji. Kanban, ze względu na praktyczny brak narzucanych z góry ograniczeń, charakteryzuje się ogromną liczbą możliwości dostrajania, co wpływa także na skomplikowanie jego efektywnego wykorzystania. Podjęcie decyzji, od czego zacząć i co jest istotne w wielu przypadkach może być trudne i ze względu na możliwy brak szybkich efektów, widocznych zaraz po rozpoczęciu korzystania z Kanban, zaowocować porzuceniem tej koncepcji. Pod tym względem Scrum wydaje się być łatwiejszy we wdrożeniu. PODSUMOWANIE Perspektywa: Wdrożenie Koncepcji Scrum Kanban Przepis na ogólne ramy organizacji pracy oparte o heurystykę. Przepis na analizowanie i zmianę organizacji pracy. Wstępne ograniczenia narzucane przez Ograniczenia dobierane w trakcie korzystania z metodę. metody. Możliwośd uzyskiwania szybkich rezultatów zależy Możliwośd uzyskiwania szybkich rezultatów, od wykorzystania. Liczba decyzji, które trzeba przy ograniczonej liczbie decyzji, które trzeba podejmowad i opartych o nie działao może byd podjąd. ogromna. Dużo zmian wykonuje się już w trakcie wdrażania metody, następnie w trakcie korzystania z metody realizowana jest optymalizacja procesu. Średni zakres możliwości dostosowywania do środowiska pracy. Proces wdrażania może byd długotrwały. Wdrożenie metody wymaga minimalnej liczby zmian. Większośd modyfikacji ma miejsce w trakcie korzystania z metody. Szeroki zakres możliwości dostosowywania do środowiska pracy. Rozpoczęcie korzystania z Kanban nie wymaga długiego okresu czasu. PERSPEKTYWA: PODZIAŁ PRACY I OGRANICZENIE PRACY W TOKU Podział pracy na mniejsze części jest jedną z metod pozwalających uprościć wykonanie całości pracy. Dokonanie umiejętnego podziału umożliwia realizację zadań o mniejszym stopniu skomplikowania i skupionych na konkretnym zagadnieniu, których realizacja posiada nadal wartość dla klienta biznesowego. 10

11 Dostarczanie pracy w postaci mniejszych elementów zapewnia też większy stopień kontroli nad wytwarzanym produktem. Wynika to z możliwości uzyskiwania informacji zwrotnej opartej o już istniejące elementy produktu i adaptację zadań w oparciu o te obserwacje. Pośrednio podejście takie minimalizuje też koszty w przypadku, gdy wykonana praca okazuje się różnić od rzeczywistych wymagań, lub być oparta o wymagania, które nie są już aktualne. Podział pracy i dostarczanie jej w postaci mniejszych elementów umożliwia ograniczanie ilości pracy wykonywanej jednocześnie. Minimalizuje to niekorzystny wpływ związany z przełączaniem się między zadaniami, skutkuje skupieniem nad aktualnie wykonywaną pracą i wpływa na skrócenie czasu realizacji zadań. Poniżej przedstawione jest wykorzystanie koncepcji podziału pracy i ograniczania ilości pracy wykonywanej jednocześnie w Scrum oraz w Kanban. SCRUM PODZIAŁ PRACY Scrum nie określa maksymalnego dopuszczalnego rozmiaru zadania w postaci wielkości bezwzględnej. Nie ma zasady mówiącej, iż zadanie o złożoności, wyliczonej za pomocą konkretnej matematycznej metody, jest odpowiednie, lub zbyt złożone. Wartość określająca czy zadanie jest odpowiedniego rozmiaru jest w Scrum zdefiniowana pośrednio, poprzez zasady związane z pracą iteracyjną. Najistotniejsza jest w tym przypadku reguła mówiąca, że zespół powinien być w stanie w pełni zrealizować wszystkie zadania przyjęte do iteracji. W efekcie maksymalna wielkość zadania, jest wielkością względną, określoną poprzez złożenie możliwości zespołu i długości iteracji. Same zadania mogą być różnych rozmiarów, przy założeniu, że zespół będzie w stanie je wszystkie zrealizować w trakcie iteracji. Zaznaczyć trzeba, że współczynnik, jakim jest czasu trwania iteracji, jest ograniczony. Scrum określa, że sprint nie powinien trwać dłużej niż cztery tygodnie, a w rzeczywistości często przyjmuje się okresy dwóch tygodni, czy nawet pojedynczego tygodnia. Drugi czynnik określający maksymalną wielkość zadań, czyli efektywność zespołu, wyznaczany jest empirycznie. Cechy Scrum zapewniają możliwość korzystania z wymienionych wcześniej pozytywnych efektów związanych z podziałem pracy i ograniczaniem pracy w toku. Wymaga to jednak odpowiedniego przygotowywania zadań. Konieczne jest dokonywanie podziału w taki sposób, aby wydzielone części były wartościowe i mogły być zrealizowane w trakcie jednej iteracji, co wymaga poświęcenia pewnego nakładu pracy i wiąże się z poświęceniem pewnej ilości czasu. PRACA W TOKU Limit ilości pracy, jaka wykonywana może być jednocześnie, jest w Scrum wyznaczany w analogiczny sposób jak maksymalny rozmiar zadań. Ilość ta nie powinna przekraczać wartości wynikającej z efektywności zespołu i czasu trwania iteracji, a więc zapewniać możliwość realizacji całości tej pracy w trakcie jednego sprintu. Krótsze sprinty skutkują większym ograniczeniem dotyczącym dopuszczalnej ilości pracy w toku. Jest to jedna z przyczyn, dla których sprinty są w Scrum często krótsze od maksymalnej dozwolonej długości ich trwania. 11

12 Iteracyjny model pracy w Scrum ułatwia także empiryczne wyznaczanie limitu pracy w toku. W przypadku, gdy okazuje się, że zespół nie był w stanie zrealizować wszystkich zadań, konieczne jest przenalizowanie przyczyn zaistniałej sytuacji, gdyż może to wskazywać, że przyjęta ilość pracy była zbyt duża. W celu ułatwienia określania odpowiedniej ilości pracy, jaką zespół zdolny jest wykonać, wykorzystywane mogą być w Scrum techniki planowania oparte o estymację i dane historyczne. Polegają one na wykorzystaniu miary określającej ilość wyestymowanej pracy, jaką zespół może być w stanie zrealizować w trakcie sprintu. Miara ta, zwana z angielskiego Velocity, aktualizowana jest po zakończeniu każdego sprintu, a następnie wykorzystywana w celu wsparcia procesu planowania kolejnej iteracji. KANBAN PODZIAŁ PRACY Kanban nie jest oparty o iteracje i nie posiada w związku z tym ograniczenia analogicznego do tego, które obecne jest w Scrum. Teoretycznie możliwa jest, więc praca nad zadaniami o dowolnym rozmiarze. W przypadku takim nie jest konieczne poświęcanie czasu na odpowiedni podział pracy. Charakter Kanban związany z wizualizacją procesu i przepływu pracy pozwala jednak na identyfikację rozmaitych problemów, w tym też takich, które mogą wynikać z pracy nad zadaniami o zbyt szerokim zakresie. Skutki wprowadzenie takiego zadania do systemu Kanban widoczne mogą być między innymi poprzez znaczne zwiększenie czasu potrzebnego na dostarczenie funkcjonalności, oraz zakłócenie pracy nad innymi zadaniami. W efekcie w sytuacji takiej powinny zostać uruchomione mechanizmy wprowadzania zmian, promowane przez Kanban jako technikę adaptacji. W przypadku, gdy czas realizacji zadania okazuje się zbyt długi i wynika to z szerokości jego zakresu, możliwe jest przyjęcie odpowiednich reguł mających na celu zapobieganie dostrzeżonym problemom w przyszłości. Jednym z takich rozwiązań mogłoby być określenie maksymalnej dopuszczalnej wielkości zadań, a więc poświęcanie pewnej ilości czasu na wstępną analizę zadań i w razie konieczności ich podział. Istotną cechą takiego podejścia jest jednak fakt, iż ograniczenia dopasowane są do charakteru zadania, środowiska i zespołu. Czynniki te wpływają bowiem na to czy dane zadanie będzie powodem zakłóceń w pracy czy też nie. W rzeczywistości korzystając z Kanban i będąc świadomym zjawiska związanego z wprowadzaniem do systemu zadań znacznie odbiegających od przeciętnego rozmiaru zabezpieczyć się można poprzez odgórne ustalenie ograniczeń dotyczących rozmiaru przyjmowanych zadań i poddawaniu ich empirycznej weryfikacji. Wymaga to oczywiście poświęcenia pewnej ilości czasu na analizę zadań poprzedzającą wprowadzanie ich do systemu. PRACA W TOKU Ograniczanie pracy w toku jest jednym z centralnych założeń metody Kanban. Jest ona ściśle kontrolowana poprzez wizualizację pracy i nakładanie limitów określających maksymalną liczbę zadań dla kolejnych stanów procesu, przez które zadania muszą przejść. Jest to podstawowe narzędzie wykorzystywane w celu optymalizacji procesu. Umożliwia ono adaptację procesu w taki sposób, aby czas jego odpowiedzi a więc też czas realizacji zadań był odpowiednio krótki. 12

13 Wprowadzenie limitów ułatwia identyfikację problemów i wąskich gardeł. W przypadku zastosowania limitów, omawiany wcześniej problem dotyczący wprowadzenia zadania o bardzo szerokim zakresie, wpłynąłby na ograniczenie przepustowości pewnego kroku w procesie i gromadzenie się zadań w krokach poprzedzających, co byłoby widocznym wskaźnikiem zaistnienia jakiegoś problemu. Limity i inne ograniczenia Kanban wyznaczane mogą być empirycznie podczas pracy i oparte o rzeczywiste wymagania. W efekcie zdarza się, iż proces oraz limity zadań dla poszczególnych jego faz definiowane są bardzo dokładnie. Wprowadzane mogą być też klasy usług, do których część zespołu może być przypisana lub zadania o różnych priorytetach. PODSUMOWANIE Perspektywa: Podział pracy i ograniczenie pracy w toku Scrum Kanban Wymuszenie pewnego stopnia granulacji zadao pracy przez metodę Zadania mogą byd dowolnej wielkości Koniecznośd podziału pracy do pewnej granularności Koniecznośd uczenia się, jaki jest odpowiedni rozmiar zadao, aby nie wpływał negatywnie na pracę Ograniczenia jako przepis oparty o heurystykę Koniecznośd wyznaczania efektywnych ograniczeo Wpływ wielkości zadao na pracę średnio widoczny Wpływ wielkości zadao na pracę wysoce widoczny Adaptacja oparta o uwagi zespołu i ilośd wykonywanej pracy w trakcie iteracji. Adaptacja oparta o ograniczanie pracy w toku i obserwację problemów. PERSPEKTYWA: SPOSÓB PRACY SCRUM PRACA ITERACYJNA Jedną z najistotniejszych cech Scrum jest ściśle iteracyjny sposób pracy. W trakcie każdej z nich zespół zobowiązany jest do realizacji pewnych określonych aktywności. Pierwszego dnia sprintu odbywa się spotkanie dedykowane zaplanowaniu zakresu pracy. Podczas tego spotkania zespół ustala z właścicielem produktu cel sprintu i wybierane są zadania, które zespół obliguje się zrealizować. W drugiej części spotkania zespół może bardziej szczegółowo omówić sposób realizacji wybranych zadań. Każdego dnia iteracji odbywa się spotkanie poświęcone empirycznej kontroli pracy. Jego celem jest analiza postępu, sygnalizowanie problemów, synchronizacja pracy i kierunkowanie zespołu na samoorganizację. Ostatniego dnia iteracji odbywa się spotkanie podsumowujące sprint. Zasadniczym celem tego spotkania jest kontrola rozwoju projektu i sterowanie jego kierunkiem. Podczas tego spotkania zespół przedstawia właścicielowi produktu zrealizowaną funkcjonalność. Właściciel produktu może zorientować się czy funkcjonalność ta odpowiada jego wyobrażeniu, czy też konieczne są modyfikacje, lub zmiana kierunku prowadzenia prac. Właściciel produktu dostarcza też informacji zwrotnej mogącej być wskazówkami dla zespołu, pozwalającymi zwiększyć stopień 13

14 samoorganizacji zespołu poprzez zapewnienie dostępu do informacji umożliwiającej mu podejmowanie odpowiednich decyzji w sytuacjach niejednoznacznych. Ostatniego dnia odbywa się także spotkanie podsumowujące pracę w sprincie. Podczas tego spotkania zespół omawia problemy, jakie napotkane zostały w czasie pracy, pomysły na ich rozwiązanie, oraz inne pomysły dotyczące adaptacji sposobu pracy. Kontrolowany jest także wpływ podjętych wcześniej decyzji, oraz stopień wdrożenia omawianych koncepcji. RYTM Metoda Scrum wprowadza ściśle określony rytm pracy. Wszystkie spotkania odbywają się w stałych odstępach czasu. W przypadku iteracji trwającej dwa tygodnie spotkania planowania, podsumowujące efekt i podsumowujące pracę odbywają się co dwa tygodnie. Umożliwia to ustalenie powtarzającego się planu spotkań z wszystkimi osobami, które powinny w nich uczestniczyć. Jest to często znacznie łatwiejsze niż zwoływania takich spotkań ad-hoc, lub w różnych terminach co iterację. Rytm ten ma także wpływ na zespół, który przyzwyczaja się do niego i jest pewien realizacji okresowych aktywności. Powiązanie okresu tych spotkań nie zawsze może być jednak optymalne. Przykładowo nie zawsze praca, dostarczana przez zespół w trakcie sprintu obejmować będzie całość, którą właściciel produktu będzie chciał wykorzystać. Czasem może być potrzebna więcej niż jedna iteracja, aby sensowne było wydanie zmian. Z drugiej strony zapewnia to postępującą kontrolę kierunku prac. SKUPIENIE NA CELU Podział czasu na okresy iteracji zapewnia możliwość zdefiniowania celu, jaki zespół powinien osiągnąć w tym czasie i na którym powinien się skupić. Stanowi to dodatkową informację pozwalającą na lepszą samoorganizację zespołu w trakcie sprintu. Przynosi to też korzyść w postaci świadomości zespołu, jaki jest kierunek rozwoju produktu. W przypadku jakichkolwiek problemów zespół podejmować może decyzje, które skutkować będą zmierzaniem do tego celu. Istnienie i świadomość celu pozwala także odblokować kreatywność zespołu i dostarczać rozwiązania, które w danym momencie najbardziej odpowiadają potrzebą biznesu w oparciu o możliwości zespołu. Dzięki temu cel biznesowy może zostać zrealizowany nawet poprzez pewną zmianę zakresu sprintu. Scrum zakłada niezmienność zakresu prac prowadzonych w trakcie iteracji, co w założeniu ma pozwolić zespołowi w pełni skupić się nad celem iteracji i realizacją zadań. Zapobiega to niekorzystnemu zjawisku, jakim jest przełączanie się pomiędzy zadaniami. Nie jest konieczne odrywanie się od aktualnie realizowanych zadań, które otrzymały przecież najwyższy priorytet, i w efekcie zmniejszanie efektywności pracy. W przypadkach, gdy zmiana kierunku prac jest rzeczywiście wymagana właściciel produktu dysponuje możliwością anulowania sprintu. Wiąże się to jednak z brakiem konieczności dostarczenie zrealizowanej w trakcie tej iteracji pracy i powoduje, iż decyzja taka podejmowana jest rzeczywiście jedynie w uzasadnionych przypadkach. Zasada ta wpływa jednak oczywiście na określenie czasu odpowiedzi systemu na poziomie czasu trwania iteracji. 14

15 GWARANCJA REALIZACJI AKTYWNOŚCI Wpisanie spotkań metodyki Scrum w rytm iteracji gwarantuje ich realizację, a więc pośrednio możliwość kontrolowania rozwoju produktu, synchronizowania pracy, omawiania problemów i poszukiwania ich rozwiązań. W przypadku, gdyby aktywności te nie były wpisane w harmonogram prac, wiele zespołów mogłoby ich nie realizować. Dotyczy to szczególnie zespołów niedoświadczonych i nie świadomych wszystkich aspektów aktywności. Konieczność odbywania tych spotkań skutkuje nabywaniem doświadczenie i nauką samoorganizacji w przypadku zespołów wkraczających dopiero w świat zwinnego rozwoju oprogramowania. GWARANCJA CZĘSTEGO ODBIORU PRACY Stały okres odbioru efektów pracy wykonanej umożliwia monitorowanie postępu prac, oraz sterowanie rozwojem produktu w oparciu o dostarczane elementy produktu. Zapewnia to możliwość wprowadzania zmian wynikających ze stanu istniejącego już produktu. Co więcej okresowy odbiór pracy stanowi element zarządzania ryzykiem. Sytuacja, w której zespół nie jest w stanie dostarczyć funkcjonalności w trakcie kilku krótkich iteracji może być sygnałem alarmowym świadczącym o braku możliwości realizacji projektu w istniejących warunkach. Co istotne informacja ta generowana jest szybko i często. Już pierwsza iteracji pozwala uzyskać pewne informacje, które aktualizowaną są po zakończenie każdego kolejnego sprintu. Pozwala to podejmować decyzje mogące zminimalizować straty finansowe, poprzez na przykład zamknięcie projektu, lub wpłynąć na zmianę środowiska pracy, poprzez na przykład przydzielenie zespołowi testerów. Stały okres odbioru efektów pracy wykonanej podczas iteracji nie tylko umożliwia sterowanie rozwojem produktu, ale wpływa też pozytywnie na motywację zespołu. Sytuacją idealną jest wdrażanie wytworzonego produktu do użycia i otrzymywanie informacji zwrotnych na ten temat. Jeśli nie jest to możliwe to nawet prezentacja wykonanej pracy skutkuje poczuciem satysfakcji zespołu. Istotą jest świadomość zapotrzebowania na produkt i fakt, iż odpowiada on wymaganiom klienta. Stały okres przekazywania wytworzonego produktu wpływa też na budowanie zaufania pomiędzy klientem biznesowym a zespołem. ZAANGAŻOWANIE CZŁONKÓW ZESPOŁU W AKTYWNOŚCI W Scrum wszyscy członkowie zespołu, niezależnie od specjalizacji biorą czynny udział we wszystkich aktywnościach. Powoduje to konieczność brania udziału w aktywnościach członków zespołu, którzy mogą się w nie nie angażować, i niebędących aktywnymi, którzy czas ten mogliby poświęcić na inne zadania. Jest to jednak rozwiązanie celowe. Zgodnie z założeniami Agile Software Development, cały zespół ma pracować jako jedna drużyna i angażować się we wszystkie aktywności. Skutkuje to spójnym stanem wiedzy całego zespołu na temat kierunku rozwoju produktu i ewentualnych problemach. Świadomość celu projektu i wiedza o możliwościach wpływania na jego realizację dostępna jest wszystkim członkom zespołu. Środowisko takie sprzyja aktywnemu współudziałowi wszystkich członków zespołu w procesie tworzenia produktu oraz przejmowanie zadań w przypadku zaistnienia takiej konieczności. POZIOM WYKORZYSTANIA MOŻLIWOŚCI ZESPOŁU Praca oparta o wiele, następujących po sobie iteracji, podczas których za każdym razem stan początkowy zdefiniowany jest przez pewną liczbę nierozpoczętych zadań, następnie zadania te są w coraz większym stopniu wykonywane, a finalnie wszystkie zadania są wykonane, cechuje się trudnością z wykorzystywaniem pełni możliwości zespołu. Zjawisko to jest szczególnie silne 15

16 w przypadku zespołów składających się ze specjalistów zajmujących się konkretnymi dziedzinami. Na początku iteracji trudno jest wykonywać działania wymagające wykonania wcześniej innych działań. Przykładem takiego działania jest testowanie. Wymaga ono istnienia produktu, który ma być poddany testowaniu. Podobnie wraz ze zbliżaniem się końca iteracji zmniejsza się liczba działań będących działaniami pierwszymi. Zjawisko to jest uzależnione od granulacji zadań w sprincie, specjalizacji zespołu i sposobu pracy. Niezmiennie jednak w mniejszym lub większym stopniu cechuje ono iteracyjny model pracy. Pewną analogią pozwalającą zobrazować ten sposób pracy jest realizacja wielu następujących po sobie cykli Kanban bez limitowania liczby zadań w kolejnych stanach procesu. Możliwym skutkiem tego modelu pracy jest realizacja zadań w taki sposób, że są stają się one w pełni ukończone i wartościowe dopiero pod koniec sprintu. Zjawisko to nazywane bywa z angielskiego scrumfall ze względu na podobieństwo do realizacji pracy w modelu waterfall, gdzie wartość uzyskiwana jest dopiero pod koniec projektu. Ze względu na ograniczenie czasu trwania iteracji skutki tej sytuacji w Scrum są jednak znacznie mniej kosztowne. W przypadku takim jednak ilość pracy w toku zbliżać się może do całości pracy zaplanowanej na iterację. Typowym wskaźnikiem istnienia tego problemu jest sytuacja, w której sprinty kończą się często nie ukończeniem znacznej części zaplanowanych zadań przy jednoczesnym rozpoczęciu pracy nad większością zadań. Zespoły Scrum w ramach samoorganizacji mogą ograniczać to zjawisko nawet bez konieczności określania procesu i definiowania limitów a jedynie poprzez odpowiednią organizację pracy ograniczając pracę w toku. CZAS NIE W PEŁNI WYKORZYSTANY W SZERSZEJ PERSPEKTYWIE Na wspomniane wcześniej niepełne wykorzystanie możliwości zespołu przy pracy za pomocą metody Scrum można spojrzeć także, jako zapewnienie niezbędnego zapasu czasu potrzebnego na rozwój zespołu zarówno pod względem technicznym jak i organizacyjnym. Nie wykorzystywanie zespołu w pełni do budowania funkcjonalności może, więc w efekcie okazać się cechą pozytywną, wpływającą na wykorzystanie lepszych rozwiązań technicznych, czy prezentację wartościowych sugestii dotyczących kierunku rozwoju produktu. Efektywna adaptacja sposobu pracy także wymaga zapewnienia pewnej ilości czasu w trakcie, którego zespół może analizować aktualne podejście. EFEKT ŚCIŚLE OKREŚLONEGO ZAKRESU PRACY I CZASU PRACY. Zobligowanie się zespołu do dostarczenia pracy przyjętej do iteracji wpływa na wysoką motywację ukierunkowaną na osiągnięcie celu, efektywną pracę oraz zespołowe rozwiązywanie problemów, które mogą stać na drodze do jego osiągnięcia. Cecha ta może mieć też w określonych przypadkach specyficzne efekty uboczne. Poziom ich występowania zależny jest od restrykcyjności środowiska związanej z ewentualnym nie wykonaniem całości pracy składającej się na iterację. W środowiskach penalizujących takie sytuacje możliwe jest występowanie efektu polegającego na dostarczeniu produktu o niskiej jakości. Skutkuje to wprowadzeniem długu technologicznego, który z dużym prawdopodobieństwem spłacić trzeba będzie w przyszłości z odsetkami, a więc poświęcając więcej czasu, niż zaoszczędzono. Barry Boehm stwierdził, że poprawienie błędu, który miał miejsce na początku projektu, może kosztować 50 do 1000 razy pod koniec projektu, w porównaniu z kosztami jego poprawienia mniej więcej w czasie, gdy został popełniony. Wprowadzanie długu technologicznego jest to sprzeczne z koncepcją Agile Software 16

17 Development, która zakłada konieczność wytwarzania produktu o wysokiej jakości. To niekorzystne zjawisko przybiera na sile także w sytuacji, gdy liczba zadań w iteracji ma tendencję do przekraczania rzeczywistych możliwości zespołu, co jest stosunkowo częstym zjawiskiem w przypadku oparcia procesu planowania jedynie o miarę velocity przy jednoczesnym niewłaściwym jej wyznaczaniu. Istotne jest też pytanie jak długo zespół może podejmować wyzwanie mierzenia się z kolejnym sprintem. Czy możliwe jest spełnienie przy takim sposobie pracy założenia o utrzymaniu wydajności w dowolnie odległej perspektywie? Przeformowując to pytanie można spytać czy zespół może przebiec maraton składający się z biegów sprinterskich. Odpowiedź zależy od stopnia eksploatacji zawodników w trakcie tych biegów. Jeśli jest to rzeczywiście bieg sprinterski to przebiegnięcie maratonu raczej nie będzie możliwe. Obserwując rzeczywiste implementacje wydaje się, że niestety nawet zespół odpowiedzialny za realizację zadań często nieświadomie dąży do eksploatacji swoich możliwości ponad miarę w trakcie sprintów. Zjawisku temu w Scrum zapobiegać ma Scrum Master. KANBAN PRACA CIĄGŁA Kanban oparty jest o model pracy ciągłej, w którym gotowe zadania pobierane są płynnie do kolejnych faz procesu, gdy pojawia się możliwość rozpoczęcia nad nimi pracy. Elementem regulującym przepływ zadań są limity pracy w toku zdefiniowane dla kolejnych faz procesu. Gdy liczba zadań w danej fazie jest mniejsza od zdefiniowanego dla niej limitu i istnieje gotowe do pobrania zadanie w fazie poprzedniej, możliwe jest wciągnięcie go do fazy kolejnej. Kanban nie definiuje aktywności poświęconych realizacji określonych celów tak jak Scrum. Wymaga jednak, spełnienia pewnych wymagań. Należą do nich wizualizacja procesu, ograniczanie pracy w toku, zarządzanie i pomiar przepływającej przez system pracy, dokonywania analizy mającej na celu identyfikację możliwości zwiększenia efektywności procesu, oraz definiowania reguł wynikających z tej analizy. Szczegóły dotyczące realizacji tych wymagań mogą się różnić w przypadku różnych implementacji Kanban. ASYNCHRONICZNOŚĆ Model pracy ciągłej w Kanban skutkuje brakiem konieczności powiązania częstotliwości realizacji aktywności. Zapewnia to możliwość pełnego dopasowania częstotliwości każdej z aktywności z osobna do specyfiki pracy. Aktywnościami, które odbywać się mogą w ramach Kanban są aktualizacja i uzupełnianie kolejki wejściowej procesu, oraz prezentacja i oddawanie wytworzonego produktu. Charakter Kanban pozwala na to, aby aktywności te odbywały się zarówno ad-hoc, w momencie, gdy pojawia się taka konieczność, jak i okresowo. Możliwe jest też przyjęcie rozwiązania mieszanego, w którym część aktywności jest okresowa a część odbywa się ad-hoc. Co więcej, przypadku przyjęcia rozwiązania okresowego, częstotliwość odbywania się różnych spotkań nie musi być jednakowa. W efekcie stan kolejki może być aktualizowany raz w tygodniu a produkt może być oddawany ad-hoc, stan kolejki może być aktualizowany dwa razy w tygodniu a produkt może być oddawany raz w miesiącu, itd. Możliwość ta pozwala na dopasowanie specyfiki procesu do środowiska pracy, co przekładać się może na efektywność finansową. Trzeba tu jednak zachować ostrożność, gdyż możliwość ta 17

18 pozwala łamać zasadę szybkiego dostarczania wytwarzanej pracy, co może doprowadzić do problemów z wdrożeniem, kontrolą rozwoju produktu itd. CZAS ODPOWIEDZI NA ZMIANY Kanban nie określa ograniczeń dotyczących wprowadzania zmian do zakresu prac tak jak dzieje się to w Scrum w czasie sprintu. Teoretycznie możliwe jest modyfikowanie kolejki wejściowej w dowolnym momencie, co pozwala reagować na zmiany szybciej niż w przypadku Scrum. Korzyść z możliwości wprowadzania takich zmian zależeć będzie jednak od charakteru procesu. Na przykład w przypadku realizacji powtarzalnych zadań niewymagających dodatkowej pracy związanej z ich wprowadzaniem do procesu może być to rozwiązanie korzystne. W przypadku konieczności zmiany kontekstu przez zespół na pracę związaną z doprecyzowaniem zadania, zdobywaniem informacji o wymaganiach i dokonania klasyfikacja rozwiązanie takie może okazać się jednak nie korzystne. Kanban nie określa też reguł uniemożliwiających wstrzymywanie aktualnie realizowanych zadań i rozpoczynania pracy nad nowymi o wyższym priorytecie. Sytuacje takie obsługiwane są najczęściej poprzez definiowanie klas zadań o różnych priorytetach i definiowanie reguł dotyczących działania w takich sytuacjach. Jeśli, na przykład, w kolejce pojawia się zadanie o wysokim priorytecie, może być ono automatycznie wciągane do pierwszej fazy procesu a inne zadania w tej fazie mogą być wstrzymywane. Skutkuje to jednak możliwym do zaobserwowania opóźnieniem innych zadań i zakłóceniem przepływu. Rozwiązanie to jest jeszcze bardziej problematyczne niż opisane powyżej i korzyść z jego przyjęcia ponownie zależy od specyfiki procesu. Rozwiązanie takie wprowadza też dalsze komplikacje. Konieczne może być określenie limitu dotyczącego takich zadań o wysokim priorytecie w celu zapewnienia, iż przepływ nie zostanie całkowicie przez nie wstrzymany, lub zabezpieczenie dedykowanego bufora wydajności dla takich zadań Drugie z opisanych rozwiązań umożliwia zapewnienie poziomu obsługi dla takich wysoce priorytetowych zadań, przy czym jeśli się one nie pojawiają to system operuje poniżej swoich rzeczywistych możliwości. PRACA AD-HOC Acykliczność Kanban pozwala na minimalizację czasu odpowiedzi systemu poprzez realizację zadań w pełni w trybie ad-hoc. W sytuacji takiej nowa praca pobierana jest jak tylko pojawia się możliwość pracy nad kolejnym zadaniem, a w momencie, gdy zadanie trafia do ostatniej fazy procesu następuje wydanie produktu. Taki sposób pracy wymaga jednak dojrzałości organizacji i odpowiadającego jej środowiska projektu. Wymagana tu może być pełne ukierunkowanie na projekt wszystkich współpracujących stron. Na przykład w momencie pobierania pracy, czy jej wydawania konieczna jest dostępność wszystkich potrzebnych do tego osób. Korzyścią, jaka płynie z takiego sposobu pracy jest minimalny czas odpowiedzi systemu. Sterowanie kierunkiem pracy poprzez wybór zadań następuje na bieżąco. Podobnie wytwarzana praca dostarczana jest na bieżąco, co pozwala czerpać z niej natychmiastowe korzyści. Może to w niektórych przypadkach prowadzić do możliwości uzyskania przewagi konkurencyjnej. 18

19 MOŻLIWOŚĆ PEŁNEGO WYKORZYSTANIA SPECJALISTÓW Szczegółowa definicja procesu w Kanban i wynikający z niej podział na ściśle określone aktywności umożliwia specjalistom skupienie się tylko na fazach, za które odpowiadają i w dziedzinie, których ich wydajność jest największa. Nie istnieje konieczność brania przez nich udziału w aktywnościach, które ich nie dotyczą lub pozyskiwania wiedzy związanej z zagadnieniami pośrednio jedynie ich dotyczącymi. Zaznaczyć trzeba, że ponownie korzyść z takiej organizacji pracy zależeć będzie od specyfiki pracy, organizacji i zespołu. W niektórych przypadkach rozwiązanie takie może okazać się nie efektywne. Zaznaczyć trzeba, że pomimo możliwości pracy specjalistów niejako w oderwaniu od siebie, to David J. Anderson postuluje realizować tak zwany swarming, czyli wspólną analizę występujących problemów, wizualizowanych na tablicy. Koncepcja ta pozwala spojrzeć na zagadnienie z różnych stron i wypracowanie rozwiązania opartego o wiedzę wszystkich specjalistów pracujących w procesie. PEŁNE WYKORZYSTANIE MOŻLIWOŚCI ZESPOŁU Praca ciągła umożliwia uzyskanie pewnej równowagi dotyczącej pracy, która obecna jest stale w systemie poprzez operowanie limitami, składem zespołu czy podziałem na klasy zadań. Dzięki temu wysiłek zespołu jest bardziej równomierny niż w przypadku pracy opartej o powtarzające się iteracje. W przypadku dobrej organizacji pracy pozwolić to może na pełniejsze wykorzystanie możliwości zespołu. Pamiętać jednak trzeba, iż pozostawienie członkom zespołu bufora umożliwiającego rozwój, oraz analizę procesu także przynosi korzyści. UTRZYMANIE WYDAJNOŚCI ZESPOŁU W DALSZEJ PERSPEKTYWIE Praca oparta o płynne pobieranie nowych zadań, charakteryzować się może mniejszą tendencją do nadmiernej eksploatacji zespołu, względem pracy opartej o powtarzające się sprinty. Odpowiedni poziom pracy jest z kolei kluczowym aspektem utrzymania wysokiej efektywności w dalszej perspektywie. W innym przypadku dochodzi do wprowadzania długu technologicznego i/lub wypalenia członków zespołu. W Scrum zapewnienie odpowiedniego poziomu pracy wymaga poprawnego zarządzania planowaniem i pomiarem pracy, co niestety często nie jest wykonywane prawidłowo. W Kanban zabezpieczenie przed przeładowaniem systemu jest łatwiejsze i pewniejsze, przy czym pamiętać trzeba, iż wymaga to pewnej dojrzałości zarówno zespołu jak i jego otoczenia. EFEKT BRAKU OGRANICZENIA CZASOWEGO, KONKRETNEGO CELU I SKUPIENIA NA SPECJALIZACJI Kanban nie posiada ograniczenia czasowego dotyczącego realizacji pracy analogicznego do czasu trwania sprintu w Scrum. Specyfika ta może w niektórych przypadkach skutkować niską wydajnością zespołu lub wykonywaniem dodatkowej, niezaplanowanej pracy. Wymaganie dotyczące automotywacji i odpowiedzialności zespołu jest więc w Kanban szczególnie istotne. Pomiar pracy, będący jednym z wymagań Kanban, może służyć w celu wykrywania takich przypadków. W oparciu o statystykę czasu wykonywania podobnych zadań w przeszłości zadania opóźniające się względem tej miary mogą być bardziej szczegółowo analizowane. Podobnie jednak jak w przypadku efektów ubocznych Scrum tu też pamiętać trzeba, iż każdy pomiar wpływa na zmienię procesu. Nadmierna restrykcyjność związana z opóźniającym się zadaniem może odnieść niespodziewane negatywne skutki. Wykonywana praca może być 19

20 niskiej jakości, zmianie może ulec estymacja zadań i nie odpowiadać rzeczywistości, lub nawet zadania mogą być minimalnie opóźniane w celu zmiany średniej miary czasu ukończenia zadania. Brak cykli ukierunkowanych na osiągnięcie konkretnego celu utrudnia podejmowania decyzji ze względu na możliwość braku dostępu do takiej informacji. Ogranicza to prawdopodobieństwo podejmowania właściwych decyzji przez zespół w sytuacjach niejednoznacznych a więc poniekąd stopień samoorganizacji. Informacje takie mogą być dostarczane w inny sposób niż ma to miejsce w Scrum, metoda Kanban tego jednak nie wymaga, co skutkuje koniecznością ewentualnej identyfikacji i rozwiązania tego problemu w trakcie pracy. Podkreślić też trzeba, iż nadmierna specjalizacja podgrup tworzących zespół i ich skupienie jedynie na sprawach bezpośrednio ich dotyczących może doprowadzić do utracenia szerszej perspektywy, co także może odbić się negatywnie na pracy, poprzez na przykład implementację funkcjonalności niezgodnie z wymaganiami lub zgodnie z wymaganiami, ale niespełniającej swej funkcji. PODSUMOWANIE Perspektywa: Sposób pracy Scrum Kanban Rytmicznośd pracy Płynnośd pracy Synchronizacja aktywności Aktywności mogą byd synchroniczne lub asynchroniczne Skupienie na celu, minimalizacja przełączania pomiędzy zadaniami Niski czas odpowiedzi systemu na zmiany Pewnośd realizacji aktywności związanych z Agile Software Development Możliwośd doboru czynności dopasowanych do środowiska Pełne zaangażowanie zespołu w projekt, wiedza ogólna i współodpowiedzialnośd Możliwośd pełnego wykorzystania specjalistów i wiedza specjalistycznej Trudnośd w pełnym wykorzystaniu zespołu ze względu na skokowy sposób pracy Możliwośd pełnego wykorzystania zespołu ze względu na płynny sposób pracy Niebezpieczeostwo przeładowania poprzez Niebezpieczeostwo przeładowania poprzez stosowanie źle wyznaczanych miar podczas nadmierną optymalizację wykorzystania planowania i penalizacji związanej z zespołu i restrykcyjności związanej z niedostarczeniem funkcjonalności niedostarczeniem funkcjonalności Utrzymanie wydajności zespołu w dalszej perspektywie wymaga znacznego doświadczenia. Utrzymanie wydajności zespołu w dalszej perspektywie wymaga mniejszego doświadczenia. PERSPEKTYWA: DEFINICJA GOTOWOŚCI Definicja gotowości określa warunki, jakie spełnić musi zadanie, aby można było rozpocząć jego realizację. SCRUM Wymagania Scrum dotyczące przyjmowanych do realizacji zadań zdefiniowane są stosunkowo ogólnie. Mówią one, że zespół powinien w pełni rozumieć zakres i cel tych zadań. Celem tych wymagań jest zapewnienie możliwości efektywnej pracy zespołu w trakcie iteracji. Zadania, 20

Lekkie metodyki. tworzenia oprogramowania

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Planowanie i realizacja zadań w zespole Scrum

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

Bardziej szczegółowo

Zarządzanie projektami. Porównanie podstawowych metodyk

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Scrum. Zwinna metodyka prowadzenia projektów

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

Bardziej szczegółowo

Zarządzanie bezpieczeństwem informacji przegląd aktualnych standardów i metodyk

Zarządzanie bezpieczeństwem informacji przegląd aktualnych standardów i metodyk Zarządzanie bezpieczeństwem informacji przegląd aktualnych standardów i metodyk dr T Bartosz Kalinowski 17 19 września 2008, Wisła IV Sympozjum Klubu Paragraf 34 1 Informacja a system zarządzania Informacja

Bardziej szczegółowo

Agile Project Management

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

Bardziej szczegółowo

Narzędzia doskonalenia produkcji - LEAN, KAIZEN, TOC, GEMBA

Narzędzia doskonalenia produkcji - LEAN, KAIZEN, TOC, GEMBA Narzędzia doskonalenia produkcji - LEAN, KAIZEN, TOC, GEMBA Opis W jaki sposób angażować pracowników w doskonalenie procesów produkcji? Co motywuje ludzi do aktywnego uczestnictwa w rozwiązywaniu problemów

Bardziej szczegółowo

Feature Driven Development

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

Bardziej szczegółowo

Audyt funkcjonalnego systemu monitorowania energii w Homanit Polska w Karlinie

Audyt funkcjonalnego systemu monitorowania energii w Homanit Polska w Karlinie Audyt funkcjonalnego systemu monitorowania energii w Homanit Polska w Karlinie System zarządzania energią to uniwersalne narzędzie dające możliwość generowania oszczędności energii, podnoszenia jej efektywności

Bardziej szczegółowo

Projektowanie systemów informatycznych. wykład 6

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

Bardziej szczegółowo

OFERTA SZKOLEŃ BIZNESOWYCH

OFERTA SZKOLEŃ BIZNESOWYCH OFERTA SZKOLEŃ BIZNESOWYCH Przywództwo i zarządzanie zespołem Szkolenie z zakresu przywództwa, kompetencji liderskich i zarządzania zespołem. Podniesienie kompetencji zarządczych w zakresie przywództwa,

Bardziej szczegółowo

Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście. Rozdział pochodzi z książki:

Komputerowe 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ółowo

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

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Zarządzanie projektami w NGO

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

Bardziej szczegółowo

Katalog rozwiązań informatycznych dla firm produkcyjnych

Katalog rozwiązań informatycznych dla firm produkcyjnych Katalog rozwiązań informatycznych dla firm produkcyjnych www.streamsoft.pl Obserwować, poszukiwać, zmieniać produkcję w celu uzyskania największej efektywności. Jednym słowem być jak Taiichi Ohno, dyrektor

Bardziej szczegółowo

Optymalizacja Automatycznych Testów Regresywnych

Optymalizacja Automatycznych Testów Regresywnych Optymalizacja Automatycznych Testów Regresywnych W Organizacji Transformującej do Agile Adam Marciszewski adam.marciszewski@tieto.com Agenda Kontekst projektu Typowe podejście Wyzwania Cel Założenia Opis

Bardziej szczegółowo

Asynchroniczne interfejsy WWW

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

Bardziej szczegółowo

Wskazówki projektowe. Programowanie Obiektowe Mateusz Cicheński

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Katalog rozwiązań informatycznych dla firm produkcyjnych

Katalog rozwiązań informatycznych dla firm produkcyjnych Katalog rozwiązań informatycznych dla firm produkcyjnych www.streamsoft.pl Obserwować, poszukiwać, zmieniać produkcję w celu uzyskania największej efektywności. Jednym słowem być jak Taiichi Ohno, dyrektor

Bardziej szczegółowo

DLA SEKTORA INFORMATYCZNEGO W POLSCE

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

Bardziej szczegółowo

MIERZENIE EFEKTYWNOŚCI DZIAŁAŃ SPOŁECZNYCH

MIERZENIE EFEKTYWNOŚCI DZIAŁAŃ SPOŁECZNYCH MIERZENIE EFEKTYWNOŚCI DZIAŁAŃ SPOŁECZNYCH PRAKTYCZNE WYKORZYSTANIE MODELU LBG W FUNDACJACH KORPORACYJNYCH Warszawa, 11 września 2014r. Małgorzata Greszta, SGS Polska NASZA EKSPERCKA WIEDZA W ZAKRESIE

Bardziej szczegółowo

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

6 kroków do skutecznego planowania na postawie wskaźników KPI

6 kroków do skutecznego planowania na postawie wskaźników KPI 6 kroków do skutecznego planowania na postawie wskaźników KPI Urzeczywistnianie celów biznesowych w praktyce Planowanie i optymalizacja łańcucha dostaw Odkryj brakujące połączenie pomiędzy celami biznesowymi

Bardziej szczegółowo

Scrum w praktyce. Michał Piórek

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Data: 06-07 marzec 2014 r. (2 dni, czwartek-piątek), godz. 9-16. Miejsce: Eureka Technology Park, Innowatorów 8

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

Bardziej szczegółowo

Launch. przygotowanie i wprowadzanie nowych produktów na rynek

Launch. przygotowanie i wprowadzanie nowych produktów na rynek Z przyjemnością odpowiemy na wszystkie pytania. Prosimy o kontakt: e-mail: kontakt@mr-db.pl tel. +48 606 356 999 www.mr-db.pl MRDB Szkolenie otwarte: Launch przygotowanie i wprowadzanie nowych produktów

Bardziej szczegółowo

Marta Ożóg 183858 Agnieszka Pastusińska 183875

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

Bardziej szczegółowo

CZYNNIKI SUKCESU PPG

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

Bardziej szczegółowo

ŚCIEŻKA: Praktyk KAIZEN

ŚCIEŻKA: Praktyk KAIZEN ŚCIEŻKA: Praktyk KAIZEN Ścieżka dedykowana jest każdej osobie, która chce rozwijać siebie i swoją organizację - w szczególności: Koordynatorom i liderom Lean/KAIZEN odpowiedzialnym za obszary produkcyjne

Bardziej szczegółowo

Dopasowanie IT/biznes

Dopasowanie IT/biznes Dopasowanie IT/biznes Dlaczego trzeba mówić o dopasowaniu IT-biznes HARVARD BUSINESS REVIEW, 2008-11-01 Dlaczego trzeba mówić o dopasowaniu IT-biznes http://ceo.cxo.pl/artykuly/51237_2/zarzadzanie.it.a.wzrost.wartosci.html

Bardziej szczegółowo

www.streamsoft.pl Katalog rozwiązań informatycznych dla firm produkcyjnych

www.streamsoft.pl Katalog rozwiązań informatycznych dla firm produkcyjnych www.streamsoft.pl Katalog rozwiązań informatycznych dla firm produkcyjnych Obserwować, poszukiwać, zmieniać produkcję w celu uzyskania największej efektywności. Jednym słowem być jak Taiichi Ohno, dyrektor

Bardziej szczegółowo

Testujemy dedykowanymi zasobami (ang. agile testers)

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

Bardziej szczegółowo

4. Wprowadzanie Scruma w ImmobilienScout24 4.1. Opis sytuacji

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

Bardziej szczegółowo

6 kroków, jak dobrze przygotować się do wdrożenia systemu ERP?

6 kroków, jak dobrze przygotować się do wdrożenia systemu ERP? 6 kroków, jak dobrze przygotować się do wdrożenia systemu ERP? Co to jest metodyka projektowa Microsoft Dynamics Sure Step? Niniejszy przewodnik może pomóc firmie w prawidłowym przygotowaniu się i przeprowadzeniu

Bardziej szczegółowo

Skuteczność => Efekty => Sukces

Skuteczność => Efekty => Sukces O HBC Współczesne otoczenie biznesowe jest wyjątkowo nieprzewidywalne. Stała w nim jest tylko nieustająca zmiana. Ciągłe doskonalenie się poprzez reorganizację procesów to podstawy współczesnego zarządzania.

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

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

Bardziej szczegółowo

Szkolenie 2. Zarządzanie programami

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

Bardziej szczegółowo

ZARZĄDZANIE MARKĄ. Doradztwo i outsourcing

ZARZĄDZANIE MARKĄ. Doradztwo i outsourcing ZARZĄDZANIE MARKĄ Doradztwo i outsourcing Pomagamy zwiększać wartość marek i maksymalizować zysk. Prowadzimy projekty w zakresie szeroko rozumianego doskonalenia organizacji i wzmacniania wartości marki:

Bardziej szczegółowo

Przypadki bez przypadków. Jak dobierać scenariusze testowe.

Przypadki bez przypadków. Jak dobierać scenariusze testowe. Przypadki bez przypadków. Jak dobierać scenariusze testowe. Konferencja SQAM 2008 Warszawa, 29. kwietnia Wojciech Pająk 29 kwietnia 2008 Warszawa Zagadnienia prezentacji 1. Wprowadzenie 2. Definicje przypadków

Bardziej szczegółowo

ŚCIEŻKA: Zarządzanie projektami

Ś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

Bardziej szczegółowo

RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010

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ę

Bardziej szczegółowo

Szkolenie Scrum w projektach IT (Agile)

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

Bardziej szczegółowo

Społeczna odpowiedzialność biznesu podejście strategiczne i operacyjne. Maciej Bieńkiewicz

Społeczna odpowiedzialność biznesu podejście strategiczne i operacyjne. Maciej Bieńkiewicz 2012 Społeczna odpowiedzialność biznesu podejście strategiczne i operacyjne Maciej Bieńkiewicz Społeczna Odpowiedzialność Biznesu - istota koncepcji - Nowa definicja CSR: CSR - Odpowiedzialność przedsiębiorstw

Bardziej szczegółowo

Compuware Changepoint. Portfolio Management Tool

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

Bardziej szczegółowo

Zarządzanie projektami a zarządzanie ryzykiem

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

Bardziej szczegółowo

Transformacja wiedzy w budowie i eksploatacji maszyn

Transformacja wiedzy w budowie i eksploatacji maszyn Uniwersytet Technologiczno Przyrodniczy im. Jana i Jędrzeja Śniadeckich w Bydgoszczy Wydział Mechaniczny Transformacja wiedzy w budowie i eksploatacji maszyn Bogdan ŻÓŁTOWSKI W pracy przedstawiono proces

Bardziej szczegółowo

Monitoring procesów z wykorzystaniem systemu ADONIS

Monitoring procesów z wykorzystaniem systemu ADONIS Monitoring procesów z wykorzystaniem systemu ADONIS 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

Bardziej szczegółowo

Zmiany wymagań normy ISO 14001

Zmiany wymagań normy ISO 14001 Zmiany wymagań normy ISO 14001 Międzynarodowa Organizacja Normalizacyjna (ISO) opublikowała 15 listopada br. zweryfikowane i poprawione wersje norm ISO 14001 i ISO 14004. Od tego dnia są one wersjami obowiązującymi.

Bardziej szczegółowo

Wprowadzenie do zarządzania projektami

Wprowadzenie do zarządzania projektami Wprowadzenie do zarządzania projektami Project Management dr Marek Wąsowicz Katedra Projektowania Systemów Zarządzania, UE Wrocław Wrocław, 23 października 2012 r. Zawartość modułu (4h): wskazanie możliwości

Bardziej szczegółowo

Oferta szkoleń firmy Code Sprinters

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

Bardziej szczegółowo

Zarządzanie procesami i logistyką w przedsiębiorstwie

Zarządzanie procesami i logistyką w przedsiębiorstwie Zarządzanie procesami i logistyką w przedsiębiorstwie Opis Projektowanie i ciągła optymalizacja przepływu produktu w łańcuchu dostaw oraz działań obsługowych i koniecznych zasobów, wymaga odwzorowania

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Organizacyjny aspekt projektu

Organizacyjny aspekt projektu Organizacyjny aspekt projektu Zarządzanie funkcjonalne Zarządzanie między funkcjonalne Osiąganie celów poprzez kierowanie bieżącymi działaniami Odpowiedzialność spoczywa na kierownikach funkcyjnych Efektywność

Bardziej szczegółowo

Cele kluczowe W dziedzinie inwestowania w zasoby ludzkie W zakresie wzmacniania sfery zdrowia i bezpieczeństwa

Cele kluczowe W dziedzinie inwestowania w zasoby ludzkie W zakresie wzmacniania sfery zdrowia i bezpieczeństwa Cele kluczowe Idea społecznej odpowiedzialności biznesu jest wpisana w wizję prowadzenia działalności przez Grupę Kapitałową LOTOS. Zagadnienia te mają swoje odzwierciedlenie w strategii biznesowej, a

Bardziej szczegółowo

Kanban - od systemu push do pull - Planowanie operacyjne produkcji

Kanban - od systemu push do pull - Planowanie operacyjne produkcji Kanban - od systemu push do pull - Planowanie operacyjne produkcji Terminy szkolenia 16-17 listopad 2015r., Katowice - Novotel Centrum 19-20 maj 2016r., Sopot - Hotel Haffner**** Opis Dotrzymać terminów

Bardziej szczegółowo

Społecznie odpowiedzialne zarządzanie w organizacjach publicznych. Teza cele konstrukcja realizacja

Społecznie odpowiedzialne zarządzanie w organizacjach publicznych. Teza cele konstrukcja realizacja Dr Grzegorz Baran, Instytut Spraw Publicznych UJ Społecznie odpowiedzialne zarządzanie w organizacjach publicznych Teza cele konstrukcja realizacja Teza Zakorzenienie modelu działania organizacji publicznej

Bardziej szczegółowo

Charakterystyka systemu zarządzania jakością zgodnego z wymaganiami normy ISO serii 9000

Charakterystyka systemu zarządzania jakością zgodnego z wymaganiami normy ISO serii 9000 Charakterystyka systemu zarządzania jakością zgodnego z wymaganiami normy ISO serii 9000 Normy ISO serii 9000 Zostały uznane za podstawę wyznaczania standardów zarządzania jakością Opublikowane po raz

Bardziej szczegółowo

Case Study. Rozwiązania dla branży metalowej

Case Study. Rozwiązania dla branży metalowej Case Study Rozwiązania dla branży metalowej Charakterystyka klienta Firma produkująca wyroby ze stali czarnej, aluminium, stali nierdzewnej oraz elementy konstrukcji i konstrukcje metalowe. W palecie rozwiązań

Bardziej szczegółowo

Spis treści. 00 Red. Spis tresci. Wstep..indd 5 2009 12 02 10:52:08

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.

Bardziej szczegółowo

MSF. Microsoft Solution Framework

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

Bardziej szczegółowo

Scaling Scrum with SAFe. Małgorzata Czerwińska

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

Bardziej szczegółowo

X SPOTKANIE EKSPERCKIE. System ocen pracowniczych metodą 360 stopni

X SPOTKANIE EKSPERCKIE. System ocen pracowniczych metodą 360 stopni X SPOTKANIE EKSPERCKIE System ocen pracowniczych metodą 360 stopni Warszawa, 16.09.2011 Ocena wieloźródłowa od koncepcji do rezultatów badania dr Anna Bugalska Najlepsze praktyki Instytutu Rozwoju Biznesu

Bardziej szczegółowo

ISO Revisions. ISO Revisions ISO 9001. Znaczenie ryzyka w zarządzaniu jakością. Jak podchodzić do zmian?

ISO Revisions. ISO Revisions ISO 9001. Znaczenie ryzyka w zarządzaniu jakością. Jak podchodzić do zmian? ISO 9001 Znaczenie ryzyka w zarządzaniu jakością Jak podchodzić do zmian? Tło historyczne i przegląd aktualizacji wprowadzonych do ISO 9001:2015 Międzynarodowy Standard ISO 9001 podlega przeglądowi w regularnych

Bardziej szczegółowo

Podejście zwinne do zarządzania projektami

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

Bardziej szczegółowo

Plan Komunikacji projektu samooceny CAF. Gminy Zapolice. Zapolice, lipiec 2011

Plan Komunikacji projektu samooceny CAF. Gminy Zapolice. Zapolice, lipiec 2011 1 Plan Komunikacji projektu samooceny CAF Gminy Zapolice Zapolice, lipiec 2011 1 2 SPIS TREŚCI: str. Wprowadzenie... 3 1. Projekt wdrożenia metody CAF w Urzędzie... 3 2. Plan komunikacji uczestników wdrożenia

Bardziej szczegółowo

Nie o narzędziach a o rezultatach. czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT. Władysławowo, 6 października 2011 r.

Nie o narzędziach a o rezultatach. czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT. Władysławowo, 6 października 2011 r. Nie o narzędziach a o rezultatach czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT Władysławowo, 6 października 2011 r. Dlaczego taki temat? Ci którzy wykorzystują technologie informacyjne

Bardziej szczegółowo

Budowa systemu wspomagającego podejmowanie decyzji. Metodyka projektowo wdrożeniowa

Budowa 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ółowo

Uchwała Nr 28/2013/IV Senatu Politechniki Lubelskiej z dnia 26 kwietnia 2013 r.

Uchwała Nr 28/2013/IV Senatu Politechniki Lubelskiej z dnia 26 kwietnia 2013 r. Uchwała Nr 28/2013/IV Senatu Politechniki Lubelskiej z dnia 26 kwietnia 2013 r. w sprawie określenia efektów kształcenia dla studiów podyplomowych Zarządzanie Logistyką w Przedsiębiorstwie, prowadzonych

Bardziej szczegółowo

Nowe trendy w zarządzaniu operacyjnym Przejście z zarządzania ręcznie sterowanego do efektywnie zarządzanej firmy

Nowe trendy w zarządzaniu operacyjnym Przejście z zarządzania ręcznie sterowanego do efektywnie zarządzanej firmy Nowe trendy w zarządzaniu operacyjnym Przejście z zarządzania ręcznie sterowanego do efektywnie zarządzanej firmy Paweł Zemła Członek Zarządu Equity Investments S.A. Wprowadzenie Strategie nastawione na

Bardziej szczegółowo

Raport oceny kompetencji

Raport oceny kompetencji Symulacje oceniające kompetencje Raport oceny kompetencji Rut Paweł 08-01-2015 Kompetencje sprzedażowe dla efactor Sp. z o.o. Dane osobowe Rut Paweł CEO pawel.rut@efactor.pl more-than-manager.com 2 z 13

Bardziej szczegółowo

PROJEKT ZARZĄDZANIE PROJEKT. Przedsięwzięcie powtarzalne, kilkurazowe = PROCES

PROJEKT ZARZĄDZANIE PROJEKT. Przedsięwzięcie powtarzalne, kilkurazowe = PROCES Kamila Vestergaard www.analizybiznesowe.info.pl PROJEKT Zestaw działań, które zostały uprzednio zaplanowane, mają jasno wyznaczony cel oraz są wykonywane w ramach jednorazowego przedsięwzięcia Przedsięwzięcie

Bardziej szczegółowo

Architektura bezpieczeństwa informacji w ochronie zdrowia. Warszawa, 29 listopada 2011

Architektura bezpieczeństwa informacji w ochronie zdrowia. Warszawa, 29 listopada 2011 Architektura informacji w ochronie zdrowia Warszawa, 29 listopada 2011 Potrzeba Pomiędzy 17 a 19 kwietnia 2011 roku zostały wykradzione dane z 77 milionów kont Sony PlayStation Network. 2 tygodnie 25 milionów

Bardziej szczegółowo

Popularyzacja podpisu elektronicznego w Polsce

Popularyzacja podpisu elektronicznego w Polsce Popularyzacja podpisu elektronicznego w Polsce Rola administracji w budowaniu gospodarki elektronicznej Warszawa, 25 września 2006 r. Poruszane tematy Wprowadzenie i kontekst prezentacji Rola administracji

Bardziej szczegółowo

Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią

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

Bardziej szczegółowo

DOSKONALENIE PROCESÓW

DOSKONALENIE PROCESÓW KATALOG SZKOLEŃ DOSKONALENIE PROCESÓW - Tworzenie projektów ciągłego doskonalenia - Konsultacje z ekspertami - Poprawa jakości oraz produktywności - Eliminacja marnotrawstwa - Redukcja kosztów - Metody

Bardziej szczegółowo

Uwarunkowania i kierunki rozwoju systemów kontroli w administracji publicznej

Uwarunkowania i kierunki rozwoju systemów kontroli w administracji publicznej Uwarunkowania i kierunki rozwoju systemów kontroli w administracji publicznej Prof AE dr hab. Wojciech Czakon Katedra Zarządzania Przedsiębiorstwem Akademia Ekonomiczna w Katowicach Program wystąpienia

Bardziej szczegółowo

Zarządzanie testowaniem wspierane narzędziem HP Quality Center

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

Bardziej szczegółowo

Zarządzanie projektami. Wykład 2 Czym jest zarządzanie projektami?

Zarządzanie projektami. Wykład 2 Czym jest zarządzanie projektami? Zarządzanie projektami Wykład 2 Czym jest zarządzanie projektami? Plan Czym jest zarządzanie projektami? Jakie są rodzaje podejść do zarządzania projektami? Jakie są grupy procesów w ramach zarządzania

Bardziej szczegółowo

Studium przypadku Bank uniwersalny

Studium przypadku Bank uniwersalny Studium przypadku Bank uniwersalny Przedsiębiorstwo będące przedmiotem studium przypadku jest bankiem uniwersalnym. Dominującą strategią banku jest przywództwo produktowe. Cele banku koncentrują się, zatem

Bardziej szczegółowo

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. Usprawnienie procesu zarządzania konfiguracją Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. 1 Typowy model w zarządzaniu IT akceptacja problem problem aktualny stan infrastruktury propozycja

Bardziej szczegółowo

Kryteria wyboru. Lp. Kryterium Opis kryterium

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

Bardziej szczegółowo

INSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH

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

Bardziej szczegółowo

LABORATORIUM 1 - zarządzanie operacyjne

LABORATORIUM 1 - zarządzanie operacyjne LABORATORIUM 1 - zarządzanie operacyjne Konkurencja a procesy operacyjne W czasie nasilających się procesów globalizacyjnych akcent działań konkurencyjnych przesuwa się z obszaru generowania znakomitych

Bardziej szczegółowo

Strategia identyfikacji, pomiaru, monitorowania i kontroli ryzyka w Domu Maklerskim Capital Partners SA

Strategia identyfikacji, pomiaru, monitorowania i kontroli ryzyka w Domu Maklerskim Capital Partners SA Strategia identyfikacji, pomiaru, monitorowania i kontroli ryzyka zatwierdzona przez Zarząd dnia 14 czerwca 2010 roku zmieniona przez Zarząd dnia 28 października 2010r. (Uchwała nr 3/X/2010) Tekst jednolity

Bardziej szczegółowo

Poziom 5 EQF Starszy trener

Poziom 5 EQF Starszy trener Poziom 5 EQF Starszy trener Opis Poziomu: Trener, który osiągnął ten poziom rozwoju kompetencji jest gotowy do wzięcia odpowiedzialności za przygotowanie i realizację pełnego cyklu szkoleniowego. Pracuje

Bardziej szczegółowo

Agile Project Management WHITEPAPER

Agile Project Management WHITEPAPER 1 Wstęp... 2 Historia... 2 DSDM ATERN... 3 Agile w zarządzaniu projektami... 4 Szkolenia i certyfikacja... 6 Certyfikaty Agile Project Management Foundation i Practitioner... 6 Szkolenie Agile Project

Bardziej szczegółowo

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Krzysztof Wertejuk audytor wiodący ISOQAR CEE Sp. z o.o. Dlaczego rozwiązania

Bardziej szczegółowo

Poziomowany system ssący w systemie Plan-de-CAMpagne

Poziomowany system ssący w systemie Plan-de-CAMpagne Poziomowany system ssący w systemie Plan-de-CAMpagne Współczesne metody zarządzania produkcją jednomyślnie podkreślają zalety produkowania dokładnie tylu wyrobów, ile w danym czasie potrzebują nasi klienci.

Bardziej szczegółowo