(Psychologické aspekty a porovnání přístupů rigorózních a agilních metodik) Jiří Svoboda katedra informačních technologií VŠE Praha svobodaj@vse.cz) Abstrakt: Pro úspěch projektu je velmi důležité nepodcenit pozici projektového manažera a zvolit takovou osobnost, která dokáže sestavit fungující tým. Proto je dobré mít alespoň základní povědomí o psychologii a teorii týmových rolí. V článku jsou uvedeny požadavky na roli projektového manažera, různá pojetí této role, předpoklady pro vytvoření dobrého vývojového týmu a rozdíly v přístupu tradičních a agilních metodik k lidskému faktoru. Klíčová slova: projektové řízení, projektový manažer, tým, týmové role, Belbinovy týmové role, sestavení týmu, agilní metodiky, extrémní programování Abstract: For achieving the successful project is essential not to underestimate the position of project manager and choose the right person, who is able to build up an effective team. Therefore it s good to have at least a basic know-how in psychology and theory of team roles. In this article you can find requirements identified for an project manager role, different concepts of this role, prerequisites for setting up a good development team and the distinctions between the approach to the human factor of classic and agile methodologies. Keywords: project management, project manager, team, team roles, Belbin team roles, building up a team, agile methodologies, extreme programming 1. Úvod V této práci bych se rád pokusil o přiblížení problematiky sestavování projektových týmů s důrazem na využití psychologických poznatků. Zaměřím se na osobnost projektového manažera, požadavky na tuto roli a sestavení optimálního projektového týmu zejména z pohledu osobnostních profilů členů týmu. Při obsazování rolí v každém projektu, ať už jde o roli projektového manažera nebo o role v řešitelském týmu, stojí obvykle na prvním místě odborné znalosti a předpoklady, což má samozřejmě své logické opodstatnění. V této práci chci ale poukázat zejména na druhou oblast, podle které by měli být členové týmů vybíráni. Touto oblastí je výběr na základě psychologických znalostí. Psychologie je samozřejmě věda velmi obsáhlá, proto se budu soustředit jen na základní přístupy z psychologie osobnosti, týmů a typologie týmových rolí, které mohou být široce využívány při řízení projektu v praxi. V posledních letech se pod rostoucím tlakem, zejména na rychlost, začínají prosazovat nové přístupy k vývoji software, proto se pokusím porovnat pojetí řízení lidských zdrojů a týmů u agilních a klasických, rigorózních metodik, které je velmi rozdílné. 100 SYSTÉMOVÁ INTEGRACE 2/2009
2. Projektový manažer a různá pojetí této role v současném IT prostředí Projektový manažer zásadním způsobem ovlivňuje celý projekt ve všech jeho fázích. Na schopnostech a osobnosti vedoucího projektu závisí velkou měrou úspěch vedeného projektu. Přijetí této role znamená akceptování obrovské zodpovědnosti v mnoha případech i za situace a stavy, které je velmi těžké nebo dokonce nemožné ovlivnit. Zodpovědnost projektového manažera má přitom řadu podob, jde o zodpovědnost vůči samotnému projektu, o dodržení projektové specifikace, časového harmonogramu, metodických postupů, řízení lidských zdrojů a rizik, dokumentace a mnoha dalších atributů každého projektu. Další oblastí zodpovědnost vůči vlastnímu týmu a schopnost efektivně a úspěšně řídit tým, je pro výsledek projektu klíčová. Projektový manažer musí být rovněž zodpovědný vůči klientovi a vůči vlastnímu managementu, musí mít schopnost a odvahu pravdivě reportovat jak dobré, tak i špatné zprávy, které zpravidla vždy i v případě dočasného zatajení nakonec vyplují na povrch, to vše vyžaduje v této roli silnou osobnost. Aby pracovník na pozici projektového manažera, svoji roli zvládl je důležité naplnění co nejvíce z následujících bodů: Osobnostní charakteristiky: silná, zodpovědná osobnost, připravena nést zodpovědnost za výsledky své práce výborné komunikační a organizační dovednosti, používané směrem dovnitř projektu k vlastnímu týmu, tak i navenek vůči klientům a managementu vlastní firmy vůdcovské schopnosti, schopnost motivovat, zde bych rád uvedl klasickou definici Yance Packarda: Leadership is the art of getting others to want to do something that you believe should be done. Tvrdé dovednosti: znalost projektového managementu, metodik, postupů, případné certifikace (např. Prince2, PMI) odborné znalosti odvětví a prostředí, ve kterém se projekty realizují Výše uvedené vlastnosti a znalosti jsou platné obecně, podíváme-li se ale na roli projektového manažera v každodenní praxi a v různých firmách, velmi se liší. Do ICT oblasti spadá velké množství činností, které jsou velmi různorodé. Rozdílné budou tedy požadavky na projektového manažera ve velké firmě pro projekty vyjádřené řádově stovkami až tisíci mandayů (MD) a jiné budou požadavky na projektového manažera ve firmě vyvíjející internetové produkty, což je tématem následující podkapitoly. 2.1 Požadavky na projektového manažera v internetové firmě Specifikujme si nejprve prostředí internetové firmy, kterým se budeme zabývat. Popsanou strukturu a způsob práce jsem pozoroval u řady menších a středních internetových firem, proto ji budu považovat v této kapitole za výchozí. Na níže uvedeném schématu jsou zobrazeny nejdůležitější role při zpracování zakázky, account manažer se zákazníkem vyjednává o uspokojení jeho potřeb realizací SYSTÉMOVÁ INTEGRACE 2/2009 101
Jiří Svoboda zakázky - typicky formou projektu. Poté nastává čas pro specifikaci projektu, kdy se připravuje zadání včetně realizačních dokumentů, na tom se spolu se zákazníkem a account manažerem podílí významnou měrou i projektový manažer. Je to z toho důvodu, že ve většině případů zákazník, ani klient nemají potřebné odborné znalosti pro přípravu takové specifikace, ze které bude možné vyjít při analýze a vlastním návrhu aplikace. Projektový manažer v tomto organizačním uspořádání tedy často plní i roli odborného konzultanta. Kromě toho samozřejmě pracuje s vývojovým týmem, kde může zároveň plnit roli tým leadera, obzvlášť v případě menších projektů. Šipky ve schématu znázorňují komunikační toky, zákazník primárně komunikuje s account manažerem, ten předává informace a požadavky projektovému manažerovi, který komunikuje napřímo s vývojovým týmem. Account manažer je odfiltrován, až na výjimečné případy, od vývojového týmu. Tyto výjimky posuzuje projektový manažer. Samozřejmě probíhají projektové schůzky, kterých se někdy zúčastňuje i klient a kde může být přítomen i zástupce vývojového týmu (pokud je to žádoucí). Je zřejmé, že v tomto případě budou akcentovány jiné vlastnosti projektového manažera, než když je řízení projektu více procesně formalizováno, což zpravidla ve velkých firmách je. V případě popsané internetové firmy nebo firmy s obdobnou organizační strukturou, považuji za klíčové tyto dovednosti a schopnosti: organizační a analytické myšlení otevřená dynamická osobnost (důležité pro dotažení projektu do úspěšného cíle) komunikační schopnosti, projektový manažer musí zvládnout být prostředníkem mezi vývojovým týmem a account manažerem, musí se umět diplomaticky pohybovat mezi těmito póly s často naprosto odlišnými názory a úrovněmi znalostí, takže jde často o práci pod velkým tlakem schopnost řídit tým vybudovat si odpovídající postavení v týmu, ideálně pomocí přirozené autority, zde jde o časté vykonávání role team leadera u některých projektů 102 SYSTÉMOVÁ INTEGRACE 2/2009
zodpovědnost a spolehlivost znalost principů projektového řízení odborné znalosti 2.2 Požadavky na projektového manažera ve velkých firmách Pojetí role projektového manažera se v menších firmách oproti velkým firmám poměrně liší. Čím více se pohybujeme od malých projektů k velkým, tím je projektové řízení více procesně formalizováno. Zatímco v mnoha internetových projektech se doba dodání měří v týdnech a desítkách MD, za velké projekty můžeme považovat projekty trvající řadu měsíců až let se stovkami a tisíci MD. Z velkého rozsahu vyplývá nutnost mít projekt co nejvíce pod kontrolou, což je podporováno nastavenými procesy a použitím metodik. Metodik pro řízení projektu je poměrně velké množství a pokrývají celou škálu různých druhů projektů, ať jde o přizpůsobivější metodiky podporující agilní přístupy k vývoji (zpravidla využívající iterativní vývoj), nebo o velmi robustní a rigidní metodiky pro vývoj softwaru, kde jsou podrobně popsány všechny fáze a dokumenty, které se musí průběžně vytvářet (příkladem je metodika Rational Unified Process - RUP). Stejně jako se od sebe liší pojetí různých metodik, liší se i postoje samotných projektových manažerů k těmto metodikám. Tyto postoje jsou závislé na osobnostním profilu, řada lidí má schopnost být dobrým koučem a dobře reagovat na ad hoc vzniklé problémy a mají vrozené předpoklady být leadery, v tom případě je pro ně často obvykle vysoká formalizace a metodiky s mnohdy vysokým počtem různých dokumentů svazující. Na opačném pólu stojí osobnosti, které se díky formalizaci cítí jistější a vysoký podíl každodenní až úřednické práce jim nevadí. Z výše popsaných příkladů vyplývá, že při efektivním výběru projektového manažera je důležité si uvědomit, na jaký typ projektů bude nasazen a jaký způsob řízení po něm bude vyžadován. Je proto vhodné znát osobnostní zaměření a dbát na něj při obsazování této role. Od člověka, který bude mít každodenní vnitřní nechuť k práci, se nedají očekávat vynikající výsledky. Představme si situaci, kdy projektového manažera čeká první schůzka s řídící komisí, kde čeká několik lidí od zákazníka v různých rolích (např. sponzor, koordinátor, klíčový uživatel, vedoucí informatiky) a kolegové z dodavatelské firmy (např. zástupce vedení, vedoucí analytik). Pokud projektový manažer nedokáže na této schůzce získat důvěru všech zúčastněných, bude se mu v průběhu projektu velmi těžko získávat (je to i tím, že lidé při svém vnímání dají velmi mnoho na první dojem, který se utváří v několika prvních sekundách kontaktu) a tato důvěra mu bude chybět při pozdějším reportování nepříznivých událostí, které se v projektu určitě vyskytnou. Stejně tak jako mít schopnost získat si důvěru, je důležité zvládnutí komunikace s lidmi, kteří mají mnohdy velmi nízkou úroveň odborných znalostí. Na první pohled to může být samozřejmý požadavek, ale řadě lidí schopnost vysvětlit složitější problém laikům chybí. Pro projektového manažera na velkých projektech považuji za důležité tyto dovednosti a schopnosti: organizační a analytické myšlení schopnost prosadit sebe a své požadavky v nepřátelsky naladěném prostředí SYSTÉMOVÁ INTEGRACE 2/2009 103
Jiří Svoboda komunikační schopnosti, musí se zodpovídat řídící komisi a managementu vlastní firmy znalost metodik projektového řízení zodpovědnost a spolehlivost odborné znalosti na dostatečné úrovni 2.3 Shrnutí Při srovnání požadavků na projektového manažera v malé firmě na internetových projektech a velkých projektech, považuji za největší rozdíl důraz na schopnosti team leadera (jehož roli projektový manažer často v prvním případě zastupuje) a nutnost znalosti metodik projektového řízení v případě druhém. V prvním případě je prostředí, ve kterém se projekty realizují daleko méně formální, firemní kultura malých a internetových firem je zpravidla velmi uvolněná oproti kultuře velkých firem, kde je vše obvykle silně zprocesováno a svázáno. Proto i způsob každodenní komunikace se v obou případech liší. Pokud bych měl vybrat z výše uvedených požadavků nejdůležitější schopnost, je to podle mého názoru, vedle nezbytné úrovně odborných znalostí, umění komunikace. Pokud bude projektový manažer splňovat všechny požadavky, ale nebude umět komunikovat, zůstane to, co skutečně umí, ostatním lidem skryté, bude se mu obtížně budovat důvěra u spolupracovníků a řídící komise, což vedení projektu zbytečně komplikuje. Pokud dobrou komunikací projektový manažer ještě podpoří základními znalostmi z oboru psychologie osobnosti a psychologie řízení, má výbornou výchozí pozici pro řízení širokého portfolia projektů. 3. Tým a přístupy k práci s týmem Problematika týmu a práce s týmem je velmi obsáhlá, proto bych chtěl uvést jen základní teoretická východiska, která případnému zájemci poskytnou náměty k hlubšímu zamyšlení. Pojem tým označuje zpravidla vnitřně formálně nestrukturovanou malou skupinu lidí, kteří v jejím rámci podávají po stanovenou dobu společný výkon. Je důležité si uvědomit rozdíl mezi pojmem tým a pracovní skupina. Pracovní skupinou je ve firmě například programátorské oddělení, ve kterém je určitá vnitřní struktura (např. vedoucí programátor, senior programátor, junior programátor) a o kterém se dá předpokládat, že jeho existence je neomezená (je vázána na dobu existenci firmy). Tým, ve svém ryzím pojetí, je oproti tomu struktura vytvořená pouze dočasně, kde kromě vedoucího týmu, neexistuje žádná vnitřní organizační struktura. Dalším typickým rysem týmu je společná zodpovědnost za odvedenou práci, která vyplývá z kolektivního hledání řešení a rozhodování. Oproti tomu v pracovní skupině je každý zodpovědný jen za svůj úsek práce. [NOVY] Optimální velikost týmu závisí na konkrétním úkolu nebo projektu, obvykle se za ideální počet považuje pět až devět členů. Při sestavování fungujícího týmu je nezbytné zohlednit nejen odborná hlediska, ale i psychologická, je vhodné se potenciálních členů zeptat, s kým by chtěli a naopak nechtěli spolupracovat (čímž se chceme vyhnout antagonickým vztahům) a vypracovat jejich osobnostní profily, na základě kterých zjistíme i jejich týmové role, které nám poskytnou vodítko při skládání týmu. Pokud se nám podaří tým dobře sestavit, můžeme očekávat řadu 104 SYSTÉMOVÁ INTEGRACE 2/2009
přínosů týmové práce, např. synergický efekt, vyšší kreativitu, brzké odhalení chyb, efektivní rozhodování (potlačují se extrémní názory), růst všech členů týmu. Speciálním příkladem týmů, které se v současné době široce využívají a jejich používání rychle roste zejména v ICT firmách, jsou virtuální týmy. Práce s virtuálními týmy je na první pohled obtížnější díky nemožnosti nebo velmi nízké dostupnosti osobního kontaktu se členy týmu v průběhu společné práce. Komunikace v takových týmech je zprostředkovaná ICT technologiemi. Virtuální týmy jsou velmi často využívány ve velkých mezinárodních společnostech, ale pracuje s nimi i řada malých firem zejména z oblasti vývoje software, kdy je nutné najímat externí specialisty, kteří často preferují určitou časovou a prostorovou nezávislost. Pro efektivní fungování virtuálního týmu je potřeba vyřešit řadu problematických oblastí, mezi které patří: motivace členů týmu (jak zajistit, aby se pracovníci opravdu cítili součástí týmu, byť virtuálního) nastavení efektivní a pružné komunikace (volba komunikačních kanálů, pravidel pro komunikaci) budování vzájemné důvěry v týmu, sdílení informací, podpora synergie kontrola odvedené práce (práce musí být často a důkladně kontrolována) Na první pohled by se mohlo zdát, že v případě virtuálních týmů, kdy komunikace probíhá zprostředkovaně, by se při sestavování týmu nemuselo dbát na psychologické profily členů týmu, podle mého názoru ale i v tomto případě pokud tým není vhodně složen z psychologického pohledu, začnou vznikat třecí plochy, které se budou kvůli ztížené komunikaci odstraňovat ještě obtížněji než u běžných týmů. Projektový manažer pracující s virtuálním týmem, by měl znát psychologickou problematiku týmu. Tyto znalosti mu umožní uvědomovat si a identifikovat jednotlivé jevy a situace, ke kterým bude v průběhu projektu docházet, což je nezbytným předpokladem pro jejich správné řešení. 4. Týmové role podle osobnostního profilu Každý člověk poté, co se stane členem týmu, začne vykazovat určité charakteristiky a bude se v týmu projevovat určitým stylem, ať už jde o komunikaci s ostatními členy týmu, nebo přístup k práci. Tyto znaky chování je možné sdružit do skupin a podle nich se dají určit typické týmové role. Výzkumem této oblasti se zabývá anglický vědec Raymond Meredith Belbin, který vypracoval koncept zahrnující devět týmových rolí [BEL]. Neznamená to ale, že každý člověk stoprocentně zapadá do dané role, často se osobnostní struktura každého jedince skládá z několika těchto rolí s různě silným zastoupením. Při budování týmu je vhodné zajistit jeho optimální složení nejen z odborného hlediska, ale i psychologického. 4.1 Role orientované na dosažení cíle Skupina těchto rolí podporuje společnou silnou orientaci na dosažení cíle a na cestu, která k cíli vede. SYSTÉMOVÁ INTEGRACE 2/2009 105
Jiří Svoboda Formovatel (Shaper) Formovatel, neboli také usměrňovač, anglicky Shaper je obvykle dynamická osobnost, která je silně motivovaná na cíl a úspěch. Je to leader, který svoji silnou motivací uspět zpravidla přenáší i na ostatní členy týmu. Začíná být ovšem netrpělivý, pokud se dle jeho názoru věci začínají zbytečně protahovat a může mít sklony urážet ostatní. Pokud jsou v týmu dvě takto silné osobnosti, může to vést ke konfliktům a rozkladu. Realizátor (Implementer) Realizátor je spolehlivý, loajální prakticky orientovaný pracovník, který udělá přesně to, co je mu zadáno, podle svého zdravého rozumu. Pokud máme ve vývojovém týmu programátory v těchto rolích, velmi to při předcházející kvalitní analýze urychlí samotný každodenní vývoj. Nevýhodou může být určitá nepružnost a rigidita myšlení. Dokončovatel (Finisher, Completer) Pečlivý pracovník, který rád kontroluje a hledá chyby. Je svědomitý a dokáže si svoji práci rozvrhnout tak, aby stíhal termíny. Jeho práce je u vývojových projektů důležitá zejména v pozdních fázích vývoje a při testování. Slabými stránkami mohou být přílišné obavy a opatrnost, nerad deleguje, nejraději by si celou práci udělal sám. 4.2 Role orientované na myšlení a analýzu Tyto role jsou důležité jak pro správné vnitřní fungování týmu, členové týmu v těchto rolích kriticky sledují činnosti týmem vykonávané a poskytují tak důležitý feedback (zejména hodnotitel vývoje), přinášejí nové myšlenky (inovátor), nebo prohlubují odborné znalosti, které má tým k dispozici (specialista). Inovátor (myslitel, Plant) Inovátor je tvůrčí, kreativní osobností a má rád výzvy a hledání řešení problémů novými postupy. Jeho tvořivost a nové myšlenky jsou inspirativní pro celý tým. Na druhou stranu je inovátor je často zahleděný do svého světa a může pro něj být obtížné vysvětlovat své myšlenky ostatním. Rovněž se nerad zabývá detaily, které má ve stínu svých velkých myšlenek tendenci přehlížet. Hodnotitel vývoje (Monitor) Hodnotitel vývoje pozoruje bez emocí vše co se v týmu děje. Má schopnost nadhledu a komplexního pohledu na věc, díky svým analytickým schopnostem je obvykle schopen dojít ke správným a konstruktivním závěrům. Pro svůj přístup bez emocí má často problém s motivováním ostatních členů týmu a hledáním vlastní inspirace, dokáže velmi rychle zchladit nadšení, které vyplývá ze skutečností, které nejsou úplně logicky zdůvodnitelné. Specialista (Specialist) Specialista je odborník v dané oblasti, je cílevědomý a má hluboké znalosti problematiky. Rád se kontinuálně vzdělává a o své znalosti se podělí s týmem. Pokud něco neví, snaží se s chutí odpovědi nalézt. Do týmu přináší profesionalitu, zaujetí a iniciativu. 106 SYSTÉMOVÁ INTEGRACE 2/2009
Slabou stránkou může být zájem jen o úzkou oblast a může být těžké specialistu integrovat tak, aby se cítil jako součást týmu. 4.3 Role orientované na tým Tato skupina rolí podporuje týmový přístup k práci a vnitřní organizaci týmu a tým jako celek myšlenkami z vnějšího prostředí. Koordinátor (Coordinator) Koordinátor je vyzrálý a sebevědomý, dokáže rozpoznat, co je v ostatních členech týmu, i proto je pro něho snadné efektivně delegovat práci na jiné. Usnadňuje rozhodování a pomáhá každému se soustředit na vlastní práci. Často může být formálním i neformálním vedoucím týmu. Negativní mohou být tendence delegovat všechnu práci na ostatní a může být vnímán jako manipulátor. Vyhledávač zdrojů (Resource Investigator) Vyhledávač zdrojů bývá extrovert plný entusiazmu, který dokáže vyhledávat nové příležitosti, myšlenky a kontakty. Jeho pozornost je upřena především do vnějšího prostředí, neváhá se inspirovat u ostatních a vytěžit z myšlenek a nápadů ostatních maximum pro svůj tým. Může se mu ovšem stát, že v průběhu projektu začne původní nadšení pro práci ztrácet, když opadne aura něčeho nového. Týmový pracovník (Podporovatel, Team Worker) Týmový pracovník díky své vysoké sociální inteligenci tmelí tým, dokáže zabraňovat nebo zmírňovat různé třenice, nacházet operativní řešení problematických situací vyplývajících ze sociálních interakcí. Je dobrým diplomatem, dovede se přizpůsobit a podporuje soudržnost týmu. V určitých situacích se ovšem může projevit nedostatek rozhodnosti. Výše uvedené role jsou zaměřeny převážně dovnitř týmu, existují ale i role, které jsou orientovány na interakci s vnějším okolím týmu a samotný tým např. chrání, nebo získávají nové informace. Kromě těchto vnějších a výše uvedených vnitřních týmových rolí a funkcí, existují i individuální funkce, které sloučí k uspokojení individuálních potřeb. Pokud tyto funkce nenarušují týmovou práci, měly by být tolerovány, pokud ale projevy přerostou únosnou míru, je třeba situaci řešit. Mezi takové nebezpečné funkce patří například obstrukce, agresivní chování, neúměrné sebeprosazování. 5. Sestavení optimálního projektového týmu 5.1 Projektový tým v rigidních metodikách Sestavení projektového týmu by mělo být kompetencí projektového manažera, konkrétní struktura celého projektového týmu závisí na velikosti projektu. Často používaná obecná organizační struktura projektového týmu pro větší vývojové projekty je zobrazena na následujícím schématu. Projektový manažer nese zodpovědnost za práci celého týmu a řídící proces celkově zastřešuje. Project SYSTÉMOVÁ INTEGRACE 2/2009 107
Jiří Svoboda leader koordinuje každodenní operativní běh projektu a přebírá zodpovědnost za část administrativy. Schéma je samozřejmě zjednodušeno, slouží zejména pro vytvoření představy a srovnání s agilními přístupy, do vývojového procesu vstupuje řada dalších rolí, např. externí konzultanti. Výše uvedená projektová organizační struktura je vhodná pro projekty vyvíjené pomocí rigorózních metodik, využívající zpravidla klasický vodopádový cyklus. V tomto prostředí se předpokládá direktivní řízení na všech úrovních, každý pracovník má své místo v procesu. Zákazník sleduje vývoj zvenku a komunikuje s projektovým manažerem zpravidla na plánovaných projektových schůzkách. Projekty se skládají z předem definovaných fází, jsou podrobně analyzovány a specifikovány, přičemž se vytvořená specifikace nemění, každá změna je problém, proto se jim snažíme zabránit. Důsledkem tohoto přístupu může být to, že jsme sice vyvinuli systém splňující specifikaci, ale požadavky uživatelů se díky měnícímu se prostředí změnily a nový systém nebude mít takový přínos, jaký byl původně očekáván. 5.2 Pojetí projektového týmu v agilních metodikách V posledních několika letech, zejména v souvislosti s obrovským rozmachem internetu, se stále důrazněji prosazují požadavky na co nejkratší dobu vývoje požadovaných aplikací, přičemž zadání se v průběhu vývoje často upravuje a mění. Klasické robustní metodiky zpravidla nejsou schopny poskytnout adekvátní podporu pro tento druh vývoje, proto jednak vznikají specializované variace, jak je RUP for Small Project, ale hlavně se objevili nové přístupy sdružené v tzv. agilních metodikách, zastřešené tzv. Manifestem agilního vývoje, pod kteréý se v roce 2001 podepsala řada uznávaných vývojářů. 108 SYSTÉMOVÁ INTEGRACE 2/2009
Protože se dá říci, že při definování agilních přístupů se šlo až na dřeň vývojového přístupu a důraz se klade na nejnižší úroveň vývoje software, je správné složení týmu, pro úspěch vývoje těmito technikami kritické. Zásadní důraz se klade na produkt, který má přinést co nejvyšší hodnotu zákazníkovi, proto se pracuje se změnami a jsou součástí celého vývoje, jednoduchost, práce s lidským faktorem (úzká spolupráce se zákazníkem, motivace a práce s týmem). Jednoduše řečeno, dvě nejdůležitější věci jsou výsledný produkt a lidé, kteří ho vytvářejí. Vývoj zpravidla probíhá v iteracích. Modely, dokumentace, procesy musí být jednoduché a maximálně podřízeny těmto cílům, nesmějí se vytvářet jen samy pro sebe. Mezi agilní metodiky patří např. Extrémní programování, SCRUM, Test-driven development. 5.2.1 Extrémní programování Na příkladu extrémního programování bych rád ukázal nejen moderní přístupy k vývoji software, ale hlavně velkou orientaci na týmovou práci, zahrnující návody a nástroje, jak efektivní práci v týmu podporovat. Extrémní programování (XP) je metodika, která je určena do prostředí, kde není stabilní zadání, požadavky se stále mění a času na vývoj je velmi málo. Je primárně vypracována pro malé týmy od dvou do deseti členů. [KADL] Následující výčet týmových rolí, se kterými pracuje metodika Extrémní programování, jsem rozšířil o vhodné týmové role (psáno kurzívou). Kouč sleduje a analyzuje chování a komunikaci v rámci týmu, zaměřuje se na podporování efektivního fungování týmu Koordinátor, částečně formovatel Programátor není pouhý pisatel kódu naplňujícího představy analytika, musí být schopen komunikovat v rámci týmu, umět připravit návrh a provádět testování unit. Realizátor, týmový pracovník, může být i případně inovátor Tester v pojetí XP je testování zejména na programátorech, proto by tester měl se zákazníkem připravovat testy funkcionality Dokončovatel Stopař detailně sleduje každodenní průběh projektu, stanovuje časové odhady, analyzuje příčiny zpoždění, což je část práce team leadera nebo projektového manažera při použití klasických metodik Hodnotitel vývoje Konzultant klasický odborný konzultant, expert na problematiku, většinou externí, vstupuje do týmu, když jsou potřeba jeho expertní znalosti Specialista Velký šéf jakýsi sponzor použití XP metodiky, měl by zároveň motivovat lidi Vyhledávač zdrojů Zákazník je zde opravdovou součástí týmu, musí být do projektu zatažen, je to on, kdo říká, co se má programovat a je za zadání zodpovědný Jak z navržené struktury týmu vidět, autor metodiky XP Kent Beck, si je vědom toho, že komunikace v týmu je pro úspěch projektu naprosto klíčová. Proto má ve SYSTÉMOVÁ INTEGRACE 2/2009 109
Jiří Svoboda své metodice roli kouče, který je zodpovědný za komunikaci v rámci týmu a kontinuálně pracuje na tom, aby byla maximálně efektivní. Možná K. Beck znal Belbinovu teorii týmových rolí a zohlednil ji při sestavování týmu pro XP, protože jeho týmové role se s Belbinovými na první pohled dobře kryjí. Celá metodika XP je tedy založena na dobře fungujícím týmu, ve kterém k sobě mají jeho členové velmi blízko. To podporuje důraz na neformální komunikaci, podporu komunikačních kanálů a odstranění možných komunikačních bariér (autor se dokonce zabývá i tím, jak by měla být vybavena místnost, ve které by měl ideálně pohromadě sedět celý tým). 5.2.2 Komunikace a motivace členů týmu Maximální usnadnění komunikace se prolíná celou metodikou a je podporováno i řadou nástrojů, jeden z těch neobvyklých je tzv. párové programování, kdy programování probíhá vždy v páru u jednoho počítače, první programátor hledá nejlepší způsob implementace stávající úlohy a zapisuje kód a druhý sedí vedle a kontroluje správnost uvažování prvního a hledá globální dopady zvoleného způsobu implementace a přemýšlí, zda neexistuje lepší způsob, tyto dvě funkce si mezi sebou libovolně vyměňují. Kromě přínosů, které jsou zřejmé (např. lepší kvalita kódu, dřívější nalezení chyb i v návrhu), ale vidím i velké nevýhody, především osobní náročnost práce tímto způsobem a samozřejmě toto zdvojení přinese zvýšené náklady, u kterých je otázka, zda vyrovnají přínosy tohoto přístupu. Přestože pro mnoho programátorů je tento způsob práce nepřijatelný, patří k základním pravidlům XP. Vytvoření týmového ducha je podporováno celkovým pojetím týmové práce, kdy jsou si všichni členové týmu rovni a měli by mít vzájemný respekt, jsou od začátku zainteresováni do projektu, není to tedy tak, že jen čekají na to, co jim řekne projektový manažer nebo team leader. 5.2.3 Rozšířené role pro vývoj internetových projektů Z výše uvedené charakteristiky XP se nabízí použití této metodiky pro internetové projekty, u kterých máme zpravidla velmi málo času, zákazník nedokáže na začátku projektu jasně specifikovat všechny požadavky a pracujeme s malými týmy. Doug Wallace pro tento případ použití XP definuje speciální role [WALL]: Stratég - komunikuje se zákazníky Grafik Programátor uživatelského rozhraní v podstatě CSS a XHTML kodér Programátor na straně serveru Rádce (mentor) rozumějící prostředí internetu, grafice i programování Tester zde je role rozšířena na testování uživatelského rozhraní a dalších specifických součásti internetového projektu Jedna z původních zásad extrémního programování je, že jednotliví členové týmu by neměli být příliš specializovaní (byť je to částečně porušeno u varianty XP pro webové projekty), nicméně pokud má být tým skutečně fungující, musí být sestaven z pracovníků s vhodným psychologickým profilem. 110 SYSTÉMOVÁ INTEGRACE 2/2009
5.3 Shrnutí Obecně je samozřejmě správné sestavení týmu velmi důležité pro úspěch jakéhokoliv projektu, pokud ale porovnáme reálný význam a dopady při vývoji klasickými a agilními metodikami, najdeme rozdíly. Umím si představit situaci, kdy i když máme v případě použití klasických metodik špatně sestavený tým a projekt prochází řadou obtíží, dokážeme projekt s tímto týmem více či méně úspěšně dokončit. Pokud bychom ale vyvíjeli pomocí agilních metodik, kde je kladen maximální důraz na produkt a samotný vývojový tým, přičemž by tento tým fungoval špatně, ať už by důvody byly v sestavení týmu, nebo třeba v komunikaci, nebyli bychom podle mého názoru pro obrovské komplikace schopni projekt dokončit. Jedinou možností by bylo provést hlubokou analýzu příčin a bariéry efektivního fungování se pokusit odstranit, nebo vytvořit nový tým s jiným složením, který by byl schopen projekt realizovat. V případě klasického přístupu máme totiž řadu nástrojů a technik, kterými je celý vývoj důsledně svázán, což omezuje prostor pro osobnostní projevy a dobrá metodika je dle mého názoru schopna projekt udržet i v případě špatného týmu. Ovšem pro použití agilních metodik, kde je velký prostor pro jedince a jeho seberealizaci, potřebujeme pracovníky jak profesně, tak lidsky vyspělé. 6. Závěr Jak jsme si ukázali, sestavení kvalitního týmu není jednoduché a má svá pravidla. Bohužel v praxi je často pool pracovníků, ze kterého můžeme vybírat tým, velmi omezený a pokud potřebujeme vybrat pracovníka s požadovaným psychologickým profilem, je to, i díky omezené dostupnosti zdrojů na pracovním trhu, velmi obtížné a končí to kompromisy. Nicméně pokud se těmito pravidly budeme řídit, máme velkou šanci, že tým bude optimálně fungovat. Podle mého názoru jsou tyto přístupy při sestavování projektových týmu i následném řízení projektu velmi často opomíjeny, ať už z neznalosti nebo nedostatku zdrojů, což je škoda, protože při jejich využití se nám otevírá cesta k hladšímu a kvalitnějšímu průběhu projektu. Použité zdroje [NOVY] NOVÝ, Ivan. BEDRNOVÁ,Eva. Psychologie a sociologie řízení. 2. vyd. Praha, Management Press 2002. 586 s. ISBN: 80-7261-064-3 [KADL] KADLEC, Václav. Agilní programování. 1. vyd. Brno, Computer Press 2004. 280 s. ISBN: 80-251-0342-0 [WALL] WALLACE, Doug. Extreme Programming For Web Projects. Boston, USA, Addison-Wesley 2002. 192 s. ISBN-10: 0-201-79427-6 [BEL] BELBIN: The home of Belbin Team Roles [online] [cit.2009-01-30]. Dostupné na <http://www.belbin.com> [XP] XProgramming.com an Agile Software Development Resource [online] [cit.2009-02-02]. Dostupné na <http://www.xprogramming.com> SYSTÉMOVÁ INTEGRACE 2/2009 111