Obhajoba projektu Guido

Po dlouhých dvou letech práce jsme konečně odevzdali softwarový projekt Guido a úspěšně obhájili. Pokusím se sepsat své dojmy z práce na projektu a ponaučení, která jsem si z něj odnesl.

O projektu

Guido byl na poměry softwarových projektů na MFF poměrně neobvyklý tím, že se jednalo o projekt náročnější hlavně z teoretického hlediska. Konkrétně šlo o implementaci relativně nové teorie z oboru umělé inteligence založené na práci s pravděpodobností. To s sebou přináší několik vlastností, se kterými je dobré počítat předem (my jsme si je ze začátku neuvědomovali úplně do důsledků)

• Množství kódu v takovém projektu je ve srovnání s jinými malé. Pro nezůčastněného člověka to může znamenat, že jste na takovém projektu odvedli málo práce. Vy víte, že to není pravda, bohužel čas strávený studiem a optimalizacemi se na výsledku projeví jen nepřímo.
• Je možné, že komise a oponent projekt nepochopí a nebude ho chtít nechat obhájit. To se nám (alespoń z té druhé části) nestalo.
• Vývoj takového projektu se těžko odhaduje dopředu. Nevíte, kdy narazíte na zádrhel, který vás zdrží nebo donutí část projektu přepracovat.

Na druhou stranu je nutné dodat, že takový projekt pravděpodobně nebude jenom o datlování kódu v co největším množství, ale půjde hlavně o experimentování, hledání nových postupů a optimalizace těch starých. Tím se projekt stává zajímavější a můžou se tím vyvážit i výše uvedené nepříjemnosti. Možná Vás i bude bavit ;-)

O týmu

Tým jsme sestavili ještě před začátkem projektu, náš cíl byl co nejmenší tým (a z toho plynoucí menší projekt a jednodušší organizace práce), dohromady tedy čtyři řešitelé (přesněji tři řešitelé, jedna řešitelka a vedoucí). Všichni jsme se znali předem alespoń od vidění z přednášek o umělé inteligenci a díky tomu jsme minimálně vzájemně tušili, co je kdo zač.
V mnoha soupisech zkušeností z obhájených projektů se píše "neberte do týmu své přátele, protože po dokončení projektu už to přátelé nebudou." Myslím, že takové doporučení není úplně správné, v kažédm případě byste měli předem vědět, s kým budete pracovat, protože se svými kolegy s projektu budete muset vydržet rok nebo dva a šance na změnu jsou (zvlášť ve chvíli, kdy je větší část projektu hotová) mizivé.
Je dobré si předem zjistit, kdo z týmu se chystá odjet studovat do zahraničí, kdy a na jak dlouho. Půlka našeho týmu po roce vycestovala na rok do Amsterdamu, naštěstí ale oba ve stejný čas do stejného města, proto jsme mohli pokračovat v práci jenom s drobnou změnou v dělení práce.

O vývoji

Stejně jako zadání nepatřilo mezi úplně typická, tak ani vývoj neprobíhal tak, jak je u softwarových projektů obvyklé. Alespoń podle zkušeností z obhájených projektů jsem pochopil, že práce na projektu se obvykle v úvodní fázi rozdělí do několika částí podle počtu účastníků a ti pak samostatně pracují na svých částech a jen čas od času se sejdou, aby probrali noviky a určili směr dalšího vývoje.
To v případě Guida nebylo úplně možné, protože ani po začátku vývoje nebylo úplně jasné jaká bude náročnost jednotlivých částí projektu. Navíc se nám před zahájením projektu dostala do ruky kniha Extrémní programování od Kenta Becka. Popisované výhody některých postupů byly natolik inspirativní, že jsme se rozhodli je adaptovat.
Základem bylo párové programování, které se nám dařilo udržet téměř po celou dobu vývoje (a to i ve chvíli, kdy polovina týmu odjela za Erasmem do Amsterdamu). Díky tomu odpadla nutnost pravidelných týmových schůzek, protože při vývoji byl obvykle celý tým pohromadě v labu a díky tomu jsme mohli sdílet informace a klást dotazy hned na místě, stačilo jen otočit hlavu. Alespoń z části jsme dodrželi pravidlo o sřídání vývojářů na kódu tak, aby pravidelně procházel (implicitně) revizemi i od dalších vývojářů.
Vývoj tímto způsobem sice probíhá na pohled o něco pomaleji, ale na druhou stranu si myslím, že výskyt chyb v kódu a rychlost jejich odstrańování byly proti individuálnímu vývoji nesrovnatelné.
Díky způsobu vývoje odpadla i nutnost explicitně stanovit vedoucího týmu, protože tým byl v době vývoje celý na jednom místě, bylo možné důležitá rozhodnutí dělat okamžitě a velice efektivně.
Pro vývoj libovolného projektu je vhodné používat systém pro správu verzí, u týmových projektů se jedná o věc naprosto nutnou. My jsme díky nezkušenosti použili CVS, které zvlášť pro projekty v Javě vřele nedoporučujeme, jeho věk je na něm dost znát. Ale libovolný systém je lepší než žádný a nakonec jsme se rozhodli, že si nebudeme přidělávat starosti s přenášením repository na jinam a doklepali jsme to s ním až do konce.
Užitečnou pomůckou při vývoji byly automatické (unit) testy, které díky povaze projektu bylo možné aplikovat ve skutečně velké míře. Testované byly prakticky všechny třídy s výjimkou GUI, kde automatické testování není tak jednoduché a účinné. Možnost kdykoliv kompletně otestovat kód je k nezaplacení - a navíc nám díky testům množství kódu dost narostlo :-)
Spolu s automatickými testy jsme zavedli pravidlo, že projekt v CVS musí být vždy kompilovatelný a všechny testy musí na kódu z CVS uspět (a které jsme dokonce až na pár výjimek dodrželi). To opět velkou měrou přispělo k soudržnosti a nízké chybovosti našeho kódu, protože každý člen týmu měl možnost po celou dobu vývoje testovat projekt jako kompletní aplikaci a každý se radší zamyslel, než něco commitoval do CVS.
Další absolutní nutností je buď e-mailová konference s vyhledáváním, nebo vlastní diskusní fórum. Obojí je poměrně jednoduché zařídit a vždy se vyplatí mít někde archiv všekeré důležité komunikace ohledně produktu. Osobně dávám přednost diskusnímu fóru, které umožńuje lepší organizaci diskusních threadů, jejich další třídění do kategorií a případně i další finesy (například aktuální TODO list vyvěšený na titulní straně).

O závěrečném týdnu

Asi u všech softwarových projektů začne pracovní tempo měsíc až dva před odevzdáním rapidně stoupat, s vyvrcholením v posledním týdnu. Je dobré počítat s tím, že v tomto týdnu už nestihnete nic nového naprogramovat, protože budete číst a přepisovat dokumentaci, zajišťovat její tisk, vyrábět instalační CD a do toho opravovat poslední bugy, které se najednou začnou projevovat v nečekané míře.
Pro poslední týden nebo dva je vhodné si udělat TODO list včetně priorit a věnovat se jenom položkám s nejvyšší prioritou (a těm, které můžete dokončit hodně rychle). Nemá smysl se pouštět do úkolů, které zaberou více jak den, pokud nejsou pro odevzdání naproso nepostradatelné. Byl by problém je dokončit a otestovat v rámci celé aplikace, a nestabilní nebo neotestovaná odevzdaná verze určitě není něco co byste chtěli.
Hned po odevzdání je dobré si zjistit, kdo bude projekt oponovat a nabídnout mu předvedení projektu. Oponent bude mít lepší pocit a vy budete poměrně rychle vědět, jak si s projektem stojíte a co můžete čekat na obhajobě. Navíc to je šance, jak si vyslechnout nepříjemné připomínky k projektu ještě před obhajobou a případně je do té doby vyřešit.

O dokumentaci

Dokumentace se odevzdává jednak uživatelská a jednak programátorská. K uživatelské není asi co dodat, snad jen že by měla popisovat skutečně všechny funkce, protože co není v dokumentaci, o tom se nikdo nedozví. Nevím, jaká je situace u jiných projektů, ale v tom našem se uživatelské rozhraní stabilizovalo až ke konci a předtím jaksi nebylo uživatelskou dokumentaci o čem psát.
Programátorskou dokumentaci je možné rozložit do dvou částí - na jedné straně komentáře v kódu (JavaDoc, resp. Doxygen) a na druhé dokumentace psaná jako souvislý text, která popisuje kód z nadhledu a usnadńuje orientaci. Obě části mají svoje místo a ani jedna nemůže úplně nahradit tu druhou. A obě je dobré psát hned od začátku. Opět se vyplatí pravidlo, že nekomentovaný kód do CVS nesmí, které jsme bohužel zas tolik nedoržovali.
Při psaní JavaDoc komentářů je dobré už od začátku dbát na kvalitu a výmluvnost, pokud je u funkce setScale popisek Sets scale, tak to asi nikomu nepomůže. Je vhodné se při psaní inspirovat strukturou a způsobem vyjadřování v dokumentaci k JDK (resp. inspirovat se MSDN).
K tisku jsme měli připravených cca 50 stran povídací programátorské dokumentace, do které jsme chtěli doplnit JavaDoc dokumentaci důležitých tříd (převedenou pomocí Doxygenu do latex formátu). Nechali jsme to na poslední večer před tiskem s tím, že vygenerované soubory jednoduše upravíme a přiložime. Co k tomu říct... po shlédnutí vygenerovaných souborů bylo jasné, že neupravíme a přiložíme jen v html podobě na odevzdaném CD. Proto bych rád upozornil všechny, kteří počítají s tím, že poslední den vygenerují programátorskou dokumentaci z komentářů v kódu, aby si to raději napřed vyzkoušeli a pak počítali ještě jednou.

O prezentaci

K prezentaci je nejdůležitejší vědět, že 30 minut včetně proslovu oponenta, vedoucí a diskuse je strašně krátká doba. Je dobré počítat s tím, že na proslovy a diskusi minimálně 10 minut padne, proto je lepší prezentaci plánovat na 15 minut (s tím, že před komisí se vaše prezentace možná mírně protáhne).
Cílem prezentace není předvést všechna okna v projektu a kompletně popsat jeho API, ale ukázat, co jste vlastně udělali a čím to je zajímavé, na technické detaily je programátorská dokumentace. Cílem je porotu zaujmout a přesvědčit ji, že váš projekt je super, ne ji ze začátku uspat a doufat, že se jí bude zdát něco pěkného a nechá projekt obhájit.
Před odevzdáním projektu si zajděte alespoń na jedny obhajoby a sledujte, co týmy při prezentaci dělají a jak na to komise reaguje, snažte se pochytit, co se komisi nelíbilo, proč a takového jednání se při vlastní prezentaci vyvarovat.
Také se zkuste předem zamyslet nad tím, na jaké dotazy by se vás komise a ostatní účastníci obhajob mohli ptát a připravte si na tyhle dotazy odpovědi. Schopnost pohotově odpovědět určitě udělá na všechny dobrý dojem.

O projektech obecně

Softwarový projekt pro mě byl zajímavá zkušenost,ale myslím si, že svůj hlavní cíl - totiž naučit studenty týmové práci na větším softwarovém díle neplní. O tom, jak (ne)má probíhat vývoj projektu ve více lidech jsem se během několika měsíců zaměstnání v nejmenované softwarové firmě dozvěděl mnohem víc. Na druhou stranu práce na projektu dobře posloužila pro vyzkoušení si některých extrémních programovacích praktik a praktické ověření jejich oprávněnosti.
Souvisejícím problémem projektů je, že zajímavé a bohaté na zkušenosti jsou maximální první dva měsíce a potom až poslední měsíc (první dva jsou pro ty, kteří ještě nic podobného nedělali a v posledním se naučí se pracovat ve stresu a organizovat si práci podle priorit a zbývajícího času). Zbylý čas se jen datluje kód s vyjímečně nízkou bodovou dotací, aby se splnily požadavky na velikost díla, ale nic nového tím nezískává. Čas, který to zabere by šel strávit mnohem lepším způsobem na jiných přednáškách, nebo praxí v nějaké firmě, která je jednak poučnější a jednak mnohem lépe ohodnocená.
Dost často u projektů totiž chybí vedení, který by tým směrovalo ke správným postupům a díky kterému by týmy nemusely hledat vhodná řešení organizace práce metodou pokus-omyl. A z obhajob různých minulých projektů jsem míval pocit, že některé týmu zůstaly u omylu až do úplného konce.
Pokud by projekt měl skutečně sloužit k výuce týmové práce, myslím, že by bohatě stačilo, kdyby se na něm pracovalo jen jeden semestr, ale o něco intenzivněji a pod větším dohledem ze strany lektorů (vedoucích projektů), kteří by byli schopni do projektů zasahovat a včas upozorńovali na chyby. To se v současném systému neděje a stává se, že první skutečnou zpětnou vazbu tým dostane až při obhajobě - a to není to nejlepší místo na zjištění, že něco je špatně. Pak je jasné, že není něco špatně jen v projektu, ale v celém systému, který nechá takový projekt rok nebo dva bez zásahu probíhat.
Druhou možností jsou softwarové projekty zadávané firmami, za které by byli studenti placeni a měli tak alespoń nějakou motivaci k tomu, aby se věnovali i těm méně zajímavým aspektům projektu. O zpětné vazbě zadavatele, kterému skutečně záleží na výsledku ani nemluvě.

Závěrem

Nemyslím si, že by softwarové projekty byly zbytečné a nebo že by se měly rušit, na druhou stranu jejich současná koncepce vede k velkému plýtvání časem řešitelů, a že by lépe motivovaný (finančně/bodově/...), nebo kratší - ale o to intenzivnější - zážitek pro budoucí praxi posloužil mnohem lépe.