Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Zarządzanie projektem informatycznym Prowadzący: dr inż. Bogdan Trawiński Wykład 11 i 12 Zarządzanie zespołami i komunikacją.

Podobne prezentacje


Prezentacja na temat: "Zarządzanie projektem informatycznym Prowadzący: dr inż. Bogdan Trawiński Wykład 11 i 12 Zarządzanie zespołami i komunikacją."— Zapis prezentacji:

1 Zarządzanie projektem informatycznym Prowadzący: dr inż. Bogdan Trawiński Wykład 11 i 12 Zarządzanie zespołami i komunikacją

2 Większość profesjonalnego oprogramowania jest tworzona przez zespoły składające się od dwustu do kilkuset osób (Sommervile) Nie ma możliwości, aby wszyscy członkowie tak wielkiego zespołu pracowali razem na jednym problemem Duże zespoły dzieli się na kilka grup. Każda grupa odpowiada za budowę jakiegoś podsystemu Przyjmuje się zasadę, że grupy nie powinny liczyć więcej aniżeli ośmiu członków Stworzenie małych grup umożliwia ograniczenie problemów komunikacyjnych Cała grupa może się spotkać przy jednym stole lub zebrać w swoich pokojach, nie są potrzebne skomplikowane struktury komunikacyjne Praca zespołowa (1)

3 Kiedyś celem zarządzania było kontrolowanie siły roboczej, wskazywanie co trzeba zrobić i pilnowanie, aby było to zrobione. Obecnie uznaje się, że takie podejście nie daje przewagi konkurencyjnej, a raczej odwrotnie. Obecnie pracownicy są dobrze wykształceni i oczekują, że będą włączani w przedsięwzięcie. A zatem, gdy kierownictwo nadal musi koordynować pracę ludzi i grup, to pomału odchodzi się od podejścia opartego na władzy i ścisłej kontroli. Nowoczesne podejście polega na wsparciu siły roboczej, umożliwianiu wykonania pracy oraz dbaniu o rozwój poprzez szkolenie i zachęcanie do samorozwoju. Praca zespołowa (2)

4 Utworzenie grupy, która będzie wydajnie pracować, jest krytycznym zadaniem menadżera W grupie powinna panować równowaga umiejętności technicznych, doświadczenia i osobowości W dobrej grupie panuje duch zespołu, tzn. jej członkowie są zmotywowani sukcesem grupy na równi z realizacją własnych celów Menadżerowie powinni zachęcać do jawnych czynności „budowania zespołu”, aby wypracować poczucie lojalności grupowej Praca zespołowa (3)

5 Kierownik musi motywować zespół jako całość oraz motywować osobno każdą osobę. Motywacja zespołu ma swoje źródło w osobistym zaangażowaniu kierownika, w sposobie przydziału i podziału pracy, wyraźnej wizji celu i sposobu jego osiągnięcia. Kierownik daje przykład przez własne zaangażowanie i zachowanie oraz tworzy klimat postępu i akceptacji zmiany. Motywację osobistą osiąga się poprzez własny stosunek i „niepisaną umowę”, czego dana osoba i kierownik wzajemnie od siebie oczekują. Kluczowym elementem motywacji jest projektowanie pracy poszczególnych osób; praca powinna zawierać odpowiednią ilość wyzwań i różnorodności oraz zmierzać do znaczącego wyniku. Każdy potrzebuje uzgodnionych celów, które są zrozumiałe i splatają się z osobistym i zawodowym rozwojem kariery, wynikającym z ambitnej pracy, profesjonalnych standardów, właściwych relacji i szkolenia. Motywowanie (1)

6 Motywowanie (2) Potrzeby fizjologiczne Potrzeby bezpieczeństwa Społeczne Szacunku Samo- realizacji Ludzi motywuje się poprzez spełnienie ich potrzeb

7 Ludzie pracujący w firmach softwarowych nie są ani głodni, ani spragnieni, ani nie czuję się fizycznie zagrożeni. Z menadżerskiego punktu widzenia najistotniejsze jest spełnienie potrzeb społecznych, szacunku i samorealizacji: Spełnienie potrzeb społecznych oznacza zgodę na spotykanie się ze współpracownikami i zapewnienie miejsc na takie spotkania. Nieformalne i łatwe w użyciu kanały komunikacyjne, takie jak poczta elektroniczna, są ważne. Spełnianie potrzeby szacunku wymaga pokazania ludziom, że są wysoko oceniani przez firmę. Publiczne doceniania osiągnięć jest prostym i skutecznym środkiem do tego celu. Spełnienie potrzeby samorealizacji wymaga przekazania ludziom odpowiedzialności za ich pracę, przydzielanie im trudnych, ale nie niemożliwych do wykonania zadań i zaoferowanie programu szkoleń, który umożliwi im rozwijanie swoich umiejętności. Motywowanie (3)

8 Wg Herzberga na pracowników wpływają dwa rodzaje czynników: tzw. czynniki motywujące i czynniki higieny: Czynniki higieny to elementy, których ludzie oczekują w już w momencie podejmowania pracy w wybranej firmie, a więc wypłata, ubezpieczenie, bezpieczeństwo pracy, prawo do urlopu i poczucie wspólnoty. Czynniki motywujące to możliwość zdobycia nowych umiejętności, otrzymania awansu i nagród za wytrwałą pracę. Czynniki higieny nie motywują pracowników, robią to tylko czynniki motywujące, jednakże ich brak ma negatywny wpływ na motywcję. Motywowanie (4)

9 Wg Herzberga istnieją zarówno osoby szukające motywacji, jak i osoby szukające higieny: Szukający higieny – oczekują od pracodawcy: –spójnej polityki i administracji firmy –właściwego nadzoru –odpowiedniego wynagrodzenia –prawidłowych relacji międzyludzkich –godnych warunków pracy. Szukający motywacji – ich zadowalają następujące czynniki –osiągnięcia –uznanie –samodzielna praca –odpowiedzialność –rozwój. Motywowanie (5)

10 Zamiast dużej hali, lepsze wyniki daje umieszczenie dwóch-trzech stanowisk pracy w wielu mniejszych pomieszczeniach. Personalizacja stanowiska pracy. Pokój zebrań dla organizowania formalnych spotkań pracowników. Miejsce dla spotkań nieformalnych (np. omówienie spraw przy kawie). Poczucie pracy na nowoczesnym sprzęcie. Wydajność i chęć ludzi do pracy gwałtownie spada, jeżeli odczuwają oni, że pracują na przestarzałym sprzęcie - nawet wtedy, gdy wymiana sprzętu jest merytorycznie nieuzasadniona. Komfort psychiczny, właściwa atmosfera w pracy, eliminacja napięć i zadrażnień, nie dopuszczanie do rozmywania odpowiedzialności, sprawiedliwa ocena wyników pracy poszczególnych członków zespołu, równomierny rozkład zadań. Ergonomia pracy (1)

11 Ergonomia pracy (2) Sprzyjający układ biura wg McCue’go

12 Czynniki psychologiczne mają zasadniczy wpływ na efektywność pracy zespołu. Wyróżnia się następujące typy psychologiczne: 1. Zorientowani na zadania (task-oriented). Osoby samowystarczalne, zdolne, zamknięte, agresywne, lubiące współzawodnictwo, niezależne. 2. Zorientowani na siebie (self-oriented). Osoby niezgodne, dogmatyczne, agresywne, zamknięte, lubiące współzawodnictwo, zazdrosne. 3. Zorientowani na interakcję (interaction-oriented). Osoby nieagresywne, o niewielkiej potrzebie autonomii i indywidualnych osiągnięć, pomocne, przyjazne. Osoby typu 1 są efektywne, o ile pracują w pojedynkę. Zespół złożony z takich osób może być jednak nieefektywny. Lepsze wyniki dają zespoły złożone z typów 3. Typ 1 i 2 może być także efektywny w zespole, o ile jest odpowiednio motywowany przez kierownictwo. Typy 3 są konieczne w fazie wstępnej wymagającej intensywnej interakcji z klientem. Nastawienie do pracy w zespole

13 Osobowości w zespole (1) TypCechyJak sobie z nim radzić? Urojony przywódca Wydaje mu się, że dziś kieruje projektem, a jutro zacznie rządzić całą firmą. Ten człowiek naprawdę chce rządzić – tylko nie wie jak. Daj mu szansę. Niech poprowadzi zebranie zespołu, albo zorganizuje następny etap prac. Jeśli możesz, naucz go uprzejmego wydawania poleceń. MyszBoi się jakichkolwiek samodzielnych działań, nic nie zrobi bez twojego bezpośredniego polecenia. Ze strachu przed katastrofalna pomyłką wymaga od ciebie ciągłego nadzoru. Taką osobę trzeba zachęcać do wzięcia spraw w swoje ręce. Powiedz jej, że wierzysz, iż wykona przydzielone zadania. Jeżeli popełni błąd, przeanalizujcie go wspólnie – dzięki temu nabierze pewności siebie. Ulubiony wujek lub ciocia To wasz biurowy dowcipniś. Wygłupia się, opowiada kawały i zabawne historyjki, robi innym psikusy. Jest zabawny, ale marnuje strasznie dużo czasu Zazwyczaj ma po prostu za mało pracy i wydaje mu się, że inni też się nudzą. Spróbuj dołożyć mu obowiązków. Jeżeli to nie pomoże, to zwróć uprzejmie uwagę, że jego występy nie zawsze są potrzebne.

14 Osobowości w zespole (2) TypCechyJak sobie z nim radzić? Eksperyment ator Uwielbia emocje. Jest szczęśliwy mogąc sprawdzić co się stanie, jeśli zrobi coś nietypowego. Może mieć duże doświadczenie, ale jest zbyt pewny siebie, a jego wyczyny nie zawsze są przemyślane Podtrzymuj jego cenny entuzjazm, ale powstrzymuj od podejmowania natychmiastowych działań, bez rozważenia ich potencjalnych skutków. Tacy ludzie są bystrzy i przydają się w zespole, ale wymagają pewnego nadzoru. MarudaPonurak. Nie obchodzi go projekt, uważa, że wasza technologia jest do niczego. Robi sobie 20 min. przerwy na kawę. Taki człowiek w zespole, to ciężki orzech do zgryzienia. Sam ma więciej problemów, niż mógłbyś znaleźć w całym swoim projekcie. Zacznij od oswojenia go, poza tym poinformuj przełożonych o wynikach jego pracy. To sprawi, że poczuje większą odpowiedzialność. I poproś, żeby się uśmiechnął.

15 Osobowości w zespole (3) Profile osobowości DISC: osoby dominujące (dominance), osoby inicjatywne (Influnce), osoby o stałej osobowości (Steadiness), osoby skrupulatne (Compliance).

16 Osobowości w zespole (4) Dominacja (Dominance) Podkreśla: Kształtowanie otoczenia poprzez zwalczanie oponentów i podejmowanie wyzwań. Skłonności: Osiąganie natychmiastowych wyników, podejmowanie działań, akceptowanie wyzwań, podejmowanie szybkich decyzji. Motywowany przez: wyzwania, władzę, szybkie odpowiedzi, okazje do wykazania się, uwolnienie od bezpośredniej kontroli, nowe różnorodne działania. Obawy: Utrata kontroli w otoczeniu, przed poczuciem bycia wykorzystywanym. Cechy: pewność siebie, zdecydowanie, podejmowanie ryzyka. Ograniczenia: Nie zwracanie uwagi na innych, niecierpliwość, parcie do przodu bez rozważania konsekwencji.

17 Osobowości w zespole (5) Inicjatywa (Influence) Podkreśla : Kształtowanie otoczenia poprzez perswazję. Skłonności : Zaangażowanie w sprawy ludzi, robienie korzystnego wrażenia, entuzjazm, gościnność, uczestnictwo w grupie. Motywowany przez : Uznanie społeczne, działania i relacje grupowe, swoboda wyrażania się, uwolnienie od kontroli i szczegółów. Obawy : Odrzucenie społeczne, brak akceptacji, brak wpływu. Cechy : Entuzjazm, urok osobisty, prospołeczność, siła przekonywania, wyrażanie emocji. Ograniczenia : Impulsywność, dezorganizacja, niedoprowadzanie spraw do końca.

18 Osobowości w zespole (6) Stałość (Steadiness) Podkreśla : Osiąganie stabilności, wykonywanie zadań we współpracy z innymi. Skłonności : Spokojny, cierpliwy, lojalny, umiejący słuchać innych. Motywowany przez : Rzadkie zmiany, stabilizację, szczere docenienie, współpracę, używanie tradycyjnych metod. Obawy : Brak stabilizacji, nieznane, zmiany, nieprzewidywalność. Cechy : Cierpliwość, stabilność, metodyczne podejście, spokój, opanowanie, ukierunkowanie na grupę. Ograniczenia : Nadmierna chęć dawania, stawianie swoich potrzeb na końcu, opór przed pozytywnymi zmianami.

19 Osobowości w zespole (7) Skrupulatność (Conscientiousness) Podkreśla : Praca w otoczeniu zapewniającym jakość i dokładność. Skłonności : Zwracanie uwagi na standardy i szczegóły, myślenie analityczne, dokładność, dyplomacja i pośrednie podejście do konfliktów. Motywowany przez : Jasno zdefiniowane oczekiwania wobec jego postępowania, doceniana jakość i dokładność, atmosfera z rezerwą, biznesowa, określone standardy. Obawy : Krytyka jego pracy, niechlujne metody, sytuacje emocjonalne poza kontrolą. Cechy : Zachowanie rozważne, dokładne, dyplomatyczne, powściągliwe, perfekcyjne, rzeczowe. Ograniczenia : Nadmiernie krytyczny wobec siebie i innych, niezdecydowanie z powodu chęci zebrania i przeanalizowania danych, kreatywność osłabiona przez potrzebę trzymania się zasad.

20 Role w zespole wg Belbina KoordynatorChair co-ordinator Zapewnia zgodne przywództwo, koordynowanie pracy zespołu, czasami brakuje mu oryginalności LokomotywaShaperAmbitny, dynamiczny, popycha działania do przodu, lubi działać pod presją, przezwyciężać trudności, lubi wygrywać InnowatorPlantŹródło oryginalnych, inspirujących pomysłów, jest kreatywny, czasem przywiązuje się do niepraktycznych pomysłów Krytyk wartościujący Monitor- evaluator Filtruje pomysły grupy i oddziela te, które są praktyczne, często niewrażliwy na odczucia ludzi RealizatorImplementerPraktyczny organizator, zdyscyplinowany, niezawodny, konserwatywny i wydajny. Przekształca idee w praktyczne działania Dusza zespołuTeam workerNastawiony na współpracę, dyplomatyczny, łagodzi tarcia, słucha, buduje, wyczulony na ludzi i sytuacje Skrupulatny wykonawca Completer finisher Sumienny, pilnuje postępu i terminów. Znajduje błędy i opuszczenia. Czasami zbyt drobiazgowy Poszukiwacz źródeł Resource investigator Entuzjastyczny, komunikatywny, bada możliwości, zapewnia kontakt z zewnętrzem, znajduje rozwiązania

21 Dobór personelu Pożądane cechy członków zespołu: podatność na oddziaływanie kierownictwa projektu, umiejętność pracy zespołowej, wysokiej klasy umiejętności techniczne, silna orientacja na rozwiązywanie problemów, silne nastawienie na osiąganie rezultatów, wysoka samoocena, konstruktywna krytyka

22 Cechy dobrego programisty Umiejętność pracy w stresie. W pracy często zdarzają się okresy wymagające szybkiego wykonania złożonych zadań. Dla większości osób niewielki stres działa mobilizująco. Po przekroczeniu jednak pewnego progu następuje spadek możliwości danej osoby. Próg ten jest różny dla różnych osób. Zdolności adaptacyjne. Informatyka jest jedną z najszybciej zmieniających się dziedzin. Ocenia się, że 7-9 miesięcy przynosi w informatyce zmiany, które w innych dziedzinach zajmują 5-7 lat. Oznacza to konieczność stałego kształcenia dla wszystkich inżynierów oprogramowania - stałe poznawanie nowych narzędzi, sprzętu, oprogramowania, technologii, metod, sposobów pracy. Niestety, nie wszyscy to tempo wytrzymują. (Uśpienie, zajmowanie się jednym problemem w jednym środowisku przez lata jest w informatyce bardzo groźne!)

23 Kryteria doboru: Doświadczenie w dziedzinie zastosowania Doświadczenie w pracy z platformą Doświadczenie w pracy z językiem programowania Zdobyte wykształcenie Zdolności komunikacyjne Zdolność do przystosowania się Nastawienie Osobowość Czynniki doboru personelu (1)

24 Czynniki doboru personelu (2) CzynnikOpis Doświadczenie w dziedzinie zastosowania Jeżeli projekt ma zakończyć się sukcesem, to jego twórcy muszą rozumieć dziedzinę zastosowania Doświadczenie w pracy z platformą Może być istotne, jeżeli prace obejmują programowanie na niskim poziomie. W przeciwnym wypadku zwykle nie jest krytycznym atrybutem Doświadczenie w pracy z językiem programowania Zwykle jest istotne jedynie w wypadku krótkotrwałych projektów, przy których nie ma czasu na naukę nowego języka Zdobyte doświadczenie Może być podstawową wskazówką co do tego, co kandydat powinien umieć, i o jego zdolności do uczenia się. Ten czynnik jest mniej istotny, gdy programiści zdobywają coraz więcej doświadczenia w licznych projektach

25 Czynniki doboru personelu (3) CzynnikOpis Zdolności komunikacyjne Są ważne, ponieważ członkowie zespołu muszą porozumiewać się pisemnie i ustnie z innymi współpracownikami, menedżerami i klientami Zdolność do przystosowywania się Tę zdolność można ocenić przyglądając się różnym rodzajom doświadczeń zdobytych przez kandydata. To ważny atrybut, bo z niego wynika zdolność do uczenia się. NastawienieCzłonkowie zespołu powinni być pozytywnie nastawieni do wykonywanej pracy i chcieć zdobywać nowe umiejętności. To bardzo ważny atrybut, ale zwykle bardzo trudny do oceny. OsobowośćTo bardzo ważny atrybut, ale zwykle bardzo trudny do oceny. Kandydaci muszą być racjonalnie zgodni z innymi członkami zespołu. Żaden konkretny typ osobowości nie jest mniej lub bardziej odpowiedni do inżynierii oprogramowania

26 Etapy rozwoju zespołu (1) Tuckman and Jensen (1977) 1.Formowanie 2. Burza 3.Normowanie 4. Wykonywanie czas postęp 5. Przechodzenie

27 Etapy rozwoju zespołu (2) Tuckman and Jensen (1977) EtapOpisRola lidera 1. FormowanieOstrożnie podekscytowani. Pewien niepokój i niepewność członków, do jakiego stopnia będą akceptowani, do jakiego stopnia oni zaakceptują, kto ma władzę jak ją będzie wypełniać, jakie relacje powstaną. Wzmacnia dumę z przynależności do zespołu, uznaje niepewność członków przed „nieznanym” 2. BurzaPowstają konflikty dotyczące celów, przywództwa, metod pracy, relacji, hierarchii. Porozumienia są osiągane i zrywane. Występuje opór przed zadaniami. Lider musi ujawnić i rozwiązać nieporozmienia, musi podkreślić pozytywne rezultaty, jakie da trzymanie się przez zespół podstawowych zasad i norm. Jasność ról powinna być oparta na kompetencjach.

28 Etapy rozwoju zespołu (3) Tuckman and Jensen (1977) EtapOpisRola lidera 3. NormowanieProces burzy daje uzgodnione podejście do podejmowania decyzji, podziału pracy, organizacji spotkań i pracy. Większość członków rozumie i akceptuje normy grupy, w tym swoje role, sens współpracy, unikania konfliktów, podnoszenia atmosfery w grupie i postępu w realizacji zadań. Lider często obserwuje, aniżeli interweniuje, chyba, że jest proszony o arbitraż. Potrzebne są umiejętności rozwiązywania konfliktów.

29 Etapy rozwoju zespołu (4) Tuckman and Jensen (1977) EtapOpisRola lidera 4. WykonywanieGrupa pracuje najbardziej efektywnie. Wykorzystywane są silne strony jej członków i minimalizowane słabe strony. Problemy są konstruktywnie rozpracowywane Lider skupia się na zarządzaniu wykonywaniem, zapewniając doradztwo, szkolenia i sprzężenie zwrotne 5. PrzechodzenieProjekt jest kończony i członkowie przechodzą do innych zadań. Przechodzenie może być trudne, gdy zespół odniósł sukces. Poczucie niedokończonych spraw może blokować przyszły rozwój grupy i poszczególnych jej członków Na zebraniach oraz rozmowach oceniających lider podsumowuje prace i motywuje do podejmowania kolejnych zadań

30 Etapy rozwoju zespołu (5) Tuckman and Jensen (1977)

31 Etapy rozwoju zespołu (6) Tuckman and Jensen (1977) FORMING style values/philosophy roles STORMING feedback rules of engagement power CONFORMING expectations of leaders interdependencies PERFORMING Stage 1 Membership Stage 2 Sub-Grouping Stage 3 Confrontation Stage 4 Individual Differentiation Stage 5 Collaboration MOURNING Stage 6 Disbanding/ Refocusing

32 Celem stojącym przed kierownikiem projektu jest dostarczenie produktu w wymaganym czasie, w ramach danego budżetu i posiadającego odpowiednią jakość. Główne funkcje kierownika projektu: –planowanie, –organizowanie, –motywowanie, –kontrolowanie. Kierownik projektu

33 Odpowiedzialność kierownika projektu może zmieniać się w zależności od firmy i rodzaju projektu. Zawsze obejmuje planowanie i prognozowanie. Dodatkowe obszary odpowiedzialności: odpowiedzialność interpersonalna: prowadzenie zespołu, porozumiewanie się ze zleceniodawcami, zarządem firmy i dostawcami, reprezentowanie projektu na formalnych posiedzeniach i prezentacjach; odpowiedzialność za stan informacji: monitorowanie wydajności personelu, monitorowanie zgodności postępu prac z planem projektu, informowanie zespołu o bieżących zadaniach, informowanie zleceniodawców i zarządu o stanie projektu. odpowiedzialność decyzyjna: alokacja zasobów (np. budżetu) zgodnie z planem projektu, korekta alokacji zasobów, negocjacje ze zleceniodawcą odnośnie interpretacji warunków kontraktu, negocjacje z zarządem firmy odnośnie zasobów (np. czasu komputerów), negocjacje z zespołem odnośnie zadań, rozstrzyganie wszelkich zakłóceń w toku projektu, takich jak awaria sprzętu lub problemy z personelem Kierownik projektu

34 1.Wykonawca. Ostateczny decydent, najwyższy koordynator polityki i jej realizacji. 2.Planista. Wyznacza sposób osiągnięcia celów przez zespół lun grupę. 3.Twórca polityki. Wyznacza, wspólnie z innymi, ale jako decydujący, cele i zasady postępowania w grupie. 4.Ekspert. Odgrywa rolę eksperta, chociaż korzysta z rad innych ekspertów. 5.Reprezentant. Mówi w imieniu grupy i reprezentuje ją na zewnątrz. Do niego docierają wszystkie informacje i od niego rozchodzą się dalej. 6.Organizator. Tworzy strukturę organizacyjną. 7.Nagradzający. Kontroluje osoby mu podległe, mając uprawnienia do nagradzania i stosowania kar. 14 funkcji lidera

35 8.Dający przykład. Poprzez własne działania daje przykład oczekiwanych zachowań. 9.Arbiter. Ostatecznie rozstrzyga wszystkie problemy i kontroluje relacje interpersonalne w grupie. 10.Symbol. Stanowi centrum zespołu, daje jej poczucie jedności, pomaga w odróżnieniu od innych zespołów. 11.Podpora. Członkowie zespołu mogą go wykorzystywać do podejmowania za nich trudnych decyzji. 12.Ideolog. Zespoły potrzebują wiary, wartości i standardów zachowań. Lider to tworzy. 13.Postać ojca. Skupia pozytywne emocjonalne odczucia osób podległych. 14.Kozioł ofiarny. Skupia negatywne emocjonalne odczucia osób podległych. 14 funkcji lidera

36 Skuteczność lidera jest wyznaczania przez jego umiejętność zaspokajania potrzeb w trzech obszarach: zespołu, zadania i jednostki (patrz koła Adaira) Skuteczny lider wg Adaira (1) Potrzeby dotyczące zadania Potrzeby dotyczące jednostki Potrzeby dotyczące zespołu

37 Działania skutecznego lidera dotyczące zadania: osiąganie celów zespołu definiowanie zadań planowanie pracy przydzielanie zasobów wyznaczanie odpowiedzialności monitorowanie postępu i kontrolowanie wydajności kontrolowanie jakości Skuteczny lider wg Adaira (2)

38 Działania skutecznego lidera dotyczące zespołu: budowanie zespołu i utrzymywanie jego ducha tworzenie metod pracy, aby zespół działał spójnie ustalanie standardów i utrzymywanie dyscypliny ustalanie systemów komunikacji w ramach zespołu szkolenie zespołu wyznaczanie podległych kierowników Skuteczny lider wg Adaira (3)

39 Działania skutecznego lidera dotyczące jednostki: rozwój indywidualny zrównoważenie potrzeb grupy i potrzeb indywidualnych nagradzanie dobrej wydajności pomoc w problemach osobistych Skuteczny lider wg Adaira (4)

40 W swojej książce Great Leaders Adair pisze: Istnieją trzy rodzaje potrzeb rozróżnialnych w każdym ludzkim przedsięwzięciu 1.ludzie muszą wiedzieć dokąd zmierzają, dosłownie lub w przenośni, w kategoriach ich codziennych zadań 2.ludzie chcą tworzyć całość jako zespół 3.każda osoba, jako istota ludzka, niesie ze sobą zbiór potrzeb, które wymagają zaspokojenia Skuteczny lider wg Adaira (4)

41 In Project Management: A Systems Approach to Planning, Scheduling, and Controlling, five modes for conflict resolution are explained. These modes are: Confronting, Compromising, Smoothing, Forcing, Avoiding. Conflict resolution

42 Confronting is also described as problem solving, integrating, collaborating or win-win style. It involves the conflicting parties meeting face-to- face and collaborating to reach an agreement that satisfies the concerns of both parties. This style involves open and direct communication which should lead the way to solving the problem. Conflict resolution

43 Confronting should be used when: Both parties need to win. You want to decrease cost. You want create a common power base. Skills are complementary. Time is sufficent. Trust is present. Learning is the ultimate goal. Conflict resolution

44 Compromising is also described as a "give and take" style. Conflicting parties bargain to reach a mutually acceptable solution. Both parties give up something in order to reach a decision and leave with some degree of satisfaction.. Conflict resolution

45 Compromising should be used when : Both parties need to win. You are in a deadlock. Time is not sufficient. You want to maintain the relationship among the involved parties. You will get nothing if you do not compromise. Stakes are moderate. Conflict resolution

46 Smoothing is also referred to as accommodating or obliging style. In this approach, the areas of agreement are emphasized and the areas of disagreement are downplayed. Conflicts are not always resolved in the smoothing mode. A party may sacrifice it's own concerns or goals in order to satisfy the concerns or goals of the other party. Conflict resolution

47 Smoothing should be used when : Goal to be reached is overarching. You want to create obligation for a trade-off at a later time. Stakes are low. Liability is limited. Any solution is adequate. You want to be harmonious and create good will. You would lose anyway. You want to gain time. Conflict resolution

48 Forcing is also known as competing, controlling, or dominating style. Forcing occurs when one party goes all out to win it's position while ignoring the needs and concerns of the other party. As the intesity of a conflict increases, the tendency for a forced conflict is more likely. This results in a win-lose situation where one party wins at the expense of the other party. Conflict resolution

49 Forcing should be used when : A "do or die" situation is present. Stakes are high. Important principles are at stake. Relationship among parties is not important. A quick decision must be made. Conflict resolution

50 Avoiding is also described as withdrawal style. This approach is viewed as postponing an issue for later or withdrawing from the situation altogether. It is regarded as a temporary solution because the problem and conflict continue to reoccur over and over again. Conflict resolution

51 Avoiding should be used when : You can not win. Stakes are low. Stakes are high, but you are not prepared. You want to gain time. You want to maintain neutrality or reputation. You think problem will go away. You win by delaying. Conflict resolution

52 Avoiding is also described as withdrawal style. This approach is viewed as postponing an issue for later or withdrawing from the situation altogether. It is regarded as a temporary solution because the problem and conflict continue to reoccur over and over again. Conflict resolution

53 Zespół lidera-programisty (1) Lider - programista Programista zapasowy Dokumentator Administrator Narzędziowiec Spec. od. sys. op. Autor dok. techn. Tester Wg Bakera, Arona i Brooksa najskuteczniejsze wykorzystanie dobrych programistów osiąga się przez zbudowanie zespołu wokół jednego wysoko wykwalifikowanego lidera-programisty Komunikacja z otoczeniem

54 Głowni członkowie zespołu lidera-programisty: Lider - programista – bierze całkowitą odpowiedzialność za zaprojektowanie, zaprogramowanie, przetestowanie i instalację systemu. Doświadczony programista zapasowy – wspiera lidera-programistę, bierze odpowiedzialność za zatwierdzanie oprogramowania. Dokumentator – przejmuje wszystkie funkcje urzędnicze projektu, takie jak zarządzanie konfiguracjami, redagowanie dokumentów, opracowywanie dokumentacji. Zależnie od rozmiarów i rodzaju tworzonego oprogramowania, mogą być potrzebni inni specjaliści do czasowej lub stałej pracy w zespole. Mogą to być administratorzy, specjaliści od systemów operacyjnych i języków, testerzy itp. Uzasadnienie: najlepsi programiści są do 25 razy bardziej wydajni od najgorszych. Pomysł ma już 30 lat, a ciągle jest skutecznym sposobem organizacji małych grup tworzących oprogramowanie. Zespół lidera-programisty (2)

55 Problemy: Liczba utalentowanych projektantów i programistów jest niewielka. jeżeli oni popełnią błędy, to nikt nie będzie kwestionował ich decyzji. Lider-programista bierze całą odpowiedzialność i może przypisywać sobie wszystkie zasługi w wypadku sukcesu. Członkowie grupy mogą być niezadowoleni, jeżeli ich rola w przedsięwzięciu nie jest doceniana. Ich potrzeba szacunku nie będzie zaspokojona. Przedsięwzięcie będzie zagrożone, gdy lider-programista zachoruje lub odejdzie z firmy. Zarząd firmy może nie chcieć zaakceptować takiego ryzyka. Struktury organizacyjne mogą nie być zdolne do przyjęcia takiej grupy. Wielkie firmy mają starannie zdefiniowaną strukturę. Zespół lidera-programisty (3)

56 Manifest zwinności (Agile Manifesto) Kent Beck (karty CRC, xUnit, XP) Alistair Cockburn (rodzina metodyk Crystal) Marin Fowler (refaktoryzacja, UML Distilled) Jim Highsmith (Adaptive Software Development) Luty 2001, Snowbird, Utah, 17 osób

57 Manifest zwinności (Agile Manifesto) Ważniejsze !!! Jednostki i interakcje niż procesy i narzędzia Działające oprogramowanie niż obszerna dokumentacja Współpraca klienta niż negocjacja kontraktu Nadążanie za zmianami niż trzymanie się planu

58 Manifest zwinności (Agile Manifesto) Crystal & Crystal Light Scrum ( broadest, variable end-point ) DSDM Model ( construction oriented ) Dynamic Systems Development Method Ltd. Lean Development (domain, 80/20 approach ) Feature-Driven Development - FDD (most structured) Adaptive Extreme Programming – XP

59 Manifest zwinności (Agile Manifesto)

60 Programowanie ekstremalne (1) Programowanie Ekstremalne (XP) to lekka, zwinna (ang. agile) metodyka tworzenia oprogramowania Podstawowe zasady XP: Najważniejsza komunikacja ustna. Jedyne artefakty: kod + testy IEEE/ANSI standard 830/1993? Zbędny !!! (IEEE Recommended Practice for Software Requirements Specifications) Inspekcje Fagana? Zbędne !!! Punkty funkcyjne? Zbędne !!! Żadnych nadgodzin!

61 CapGemini: Czwartki 9 i 16 grudnia. Sala 201-C7 w godzinach pkt bonusowy za uczestnictwo w 1 wykładzie Tematy wykładów: Zarządzanie jakością oprogramowania w Capgemini Software Solutions Center we Wrocławiu, Zarządzanie projektami informatycznymi w Capgemini Software Solutions Center we Wrocławiu, Wykłady firmy softwarowej

62 Programowanie ekstremalne (2) 12 praktyk XP wg Kenta Becka: 1.Planowanie. Tworzenie oprogramowania w XP odbywa się przyrostowo przez wdrażanie kolejnych wydań produktu. Planowanie wydania odbywa się przed rozpoczęciem każdej nowej iteracji. Podstawowym celem jest oszacowanie każdej pojedynczej historii użytkownika, powstałej w wyniku gry planistycznej z klientem. Do szacowania używa się jednostek zwanych idealnymi osobo-tygodniami. Idealny osobo-tydzień to tydzień pracy wyłącznie nad programem, bez dodatkowych zajęć, ale wliczający czas testowania programu. 2.Małe wydania. Małe kroki to częste łączenie kodu napisanego przez programistów. Osiąga się je przez podział zadania na małe historie użytkownika. Dzięki temu pojedynczy fragment kodu może być łatwo i szybko wykonany, przetestowany i złączony z reszta systemu. Małe wydania to częste akceptacje powstałego systemu przez klienta. Dzięki ciągłym testom i łączeniu zawsze istnieje sprawnie działająca wersja, a klient nie musi długo czekać na kolejną.

63 Programowanie ekstremalne (3) 12 praktyk XP wg Kenta Becka: 3.Metafora systemu. Każdy zespół programistyczny musi kontaktować się z klientem. Aby możliwe było wzajemne porozumienie potrzebne jest opracowanie wspólnego słownika używanych pojęć. Aby uniknąć problemów z komunikacja oraz ze słownikiem XP stosuje metaforę systemu. Jest to nic innego jak analogiczne do projektowanego oprogramowania pojęcie, które jest w sposób oczywisty zrozumiałe na klienta i dla programisty.. 4.Prosty projekt. XP zakłada, ze wymagania klienta, rynku i sytuacja w branzy ciągle się zmieniają. Nie ma wiec sensu planować rozwiązań, o których nie wiadomo, czy zostaną wykorzystane w przyszłości. Celem XP jest jak najszybsze i najprostsze osiągnięcie satysfakcji klienta przez dostarczenie oprogramowania, spełniającego postawione wymagania..

64 Programowanie ekstremalne (4) 12 praktyk XP wg Kenta Becka: 5.Ciągłe testowanie. Ciągłe testowanie to podstawowe działanie podczas pisania programu w metodzie XP. Programista jeszcze przed napisaniem danej procedury tworzy kod, który ma ją testować. W ten sposób wcześniej musi pomyśleć o wszystkich rzeczach, które mogą ’pójść źle’. Dzięki temu podczas pisania właściwego kodu procedury zabezpieczy ja przed tymi możliwościami. Pisanie procedury testowej nie powinno jednak trwać zbyt długo i nie powinna być ona zbyt rozbudowana. Zespół dąży do automatyzowania procedur testowych, które są uruchamiane po każdorazowym łączeniu kodu oraz po przerabianiu. 6.Przerabianie. Przerabianie (ang. refactoring) jest konieczne zaraz po przetestowaniu działającej procedury. Przerabianie to według autora sformułowania „poprawianie projektu istniejącego kodu”. Należy pamiętać, że przerabianie nie może zmieniać zewnętrznego zachowania programu.

65 Programowanie ekstremalne (5) 12 praktyk XP wg Kenta Becka: 7.Programowanie w parach. Jednym z bardziej krytykowanych aspektów XP. Jednakże diametralnie zmienia ono sposób pisania kodu. Podczas gdy jedna osoba (trzymająca klawiaturę) pisze kod, druga na bieżąco go sprawdza, sugeruje możliwe rozwiązania, może służyć pomocą i zwraca uwagę na błędy syntaktyczne. Tak powstały kod jest nie tylko lepszy ale i łatwiej oraz szybciej się kompiluje. Według Kenta [6] pary powinny się miedzy sobą mieszać. Również programiści wewnątrz pary powinni co jakiś czas zamieniać się miejscami. 8.Standard kodowania. XP narzuca wszystkim programistom wspólny standard kodowania i dokumentowania. Standard taki powinien być ustalony i zaakceptowany przez cała grupę. Standard powinien jednoznacznie określać wygląd kodu, ale nie powinien być zbyt długi i szczegółowy. Polecane są opracowania jednostronicowe. Standard dokumentowania zakłada, ze samych komentarzy w kodzie jest jak najmniej. Klasy powinny być tak zaprojektowane by przeznaczenie poszczególnych metod było jasne, a samo działanie oczywiste.

66 Programowanie ekstremalne (6) 12 praktyk XP wg Kenta Becka: 9.Wspólna odpowiedzialność. Dzięki standardom kodowania każdy programista czuje się jak ’u siebie’ w każdym fragmencie systemu, nawet jeśli go nie pisał. Zbiorowa praca nad kodem, to jednak nie tylko wspólne pisanie go, ale i wspólna odpowiedzialność za niego. Jeśli trzeba cos zmodyfikować nie ma problemu, bo poprawki może zrobić każdy. XP preferuje umieszczenie całej grupy programistów w jednym pomieszczeniu, co ma pomagać w komunikacji i rozwijaniu życia grupy. Zostawia jednak dla każdego jego prywatną przestrzeń. Do pracy w parach powinny być wyznaczone oddzielne komputery. 10.Ciągłe łączenie. Ciągłe łączenie to integracja programu tak często, jak to tylko możliwe. Programista po wykonaniu każdego nowego fragmentu programu łączy go z systemem. Najczęściej stosuje się jedna maszynę, na której w danej chwili może pracować jedna osoba zajmująca się łączeniem kodu. Ciągłe łączenie jest ułatwione w XP dzięki prostym projektom, ciągłym testom i wspólnej odpowiedzialności za kod.

67 Programowanie ekstremalne (7) 12 praktyk XP wg Kenta Becka: godzinny tydzień pracy. Swego rodzaju symbolem, znakiem rozpoznawczym XP, stało się wymaganie 40-to godzinnego tygodnia pracy. Zespoły programistów powinny być przyzwyczajone do stałej wydajności i stałego obciążenia. 12.Ciągły kontakt z klientem. Aby zadowolić wymagania klienta należy bezwzględnie podążać za jego życzeniami. Co jednak zrobić, gdy klient zapomniał nas o czymś poinformować lub mamy problem który wymaga przekonsultowania? Potrzebny jest kontakt z klientem. Często jest on jednak nieosiągalny, co doprowadza do opóźnień w realizacji projektu. XP zakłada ciągłą możliwość konsultacji z klientem ’na żywo’. W praktyce oznacza to codzienna obecność klienta w zespole programistów. Niektórzy twierdzą, że klient nie jest poważny, jeśli nie może poświęcić wystarczająco dużo czasu dla nowego systemu..

68 Programowanie ekstremalne (8) Podstawowe czynności podczas pracy w XP

69 Programowanie ekstremalne (9) Działania podczas typowego dnia pracy XP

70 Programowanie ekstremalne (10) Zespół w XP: W Extreme Programming zespół jest wspólnotą ludzi, którzy razem dążą do celu. Są nie tylko odpowiedzialni za projekt ale i troszczą się o niego. Darzą się wzajemnie szacunkiem i maja silne poczucie więzi. W zespole XP poza programistami są też inne osoby, odpowiedzialne za zarządzanie, oraz pomagające rozwiązywać szczególnie trudne problemy. Są to: –trener, –zarządca, –tester, –konsultant, –szef –klient. Wszystkie one mają bardzo ściśle określone kompetencje i nie powinny wzajemnie sobie wchodzić w drogę. Wszyscy są odpowiedzialni za proces powstawania aplikacji, ale gdy zespół zdobędzie pewne doświadczenie nie wszyscy będą potrzebni..

71 Programowanie ekstremalne (110) Zespół w XP: Programista. Zadania programisty są generalnie te same co zawsze. Celem jego pracy jest stworzenie oprogramowania. Tutaj jednak jego odpowiedzialność jest szersza. Bierze on czynny udział w procesie projektowania oraz sterowania wykonaniem. Programista musi posiąść pewne umiejętności, które nie są wymagane w innych metodykach, nie tylko takie jak testowanie oraz refaktoring, ale i również zdolność łatwego komunikowania się oraz posiadać wrodzony nawyk prostoty.

72 Programowanie ekstremalne (12) Zespół w XP: Klient. Klient w XP zajmuje szczególnie ważne miejsce. Zajmuje on stałe miejsce przy projektowaniu (gra w planowanie) oraz przy testowaniu (testy akceptacyjne). Ponadto kontroluje wykonanie aplikacji (choć nie może nim sterować) i podejmuje decyzje o kolejności realizacji modułów. Aby mógł sprostać tym zadaniom powinien nauczyć się pisać testy funkcjonalne oraz tworzyć opisy (historie użytkownika).

73 Programowanie ekstremalne (13) Zespół w XP: Tester. Tester spełnia funkcję kontrolną wobec programisty, ale nie na zasadzie ustawianie się w opozycji do niego. Jego zadaniem jest regularne uruchamianie testów i publiczne ogłaszanie ich wyników. Jego podstawowym współpracownikiem jest klient, któremu pomaga tworzyć i wykonywać testy funkcjonalne. Z czasem, jeśli klient nabiera doświadczenia jego rola może malec. Koncentruje się wtedy na potwierdzaniu testów

74 Programowanie ekstremalne (14) Zespół w XP: Konsultant. Czasem potrzebna jest określona wiedza specjalistyczna. Zespół nie powinien w takiej sytuacji tracić czasu na poszukiwanie rozwiązania, lecz powinien uzyskać je od konsultanta

75 Programowanie ekstremalne (15) Zespół w XP: Trener (coach) Trener jest osobą, która ponosi odpowiedzialność za cały proces tworzenia systemu. Musi utrzymać zespół na właściwej drodze do rozwiązania. Aby to zrobić musi posiadać spore doświadczenie, musi głęboko rozumieć istotę XP i potrafić dobrze nim sterowac. Jego działanie czesto jest posrednie przez zasugerowanie zmiany kierunku pracy przy pomocy okreslonego testu, badz przypadku. Pomaga w ten sposób zespołowi w samodzielnym dojsciu do poprawnych decyzji. Powinien tez wiedziec ile czasu potrzeba na zrobienie danego zadania. Zna tez sposoby zaradzenia pojawiającym sie problemom. Czesto trener musi byc dostepny jako partner do programowania dla mniej doswiadczonych. Pomaga w tworzeniu testów i refaktoringu. Jego rola moze malec wraz z rozwijaniem się zespołu i dochodzenia do wspólnej odpowiedzialnosci za projekt

76 Programowanie ekstremalne (16) Zespół w XP: Zarzadca (tracker). Zarządca jest swego rodzaju sumieniem zespołu. Jest on odpowiedzialny za właściwe szacowania. Kontroluje czy oczekiwania maja odzwierciedlenie w rzeczywistości. Sledzi obciazenie i jakosc oszacowan (na podstawie danych z przeszłosci) kazdego programisty. Jako historyk zespołu prowadzi dziennik testów funkcjonalnych, wykrytych wad, osób za nie odpowiedzialnych i testów, które pozwoliły je wykryć. Jego praca nie moze jednak zbytnio obciążać zespołu. Potrzebne mu dane powinien zbierać w sposób maksymalnie niezauważalny

77 Programowanie ekstremalne (17) Zespół w XP: Szef. Szef ma prawo wymagac rzetelnej komunikacji z zespołem. Jezeli cos idzie nie tak powinien byc natychmiast poinformowany. Moze wtedy zaproponowac pewne rozwiazania, ale nie ma władzy nad terminarzem projektu. To zespół okresla warunki realizacji na podstawie srodków zapewnionych przez szefa. Zespół ma prawo oczekiwac od niego odwagi, zaufania, zrozumienia i szybkich, kompetentnych reakcji. Taki szef bedzie dobrze kierował zespołem XP, a jego zespół bedzie zadowolony z pracy. Moze się jednak zdarzyc, ze szef bedzie musiał zatrzymac bezsensowne działania zespołu, które nie przynosza efektu.

78 Programowanie ekstremalne (18) Zespół w XP: Zapewnienie własciwych warunków pracy. Aby zespół mógł dobrze funkcjonowac musi mieć zapewnione odpowiednie warunki pracy. Pomieszczenie powinno byc wspólne dla wszystkich, tak by zapewnic swobodna komunikacje. Jednoczesnie powinny istniec (byc moze pod scianami) miejsca na prywatne rozmowy, odgrodzenie się od reszty w razie potrzeby oraz przechowywanie prywatnych rzeczy. Wyniki pracy i sledzenie postepów powinny byc widoczne na zawieszonych na scianach tablicach. Komputery do pracy w parach umieszczone są w centrum. W ten sposób łatwiej siadac przy nich w dwie osoby. Całosc powinna być zaakceptowana i lubiana przez cały zespół. Musi się on czuc dobrze, przydatne moga być odpowiednie gadzety i lubiane przez nich przedmioty. Miejsce wspólne z kanapa i ekspresem do kawy powinno byc maksymalnie sympatyczne i przyjemne..

79 Programowanie ekstremalne (19) Co to znaczy wybrać XP: Szefowie, którzy zdecydują się na wprowadzenie XP muszą być świadomi jakie to rodzi konsekwencje. Przede wszystkim musza zgodzić się na oddanie programistom władzy nad sterowaniem projektem. Musza ograniczyć zespół do maksymalnie 10 osób. Autorzy metody podkreślają, ze zespół tej wielkości sprawnie pracujący w XP może być o wiele wydajniejszy niż o wiele większe grupy pracujące w ciężkich metodykach. Szefowie muszą również potrafić sterować wspólnym życiem grupy ludzi w zespole. Muszą potrafić zorganizować miejsce pracy tak by było przyjazne, pomagało w komunikacji oraz pozwalało na celebrowanie wspólnych spotkań, posiłków i rozmów, a jednocześnie zapewniało niezbędną prywatność i spokój..

80 Programowanie ekstremalne (20) Czemu zapobiega XP: Przy przestrzeganiu zasad wydaje się oczywiste, ze stosując tę metodę można zapobiec –wykonywaniu pracy która nie ma znaczenia, bo zgodnie z zasadą minimalizacji rozwiązania robimy tylko to co jest potrzebne, –częstemu anulowaniu projektów, bo ciągły kontakt z klientem zapewnia spełnienie jego wymagań, a jego udział w procesie projektowania zapewnia dobranie właściwego harmonogramu prac –wykonywaniu pracy z której nie jest się dumnym, bo tworzony kod jest najwyższej jakości, a cały zespół pracuje nad osiągnięciem perfekcyjnego produktu..

81 Programowanie ekstremalne (21) Co daje XP: Zyski z wprowadzenia XP są oczywiste, nie da się ich jednak dobrze opisać i pojąć bez własnoręcznego wypróbowania. Wprowadzenie XP daje nie tylko bardzo dobrą aplikację, ale i dużo satysfakcji z własnej pracy. Kent Beck podkreśla, że nie bez znaczenia jest również stałe obciążenie zespołu i postawienie nacisku na nieprzemęczanie go. Doprowadza to oczywiście do mniejszego stresu i w rezultacie również zwraca się w podniesieniu jakości pracy. Współtwórca XP Kent Beck mówi, że „XP jest proste w szczegółach, ale trudne w realizacji.”

82 Programowanie ekstremalne (10) Słabości XP: brak dokumentacji klient „na miejscu” i tylko jeden zbyt krótka perspektywa planowania Jak rozwiązać te problemy i zachować zwinność?

83 Programowanie ekstremalne (11) Różnice między XP a innymi metodami są następujące: wczesne, konkretne i ciągłe informacje zwrotne w krótkich cyklach programowania; planowanie przyrostowe, które szybko owocuje planem ogólnym rozwijającym się w czasie trwania projektu; zdolność do elastycznego planowania implementacji funkcjonalności, zależnie od zmieniających się potrzeb;

84 Metodologia Scrum Scrum to metodyka prowadzenia projektów. Zaliczana do tzw. metodyk lekkich, (zwinnych, ang. Agile Project Management), zgodnych z The Agile Manifesto. Najczęściej wykorzystywana jest w projektach informatycznych. Nazwa "scrum", czyli po polsku "młyn", wywodzi się z terminu występującego w grze rugby. Używana jest w skomplikowanych projektach, w których nie można przewidzieć wszystkiego, co może się przydarzyć lub w przypadku przedsięwzięć o wysokim stopniu innowacyjności.

85 Metodologia Scrum Metodyka skupia się na: dostarczaniu kolejnych, coraz bardziej dopracowanych wyników projektu, włączaniu się przyszłych użytkowników w proces wytwórczy, samoorganizacji zespołu projektowego.

86 Metodologia Scrum Zespół i role: Zazwyczaj zespół Scrum składa się od 5 do 9 osób. Dobrze, gdy ma charakter interdyscyplinarny i składa się z osób reprezentujących różne umiejętności. Osoby uczestniczące w zespole nie mogą uczestniczyć w innych zespołach. Główne role w projekcie grają: "Mistrz Młyna" (Scrum Master), Właściciel Produktu (Product Owner) Członkowie Zespołu (The Team).

87 Metodologia Scrum Cykl życia Scrum 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting

88 Metodologia Scrum

89 Opis metodyki (1) Zespół projektowy pracuje w określonym przedziale czasowym zwanym przebiegiem (ang. sprint). Efektem przebiegu za każdym razem powinno być dostarczenie użytkownikom kolejnego działającego produktu. Zasadą jest to, że zmiany wprowadzane w jednym przebiegu muszą być namacalne dla użytkowników. Muszą wnosić wartość funkcjonalną. Przebieg może trwać od 2 do 6 tygodni. Zaleca się stosowanie przebiegów o stałych długościach.

90 Metodologia Scrum Opis metodyki (2) W pierwszym etapie tworzona jest lista wymagań użytkownika, są one gromadzone w postaci „historyjek”. Każda historyjka opisuje jedną cechę systemu. Właściciel projektu jest też zobowiązany do przedstawienia priorytetów wymagań oraz głównego celu przebiegu. Po tym formułowany jest rejestr wymagań. Cel przebiegu jest zapisywany w widocznym miejscu w pokoju członków zespołu.

91 Metodologia Scrum Opis metodyki (3) Następnie wybierane są zadania o najwyższym priorytecie, a jednocześnie przyczyniające się do realizacji celu projektu. Szacuje się czas realizacji każdego zadania. Lista zadań wraz z oszacowaną czasochłonnością nosi nazwę rejestru zadań przebiegu (sprint backlog).

92 Metodologia Scrum Opis metodyki (4) Po etapie przygotowawczym zespół przechodzi do realizacji przebiegu (sprinta). W jego trakcie Właściciel Produktu nie może ingerować w prace zespołu. Nie powinno się także zmieniać zakresu sprintu.

93 Metodologia Scrum Opis metodyki (5) Jako że zespół z założenia jest samoorganizującym się ciałem, nie ma mowy o odgórnym przypisywaniu zadań do poszczególnych członków zespołu, lecz samodzielnie dokonują oni wyboru realizowanych zadań, według wspólnych ustaleń, umiejętności czy innych preferencji.

94 Metodologia Scrum Opis metodyki (6) Naczelną zasadą metodyki jest przeprowadzanie codziennych (około 15 minut) spotkań (z ang. scrum meeting), na których omawiane są zadania zrealizowane poprzedniego dnia i problemy występujące przy ich realizacji oraz zadania do wykonania w dniu spotkania.

95 Metodologia Scrum Opis metodyki (7) Sprint kończy się spotkaniem Sprint review, na którym prezentowany jest wynik pracy zespołu poprzez prezentowanie produktu wykonanego podczas przebiegu. Powinni w nim uczestniczyć wszyscy zainteresowani projektem. Na spotkaniu, każdy członek zespołu może zabrać głos i wyrazić opinię o produkcie. Po omówieniu produktu ustalany jest termin spotkania planistycznego do następnego przebiegu.

96 Metodologia Scrum

97 RequirementsDesignCode Test W czasie przebiegu (sprintu) projektuje się, koduje i testuje produkt

98 Sprint Burndown (1) By reviewing a sprint burndown report, you can track how much work remains in a sprint backlog, understand how quickly your team has completed tasks, and predict when your team will achieve the goal or goals of the sprint

99 Sprint Burndown (2)

100 Sprint Burndown (3) A sprint burndown report shows how much work remained at the end of specified intervals during a sprint. The source of the raw data is the sprint backlog. The horizontal axis shows days in a sprint, and the vertical axis measures the amount of work that remains to complete the tasks in the sprint. The work that remains is shown in hours,

101 Sprint Burndown (4) A sprint burndown graph displays the following pieces of data: The Ideal Trend line indicates an ideal situation in which the team burns down all of the effort that remains at a constant rate by the end of the sprint. The In Progress series shows how many hours remain for tasks that are marked as In Progress in a sprint. The To Do series shows how many hours remain for tasks that are marked as To Do in a sprint. Both the In Progress and the To Do series are drawn based on the actual progress of your team as it completes tasks.

102 Sprint Burndown (5) Required Activities for Tracking Work Items For the burndown report to be useful and accurate, your team must perform the following activities for tracking tasks: Define tasks, and specify their Iteration and Area paths. For more information, see Create and Modify Areas and Iterations. Specify and update the Remaining Work field for each task or subtask as it is worked on.

103 Sprint Burndown (6) Report interpreting You can review the report to determine the progress that your team has made in a release and answer the following questions: How much work remains in the sprint? Is your team on track to finish all work for the sprint? When will your team finish all work for the sprint? How much work for the sprint is in progress?

104 Metodologia Scrum Sprint Planning Meeting Product BacklogTeam CapabilitiesBusiness ConditionsTechnologyCurrent Product Sprint Backlog Product OwnerScrum TeamManagementCustomers Sprint Goal

105 Sukces wg MSF Microsoft Solution Framework Zadowolony klient (długoterminowo) Utrzymanie w ryzach (funkcjonalność, czas, zasoby) Zgodność ze specyfikacją tworzoną na podstawie wymagań klienta „Addressing all known issues” – podjęcie wszystkich rozpoznanych problemów Łatwość wdrożenia i pielęgnacji

106 RÓWNORZĘDNOŚĆ ! (Team of Peers) – brak hierarchii Tradycyjne zespoły hierarchiczne mają problemy komunikacyjne Zmienny lider Zaufanie, uznanie, dążenie do celu, rozliczalność Samoocena (wewnątrz zespołu) Sukces (porażkę) odnosi zespół Homeostat – samoregulacja, autonaprawa, sterowanie celem Zasady działania zespołu MSF (1) Microsoft Solution Framework

107 Zasady działania zespołu MSF (2) Wspólna wizja projektu. Pełna współpraca. Uczenie się na doświadczeniach zdobytych w poprzednich projektach. Wspólne zarządzanie projektem oraz podejmowanie decyzji. Brak jednego, głównego kierownika projektu. Wspólna praca członków projektu w jednym miejscu. 6 równoważnych ról Każdy pracownik pełni jedną lub więcej ról Są role których nie powinno się ze sobą łączyć

108 Kierownik logistyki Tester Kierownik produktu Kierownik programu Edukator użytkowników Wytwórca Komunikacja „Team of peers” Współzależne i współpracujące role Każdy członek ma jasne cele i zadania Współdzielone zarządzanie projektem Niekoniecznie 6 osób! Zasady działania zespołu MSF (3)

109 Zasady działania zespołu MSF (4) Role –Każdy członek zespołu przyjmuje jedną lub więcej ról Potoki pracy (workstream) i czynności –Role wykonują przypisane im czynności, które są połączone w potoki pracy Produkty pracy –Dokumentacja, kod źródłowy, plany projektowe

110 Role w zespole MSF (1) Kierownik produktu rola: zarządzanie produktem (product management) prowadzenie zespołu w kierunku realizacji oczekiwań klienta, reprezentowanie klienta przed zespołem reprezentowanie zespołu przed klientem, BUFOR określanie zakresu projektu, opracowywanie i realizowanie planu komunikacji z klientem i użytkownikami

111 Kierownik programu rola: zarządzanie pracami projektowymi (program management) zarządzanie procesem realizacji projektu zarządzanie zasobami, alokacją zasobów zarządzanie harmonogramem, ograniczeniami projektu, odpowiedzialność za dostarczenie właściwego produktu we właściwym czasie, odpowiedzialność za zakres produktu i specyfikację, tworzenie raportów o stanie prac projektowych, organizacja komunikacji wewnątrz zespołu projektowego, łagodzenie konfliktów, kierowanie podejmowaniem krytycznych decyzji. Role w zespole MSF (2)

112 Role w zespole MSF (3) Wytwórca rola: tworzenie produktu (development) budowa i testowanie produktu spełniającego wymagania i oczekiwania klienta, uczestnictwo w projektowaniu produktu, szacowanie czasu i pracy do wykonania produktu, konsultacja w sprawach technologii, pomoc przy instalacji i wdrożeniu produktu, tworzenie, konfigurowanie i dostosowywanie produktu do klienta (customization).

113 Role w zespole MSF (4) Tester rola: Testowanie (Testing) opracowanie strategii, planów i skryptów testowania, zarządzanie procesem tworzenia „buildów” kontrola procesu i stanu budowy produktu: co jest źle, co jest już dobrze, przeprowadzanie testów, uczestniczenie w określaniu kryteriów jakości.

114 Role w zespole MSF (5) Edukator użytkowników rola: szkolenie użytkowników (User Education) uczestniczenie w zbieraniu wymagań użytkowników i określaniu funkcji systemu, reprezentowanie oczekiwań użytkowników przed zespołem projektowym, planowanie szkoleń, przygotowanie materiałów szkoleniowych i instrukcji sprawnego posługiwania się systemem, projektuje i wdraża system pomocy („user support”), uczenie użytkowników sprawnego posługiwania się produktem.

115 Role w zespole MSF (6) Kierownik logistyki rola: logistyka (Logistics Management) adwokat zespołu wobec „administracji” adwokat „administracji” wobec zespołu zapewnienie że produkt jest wdrażalny, pielęgnowalny i że firma będzie wspomagała jego eksploatację, planowanie i zarządzanie wersjami uczestnictwo przy projektowaniu, wspomaganie testów beta produktu, wspomaganie działu operacyjnego przy konfigurowaniu środowiska i samego produktu.

116 Role i cele w zespole MSF RolaCel Kierownik produktuZadowolony klient Kierownik programu Dostarczenie produktu w ramach ograniczeń projektowych Wytwórca Dostarczenie produktu zgodnego ze specyfikacją Tester Sprawdzenie wszystkich potencjalnych problemów Edukator użytkownikaSprawne użycie systemu przez użytkowników Kierownik logistykiSprawne wdrożenie produktu

117 Łączenie ról w zespole MSF █ Możliwe █ Rzadko █ Nie rekomendowane

118 Komunikacja w zespole MSF

119 Dobry zespół MSF Wspólna wizja Nastawienie na produkt finalny „Zero-defect mindset” Zogniskowanie na potrzeby klienta Chęć do nauki !

120 Skalowanie w dużych projektach (1) Optymalny zespół to 7-11 osób Minimalny – 3 (konflikt interesów !) Powyżej osób komunikacja staje się niemożliwa Zespół w jednej lokacji ! Skalowanie – tworzenie podzespołów użytkowych – „feature team” Skalowanie – tworzenie podzespołów funkcjonalnych – „function team”

121 Feature Team –Zespoły MSF – owe dla realizacji funkcji (np. zespół odpowiedzialny za realizację drukowania...) –„Hierarchia” zespołów, lead team, komunikacja odpowiedników ! Function Team –Jeden zespół, ale rola składa się z wielu osób (np. Product Management ma osobę tylko do funkcji „evangelism”) Skalowanie w dużych projektach (2)

122 Kierownik programu Wytwórca Tester Edukator Kierownik produktu Kierownik logistyki Kierownik programu Wytwórca Tester Edukator Kierownik programu Wytwórca Tester Edukator Kierownik programu Wytwórca Tester Edukator Raporty Interfejsy Jądro systemu Zespół wiodący Skalowanie w dużych projektach (3)

123 Kierownik programu Edukator Model zespołu z 7 rolami 7 rola to Architekt, który dba o całość produktu

124 Kierownik programu Edukator Rozszerzenie do struktury przedsiębiorstwa Program Management Program Management Development Testing Release Management Release Management User Experience User Experience Product Management Product Management Communication Project Managemen t Office Project Office Steering Committee

125 Struktura zarządzania firmą programistyczną Kierownik programu Dyrektor d/s programistycznych Kierownik programu Kierownik d/s jakości Kierownik projektu Kierownik projektu Koordynator projektu ze strony klienta Kierownik projektu Kierownik projektu Koordynator projektu ze strony klienta Szef zespołu programistycznego Nie powinien podlegać kierownikom programów i przedsięwzięć

126 Funkcje osób pracujących nad oprogramowaniem (1) Kierownik programu/projektu Analityk - osoba bezpośrednio kontaktująca się z klientem, której celem jest określenie wymagań i budowa modelu systemu Projektant - osoba odpowiedzialna za realizację oprogramowania. Może posiadać bardziej wyspecjalizowane funkcje: Programista - osoba implementująca oprogramowanie Osoba wykonująca testy Osoba odpowiedzialna za konserwację oprogramowania

127 Funkcje osób pracujących nad oprogramowaniem (2) Ekspert metodyczny - osoba szczególnie dobrze znająca stosowaną metodykę Ekspert techniczny - osoba szczególnie dobrze znająca sprzęt i narzędzia Model analityk/projektant + programista: funkcje analizy i projektu w jednych rękach, funkcje programisty dość niskiego poziomu. W warunkach polskich model nie zdaje egzaminu. Model analityk + projektant/programista: Model bardziej realistyczny.

128 Role w zespole realizującym (1) Kierownik programu Analityk – osoba bezpośrednio kontaktująca się z klientem w celu określenia wymagań i budowy modelu systemu Projektant – osoba odpowiedzialna za realizację oprogramowania, w zależności od zakresu prac można wyróżnić dwie funkcje: Projektant interfejsu użytkownika – osoba odpowiedzialna za zaprojektowanie zgodnego ze standardami interfejsu użytkownika Projektant baz danych – osoba odpowiedzialna za zaprojektowanie i dostrojenie baz danych. Programista – osoba implementująca oprogramowanie

129 Role w zespole realizującym (2) Osoba wykonująca testy Osoba odpowiedzialna za konserwację oprogramowania Ekspert metodyczny – osoba o szczególnie dobrej znajomości stosowanej metodyki Ekspert techniczny – osoba dobrze znająca obsługę narzędzi

130 Opis ról (1)

131 Opis ról (2)

132 Opis ról (3)

133 Co to jest komunikacja ? Komunikacja to proces w którym ludzie dzielą się znaczeniami informacji (komunikatów). Najprostszy model komunikowania się polega na przekazywaniu przez nadawcę komunikatu (werbalnego lub niewerbalnego) i odebraniu go przez odbiorcę. Komunikowanie się może być realizowane przez wypowiedzi ustne, pisemne i różne formy wizualne oraz tzw. mowę ciała (body language), np. różnego rodzaju gesty, barwę i ton głosu, mimikę twarzy. Komunikowanie się może być jednokierunkowe – nadawca przekazuje informacje bez oczekiwania ich potwierdzenia przez odbiorcę, lub dwukierunkowe – nadawca uzyskuje potwierdzenie przekazanej informacji, np. w formie pytań zadawanych przez odbiorcę.

134 Cele komunikowania się Specyfikacja celów i zadań Dokonywanie decyzji i ich wprowadzanie w życie Pomiary i ocena postępów Współpraca z klientami i dostawcami Współpraca z administracją i instytucjami rządowymi Osiąganie zysków

135 Najlepsze dostępne praktyki Pozwala zidentyfikować oraz usuwać lub poprawić nieskuteczne metody działania. Pozwala podnosić wydajność słabszych pracowników. Uniknięcie „ponownego wynalezienia koła”. Oszczędność kosztów.

136 Komunikacja w zespole projektowym Większość zadań zespołu jest realizowane dzięki współpracy między członkami zespołu. Kierownik projektu powinien cały czas nawiązywać i podtrzymywać dobry kontakt z pozostałymi członkami zespołu. Większość czasu pracy zespół spędza na porozumiewaniu się z innymi osobami.

137 Dzielenie się wiedzą w zespole projektowym Jest przywiązana do posiadających ją osób. Nie da się jej łatwo przekazać. Im bardziej jest wykorzystywana tym bardziej zyskuje na wartości. Niewykorzystywana zanika.

138 Typy komunikacji Zamierzona i bezwiedna Werbalna i niewerbalna Formalna i nieformalna W ewnętrzna i z otoczeniem Komunikacja osobista, na piśmie i za pośrednictwem elektroniki.

139 Przebieg procesu komunikacji Komunikujemy się głównie przekazując komunikaty ustnie lub w formie pisemnej. Wybór formy jego przekazania powinien być świadomy: powinien zapewniać skuteczność i efektywność. Czasami decydujemy o formie nie w pełni świadomie - raczej kierujemy się własną wygodą, impulsem, przyzwyczajeniem. Ryzykujemy wówczas popełnienie błędu i nieosiągnięcie celu.

140 Sposoby komunikowania Prezentacje Wystąpienia Dokumentacja projektu (plan, raporty, etc.) Spotkania Dyskusje Notatki Poczta Formalna Nieformalna Werbalna Pisemna Wsparcie narzędzi informatycznych

141 Efektywność metod komunikacji

142 Struktury zespołu programistycznego Struktura sieciowa – każdy z członków zespołu komunikuje się i współpracuje z pozostałymi Struktura gwiaździsta – szef zespołu jest jedyną osobą ściśle współpracującą z pozostałymi osobami

143 Wady i zalety struktury sieciowej Dzięki ścisłej współpracy członkowie zespołu wzajemnie kontrolują swoją współpracę. Realizowana jest idea wspólnego programowania Praca poszczególnych osób jest dobrze znana innym członkom zespołu, stąd przejęcie obowiązków przez inną osobę nie nastręcza dużych kłopotów Struktura sieciowa nie może liczyć więcej niż 8 osób Osoby w zespole powinny posiadać podobne doświadczenie

144 Wady i zalety struktury gwiaździstej Wymiana informacji pomiędzy osobami w zespole odbywa się za pośrednictwem koordynatora Szczególnie przydatna, jeżeli w skład zespołu wchodzi wielu niedoświadczonych pracowników Wielkość zespołu - największe znaczenie ma czynnik ludzki. Największy problem pojawia się w chwili odejścia koordynatora zespołu

145 Inne struktury komunikowania się zespołu

146 Zarządzanie komunikacją w grupie projektowej obejmuje procesy, które maj ą zapewnić odpowiednie zbieranie, udostępnianie, przechowywanie i dyspozycyjno ść informacji. Zapewnia łączność między uczestnikami projektu. Każdy związany z projektem musi być przygotowany do wysyłania i odbierania komunikatów w „języku projektowym” i musi zdawać sobie sprawę z wpływu jego komunikatów na cało ść projektu. Podstawowe procesy zwi ą zane z komunikacją w grupie projektowej: –Planowanie komunikacji (Communications Planning). –Dystrybucja informacji (Information Distribution). –Raportowanie o postępach (Performance Reporting). Procesy te powinny pojawi ć si ę przynajmniej raz w ka ż dej fazie projektu. Komunikacja w projekcie

147

148

149 Jest ono ważnym czynnikiem decydującym o sukcesie projektu. W wi ę kszości przypadków planowanie komunikacji jest częścią fazy początkowej projektu, jednak rezultaty tego procesu powinny by ć przeglądane co jakiś czas i w razie potrzeby modernizowane. wybór sposobu przekazu zależy od: wiadomości, odbiorców, wymagania dotyczące szybkości przekazu, sytuację, czynniki kulturowe Planowanie komunikacji

150 Co powinniśmy przygotować przed przystąpieniem do Planowania Komunikacji:  Wymogi komunikacyjne (Communications requirements).  Technologie komunikacji (Communications technology).  Dostępność technologii.  Dostępny personel.  Długość projektu. Co otrzymujemy w rezultacie Planowania Komunikacji:  Plan zarządzania komunikacj ą. Komunikacja w projekcie (cd.)

151 Dystrybucja informacji obejmuje udostępnianie informacji potrzebnych osobom związanym z projektem. Polega na wprowadzeniu w życie Planu zarządzania komunikacją jak również reagowanie na nieoczekiwane żądania informacji. Czego potrzebujemy? – Wyniki pracy. – Plan zarządzania komunikacją. – Plan projektu. Co otrzymujemy jako rezultat tego procesu: –Dane o projekcie (korespondencja, notatki, raporty, dokumenty opisujące projekt...) Dystrybucja informacji

152 Narzędzia i techniki dystrybucji informacji: Umiejętność komunikacji. Rodzaje komunikacji: – Pisemna/ustna, słuchanie i mówienie. – Wewnętrzna i zewnętrzna. – Formalna i nieformalna. – Pionowa i pozioma. System przechowywania informacji. System dystrybucji informacji. Dystrybucja informacji (cd.)

153 Raportowanie o postępach obejmuje zbieranie informacji o postępach w projekcie mające na celu udostępnienie osobom związanym z projektem informacji w jaki sposób wykorzystywane są wszelkie środki do osiągnięcia sukcesu. Obejmuje ono: –Raportowanie o statusie – w jakiej fazie znajduje si ę projekt. –Raportowanie o postępach – co udało się osi ą gn ąć grupie projektowej. –Przewidywanie o przyszłych post ę pach i statusie. Czego potrzebujemy: – Plan projektu. – Wyniki pracy. – Inne dane dotyczące projektu. Raportowanie o postępach

154 Narzędzia i techniki raportowania o postępach: –Przegląd postępów. – Wszelkie analizy (porównanie rezultatów osiągniętych z zakładanymi – koszty, terminy...) – Analiza trendu projektu (określa czy postępy w miarę upływu czasu są coraz lepsze czy coraz gorsze). – Narzędzia i techniki dystrybucji informacji. Co otrzymujemy? –Raport o postępach. –Wymagania zmian. Raportowanie o postępach (cd.)

155 Raporty o charakterze informacyjnym Obrazują postęp prac projektowych Odbiorcami są : sponsor, zleceniodawca, inni partnerzy zewnętrzni Najlepiej jeśli tego rodzaju raporty mają charakter cykliczny (przygotowywane w określonych terminach). Sprzyjają wytworzeniu atmosfery partnerstwa i współodpowiedzialności. Raporty zewnętrzne

156 Zebrania mogą mieć charakter –Informacyjny –Roboczy (rozdział zadań do realizacji) –Uzgodnień realizacyjnych –Narad roboczych, organizowanych w celu rozwiązania jakiegoś problemu. Organizacja zebrań

157 Usługi telekomunikacyjne –Telefon –Telefaks –Rozmowy konferencyjne (trzech lub więcej rozmówców) –poczta głosowa (voice mail) –Callback –Automatyczne wybieranie aż do skutku (gdy numer jest zajęty) –Usługa IVR –speed calling (automatyczne nadawanie komunikatów do zaprogramowanej liczby rozmówców) Systemy komunikacji mobilnej –Smartfony –GPS Technologie komunikacji

158 Technologie internetowe – –Grupy dyskusyjne –Wideo konferencje –Komunikatory –VoIP –Intranet –i wszystkie inne omawiane w czasie prezentacji na projektach Technologie komunikacji (cd.)

159 Intranet- strona z informacjami o projekcie, system współdzielenia plików Narzędzia do zarządzania czasem, organizowania spotkań, informowania innych o własnych czynnościach Narzędzia komunikacyjne

160 Dziękuję za uwagę


Pobierz ppt "Zarządzanie projektem informatycznym Prowadzący: dr inż. Bogdan Trawiński Wykład 11 i 12 Zarządzanie zespołami i komunikacją."

Podobne prezentacje


Reklamy Google