Zkušenosti ze školního softwarového projektu BEEN

Úvod pro nematfyzáky

Součástí studia informatiky na MFF UK je i předmět Softwarový projekt. V rámci něj mají studenti za úkol vytvořit větší softwarové dílo, řádně ho zdokumentovat a obhájit před projektovou komisí. Cílem předmětu je především naučit studenty pracovat na větším projektu v týmu.

Při obhajobě jsou řešitelé vyzýváni, aby své zkušenosti z projektu sepsali a poslali projektové komisi – kvůli zpětné vazbě a poučení dalších generací studentů. Komise zkušenosti zveřejňuje na speciální stránce.

Rozhodl jsem se své zkušenosti zveřejnit ve svém zápisníku, protože mám pocit, že to je zajímavé téma nejen pro matfyzáky-informatiky a ukazuje to matfyz z trochu neobvyklé perspektivy. Nicméně text je i tak psán především pro "interní" čtenáře a komisi jsem na něj samozřejmě poslal odkaz.

Pro pořádek je nutno dodat, že náš projekt byl ještě veden podle starého systému – podle něj byla nominální délka projektu 1 rok a prodlužování bylo běžné. Dnes je už zaveden systém nový, kde je standardní délka projektu zkrácena na 9 měsíců a je omezena možnost prodlužování. Typický rozsah projektů by tedy měl být menší.

Obecné povídání

Po dokončení projektu jsem si říkal, že do zkušeností dost možná napíšu podobně ostrá slova jako kdysi Johanka. Od té doby jsem trochu vychladl, ale i tak moje zkušenosti rozhodně nebudou vyznívat pozitivně.

Celý projekt ve své současné podobě je šílenost. Jste hozeni do vody spolu s několika dalšími lidmi a místo aby vás někdo učil plavat, je na vás, abyste se neutopili a doplavali ke břehu. A tak se nějak plácáte a pokud se doplácáte na souš, stojí tam člověk (oponent), který víceméně subjektivně ohodnotí váš plavecký styl a může vás spolu s komisí poslat ještě si trochu zaplavat. Tak či onak na břeh vylezete vyčerpáni a nikdy v životě už do vody nebudete chtít vlézt.

O příčinách toho, proč projekty takto vypadají, už bylo napsáno mnoho. Jednou z příčin stávajícího stavu, o které se ale příliš nemluví, je neodbornost vedoucích projektů. Neodborností nemyslím, že by vedoucí nerozuměl tomu, co dělá (s tím jsem se na MFF téměř nesetkal), ale že nerozumí tomu, jak vést větší projekt srovnatelný s běžným komerčním. Není to nic překvapivého, protože 90 % lidí na MFF nikdy nic takového nedělalo – ale když někdo něco nedělá, neměl by to učit, ne?

Možná předchozí odstavce zní jako fňukání studentíka, že ho nikdo nevedl za ručičku. Jenže metoda "hoďme studenty do vody, ať plavou" zcela zjevně nefunguje (viz drtivá většina zkušeností z projektů). A byť je situace nyní aspoň částečně řešena (zkrácením doby k vypracování projektu a větším tlakem na včasné dokončení), je to podle mě málo.

Dle mého názoru by projekty ideálně měl vést někdo, kdo už někdy několik úspěšných (komerčních) projektů vedl, měl by studentům pomoci s metodologií, plánováním práce a dalšími organizačními věcmi. Aby se studenti naučili, jak se projekty mají dělat, a ne jak se dělat nemají.

Chápu, že takových lidí je minimum, nejsou peníze na jejích zaplacení a současní vedoucí mají milion jiných věcí na práci, než "managovat" studentské projekty, i kdyby to uměli. Ale co třeba kdyby měl předmět softwarový projekt na fakultě vyhrazeného člověka, který by právě s takovými věcmi studentům pomáhal? Za kterým by studenti přišli každé dva měsíce a on by jim dovedl říct, co dělají špatně a jak to dělat lépe? A neměl by na starost nic moc jiného, takže by se projektům mohl opravdu věnovat? Jen námět na zamyšlení...

A ještě si rýpnu: Učí se někde na matfyzu, jak připravovat srozumitelné prezentace a mluvit před lidmi? (Odpověď: Ne. Jediný předmět, který s tím měl něco společného – praktikum z informatiky – byl před několika lety bez náhrady zrušen.) Učí se někde na matfyzu, jak psát dokumentaci k programům? (Pokud je mi známo, tak taky ne, když nepočítám pár stručných tipů k dokumentaci zápočťáků, co se dají najít na webech vyučujících.) A proč se z toho tedy zkouší? A rovnou před komisí a s nezanedbatelnými negativními důsledky pro studium v případě neúspěchu?

O našem projektu

Teď trochu konkrétněji o našem projektu. Psali jsme prostředí pro spouštění distribuovaných benchmarků pro skupinu distribuovaných systémů na katedře softwarového inženýrství. Původní plán byl mít projekt hotový za cca 3/4 roku – to se nám podařilo přetáhnout téměř 3× (projekt se táhnul od podzimu 2004 do zimy 2006).

Při zpětném pohledu se zdá, že úloha nebyla nejlepším kandidátem na softwarový projekt. Bylo potřeba hodně zkoumat a vymýšlet architekturu celého řešení, a to se neobešlo bez mnoha slepých cest a přepisování už napsaných věcí. Softwarový projekt by měla být lépe ohraničená úloha. Na druhou stranu bylo výhodou, že vedoucí (Tomáš Kalibera) měl o projekt zájem a jeho přístup bych označil za vysoce nadprůměrný.

Klíčovým faktorem průběhu celého projektu byla absence jasné vedoucí osobnosti. Zpočátku to vypadalo, že se této role chopí Tomáš (vedoucí projektu), ale po cca 2–3 měsících polevil. Pak začal být aktivní Michal, který spolu s Jaroslavem vymýšlel architekturu projektu. V té době jsem si myslel, že kluci vědí, co dělají, a popravdě řečeno jsem se ani o samotné jádro projektu nechtěl příliš starat, takže jsem je nechal vymýšlet. Byla to chyba. Michal s Jarem strávili půl roku v nekonečných diskuzích, které nikam nevedly a projekt jen zdržely. Kdybych byl aktivnější a diskuzí se účastnil, možná bych je dokázal včas zarazit. Ale to je jen spekulace.

Projekt se v následujících měsících "tak nějak vyvíjel", ale někdy na jaře 2006 jsem získal pocit, že se nikam významně neposouvá, a postupně jsem se chopil "managování". Snažil jsem se řídit schůzky, evidovat a prioritizovat úkoly, apod. – zkrátka projekt trochu táhnout. Nebylo to lehké vzhledem k tomu, že jsem nepracoval přímo na jádru projektu (lecos pro mě byla "magie"), a vzhledem k absenci donucovacích prostředků. Myslím ale, že moje iniciativa v této době projektu výrazně pomohla. I tak jsem se dopustil nejméně dvou chyb:

  1. Příliš jsem věřil ostatním členům týmu a spoléhal na to, že se sami dokážou motivovat k práci. Zdaleka ne u každého to byla pravda – bohužel jsem některé členy týmu přecenil.
  2. Neinicioval jsem vyloučení Tondy Tomečka z týmu v létě 2006, kdy dva měsíce téměř nic nedělal. Bál jsem se, že převzetí jeho práce někým jiným by nás zdrželo. Dnes je jasné, že by to bylo naopak.

Antonín Tomeček, nejslabší článek týmu, je kapitola sama pro sebe. Zaslouží si, abych tu řekl, že jeho kód byl běžně dodávaný pozdě, byl špatně navržený i implementovaný a také plný chyb, což nám způsobilo nemálo problémů. Tonda se zbytkem týmu nesplynul ani lidsky, měl snahu se vyhýbat schůzkám a komunikace s ním nebyla snadná. Osobně ho nepovažuju za kompetentního programátora.

S blížícím se dokončením projektu se tempo prací zvyšovalo a velice dobře se poznalo, kdo ze členů týmu se v dřívějších fázích "ulejval" a kdo nikoliv. Spousta funkcí byla nakonec k mé nemalé radosti dodělávána na poslední chvíli nebo nebyla dodělána vůbec a z finální verze byla vyškrtnuta. Noc před odevzdáním jsme pracovali non-stop, což o projektu vypovídá víc než cokoliv jiného. (Byť je to u softwarových projektů na MFF běžné – což zas vypovídá o projektech jako celku.)

Co jsem se naučil?

V podstatě dvě věci:

  1. Javu a několik technologií okolo ní (RMI, Eclipse, Ant, Tomcat, JavaCC,...).
  2. Pochopil jsem, že lidi, se kterými budu někdy spolupracovat na čemkoliv důležitém, si musím vybrat sám, nejlépe na základě předchozích zkušeností na nějakém menším projektu. Zní to možná trochu namyšleně, ale z našeho týmu bych byl ochotný do budoucna spolupracovat jen s jedním, možná dvěma jeho členy. Ostatní mě nepřesvědčili buď po stránce programátorských schopností, nebo pracovní morálky.

Na dva roky práce, včetně posledních pěti měsíců permanentního stresu, kdy jsem v podstatě nežil a věnoval se jen projektu, to není nic moc.

Co jsem se naopak nenaučil, byla proklamovaná práce v týmu – práce v CZille (skupina dobrovolníků zabývajících se lokalizací a podporu produktů Mozilly v ČR) a Impala Design (webdesignerská firmička, kterou provozujeme s kamarádem) mi v tomhle dala mnohem víc zkušeností, už kvůli tomu, že se zde vše odehrávalo v reálném prostředí a ne všichni, se kterými jsem spolupracoval, byli matfyzáci.

Co bych doporučil dalším účastníkům projektů?

(Snažil jsem se vynechat věci, co už jsou mnohokrát řečeny jinde, krom některých opravdu důležitých.)

A na závěr pár technických tipů:

Mar 9, 2007 – 13:31

Comments

Dan Lukes
Dan Lukes
Ackoliv jsem clenem te komise, poskytnu nazor toliko soukromy. Nektere zde prezentovane nazory sdilim - zejmena ten, ze mnoho vedoucich ve skutecnosti ma male zkusenosti a tedy nedostatecnou kvalifikaci pro skutecne odborne vedeni takovych projektu. Navic se zda, ze fakticky vetsina "vedoucich" nezastava ulohu vedouciho projektu - nerozdeluji praci, nekontroluji vcasne a kvalitni odevzdavani prubeznych nezivysledku, nekoordinuji. Funguji spise v roli "konzultantu". Skutecneho vedouciho projektu si tak team musi najit - a skutecna smule je, pokud team byl vystaven tak, ze tam nikdo schopny tuto roli zastavat neni. Ztotoznim se i s tim, ze mnoho projektu, zejmena "minule koncepce" bylo prilsi megalomanskych.

Nicmene, s nekterymi vecmi se uplne neztotoznim - nebylo to k nicemu. Jestli jsi se naucil, ze "schopnost psat kod" je jen jednou - a zdaleka ne nejdulezitejsi - ze schopnosti, ktere jsou potreba pro dokonceni projektu, ze cele je to prevedsim o schopnosti "ukocirovat" team lidi (ne vzdy si clovek muze uplne svobodne a libovolne vybrat). Ze je treba rozdelit ukoly a odpovednost.

Ted, kdyz uz to vite, zni to jako triviality, ktere "lze vymyslet selskym rozumem" - jenze - podle vseho podobnou zkusenost ucini prakticky kazdy projekt - a to vcetne tech, u kterych se zdalo, ze si databazi zkusenosti z projektu peclive prostudovali - zda se tedy, ze nejmene nektere z techto zkusenosti jsou nesdelitelne - a lze je ziskat jedine vlastnorucnim pokusem, a ten musi probihat pod urcitym tlakem - jinak ke vzniku zkusenosti vubec nedojde.

Urcite tedy slo ledacos udelat jinak, zejmena celkova obrtiznost a s tim souvisejici casova narocnost by mela byt mensi (a ja doufam, ze se zmenou pravidel se daleko mensi stane), ale pres vsechny zapory a nedostatky si myslim, ze jste se naucili pomerne dost - a zejmena nektere veci, ktere se opravdu nedaji predat zadnym prednasenim ani ctenim script.

Co me mrzi, ze jste se nenaucili komunikovat - a tim ted nemyslim se sebou. Kdyz v realnem komercnim svete zjistite, ze zadani a cas k reseni spolu proste nekoreluji, a to neni situace nijak neobvykla, je potreba se sejit se zucastnenymi (v komercnim svete se sefem, tady s vedoucim a v pripade potreby do diskuse zatahnout i komisi) a dohodnout se "co s tim". Reseni je spousta - posunuti terminu, uprava zadani - nej casteji se pouziva obe. Ale je potreba se domluvit vcas - tak, aby stale platilo, ze vysledku lze dosahnout a spokojeny budou vsechny zucastnene strany misto toho aby team programatoru padal na hubu, vysledek odevzdal nekolik mesicu po terminu a jeste slo o vysledek plny diskutabilnich kvalitativnich kompromisu. I kdyz, mozna si i tohle dulezite pouceni z projektu odnasite ...
David Majda
[1] Souhlasím s tím, že zkušenosti z projektu jsou do velké míry jiným způsobem nesdělitelné - ostatně nikde taky nepíšu, že by se měl projekt úplně zrušit. Otázka je, za jakou cenu (= především čas) jsou zkušenosti získány a zda by se nedaly získat "levněji".

V našem konkrétním případě se mi cena těchto zkušeností zdála až příliš vysoká. A jak uvádím v textu, zkušenosti podobného typu jsem sbíral i jinde, kde mě to na rozdíl od projektu bavilo a vydělal jsem si přitom i nějaké peníze. Projekt byl z mého pohledu spíše brzdou. Ale uznávám, že v tomto není můj případ asi typický, a taky uznávám, že část zkušeností z projektu dost možná ocením až časem (tj. že možná mají větši hodnotu, než jim přisuzuju teď).

Ad komunikace: S vedoucím komunikace samozřejmě probíhala, měnily se jak temríny, tak rozsah práce (zadání jsme měli naštěstí napsané dostatečně obecně). Bohužel se nám ale špatně cokoliv odhadovalo, jednak kvůli nezkušenosti některých členů týmu a jednak kvůli charakteru projektu, kde se objevovaly nové a nové záludnosti a problémy. Na druhou stranu, s tímhle se komerční projekty musí vypořádat taky. Musím přiznat, že projekt mě naučil si na toto dávat větší pozor.

Ad komunikace s projektovou komisí: Jeden z důvodů toho, že se příliš nekoná, je IMO i to, že pohledu studentů je jakékoliv zatahování komise např. do procesů typu "úprava zadání směrem ke změnšení" ukázka slabosti projektu, odhalení jeho problémů, a tedy snížení šance na obhajobu. Ve chvíli, kdy je komise efektivně orgán, který studentovi neúspěšnou obhajobou může pořádně zkomplikovat nebo i ukončit studium, je tento pohled myslím pochopitelný. Ze strany komise by možná pomohlo nějaké vstřícné gesto, že by na webu (který je mimochodem strašný!) bylo jednoznačně deklarování, že komise je tu i od toho, aby řešila tento typ problémů, že se běžně stávají, nebudou z nich vyvozovány negativní důsledky a že je lepší se na ni při problémech obrátit dřív, než později. Snaha o komunikaci by měla být vzájemná.
Jaroslav Urban
Jaroslav Urban
Ako dalsi clen teamu tohto projektu pridam par poznamok. Najprv moje skusenosti s nastrojmi ktore sme pouzili (myslim ze tie skusenosti platia aj pre ostatnych):

1) Eclipse: vsetci sme pouzivali IDE Eclispe, a ja som bol jednoznacne spokojny. Spravalo sa podla nasich predstav a prisposobilo sa nam, nie naopak. Na zaciatku nam chvilu trvalo kym sme sa ho naucili poriadne pouzivat, ale potom to stalo za to. Dost sme pouzivali refaktorovanie kodu, integracia s CVS je vyborna. Mali sme vsetci rovnako nastavene automaticke formatovanie kodu, takze to zjednodusovalo dodrziavanie coding conventions (neskor sme pouzivali plugin Checkstyle).

2) Ant: standardny build system pre Javove projekty, k nemu nie je moc co dodat. Build subory sa v nom pisu celkom pohodlne...myslim ze poslednou dobou sa zacina presadzovat jeho "potomok" Maven, s tym to ale neviem porovnat

3) CVS: nejaky revision control system je samozrejme nutny, my sme vybrali CVS. dneska by sme uz zrejme pouzili SVN, ktore riesi niektore problemy s CVS na ktore sme narazili aj my (napr. komplikovany presun suborov/adresarov). CVS ma vynikajucu integraciu v Eclipse, takze sa pouzivalo velmi prijemne.

4) Wiki: pouzivali sme DokuWiki. jednoznacne odporucam pre projekty pouzivanie nejakej wiki (sukromnej, pod heslom), je to vyborne miesto na ukladanie vyvojarskej dokumentacie, rodiacej sa architektury projektu atd.

5) VMWare: mali sme stastie ze sme mohli sami pouzivat skolsky VMWare server, ktory zvlada mnozstvo sucasne beziacich virtualnych strojov (pripajali sme sa na neho vzdialene). taktiez sme mali k dispozicii multilicencie windows. takto sme si moli spravit virtualnu siet na ktorej bezali rozne platformy. s tym sa nam to omnoho lepsie testovalo (na windows xp, gentoo a fedore linuxu). podla mojho nazoru by sme bez pristupu k tomu vmware serveru projekt bud este neodovzdali, alebo odovzdali vo velmi neodladenom stave....tento vmware server je uz zrejme teraz pouzivany na vyuku (administrace windows a linuxu pravdepodobne). myslim ze by bolo velmi dobre keby skola nejakym sposobom spristupnila vmware servery aj mimo tych par predmetov kde sa pouzivaju. urcite by to pomohlo mnohym projektom/zapoctakom atd. je mi jasne ze by boli velke problemy s kapacitou, takze neviem ci je to realne....



o nasom projekte si myslim ze nie je vhodny na softwarovy projekt. nanestastie to na nom nie je moc vidno. nas projekt bol velmi vyzkumny, pokial viem nic podobne neexistuje, na druhu stranu u softaroveho projektu musite "slubit" co spravite. nas projekt by sa dobre vyvijal pre skupinu ktora nie je tlacena casom, ktora moze postupovat iterativne, ked si vymysli featuru tak ju skusi implementovat. ak zisti ze to implementovat nejde (alebo je to strasne moc prace), tak sa nic nedeje, atd.

my sme samozrejme neboli moc skuseni, takze sme sa snazili vsetko vymysliet na zaciatku, a nevideli sme veci ktore nie su podstatne, takze sme ich hned na zaciatku nevyhodili. v projekte maju studenti samozrejme strach z vyhazdovania featur, nevieme nakolko je komisia zhovievava k zjednodusovaniu projektov. takto sme dost prace venovali veciam ktore nakoniec neboli nejak podstatne.

suhlasim s Davidom ze projekty potrebuju silneho veduceho, a som rad ze jemu sa to do istej miery podarilo dosiahnut. nanestastie to u nas trvalo dlho, takze ostanym projektom odporucam najst si "autoritu" hned na zaciatku. ale ta autorita musi byt skutocna a efektivna, nemozete sa hrat na veduceho. veduci musi projektu rozumiet, pretoze jeho dolezita funkcia je vyhadzovanie nepotrebnych featur (a vseobecne prioritizacia prace).

na projekte som sa strasne moc naucil, ale tiez neviem ci to stalo za tu cenu. vacsinu veci som sa naucil za cca. 1. rok projektu, potom to bola hlavne drina.....na konci som sa naucil ake je jednoduche vyhadzovat z projektu featury, kedze o tom ktora featura ostane a ktora nie som rozhodoval hlavne ja s Davidom :)

buducim projektom urcite prospeje kratsi rozsah, ale nie som si isty ci to staci. myslim ze by prospelo keby viac projektov zadavali firmy, aby sa napr. aj jednotlivec mohol zucastnit nejakeho vacsieho projektu robeneho nejakou firmou. mozno by mu to dalo viac ako cisto skolsky projekt.
Milan Kryl
Dost zajímavých a praktických informací o projektech se dá najít v knize od 37Signals - Getting Real.

http://gettingreal.37signals.com/

Je dostupná i ve formě HTML zdarma na webu, takže ji lze použít jako jeden z velmi užitečných zdrojů před plánováním projektu (myslím i na MFF).

http://gettingreal.37signals.com/toc.php

Je pravda, že některé zkušenosti člověk získá, až je zažije na vlastní kůži, ale něčeho se může i velmi dobře vyvarovat (případně až zjistí, že má tato kniha opravdu reálné pozadí).

Davide, pokud neznáš, tak doporučuju minimálně její první polovinu k přečtení.
Josef Pelikán
[1] Mám svůj názor na kvalitu vedoucích projektů v komerční sféře: účastnil jsem se několika projektů (větších než jsou studentské projekty na MFF) a věřte mi - často je i tam vedoucím člověk, který vůbec nechápe, co "vůdcovství" obnáší.

Navíc se vám tam může stát, že bude vedení připomínat, že sice projekt se už (vinou firmy) zpozdil o rok, ale že každým dnem zpoždění firma přichází o 1/2 milionu Kč..

Řídit týmy typu "tři kamarádi" (kteří si vyhovují) je něco úplně jiného než řídit tým 10 vývojářů, kteří mohou být i lidsky nekompatibilní. A v reálné praxi nastane spíše ten druhý případ..

Shrnutí - na MFF nejsou možná nejkompetentnější vedoucí, ale v praktickém životě (v Česku) jich také moc není!
Petr Tůma
Petr Tůma
Jen malý postřeh k otázce vedení projektu. Ve srovnání s firemními projekty má vedoucí projektu ve škole velmi omezené možnosti, jak tlačit na členy týmu. V podstatě je může jenom vyhodit (vedle promlouvání do duše), což je za drobné výpadky příliš tvrdý postih ...

... navíc na projektu se mají lidé učit a je velmi těžké rozlišit, zda členové týmu nepracují, protože neumí to, co mají udělat (za což se asi těžko může trestat), nebo jen protože se jim nechce (za což bych klidně vyhodil).

Krom toho ve firmě je přirozené žádat práci "na plný úvazek", projekt je oproti tomu jen jedna z částí výuky.

Tedy uznávám, že vedení projektu je často problém, ale chci upozornit na to, že ve škole se v tomto ohledu těžko vytvoří situace odpovídající firemní praxi.
Přemek Brada
Dovolte pár postřehů "z venku" (http://www.kiv.zcu.cz/staff/).

[1] Z mé praxe výuky SWI na univerzitě je právě otázka motivace, tedy "vzniku zkušenosti", tou skoro nejdůležitější. To je důvod, proč se podobné projekty, se všemi slabinami, používají jako součást curicula při výuce softwarového inženýrství. Většina SWI je totiž tak trochu "selský rozum" který, když ho člověk poslouchá na přednášce, se jeví jako samozřejmost. Při projektu si člověk trochu natluče, čímž zjistí, že to taková samozřejmost není, a to mu může otevřít oči/hlavu pro schopnost začít brát metodiky a spol. trochu vážně.

Samozřejmě, pokud je cena za získání takové zkušenosti moc velká, pak takový postup může být kontraproduktivní. Bez jisté pokory garantů projektu a komise, sebereflektující vlastní nezkušenost s řízením velkých projektů, se to neobejde...

[2] Ad role komise: osobně bych při hodnocení projektu dával velkou váhu hodnocení vedoucího (či spíše "konzultanta"), který projekt přeci jen sleduje delší dobu a dokáže - doufejme - objektivně zhodnotit výkon týmu.

[3] Řízení "výzkumných" softwarových projektů není jednoduché ani z jedné strany, protože ani zadavatel často nedokáže predikovat kam se vývoj bude ubírat. Jako ex-post námět mohu doplnit, že podle diskuse s lidmi zběhlými v agilních metodikách by např. SCRUM (http://www.controlchaos.com/about/) mohl být použitelným iterativním rámcem pro takový vývoj.

Add comment

It is not possible to add comments to posts older than one month.