Zarządzanie projektem informatycznym

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

Praca zespołowa (1) 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 (2) 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 (3) 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

Motywowanie (1) 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.

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

Motywowanie (3) 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 (4) 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 (5) 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.

Ergonomia pracy (1) 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ń.

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

Nastawienie do pracy w zespole
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.

Osobowości w zespole (1)
Typ Cechy Jak 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ń. Mysz Boi 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.

Typ Cechy Jak sobie z nim radzić? Eksperymentator 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. Maruda Ponurak. 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ął.

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

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.

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.

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.

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.

Role w zespole wg Belbina
Koordynator Chair co-ordinator Zapewnia zgodne przywództwo, koordynowanie pracy zespołu, czasami brakuje mu oryginalności Lokomotywa Shaper Ambitny, dynamiczny, popycha działania do przodu, lubi działać pod presją, przezwyciężać trudności, lubi wygrywać Innowator Plant Ź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 Realizator Implementer Praktyczny organizator, zdyscyplinowany, niezawodny, konserwatywny i wydajny. Przekształca idee w praktyczne działania Dusza zespołu Team worker Nastawiony 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

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

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

Czynniki doboru personelu (1)
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ść

Opis 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

Opis 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ę. Nastawienie Czł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

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

Tuckman and Jensen (1977) Etap Opis Rola lidera 1. Formowanie Ostroż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. Burza Powstają 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.

Tuckman and Jensen (1977) Etap Opis Rola lidera 3. Normowanie Proces 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.

Tuckman and Jensen (1977) Etap Opis Rola lidera 4. Wykonywanie Grupa 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. Przechodzenie Projekt 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ń

Tuckman and Jensen (1977)

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

Główne funkcje kierownika projektu:
Kierownik projektu 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 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

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

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

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

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

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

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

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

Conflict resolution 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 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 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 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 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 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 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 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 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 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 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 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.

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

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.

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

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

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

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

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!

Wykłady firmy softwarowej
CapGemini: Czwartki 9 i 16 grudnia. Sala 201-C7 w godzinach 1 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,

12 praktyk XP wg Kenta Becka: 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. 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ą.

12 praktyk XP wg Kenta Becka: 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. . 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. .

12 praktyk XP wg Kenta Becka: 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. 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 .

12 praktyk XP wg Kenta Becka: 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. 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.

12 praktyk XP wg Kenta Becka: 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. 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.

12 praktyk XP wg Kenta Becka: 40-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 . 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. .

Podstawowe czynności podczas pracy w XP

Działania podczas typowego dnia pracy XP

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

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.

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

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

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

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

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

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.

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

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

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

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

Jak rozwiązać te problemy
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ść?

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;

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.

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.

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

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

Metodologia Scrum

Metodologia Scrum 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.

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.

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

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.

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.

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.

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.

Metodologia Scrum

Metodologia Scrum W czasie przebiegu (sprintu) projektuje się, koduje i testuje produkt Requirements Design Code Test

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

Sprint Burndown (2)

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,

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.

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.

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?

Metodologia Scrum Sprint Planning Meeting Product Owner Scrum Team
Customers Management Product Backlog Sprint Planning Meeting Team Capabilities Sprint Goal Business Conditions Sprint Backlog Technology Current Product

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

Zasady działania zespołu MSF (1) Microsoft Solution Framework
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 (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ć

Edukator użytkowników
Zasady działania zespołu MSF (3) Kierownik programu Kierownik produktu 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! Edukator użytkowników Tester Kierownik logistyki

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

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

Role w zespole MSF (2) 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 (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).

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.

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.

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.

Role i cele w zespole MSF
Rola Cel Kierownik produktu Zadowolony klient Kierownik programu Dostarczenie produktu w ramach ograniczeń projektowych Wytwórca Dostarczenie produktu zgodnego ze specyfikacją Tester Sprawdzenie wszystkich potencjalnych problemów Edukator użytkownika Sprawne użycie systemu przez użytkowników Kierownik logistyki Sprawne wdrożenie produktu

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

Komunikacja w zespole MSF

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

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”

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

Kierownik programu Kierownik produktu Wytwórca Zespół wiodący Edukator Tester Kierownik logistyki Kierownik programu Kierownik programu Kierownik programu Wytwórca Wytwórca Raporty Jądro systemu Wytwórca Edukator Tester Edukator Tester Interfejsy Edukator Tester

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

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

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

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

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.

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

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

Opis ról (1)

Opis ról (2)

Opis ról (3)

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

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

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.

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.

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.

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

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.

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

Efektywność metod komunikacji

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

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

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

Inne struktury komunikowania się zespołu

Komunikacja w projekcie
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.

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

Komunikacja w projekcie (cd.)
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ą.

Dystrybucja informacji
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 (cd.)
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.

Raportowanie o postępach
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 (cd.)
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.

Raporty zewnętrzne 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.

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

Technologie komunikacji
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 (cd.)
Technologie internetowe Grupy dyskusyjne Wideo konferencje Komunikatory VoIP Intranet i wszystkie inne omawiane w czasie prezentacji na projektach

Narzędzia komunikacyjne
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

Dziękuję za uwagę

Zarządzanie projektem informatycznym

Podobne prezentacje

Prezentacja na temat: "Zarządzanie projektem informatycznym"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres

Wejść

Zaloguj się poprzez sieć społeczną:

Zarządzanie projektem informatycznym

Podobne prezentacje

Prezentacja na temat: "Zarządzanie projektem informatycznym"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres