Team Se@Msi: Meranie v softvÃ©rovom inÅ¾inierstve. - FIIT STU ...

More documents

Recommendations

Info

26 Eseje počúvať, ak ich tímová práca má byť efektívna. Ani na túto úroveň komunikácie by dobrý manažér nemal zabúdať. Príbeh tretí: Manažér je tu pre projekt a nie projekt pre manažéra. Tento príbeh sa odohráva v prostredí veľkej telekomunikačnej spoločnosti. Náš sprievodca príbehom sa volá Pradeep a práve k tejto firme nastúpil. Jeho nadriadený ho na začiatok priradil k údržbe 20 ročného softvéru, napísaného v C a assembleri. Počas “tréningu” sa Pradeep zdokonalil v technickej oblasti a získal vedomosti o modele vyspelosti procesu (CMM). Zamestnanci spoločnosti boli hrdí na to, že ich spoločnosť bola ohodnotená CMM stupňom 3. Aj Pradeep bol hrdý na to, že pracuje v spoločnosti, ktorá používa metódy, ktoré jeho vyučujúci na univerzite označili ako najlepšie. Tréning skončil a Pradeep bol presunutý k malému tímu. Koncom roka spoločnosť získala dokonca CMM úroveň 4 a začala aplikovať rovnaký model práce na všetky projekty. A kde je problém v tomto prípade Organizácia práce je na skvelej úrovni, nikde nie je zmienka o meškaní projektu alebo iných problémov. Lenže nie je všetko zlato, čo sa blyští. Presun myšlienok z teórie do praxe nie je jednoduchý. V Pradeepovej spoločnosti manažéri, ktorí dozerali na kvalitu procesu tvorby projektu (v článku nazývaní “project police”) nútili každého dodržiavať štandardy do písmena. Takýto spôsob tvrdo dopadol najmä na malé projekty. Situácia sa dostala až do štádia, keď členovia tímov úmyselne zavádzali chyby do programu, ak sa pri testovaní ukázalo, že ich je menej ako sa očakáva. T.j. menej ako tabuľková hodnota, ktorou sa riadili manažéri. Každá odchýlka bola podozrivá. Manažéri sa pustili jednou cestou, nezohľadňujúc špecifické vlastnosti jednotlivých projektov. Začali aplikovať jeden formát na všetky projekty – veľké, malé, údržbu, výskum či vývoj. Manažér má napomáhať projektu, je to on kto “slúži” projektu a nie projekt manažérovi. Formálne postupy, merania napredovania prác, správy o stave projektu sú tu na uľahčenie práce pri riadení a realizácii projektu. Všetky tieto manažérske postupy sú prostriedkom a nie cieľom. Prostriedkom k riadeniu a sledovaniu projektu. Ak sa na toto zabudne, z prostriedkov na stanú ciele činnosti manažéra. Riadiace postupy skostnatejú a namiesto uľahčenia práce ju členom tímu zhoršujú. Pokiaľ sa manažéri zmenia na kontrolórov, ktorí len sledujú dodržiavanie pravidiel, mali by byť vymenení. A opäť sa dostáva do popredia otázka citlivého, uváženého prístupu vedúceho pracovníka. Aj projekty z jednej oblasti môžu (a zvyčajne) sú rôzne. Nemožno ich zaradiť do jednej škatuľky. K tomu je nevyhnutné, aby manažér mal znalosti a hlavne skúsenosti z problémovej oblasti. Preto sa ako ideálne javí, dosadzovať na miesta riadiacich pracovníkov bývalých odborníkov – návrhárov, programátorov a ďalších. Lenže kto je dobrý programátor nemusí byť ešte dobrý manažér. A nie každý dobrý manažér projektu je dobrý manažér kontroly procesu, tak ako sa to stalo v našom poslednom príbehu.
N Softvérový manažér 27 a manažéra (nielen softvérového) číha množstvo nebezpečenstiev. Tak ako sa postupne zvyšuje komplexnosť sofvérových produktov, tak stúpajú aj nároky na riadenie takéhoto projektu. V ľuďoch je často zakorenená predstava, že hlavné problémy sú technického rázu [Racos98]. Nie je to pravda. Mnohé problémy skončili neúspešne kvôli organizácii práce, či problémom v komunikácii. Všetci isto poznáme príbeh o Babylonskej veži [Brooks95]. Členovia tímu sú jedinečné ľudské bytosti, dosahujú nielen rôznu pracovnú výkonnosť, ale majú aj rôzne spoločenské cítenie. Niekto spolupracuje s ostatnými rád, iný radšej pracuje sám. Medzi členmi tímu sa môžu vyskytnúť problémy, ktoré nesúvisia, resp. nevznikli na pracovisku. Na to, aby manažér zvládol ukontrolovať vývoj vo svojom tíme, aby ľudí dokázal motivovať, usmerniť ich, aby ťahali za jeden povraz, musí byť dobrý psychológ. Tu mu jeho znalosti z problémovej oblasti nepomôžu. Musí so svojím tímom „žiť“, aby zachytil vznikajúce problémy a nie až keď sa prejavia v plnej sile. Manažéri často zasahujú, až keď morálka tímu dosiahla dno [Mirantes97]. Vtedy je už ale neskoro. Literatúra [Brooks95] BROOKS, FREDERICK P.: The Mythical Man-Month: Essays on Software Engineering. 2. vyd. Addison-Wesley, 1995. 336 s. ISBN 020135959. [Mirantes97] MIRANTES, A.: Keeping a good software team. 1997. http://www.baz.com/kjordan/swse625/htm/tp-am.htm. [Racos98] RACOS, J.: Project <strong>Team</strong>s – Myths and Reality. 1998. http://www.dot.ca.gov/hq/projmgmt/CHRONOLOGY/Int ranet/PMI/PDF/PD27.PDF. [Reifer99] REIFER, D. J.: A tale of three developers. Computer IEEE, November 1999, s. 128-130.
Page 1: MSI KIVT FEI STU Bratislava
Page 5 and 6: Slovenská technická univerzita 20
Page 7: Predslov Publikácia, ktorú práve
Page 11: DIEL I. Eseje o manažmente softvé
Page 15 and 16: Chyby v procese tvorby softvéru a
Page 21 and 22: Je otvorený zdrojový text riešen
Page 23 and 24: Technické problémy Je otvorený z
Page 25 and 26: Je otvorený zdrojový text… 15 p
Page 27 and 28: Zlatá rybka Peter AGH „Chcem to
Page 29 and 30: Zlatá rybka 19 treba počítať a
Page 31 and 32: Zlatá rybka 21 určité znalosti a
Page 33 and 34: Softvérový manažér Ján Pidych
Page 35: Softvérový manažér 25 Príbeh d
Page 40 and 41: 30 Eseje Všadeprítomné modely Pr
Page 42 and 43: 32 Eseje Príklad kolízie medzi mo
Page 44 and 45: 34 Eseje a revízia pokračuje v di
Page 46 and 47: 36 Eseje technikou vyjednávania o
Page 48 and 49: 38 Eseje • Kapacita procesu • S
Page 50 and 51: 40 Eseje dostupné používateľovi
Page 52 and 53: 42 Eseje Manažér môže podniknú
Page 54 and 55: 44 Eseje prístup. Nestačí zhroma
Page 56 and 57: 46 Eseje Napriek všetkým snahám
Page 58 and 59: 48 Eseje [LOCS] 10 15 10 14 10 13 1
Page 61 and 62: Pripravte sa zlyhať Michal Šrámk
Page 63 and 64: Pripravte sa zlyhať 53 Zabehnuté
Page 65 and 66: Pripravte sa zlyhať 55 k pokroku.
Page 67 and 68: Testovanie požiadaviek a človek v
Page 73 and 74: Čo robiť, keď zákazník nevie p
Page 75 and 76: Čo robiť, ked zákazník nevie pr
Page 77 and 78: Čo robiť, ked zákazník nevie pr
Page 79 and 80: Ako zlepšiť softvérové procesy
Page 81 and 82: Ako zlepšiť softvérové procesy
Page 83: Ako zlepšiť softvérové procesy
Page 86 and 87:
76 Eseje snažia splniť normy (nap
Page 88 and 89:
78 Eseje myslieť aj na to, že int
Page 90 and 91:
80 Eseje Obstarávanie môže pomô
Page 92 and 93:
82 Eseje [Cross] CROSS, S.E.: Towar
Page 95 and 96:
Úvod Priznám sa, že keď som prv
Page 97 and 98:
Úvod 87 Produktom etapy návrhu je
Page 99:
Úvod 89 merania softvéru z pohľa
Page 102 and 103:
92 Meranie a životný cyklus softv
Page 104 and 105:
Page 106 and 107:
Page 109 and 110:
Meranie v etape návrhu Stanislav H
Page 111 and 112:
Meranie v etape návrhu 101 niektor
Page 113 and 114:
Meranie v etape návrhu 103 Metrika
Page 115 and 116:
Meranie v etape návrhu 105 Pomocou
Page 117 and 118:
Meranie v etape návrhu 107 Funkcio
Page 119 and 120:
Meranie v etape návrhu 109 kompakt
Page 121 and 122:
Meranie v etape implementácie Vlad
Page 123 and 124:
Meranie v etape implementácie 113
Page 125 and 126:
Page 127:
Page 130 and 131:
120 Meranie a životný cyklus soft
Page 132 and 133:
Page 134 and 135:
Page 137 and 138:
Meranie pri testovaní, prevádzke
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Meranie vyspelosti softvérového p
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Page 159 and 160:
Meranie produktivity Ján Pidych Ab
Page 161 and 162:
Meranie produktivity 151 Takisto je
Page 163 and 164:
Meranie produktivity 153 TDEV je č
Page 165 and 166:
Meranie produktivity 155 komunikác
Page 167:
Meranie produktivity 157 Litaratúr
Page 170 and 171:
160 Meranie a manažment, meranie p
Page 172 and 173:
Page 174 and 175:
Page 176 and 177:
Page 178 and 179:
show all

Team Se@Msi: Meranie v softvÃ©rovom inÅ¾inierstve. - FIIT STU ...

Create successful ePaper yourself

Delete template?

Save as template?