GIT Consult

Projektový management v IT

Projektový management v IT

 

V IT inzerci se to často hemží výrazy jako Waterfall, Agile nebo Scrum. I když většina recruiterů ví, že jde o projektové metodologie užívané při vývoji softwaru, málokdo už tuší, jak se od sebe liší a proč jsou vůbec zkušenosti s nimi tolik žádané.

Vybrali jsme proto 5 metodologií, které by se měl každý recruiter pracující v IT odvětví určitě znát.

 

Waterfall

Česky vodopád, je jedna ze starších metodologií pro řízení projektů. První zmínky o tomto principu pocházejí z roku 1970 (ještě ne pod tímto názvem) a patří mezi tzv. tradiční přístupy řízení projektů (mám řadu úkolů a ty provádím podle určitého scénáře). Název je pak symbolem pro hlavní myšlenku, tedy řešit úkoly kaskádovitě, jeden za druhým, jako vodopád.

Vývoj softwaru čistě podle této metodiky by tak mohl vypadat například takto. V první fázi si stakeholdeři vydefinují zadání projektu, cíle, specifika a další důležité otázky. Tuto fází následně uzavřou a předají spolu s dokumentací týmu designérů. Designéři navrhnou software podle předané dokumentace a následně vše opět předají vývojářům, testerům a nakonec klientovi, případně uživatelům. Na postupu se zdá vše v pořádku, důležitou součástí této projektové metodiky je však to, že se po uzavření jedné části již nelze vracet. Může se tak stát, že testovací tým nebo designéři objeví novou funkci, kterou by budoucí uživatelé rádi využívali, waterfall přidání této funkce však neumožňuje.

Ne jednu stranu se to může zdát nelogické, na druhou však zabraňuje neustálým změnám a nekonečnému cyklení vývoje. Z toho vyplývá, že jednou z velkých nevýhod tohoto systému je značná nepřizpůsobivost. V době velkých technologických změn a nutnosti změn v požadavcích na systém, se stal tento způsob řízení projektu spíše neefektivní.

Naopak výhodou je jasná strategie jednotlivých kroků, jednoduchá implementace do pracovního prostředí a snadné pochopení všech principů v rámci jednotlivých týmů. Také zajišťuje, že na jednotlivých úkolech v danou dobu pracují pouze zaměstnanci, kteří tématu rozumí. Nestane se tak, že na poradách půl roku sedí někdo, kdo k tématu nemá co říci. Tým tak roste a mění se podle jednotlivých fází projektu.

I dnes se Waterfall pro vývoj softwaru hojně používá, většinou v kombinaci s jednou nebo více agilními metodikami. Proces je tak rozdělen do uzavřených celků ale uvnitř tohoto celku pak jednotlivé týmy využívají pro splnění úkolů například metodiku Kanban.

 

Agile

V reakci na nedostatečnou flexibilitu Waterfallu (do té doby nejužívanější metodiky pro vývoj SW aplikací) byl v roce 2001 vydán skupinou vývojářů tzv. Agilní manifest. Ten shrnuje principy zcela nového přístupu k řízení projektů, u kterých je nutná vysoká míra flexibility. Zároveň chtěli zajistit, aby byla zvýšena komunikace mezi členy týmu a rychlost dokončení projektu. Českou verzi manifestu si můžete prohlédnout zde: http://agilemanifesto.org/iso/cs/manifesto.html

Důležité pro pochopení celého principu je, že Agile je více filozofií a celkovým přístupem k práci, než samostatnou metodologií. Z tohoto přístupu se pak vyvinulo několik samostatných metod jako Scrum, Extreme Programming nebo Adaptive Project Management, kterým se říká frameworky.

Nejdůležitějším principem je identifikace vždy nejdůležitějších a prioritních úkolů pro dané období a následně se zabývat pouze jimi. Neustálá revize těchto úkolů pak umožňuje rychle reagovat na změny. Například pokud klient přijde s novým požadavkem na funkci aplikace, která je pro něj urgentní, zařadí se do tzv. sprint backlogu a vyřeší při první možné příležitosti. Samotný Agile však neurčuje, zda období má být 30 denní (jako Scrum), kratší nebo delší a neurčuje postup prací.

Výhodou implementace tohoto přístupu je zvýšená komunikace v týmu a přesto snížení písemné dokumentace. Samozřejmě i velká přizpůsobivost a transparentnost projektu. Každý člen týmu totiž přesně ví, na čem pracují ostatní, případně s čím mají problém. Pokud je členem týmu navíc klient nebo jiný stakeholder, má jasnou zpětnou vazbu o tom, co, proč a kdy se na projektu děje.

Co přístup příliš neřeší je motivace a řízení lidí. Motivaci má zajistit přístup tím, že jsou zadávány pouze malé a rychle splnitelné úkoly a tak mají členové týmu neustále pocit postupu. Důležitou součástí řízení jsou také status meetingy, které by měli probíhat co nejčastěji a to formou „z očí do očí“.

To pak v dnešním světě vývoje zvyklém pracovat na remote (tedy vzdáleně) může působit obtíže. Agile totiž vždy upřednostňuje osobní rovinu komunikace před elektronickou.

 

Scrum

Scrum je jedním z frameworků, tedy jakýchsi nadstaveb pro agilní přístup. Jde již o plnohodnotnou metodiku, která určuje, jakým způsobem k výsledku máte postupovat. Slovo Scrum pochází ze sportu rugby, u nás se překládá jako mlýn. Jedinou viditelnou paralelou je blízké spojení týmu, ke kterému ve Scrumu i scrumu dochází.

rugby scrum

https://en.wikipedia.org/wiki/Scrum_(rugby)

Týmy fungují v 15 nebo 30 denních cyklech, neboli Sprintech. Každý měsíc uspořádá tým Scrum session, kde prodiskutují všechny úkoly, rozdělí je podle priorit a ty nejdůležitější do co možná nejmenších částí (po jednom až dvou dnech). Každý den pak začíná 15 minutovou schůzkou týmu, kde se probere, co se za předchozí den stihlo, co se nestihlo, případně změny v pořadí úkolů, komu úkoly ten den připadnou atd.

Místo projektového manažera a člena týmu jsou v této metodice celkem tři role. První je role Scrum Mastera, jehož úkolem není řídit projekt, ale především hlídat, že se vše v rámci projektu řídí právě principy Agilu a Scrumu. V některých případech pomáhá týmu s prací a rozřazuje úkoly v rámci týmu, nezodpovídá však za výsledky. Je spíše jakýmsi ambasadorem dané metodologie a nejčastěji se Scrum Masteři recruitují ze seniorních vývojářů v týmu.

Dalšími rolemi ve Scrumu jsou pak Product Owner, který předkládá a udržuje vizi projektu v rámci týmu. Často je to zástupce klienta nebo marketingového oddělení. Zbytek týmu jsou jednotliví členové.

Jasnou výhodou tohoto přístupu je vysoká flexibilita týmu i projektu, vysoká míra komunikace napříč týmem, transparentnost jednotlivých činností a neustálá zpětná vazba na každý krok vpřed. Nevýhodou je poměrně vysoká složitost implementace. Tým často nerozumí nutnosti krátkých každodenních schůzek, schůzky se protahují a řeší se na nich problémy, které mají zůstat mimo. Navíc role Scrum Mastera je pro mnohé neuchopitelná a často tak dochází k propojení s rolí projektového manažera (který ale v této metodologii nemá existovat). I zde je navíc preferovaná komunikace v rámci jedné kanceláře.

 

Kanban

Metodologie vyvinutá v rámci společnosti Toyota v roce 1940 se nezdá vhodná pro současný vývoj softwaru. Metodologie je však dnes upravená pro potřeby právě těchto projektů, spojená s principy Agilu a často doplněná o další přístupy.

Ve svém principu je velice podobná metodě Scrum, na rozdíl od ní je ale mnohem více vizuální. Jednotlivé úkoly jsou zapsány (na lepicí papírky, do mobilní nebo webové aplikace, nebo přímo na fyzickou tabuli) a roztříděny na nástěnce nebo tabuli. Ta obsahuje sloupce jako důležité, méně důležité, aktuálně pracuji, někde je problém, hotovo, případně další podle preferencí týmu. Zároveň je tabule rozdělena podle druhů úkolů do řádek. Barva papírku nebo popisovače často reprezentuje odpovědnou osobu. Celý tým (a lidi mimo něj, například vedení společnosti) má tak skutečný přehled o tom, jaké úkoly čekají na zpracování, kdo na daném úkolu pracuje a v jaké fázi se úkol nachází.

Důležité je rozdělit úkoly na co možná nejjednodušší a nejmenší prvky, s čímž mohou mít členové týmu problémy. Často mají dojem, že úkol je již dost malý, ale při jeho plnění zjistí, že trvá déle než 2 dny.

Samotné slovo Kanban se z japonštiny překládá jako karta pokynů (signal card) a dříve byla hojně využívána ve výrobních firmách pro mapování výrobních a logistických procesů. Dnes ji doporučují i jako výborný prostředek pro řízení práce jednotlivce.

 

Extreme Programming

Jednou z méně známých metod, také vycházejících z agilního přístupu je tzv. extrémní programování. Celá metoda stojí na myšlence dodávat software rychleji a ve vyšší kvalitě. Celý projekt se tak rozdělí do menších částí a ty pak jednotlivě prochází celým cyklem vývoje (návrh, programování, testování, kontrola a refactoring kódu atd.). To zajišťuje dostatečnou flexibilitu, i když nižší než například u Scrumu, ale zároveň jasnou strategii tvorbu softwaru. Navíc umožňuje implementovat činnosti, jako právě refactoring kódu, které v běžném vývoji na řadu nepřichází vůbec nebo jen málokdy. Více také na: http://www.extremeprogramming.org/

 

Metodologií řízení projektů, které se v rámci vývoje softwaru využívají v současnosti, je mnoho. Mezi ty další patří například:

  • Lean
  • Six Sigma
  • Prince 2
  • PMBOK
  • Rapid Application Development
  • Adaptive Project Framework

 

Pokud vás tématika projektového managementu v rámci informačních technologií zajímá, doporučujeme navštívit náš kurz IT technologií pro recruitery, kde se tomuto tématu podrobně věnujeme, včetně osvětlení certifikací a dalších termínů jako například ITIL, Prince 2, PMBOK a další.