Zarzadzanie zespolami IT

Zarz

dzanie projektem informatycznym

Zarz

dzanie zespołem i komunikacj

•

kszo

ść

profesjonalnego oprogramowania jest tworzona przez

zespoły składaj

ce si

od dwustu do kilkuset osób

•

Nie ma mo

liwo

ci, aby wszyscy członkowie tak wielkiego zespołu

pracowali razem na jednym problemem

•

e zespoły dzieli si

na kilka grup. Ka

da grupa odpowiada za

budow

jakiego

podsystemu

•

Przyjmuje si

zasad

e grupy nie powinny liczy

cej ani

eli

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)

•

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

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)

• Utworzenie grupy, która b

dzie wydajnie pracowa

, jest

krytycznym zadaniem menad

era

• W grupie powinna panowa

równowaga umiej

tno

technicznych, do

wiadczenia i osobowo

• W dobrej grupie panuje duch zespołu, tzn. jej członkowie

zmotywowani sukcesem grupy na równi z realizacj

własnych celów

• Menad

erowie powinni zach

do jawnych czynno

„budowania zespołu”, aby wypracowa

poczucie

lojalno

ci grupowej

Praca zespołowa (3)

•

Kierownik musi motywowa

zespół jako cało

ść

oraz motywowa

osobno ka

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.

•

dy potrzebuje uzgodnionych celów, które s

zrozumiałe i splataj

z osobistym i zawodowym rozwojem kariery, wynikaj

cym z

ambitnej pracy, profesjonalnych standardów, wła

ciwych relacji i

szkolenia.

Motywowanie (1)

Motywowanie (2)

Potrzeby fizjologiczne

Potrzeby bezpiecze

stwa

Społeczne

Szacunku

Samo-

realizacji

Ludzi motywuje si

poprzez spełnienie ich potrzeb

Ludzie pracuj

cy w firmach softwarowych nie s

ani głodni, ani

spragnieni, ani nie czuj

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

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)

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

momencie podejmowania pracy w wybranej firmie, a wi

c wypłata,

ubezpieczenie, bezpiecze

stwo pracy, prawo do urlopu i poczucie

wspólnoty.

•

Czynniki motywuj

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)

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)

•

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

przestarzałym sprz

cie - nawet wtedy, gdy wymiana sprz

tu jest

merytorycznie nieuzasadniona.

•

Komfort psychiczny, wła

ciwa atmosfera w pracy, eliminacja napi

ęć

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)

Ergonomia pracy (2)

Sprzyjaj

cy układ biura wg McCue’go

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

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

Osobowo

ci w zespole (1)

Zazwyczaj ma po prostu za mało pracy i
wydaje mu si

e inni te

nudz

Spróbuj doło

mu obowi

zków. Je

eli

to nie pomo

e, to zwró

uprzejmie

uwag

e jego wyst

py nie zawsze s

potrzebne.

To wasz biurowy dowcipni

Wygłupia si

, opowiada kawały i

zabawne historyjki, robi innym
psikusy. Jest zabawny, ale marnuje
strasznie du

o czasu

Ulubiony
wujek lub
ciocia

Tak

osob

trzeba zach

do wzi

cia

spraw w swoje r

ce. Powiedz jej,

wierzysz, i

wykona przydzielone

zadania. Je

eli popełni bł

przeanalizujcie go wspólnie – dzi

ki temu

nabierze pewno

ci siebie.

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.

Mysz

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

esz, naucz go uprzejmego

wydawania polece

Wydaje mu si

e dzi

kieruje

projektem, a jutro zacznie rz

dzi

cał

firm

Urojony
przywódca

Jak sobie z nim radzi

Cechy

Typ

Osobowo

ci w zespole (2)

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,

poczuje wi

ksz

odpowiedzialno

ść

. I

popro

eby si

miechn

ł.

Ponurak. Nie obchodzi go projekt,
uwa

e wasza technologia jest

do niczego. Robi sobie 20 min.
przerwy na kaw

Maruda

Podtrzymuj jego cenny entuzjazm, ale
powstrzymuj od podejmowania
natychmiastowych działa

, bez

rozwa

enia ich potencjalnych skutków.

Tacy ludzie s

bystrzy i przydaj

zespole, ale wymagaj

pewnego

nadzoru.

Uwielbia emocje. Jest szcz

ęś

liwy

mog

c sprawdzi

co si

stanie,

li zrobi co

nietypowego. Mo

mie

e do

wiadczenie, ale jest

zbyt pewny siebie, a jego wyczyny
nie zawsze s

przemy

lane

Eksperyment
ator

Jak sobie z nim radzi

Cechy

Typ

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

Osobowo

ci w zespole (4)

Dominacja (Dominance)

•

Podkre

: Kształtowanie otoczenia poprzez zwalczanie oponentów i

podejmowanie wyzwa

•

Skłonno

: 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

: Kształtowanie otoczenia poprzez perswazj

•

Skłonno

: 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, brak Impulsiveness,

disorganization, nie doprowadzanie spraw do ko

ca.

Osobowo

ci w zespole (6)

Stało

ść

(Steadiness)

•

Podkre

: Osi

ganie stabilno

ci, wykonywanie zada

współpracy z innymi.

•

Skłonno

: 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

: Praca w otoczeniu zapewniaj

cym jako

ść

i dokładno

ść

•

Skłonno

: Zwracanie uwagi na standardy i szcegół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, Criticism of their work, niechlujne

metody, sytuacje emocjonalne poza kontrol

•

Cechy

: Zachowanie rozwa

ne, dokładne, dyplomatyczne,

pow

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

Entuzjastyczny, komunikatywny, bada mo

liwo

ci,

zapewnia kontakt z zewn

trzem, znajduje rozwi

zania

Resource
investigator

Poszukiwacz

ródeł

Sumienny, pilnuje post

pu i terminów. Znajduje bł

dy i

opuszczenia. Czasami zbyt drobiazgowy

Completer
finisher

Skrupulatny
wykonawca

Nastawiony na współprac

, dyplomatyczny, łagodzi tarcia,

słucha, buduje, wyczulony na ludzi i sytuacje

Team
worker

Dusza zespołu

Praktyczny organizator, zdyscyplinowany, niezawodny,
konserwatywny i wydajny. Przekształca idee w praktyczne
działania

Implementer

Realizator

Filtruje pomysły grupy i oddziela te, które s

praktyczne,

sto niewra

liwy na odczucia ludzi

Monitor-
evaluator

Krytyk
warto

ciuj

ródło oryginalnych, inspiruj

cych pomysłów, jest

kreatywny, czasem przywi

zuje si

do niepraktycznych

pomysłów

Plant

Innowator

Ambitny, dynamiczny, popycha działania do przodu, lubi
działa

pod presj

, przezwyci

ęŜ

trudno

ci, lubi wygrywa

Shaper

Lokomotywa

Zapewnia zgodne przywództwo, koordynowanie pracy
zespołu, czasami brakuje mu oryginalno

Chair
co-ordinator

Koordynator

Dobór personelu

Ŝą

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

okresy

wymagaj

ce szybkiego wykonania zło

onych zada

. Dla wi

kszo

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

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

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)

Czynniki doboru personelu (2)

e by

podstawow

wskazówk

co do tego, co

kandydat powinien umie

, i o jego zdolno

ci do uczenia

. Ten czynnik jest mniej istotny, gdy programi

zdobywaj

coraz wi

cej do

wiadczenia w licznych

projektach

Zdobyte
do

wiadczenie

Zwykle jest istotne jedynie w wypadku krótkotrwałych
projektów, przy których nie ma czasu na nauk

nowego

zyka

wiadczenie w

pracy z j

zykiem

programowania

e by

istotne, je

eli prace obejmuj

programowanie

na niskim poziomie. W przeciwnym wypadku zwykle nie
jest krytycznym atrybutem

wiadczenie w

pracy z platform

eli projekt ma zako

czy

sukcesem, to jego

twórcy musz

rozumie

dziedzin

zastosowania

wiadczenie w

dziedzinie
zastosowania

Opis

Czynnik

Czynniki doboru personelu (3)

To bardzo wa

ny atrybut, ale zwykle bardzo trudny do oceny.

Kandydaci musz

racjonalnie zgodni z innymi członkami

zespołu.

aden konkretny typ osobowo

ci nie jest mniej lub

bardziej odpowiedni do in

ynierii oprogramowania

Osobowo

ść

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.

Nastawienie

zdolno

ść

na oceni

przygl

daj

c si

ró

nym rodzajom

wiadcze

zdobytych przez kandydata. To wa

ny atrybut, bo

z niego wynika zdolno

ść

do uczenia si

Zdolno

ść

przystosowywania
si

ne, poniewa

członkowie zespołu musz

porozumiewa

pisemnie i ustnie z innymi współpracownikami,

mened

erami i klientami

Zdolno

komunikacyjne

Opis

Czynnik

Etapy rozwoju zespołu (1)

Tuckman and Jensen (1977)

1.Formowanie

2. Burza

3.Normowanie

4. Wykonywanie

czas

ęp

5. Przechodzenie

Etapy rozwoju zespołu (2)

Tuckman and Jensen (1977)

Lider musi ujawni

rozwi

nieporozumienia,

musi podkre

pozytywne

rezultaty, jakie da trzymanie
si

przez zespół

podstawowych zasad i
norm. Jasno

ść

ról powinna

oparta na

kompetencjach.

Powstaj

konflikty dotycz

ce celów,

przywództwa, metod pracy, relacji,
hierarchii. Porozumienia s

osi

gane i

zrywane. Wyst

puje opór przed

zadaniami.

2. Burza

Wzmacnia dum

przynale

ci do zespołu,

uznaje niepewno

ść

członków przed
„nieznanym”

Ostro

nie podekscytowani. Pewien

niepokój i niepewno

ść

członków, do

jakiego stopnia b

akceptowani, do

jakiego stopnia oni zaakceptuj

, kto ma

władz

jak j

dzie wypełnia

, jakie

relacje powstan

1. Formowanie

Rola lidera

Opis

Etap

Etapy rozwoju zespołu (3)

Tuckman and Jensen (1977)

Lider cz

sto obserwuje,

ani

eli interweniuje, chyba,

e jest proszony o arbitra

Potrzebne s

umiej

tno

rozwi

zywania konfliktów.

Proces burzy daje uzgodnione
podej

cie do podejmowania decyzji,

podziału pracy, organizacji spotka

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

3. Normowanie

Rola lidera

Opis

Etap

Etapy rozwoju zespołu (4)

Tuckman and Jensen (1977)

Na zebraniach oraz
rozmowach
oceniaj

cych lider

podsumowuje prace i
motywuje do
podejmowania
kolejnych zada

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

e blokowa

przyszły rozwój

grupy i poszczególnych jej
członków

5. Przechodzenie

Lider skupia si

zarz

dzaniu

wykonywaniem,
zapewniaj

c doradztwo,

szkolenia i sprz

ęŜ

enie

zwrotne

Grupa pracuje najbardziej
efektywnie. Wykorzystywane s

silne strony jej członków i
minimalizowane słabe strony.
Problemy s

konstruktywnie

rozpracowywane

4. Wykonywanie

Rola lidera

Opis

Etap

Etapy rozwoju zespołu (5)

Tuckman and Jensen (1977)

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

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

zale

ci od firmy i rodzaju projektu. Zawsze obejmuje planowanie i

prognozowanie.

•

Dodatkowe obszary odpowiedzialno

ci:

•

odpowiedzialno

ść

interpersonalna

: prowadzenie zespołu, porozumiewanie

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

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

dalej.

Organizator

. Tworzy struktur

organizacyjn

Nagradzaj

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

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

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

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

dotycząąąące zadania

ce zadania

Potrzeby

dotycz

dotycząąąące

jednostki

Potrzeby

dotycz

dotycząąąące

zespo

zespołłłłuuuu

Działania skutecznego lidera dotycz

ce zadania:

• osi

ganie celów zespołu

• definiowanie zada

• planowanie pracy

• przydzielanie zasobów

• wyznaczanie odpowiedzialno

• monitorowanie post

pu i kontrolowanie wydajno

• kontrolowanie jako

Skuteczny lider wg Adaira (2)

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)

Działania skutecznego lidera dotycz

ce jednostki:

• rozwój indywidualny

• zrównowa

enie potrzeb grupy i potrzeb indywidualnych

• nagradzanie dobrej wydajno

• pomoc w problemach osobistych

Skuteczny lider wg Adaira (4)

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

da osoba, jako istota ludzka, niesie ze sob

zbiór

potrzeb, które wymagaj

zaspokojenia

Skuteczny lider wg Adaira (4)

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

Głowni członkowie zespołu lidera-programisty:

•

Lider - programista

– bierze całkowit

odpowiedzialno

ść

zaprojektowanie, zaprogramowanie, przetestowanie i instalacj

systemu.

•

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

potrzebni inni specjali

ci do czasowej lub stałej pracy w zespole.

Mog

to by

administratorzy, specjali

ci od systemów operacyjnych i

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)

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

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)

Manifest zwinno

(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

Manifest zwinno

(Agile Manifesto)

niejsze !!!

• Jednostki i interakcje

procesy i narz

dzia

•

Działaj

ce oprogramowanie

obszerna dokumentacja

•

Współpraca klienta

negocjacja kontraktu

•

Nad

ąŜ

anie za zmianami

trzymanie si

planu

Manifest zwinno

(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 –

Manifest zwinno

(Agile Manifesto)

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?

dny !!!

(IEEE Recommended Practice for Software Requirements Specifications)

•

Inspekcje Fagana?

dne !!!

•

Punkty funkcyjne?

dne !!!

•

adnych nadgodzin!

Programowanie ekstremalne (2)

12 praktyk XP wg Kenta Becka:

Planowanie

. Tworzenie oprogramowania w XP odbywa si

przyrostowo

przez wdra

anie kolejnych wyda

produktu. Planowanie wydania odbywa

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

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

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

głym testom i ł

czeniu zawsze istnieje sprawnie działaj

ca wersja, a

klient nie musi długo czeka

na kolejn

Programowanie ekstremalne (3)

12 praktyk XP wg Kenta Becka:

Metafora systemu

. Ka

dy zespół programistyczny musi kontaktowa

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

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

Programowanie ekstremalne (4)

12 praktyk XP wg Kenta Becka:

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

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

ąŜ

do automatyzowania procedur testowych, które s

uruchamiane po

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

pami

e przerabianie nie mo

e zmienia

zewn

trznego zachowania

programu .

Programowanie ekstremalne (5)

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

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

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

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.

Programowanie ekstremalne (6)

12 praktyk XP wg Kenta Becka:

Wspólna odpowiedzialno

ść

. Dzi

ki standardom kodowania ka

programista czuje si

jak ’u siebie’ w ka

dym fragmencie systemu, nawet

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

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.

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.

Programowanie ekstremalne (7)

12 praktyk XP wg Kenta Becka:

11.

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 .

12.

gły kontakt z klientem

. Aby zadowoli

wymagania klienta nale

bezwzgl

dnie pod

ąŜ

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ł

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

wystarczaj

co du

o czasu dla nowego systemu. .

Programowanie ekstremalne (8)

Podstawowe czynno

ci podczas pracy w XP

Programowanie ekstremalne (9)

Działania podczas typowego dnia pracy XP

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

o niego.

Darz

wzajemnie szacunkiem i maja silne poczucie wi

zi.

•

W zespole XP poza

programistami

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

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

wiadczenie nie wszyscy b

potrzebni. .

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.

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

pisa

testy

funkcjonalne oraz tworzy

opisy (historie u

ytkownika).

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

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

Programowanie ekstremalne (15)

Zespół w XP:

•

Trener (coach)

Trener jest osob

, która ponosi odpowiedzialno

ść

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 zarz

dza

•

Powinien te

wiedzie

, ile czasu potrzeba na wykonanie danego zadania.

Zna te

sposoby zaradzenia pojawiaj

cym si

problemom.

•

sto trener musi by

dost

pny jako partner do programowania dla

mniej do

wiadczonych.

•

Pomaga w tworzeniu testów i refaktoringu.

•

Jego rola mo

e male

wraz z rozwijaniem si

zespołu i dochodzenia do

wspólnej odpowiedzialno

ci za projekt

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.

•

Monitoruje obci

ąŜ

enie i jako

ść

oszacowa

(na podstawie danych z

przeszło

ci) ka

dego programisty.

•

Prowadzi dziennik testów funkcjonalnych, wykrytych wad, osób za nie
odpowiedzialnych i testów, które pozwoliły je wykry

•

Jego praca nie mo

e jednak zbytnio obci

ąŜ

zespołu. Potrzebne mu

dane powinien zbiera

w sposób maksymalnie niezauwa

alny

Programowanie ekstremalne (17)

Zespół w XP:

•

Szef

. Szef ma prawo wymaga

rzetelnej komunikacji z zespołem.

•

eli co

idzie nie tak, powinien by

natychmiast poinformowany. Mo

wtedy zaproponowa

pewne rozwi

zania, ale nie ma władzy nad

terminarzem projektu.

•

To zespół okre

la warunki realizacji na podstawie

rodków zapewnionych

przez szefa.

•

Zespół ma prawo oczekiwa

od niego odwagi, zaufania, zrozumienia i

szybkich, kompetentnych reakcji. Taki szef b

dzie dobrze kierował

zespołem XP, a jego zespół b

dzie zadowolony z pracy.

•

e si

jednak zdarzy

, ze szef b

dzie musiał zatrzyma

bezsensowne

działania zespołu, które nie przynosz

efektu.

Programowanie ekstremalne (18)

Zespół w XP:

•

Zapewnienie wła

ciwych warunków pracy

. Aby zespół mógł

dobrze funkcjonowa

musi mie

zapewnione odpowiednie warunki pracy.

•

Pomieszczenie powinno by

wspólne dla wszystkich, tak by zapewni

swobodna komunikacje.

•

Jednocze

nie powinny istnie

miejsca na prywatne rozmowy,

odgrodzenie si

od reszty w razie potrzeby oraz przechowywanie

prywatnych rzeczy.

•

Wyniki pracy i monitorowanie post

pów powinny by

widoczne na

zawieszonych na

cianach tablicach.

•

Komputery do pracy w parach umieszczone s

w centrum. W ten sposób

łatwiej siada

przy nich w dwie osoby.

•

Cało

ść

powinna by

zaakceptowana i lubiana przez cały zespół. Musi si

on czu

dobrze, przydatne mog

odpowiednie gad

ety i lubiane przez

nich przedmioty. Miejsce wspólne z kanap

i ekspresem do kawy

powinno by

maksymalnie wygodne..

Programowanie ekstremalne (19)

Co to znaczy wybra

XP:

•

Szefowie, którzy zdecyduj

na wprowadzenie XP musz

wiadomi jakie to rodzi konsekwencje.

•

Przede wszystkim musza zgodzi

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

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

prywatno

ść

i spokój. .

Programowanie ekstremalne (20)

Czemu zapobiega XP:

•

Przy przestrzeganiu zasad wydaje si

oczywiste, ze stosuj

c t

metod

na zapobiec

–

wykonywaniu pracy która nie ma znaczenia, bo zgodnie z zasad

minimalizacji rozwi

zania robimy tylko to co jest potrzebne,

–

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

. .

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

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,

„XP jest proste w szczegółach, ale trudne w realizacji.”

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ść?

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;

Sukces wg MSF

Microsoft Solution Framework

• Zadowolony klient (długoterminowo)

• Utrzymanie w ryzach (funkcjonalno

ść

, czas,

zasoby)

• Zgodno

ść

ze specyfikacj

tworzon

podstawie wymaga

klienta

• „Addressing all known issues” – podj

cie

wszystkich rozpoznanych problemów

• Łatwo

ść

wdro

enia i piel

gnacji

•

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

) odnosi zespół

•

Homeostat – samoregulacja, autonaprawa, sterowanie
celem

Zasady działania zespołu MSF (1)

Microsoft Solution Framework

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

•

dy pracownik pełni jedn

lub wi

cej ról

•

role których nie powinno si

ze sob

czy

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

•

dy członek ma

jasne cele i zadania

•

Współdzielone
zarz

dzanie projektem

•

Niekoniecznie 6 osób!

Zasady działania zespołu MSF (3)

Zasady działania zespołu MSF (4)

• Role

– Ka

dy członek zespołu przyjmuje jedn

lub

cej ról

• Potoki pracy (workstream) i czynno

– Role wykonuj

przypisane im czynno

ci, które

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

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)

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

ytkowników i okre

laniu funkcji systemu,

•

reprezentowanie oczekiwa

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

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

█

liwe

█

Rzadko

█

Nie rekomendowane

Product Management

Program Management

Development

Testing

User education

Logistics Management

Komunikacja w zespole MSF

Dobry zespół MSF

•

Wspólna wizja

•

Nastawienie na produkt finalny

•

„Zero-defect mindset”

•

Zogniskowanie na potrzeby klienta

•

ęć

do nauki !

Skalowanie w du

ych projektach (1)

• Optymalny zespół to 7-11 osób

• Minimalny – 3 (konflikt interesów !)

• Powy

ej 17-20 osób komunikacja staje si

niemo

liwa

• Zespół w jednej lokacji !

• Skalowanie – tworzenie podzespołów

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

Skalowanie w du

ych projektach (2)

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

dro

systemu

Zespół

wiod

Skalowanie w du

ych projektach (3)

Kierownik

programu

Edukator

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

Program

Management

Program

Management

Development

Testing

Release

Management

Release

Management

User

Experience

User

Experience

Product

Management

Product

Management

Communication

Project

Management

Office

Project

Office

Steering

Committee

Struktura zarz

dzania firm

programistyczn

Kierownik
programu

Dyrektor d/s
programistycznych

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

Nie powinien podlegać
kierownikom programów i
przedsięwzięć

Funkcje osób pracuj

cych nad

oprogramowaniem (1)

• Kierownik programu/projektu

• Analityk - osoba bezpo

rednio kontaktuj

ca si

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

sprz

t i narz

dzia

• Model analityk/projektant + programista: funkcje

analizy i projektu w jednych r

kach, funkcje programisty

ść

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

klientem w celu okre

lenia wymaga

i budowy modelu

systemu

•

Projektant

– osoba odpowiedzialna za realizacj

oprogramowania, w zale

ci od zakresu prac mo

wyró

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)

Leader
Projektu

Dyrektor projektu
Manager projektu
Senior analityk

Odpowiedzialni za wszystkie
prace aplikacyjne: planowanie,
kontrola realizacji, informowanie i
kontrola jako

ci.

Analityk

Analityk biznesowy

Analityk systemowy

Odpowiada za wła

ciw

analiz

rozwi

biznesowych stan

bie

Ŝą

cy i mo

liwo

ci rozwoju

systemu zgodnie z
przewidywanym rozwojem
danego obszaru biznesowego.
Odpowiada za poprawno

ść

procesu analizy zgodnie z
przyj

metodyk

i stosowanymi

narz

dziami.

Opis ról (2)

Projektant

Projektant
systemowy

Architekt Systemu

Odpowiada za identyfikacj

rozwi

zania wszelkich zagadnie

projektowych na ka

dym etapie

budowy systemu. Przygotowanie
specyfikacji programowej, projektu
bazy danych, prototyping.
Opracowanie architektury
technicznej systemu

Programista

Senior programista
Programista
Dokumentalista

Odpowiedzialno

ść

za kodowanie,

testy cz

stkowe i cało

ciowe,

dokumentacj

programow

przygotowanie dokumentacji dla
administratorów.

Audytor

Audytor osoba lub
dertament

Odpowiedzialno

ść

za organizacj

Audytu, kryteria kontroli i
bezpiecze

stwa. Badanie

zgodno

ci systemu z zało

eniami

biznesowymi i technicznymi.
Niejednokrotnie Audytor jest
powoływany z niezale

nej firmy nie

bior

cej udziału w procesie budowy

systemu.

Opis ról (3)

Administrator
Bazy Danych

Senior administrator
DB
Administrator DB

Odpowiedzialny za zarz

dzanie

baz

danych, strojenie,

archiwizacj

, odtwarzanie,

zarz

dzanie u

ytkownikami i

bezpiecze

stwo bazy.

Pracownicy
techniczni

Odpowiedzialni za instalacj

hardware i software, bibliotek
danych i programów, identyfikacj

diagnostyk

bł

dów wynikaj

cych z

nieprawidłowego funkcjonowania
sprz

tu lub oprogramowania.

Administrator
sieci

Analityk sieci
Techniczny analityk
Kontroler sieci

Odpowiedzialni za wszystkie
wymagania zwi

zane z architektur

sieci, transmisj

danych,

komunikacj

i monitorowaniem

funkcjonowania sieci.

Co to jest komunikacja ?

•

Komunikacja to proces w którym ludzie dziel

znaczeniami

informacji (komunikatów).

•

Najprostszy model komunikowania si

polega na przekazywaniu

przez nadawc

komunikatu (werbalnego lub niewerbalnego)

i odebraniu go przez odbiorc

•

Komunikowanie si

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

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

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

•

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.

•

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.

Typy komunikacji

•

Zamierzona i bezwiedna

•

Werbalna i niewerbalna

•

Formalna i nieformalna

•

ewn

trzna i z otoczeniem

•

Komunikacja osobista, na pi

mie i za

rednictwem elektroniki

Przebieg procesu komunikacji

•

Komunikujemy si

ównie przekazuj

komunikaty ustnie lub w formie pisemnej.

•

Wybór formy jego przekazania powinien by

wiadomy: powinien zapewnia

skuteczno

ść

efektywno

ść

•

Czasami decydujemy o formie nie w pe

wiadomie - raczej kierujemy si

asn

wygod

, impulsem, przyzwyczajeniem.

Ryzykujemy wówczas pope

nienie b

łę

du i

nieosi

gni

cie celu.

Sposoby

komunikowania

•Notatki

•Poczta

•Spotkania

•Dyskusje

•Dokumentacja
projektu (plan,
raporty, etc.)

•Prezentacje

•Wyst

pienia

Werbalna Pisemna

Wsparcie

narz

dzi

informatycznych

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

ą ś

współpracuj

pozostałymi osobami

Wady i zalety struktury sieciowej

•

Dzi

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

ych kłopotów

•

Struktura sieciowa nie mo

e liczy

cej ni

osób

•

Osoby w zespole powinny posiada

podobne

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

•

Zarz

dzanie komunikacj

w grupie projektowej obejmuje procesy,

które maj

zapewni

odpowiednie zbieranie, udost

pnianie,

przechowywanie i dyspozycyjno

ść

informacji. Zapewnia

łą

czno

ść

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

ść

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

przynajmniej raz w ka

dej fazie

projektu.

Komunikacja w projekcie

• Jest ono wa

nym czynnikiem decyduj

cym o

sukcesie projektu.

• W wi

kszo

ci przypadków planowanie komunikacji

jest cz

ęś

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

przekazu, sytuacj

, czynniki kulturowe

Planowanie komunikacji

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

• 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

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

• 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

ąć

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

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