Sablona prispevky MSI

Podobné dokumenty
Microsoft Word - Ivanec - esej2011_16-si-xivanec.doc

Sablona prispevky MSI

Microsoft Word - Pavlech - esej2011_02-is-xpavlechl.doc

Microsoft Word - Hitka - esej2011_06-is-xhitka.doc

Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií Zápisnica zo stretnutia #4 Tím sixpack Bc. Jozef Blažíček B

Sablona prispevky MSI

#project #process #change PRACUJTE FLEXIBILNE A INOVATÍVNE! AGILE MANAGEMENT

Snímka 1

Agilní metodiky pro distribuované projekty

Microsoft Word - Manažment_tagov_tim24_tema12_2017.docx

Microsoft Word - Kocian - esej2011_13-is-xkocianr.doc

NSK Karta PDF

msipapersource34-gablovsky

Sablona prispevky MSI

Sablona prispevky MSI

Snímka 1

Microsoft Word - Bartalos.doc

msipapersource54-fabik

Microsoft PowerPoint - OOP_prednaska_10.pptx

Sablona prispevky MSI

Microsoft Word - Fabik - esej2011_18-is-xfabik.doc

Sablona prispevky MSI

Microsoft Word - msipaper63-lamos.doc

V jedinej lekcii Meno: 1 Ako reagujete na profesionálne médiá? Pracujte vo dvojiciach a pripravte sa na hranie rolí. Označte sa ako Osoba A a Osoba B.

Style Sample for C&N Word Style Sheet

Microsoft Word - Lajcin - esej2011_07-si-xlajcin.doc

Sablona prispevky MSI

Microsoft Word - msipaper44-hlavacek.doc

Manažment v Tvorbe Softvéru 2018/2019

C(2014)5449/F1 - SK

SPRINT 2

#project #process #change Univerzitný program projektový manažment Školenie pre budúcich expertov projektového riadenia

Sablona prispevky MSI

Microsoft PowerPoint - 1_eSO1

Microsoft Word - Krajcovic - Esej2011_10-si-xkrajcovic.doc

Prezentácia programu PowerPoint

Microsoft Word - Vacula - esej2011_04-si-xvacula.doc

Vzorové riešenia úlohy 4.1 Bodovanie Úvod do TI 2010 Dôvod prečo veľa z Vás malo málo bodov bolo to, že ste sa nepokúsili svoje tvrdenia dokázať, prič

Snímka 1

(Microsoft PowerPoint - TESCO - v\341\232 partner pre praktick\351 vyu\350ovanie.ppt)

Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií Ilkovičova 2, , Bratislava 4 Internet vecí v našich ž

Microsoft Word - Jaroszewicz - esej2011_08_15_xjaroszewicz.docx

Paralelné algoritmy, cast c. 2

PowerPoint Presentation

Nová éra Microsoft Dynamics 365 v IT spoločnosti GAMO Vďaka dodanému riešeniu sme pomohli zlepšiť fungovanie kľúčových oblastí

Slovenská technická univerzita Fakulta informatiky a informačných technológii Ilkovičova 2, Bratislava Dokument riadenia Tímový projekt II Seal

ISO Systémy manažérstva proti korupcii Svetový deň normalizácie 2018 Miroslav HRNČIAR Žilinská univerzita v Žiline

Prezentácia programu PowerPoint

Microsoft Word - RolyRiadeniaZmien_V1.doc

Mechanizmus skupiny EIB na vybavovanie sťažností

Zastupujeme ľudí s mentálnym postihnutím a ich príbuzných ĽUDIA S MENTÁLNYM POSTIHNUTÍM A ICH PRÍBUZNÍ: VYUŽIME EURÓPSKE VOĽBY 2019 NA MAXIMUM Inclusi

Snímka 1

4-david-msipapersource10.doc

Microsoft Word - šaderová-LM.doc

Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií Iľkovičova 2, , Bratislava 4 Metodika verziovania Tím

Sablona prispevky MSI

10-4 promo

Microsoft Word - Manazment_projektov_tim24_tema12_2017.docx

WP summary

4. Aktivity Klubu pacientov SMyS [režim kompatibility]

Prezentace aplikace PowerPoint

SMART Brain-worksopy-1

Moderne projekty v biznis suvislostiach-1

iot business hub whitepaper isdd_em_New.pdf

Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií Iľkovičova 2, , Bratislava 4 Tímový projekt MOB-UX Pr

Predstavenie tímu Náš tím pozostáva zo siedmich členov: Andrej Hucko, Jakub Domian, Ľubomíra Trnavská, Ján Karaffa, Ľudovít Popelka, Dušan Janeček a Z

Chemical Business NewsBase

Dejepis extra 12/2018 Časopis nie iba pre tých, čo majú radi históriu... Pred budovou Národnej banky Slovenska.

Kreatívny priestor a jeho úloha v akademických knižniciach (s príkladom zo Slovenska)

msipapersource61-petras

NSK Karta PDF

Zdravé sebavedomie odzrkadľuje spôsob, akým vidíme sami seba. Ak sa chceme stať sebavedomejšími ľuďmi, musíme zmeniť to, čo si myslíme sami o sebe, ak

Stepanek3D bannery

Brezina_Gertler_Pekar_2005

Kategória školenia Kurzy Project, Outlook obsahuje kurzy: Outlook základy Účastníci kurzu Outlook základy sa naučia využívať tento program na ov

Princípy tvorby softvéru Modelovanie domény

Microsoft Word - msipaper57-petrakova.doc

Sablona prispevky MSI

Digitálne technológie v každodennom živote 3. ročník akademický rok 2019/2020 Harmonogram prednášok

Detekcia akustických udalostí v bezpečnostných aplikáciách

Prezentácia programu PowerPoint

Prezentácia programu PowerPoint

News Flash 25. augusta, 2015 Zabezpečenie stravovania pre zamestnancov

IAB budicek - Branding Landscape & Research options_FINAL_Gregor.pptx

BUSINESS INTELLIGENCE (BI) MAGIC Štatistiky Obchod a sklady

Matematika 2 - cast: Funkcia viac premenných

kočíky pre dvojčatá

Rozdeľovanie IT zákaziek UX Peter Kulich

Dobývanie znalostí

TECHNICKÁ UNIVERZITA VO ZVOLENE, ÚSTAV TELESNEJ VÝCHOVY A ŠPORTU usporiada 7. ročník vedeckej konferencie s medzinárodnou účasťou TELESNÁ VÝCHOVA A ŠP

Snímka 1

Microsoft Word - AAC-U2-sprava o transparentnosti 2017

Dostatok energie u chronického ochorenia obličiek a optimálnu telesná hmotnosť - Dieta při chronickém onemocnění ledvin

NSK Karta PDF

TS - Budúcnosť autobusovej dopravy SAD Žilina je samozrejmá súčasť našich životov ǀ Žilina ǀ Tlačová správa SAD Žilina, a.s. Spoločnosť Slov

bakalarska prezentacia.key

Platný od: OPIS ŠTUDIJNÉHO ODBORU

Akadémia projektového manažmentu

Prepis:

JE SCRUM TO PRAVÉ ORECHOVÉ PRE MANAŽÉRA PLÁNOVANIA? Ako plánovať a nepreplánovať sa až príliš. Michal Roško Slovenská technická univerzita Fakulta informatiky a informačných technológií Ilkovičova 3, 842 16 Bratislava Michal.rosko@yahoo.com Abstrakt. Plánovanie akéhokoľvek projektu je činnosť zložitá a plánovanie projektu, ktorý má byť podľa predstáv zákazníka ešte viacej. Je preto používanie SCRUM-u naozaj ideálne vo všetkých prípadoch? SCRUM sa síce aktívne používa a ponúka možnosti, ako vytvoriť produkt, ktorý je podľa predstáv zákazníka, ale aký faktor zohrávajú skúsenosti členov tímu pri plánovaním v SCRUM-e? Aké skúsenosti musí mať manažér plánovania pre vytvorenie úspešného projektu? Mnohé ďalšie otázky sa vynárajú pri zamyslení sa nad nadpisom, či je SCRUM to pravé orechové pre manažéra plánovania. Plánovanie jednotlivých etáp v SCRUM-e má svoje úskalia, a práve plánovanie môže byť ovplyvnené viacerými faktormi. SCRUM je založený na tíme, ale čo ak nie je tento tím dostatočne skúsený? Jedným z najhlavnejších faktorov, ktorý ovplyvňuje viaceré etapy, nie len plánovanie, je práve skúsenosť. Či už skúsenosť na strane tímu, členov tímu alebo na strane manažéra plánovania. Kľúčové slová: SCRUM, plánovanie, skúsenosti, tím Úvod Úloha manažéra plánovania v dnešnej dobe nie je vôbec jednoduchá. Z hľadiska skúseností môžem manažérov rozdeliť do dvoch skupín. Tí z nich, ktorí sa tejto problematike dlhodobo venujú, čiže majú viacero skúsenosti a tí, ktorí sú v tejto oblasti úplní nováčikovia. Skúsený manažér plánovania sa môže napriek svojim skúsenostiam Manažment projektov softvérových a informačných systémov, 2012, s. 1-6

2 Michal Roško ocitnúť v roli nováčika, ak sa dostane do tímu, s ktorým ešte nepracoval. Každý tím má svoje osobné návyky, spôsoby komunikácie, vlastne celková práca v rozličných tímoch sa líši. Jeden z predpokladov pre definíciu úspešného tímu je, že tím je súdržná skupina ľudí, ktorí sa zaviazali k dosiahnutiu spoločných cieľov, ktorí dobre spolupracujú, a ktorí produkujú vysoko kvalitné výsledky[1]. Ako je vidieť, v tejto definícií nie je spomínané, akým spôsobom spolupracujú a ako dosiahnu kvalitné výsledky. To znamená, že každý tím môže mať svoj vlastný prístup. Na vlastnej koži sa utvrdzujem v tom, že byť v roly manažéra plánovania, ktorý nemá skúsenosti s plánovaním v tíme, nie je vôbec jednoduché. Určite je veľkou výhodou, ak sa takýto manažér nachádza v tíme ľudí, ktorých pozná a spolupracoval s nimi už na nejakých projektoch. Nič však nezaručuje, že plánovanie bude činnosť nenáročná a plánovanie akéhokoľvek projektu bude jednoduché. Pri skúmaní tímu a plánovania som sa stretol s nasledovnými bodmi, ktoré ovplyvňujú plánovanie, a ktorým sa ďalej venujem v tejto eseji: 1. Miera skúseností jednotlivcov v tíme 2. Súdržnosť - spoločné skúsenosti tímu 3. Skúsenosti manažéra plánovania V dnešnej dobe sa považuje agilný vývoj softvéru za trend, ktorým sa uberajú viaceré firmy. Jedným z týchto agilných vývojov je práve SCRUM. Práve tomuto spôsobu vývoja softvéru sa venujem v tejto eseji. Oproti tradičným metódam má SCRUM výhodu v tom, že manažér plánovania dostatočne rýchlo reaguje na prípadné konflikty alebo nedodržiavanie plánu. Tu upozorňujem na zásadný bod, ktorý sa nachádza v manifeste agilného vývoja[1]. Reagovanie na zmeny pred dodržovaním plánu je jeden z bodov tohto manifestu, ktorý sa najviac vzťahuje na manažéra plánovania. Samozrejme aj ostatné body tohto manifestu sú pre plánovanie dôležité, ak sa vyvíja pomocou SCRUM-u. Body ako plánovať dokončenie funkcionality určitých častí pred vytváraním vyčerpávajúcej dokumentácie. Plánovanie stretnutí so zákazníkom, pretože treba reagovať na jeho požiadavky. Z hľadiska plánovania je najzaujímavejší typ SCRUM-u spomínaný v článku[4]. Konkrétne v tomto type sa autori vyjadrujú aj o takzvanom dennom SCRUM-e. Denný SCRUM znamená, že sa každý deň počas vývoja uskutočňuje krátke stretnutie, kde sa určia šprinty na daný deň. Práve tieto stretnutia napomáhajú manažérovi plánovania veľmi rýchlo a flexibilne reagovať na vzniknuté situácie. Ale je pre manažéra plánovania jednoduché plánovať projekt, ktorý sa vyvíja pomocou SCRUM-u, ak má stále reagovať na zmeny? Sú výhodné denné SCRUM-y, ak sa nachádza v novom tíme, kde nemusí byť správne zabehnutá komunikácia? Je jednoduché naplánovať úlohy pre tím, ktorý manažér plánovania pozná, ale ešte sa nestretol s plánovaním ako takým? Pri spojení SCRUM-u a plánovania vzniká mnoho otázok, na ktoré sa budem snažiť odpovedať a odporučiť metódy, ktoré by mohli toto plánovanie počas vývoja uľahčiť.

Je SCRUM to pravé orechové pre manažéra plánovania? 3 SCRUM a plánovanie Vytváranie backlogu Samotné plánovanie sa začína už pri vytváraní backlogu. Ako sa vraví, náš zákazník, náš pán. Ale ak nemáme dostatok času na vyriešenie špeciálnych požiadaviek, nie je správne ich ani zaraďovať do vývoja. Na základe vytvoreného backlogu manažér plánovania dokáže zostaviť základný plán. Pri tomto vytváraní však musí brať ohľad na to, že sa vyvíja SCRUM-om a nie tradičnými spôsobmi. To znamená, že daný plán musí byť dostatočne flexibilný. Ak má manažér plánovania naplánovať celý projekt tak, aby sa vošiel do určitého obdobia, musí vyberať úlohy, ktoré sa stihnú za toto obdobie vykonať. Úlohy, ktoré sa nezaradia ani do plánu musia byť odôvodnené, prečo neboli zaradené. Najčastejším dôvodom býva časová náročnosť, ale taktiež aj iné body sú dôležité. Samozrejmosťou je, že manažér, ktorý pozná svoj tím a nie je to ich prvý projekt, dokáže tieto odhady plánu spraviť najpresnejšie. Výber úloh V ďalšom kroku, kde sa určujú priority úloh, ktoré sa nachádzajú v backlogu, zohráva plánovanie veľkú úlohu. Samozrejmosťou je, že zákazník vo veľkej miere ovplyvňuje to, aká časť funkcionality sa bude implementovať. Práve tu je výhodou, ak má manažér plánovania skúsenosti s takýmto typom projektu. Dokáže lepšie ohodnotiť dôležitosť určitých úloh danej funkcionality. Pri neskúsenom manažérovi môže veľkú rolu zohrať jeho tím, hlavne ak sa nachádza v kolektíve ľudí, ktorých pozná a vie, že s daným typom úlohy sa niektorí členovia tímu už stretli. SCRUM má tú výhodu, že na každom kroku vývoja softvéru sa zúčastňuje celý tím. Aj pri určovaní priorít úloh sa zúčastňuje celý tím, kde môžu "svoje" povedať aj vývojári. Napríklad, ak potrebujú nejakú úlohu vyriešiť skôr než inú a na prvý pohľad sa to nemusí tak zdať. Ak by manažér plánovania sám určoval priority úlohám, mohlo by sa stať, že by vznikol spomínaný prípad, tým pádom by vývojári zbytočne stáli a čakali, až kým by sa nevyriešila daná úloha, ktorá ich blokuje. Plánovanie vytvárania priebežných verzií Súčasťou SCRUM-u je aj ponúkanie priebežných verzií (ang. release). Tieto verzie predstavujú určitú funkcionalitu a vývoj môže obsahovať viaceré šprinty. Výsledkom by mala byť vyhotovená určitá časť funkcionality celého produktu. Aj v tomto kroku zohráva svoju úlohu manažér plánovania. Skúsený manažér plánovania dokáže lepšie naplánovať vydanie priebežnej verzie. Môžem napísať jedno veľké "ale", ak tento manažér nepozná svoj tím, nemusí to byť on ako plánovač, ktorý zlyhá, ale môže to byť práve tím, ktorý zlyhá pri plnení úloh. S kľudom sa môže stať, že ak sa nachádza v novom kolektíve, naplánovanie prvej priebežnej verzie nebude úplne podľa plánu. Pričom plán, ktorý vytvoril tento manažér plánovania, by tím, s ktorým už spolupracoval, stihol do bodky naplniť. Tu sa snažím práve načrtnúť rôznorodosť tímov. Každý tím je v určitej miere odlišný. Mohol by som dokonca povedať, že ak by nejakú úlohu riešili dva tímy naraz, tak by určite neskončili naraz a dokonca aj

4 Michal Roško finálna podoba úlohy by sa mohla čiastočne líšiť. V opačnom prípade, keď je na pozícii manažéra plánovania neskúsený človek, môže naplánovanie vydania priebežnej verzie dopadnúť rôzne. Ak sa manažér plánovania nachádza v kolektíve schopných ľudí, ktorí dokážu splniť svoje úlohy do bodky, čiže ak sú individuálne schopnosti členov tímu na vysokej úrovni, tak aj výsledky ich prác budú na vysokej úrovni. To znamená, že aj keď naplánovaná úloha neobsahuje úplne presne definované podúlohy, tento skúsený člen tímu dokáže túto úlohu splniť. Sám sa utvrdzujem v tom, že ak má manažér plánovania k dispozícií tím, ktorý je zostavený so šikovných ľudí, plán vydania pribežnej verzie sa vytvára jednoducho. Ak sa však takýto neskúsený manažér nachádza v tíme, ktorý je pre neho nový a nevie, čo môže očakávať od tohto tímu, musí sa najprv naučiť, aké plány vytvárať pre takýto tím. Tu prichádza vhod využiť metodiky na sledovanie členov. Napríklad na sledovanie vyťaženosti tímu môže dobre poslúžiť Ganttov graf. Existujú aj rôzne iné spôsoby, ale tento patrí k najpoužívanejším. Ohodnocovanie úloh v šprinte Ako som spomenul na začiatku predchádzajúceho odseku, vydanie priebežnej verzie pozostáva z viacerých šprintov. Šprint je časové obdobie, na ktoré manažér plánovania naplánuje určitý počet úloh, ktoré sa majú vykonať. Práve tu napomáha spôsob ohodnocovania úloh pomocou kartičkovej metódy. Táto metóda je veľmi praktická a je považovaná za veľmi dobrú pomôcku pri odhadovaní časovej zložitosti určitých úloh. Ak sa stretne tím, ktorý túto metódu ešte nepoužíval, tak sa prvotné odhady môžu u viacerých členov líšiť. Po viacerých odhadoch sa všetci členovia tímu dostanú na jednu rovinu a odhady začnú byť lepšie a aj rozdiely v odhadoch sa znížia. Osobne som si tento spôsob ohodnocovania úloh vyskúšal a môžem ho odporučiť každému manažérovi plánovania, ktorý si nie vždy vie predstaviť časovú náročnosť danej úlohy. Dôležitým faktorom pri plánovaní úloh zo šprintu je to, aby týchto úloh nebolo príliš veľa, ale aj naopak príliš málo. Z tohto dôvodu je dobré mať správne vyriešené sledovanie tímu a na základe výsledkov z predchádzajúcich šprintov upravovať prípadné zvolené množstvo úloh. Samotné plánovanie úloh v šprinte sa môže vykonávať rôznymi spôsobmi. Skúsený manažér vie lepšie rozdeliť úlohu na podúlohy. Pri plánovaní úloh musí každý manažér myslieť na to, aby eliminoval prestoje členov tímov a aby správne využil možnosti, ktoré mu tím ponúka. Práve správnym určením podúloh môže dosiahnuť to, že zmenší veľkosť práce pre jednotlivca a v dôsledku toho môže lepšie rozdeliť pracovníkov. Pri dekompozícii úloh na podúlohy, môže využiť skúsenosti tímu alebo vlastné skúsenosti, ak sa s danou problematikou už stretol. Taktiež sa dajú využiť skúsenosti jednotlivých členov tímu, ktorí vedia, aké podúlohy daná úloha môže obsahovať. Plánovanie úloh Plánovanie jednotlivých úloh je z pohľadu manažéra plánovania podobné ako pri tradičnom spôsobe vývoja softvéru. Viaceré úlohy sú vlastne také menšie vodopády skladajúce sa z analýzy, návrhu, implementácie a testovania. Tu môže využiť manažér

Je SCRUM to pravé orechové pre manažéra plánovania? 5 svoje skúsenosti z projektov, v ktorých vývoj bol práve vedený tradičným spôsobom. Ako je známe, v tradičnom spôsobe vývoja sa plán robí na začiatku a následne je upravovaný len minimálne[3]. Rozdelením vývoja na úlohy a podúlohy vytvorí možnosť naplánovania týchto úloh, ale taktiež priestor na zmenu nejakej z úloh v prípade potreby. Tradičným príkladom môže byť využitie výpočtu kritickej cesty na odhad dĺžky trvania úlohy. Plánovanie však nie je len o odhadovaní časovej zložitosti, ale aj o správnom zvolení poradia úloh a správnom využití všetkých možností tímu. Úloha manažéra plánovania naplánovaním úloh vôbec nekončí. Práve naopak manažér plánovania musí byť stále v strehu, aby mohol preplánovať úlohy v prípade nejakých komplikácii. Spomínaný denný SCRUM pomáha manažérovi plánovania vytvárať si obraz o aktuálnom stave a tým pádom mu umožňuje aj vytvárať lepšie plány a zmeny v plánoch. Ďalší prípad je z pohľadu projektu lepší, a to, keď manažér plánovania nadhodnotí úlohu a pri analýze tejto úlohy sa zistí, že problematika nie je až tak zložitá a na vyriešenie úlohy sa spotrebuje menej času. Tým pádom môže manažér plánovania využiť túto situáciu a naplánovať členom tímu, ktorí mali túto úlohu riešiť, ďalšiu úlohu. Plánovanie úloh pre členov tímu, ktorí sú skúsení nie je až tak zložité, ako plánovanie úloh pre členov tímu, ktorí sú neskúsení. Ak manažér plánovania vytvára plán pre skúseného člena tímu, môže mu tento člen pomôcť lepšie sa oboznámiť s danou problematikou, a tým pádom môže byť vytvorený plán pre úlohu presnejší. Zhrnutie Manažér plánovania má ťažkú úlohu plánovať, ale v SCRUM-e je toto plánovanie zjednodušené, ak má k dispozícií ten správny tím ľudí, ktorí majú skúsenosti. V konečnom dôsledku nezáleží na tom, či je manažér plánovania skúsený, alebo nie, pretože SCRUM je založený na tíme. A aj ten najlepší plán pre nesprávny tím nemusí priniesť očakávané výsledky. Naopak aj zlý plán s dobrým tímom môže v konečnom dôsledku vytvoriť vec, ktorá bude funkcionálne na vysokej úrovni. Takže odpoveď na otázku, či je SCRUM to pravé orechové pre manažéra plánovania je áno, ak má k dispozícii ten správny tím ľudí pre daný projekt, ktorí majú skúsenosti a nie v opačnom prípade. Použitá literatúra 1. Janice El-Bayoumi.: Client Services Work Planning. University of New Brunswick(2007) 2. Manifesto for Agile Software Development. Web: http://agilemanifesto.org/ 3. Israr Ur Rehman, Sajid ullah, Abul Rauf, Arshad Ali Shahid.: Scope Management in Agile Versus Traditional Software Development Methods. Proceedings of the 2010 National Software Engineering Conference, ACM, Istambul(2010) 4. Jeff Sutherland, Ph.D.: Future of Scrurn: Parallel Pipelining of Sprints in Complex Projects. Proceedings of the Agile Development Conference (ADC'05), IEEE(2005)

6 Michal Roško Annotation Is planning in SCRUM so good for planning manager? Planning of any project is a complex operation and planning of a project, which is based on costumer s concept even more. Is therefore SCRUM using ideal in every case? However SCRUM is actively used and offers the possibility to create a product that is based on customer s concept, but what factor do the experiences of team members play in the planning in SCRUM? What level of experience must the planning manager have? Many other questions come to mind, when you think about the title, if the planning in SCRUM is so good for the planning manager. Planning of each stage in SCRUM has its pitfalls and especially the planning can be affected by several factors. SCRUM is based on a team, but what happens if the team is not experienced enough? One of the major factors that affect several stages, not only the planning, is an experience, whether it is an experience of the team, team members or the planning manager.