O obhajobě toho moc napsat nemůžu, protože jsem v té době lyžoval kdesi v Alpách. Taky odevzdávat jsem nebyl já, ani předvádět to oponentovi...celkem vzato jsem se ke konci skoro flákal. Ale co už, měl jsem nejvíc odpracovaných hodin.
Zkusím shrnout aspoň nějaké závěrečné poučení a poučky z našeho projektu.
Softwarový projekt na MFF
Oficiální délka tvání projektu je podle nových pravidel 9 měsíců. Reálně jsme na projektu dělali skoro rok, a to nepočítám přípravu, úvodní dohadování se zákazníkem, hledání vedoucího a podobně.
Prvních zhruba 6 měsíců práce na projektu bylo celkem poučných a užitečných šest měsíců. Naučili jsme se leccos z reálného světa, kde si člověk nesmolí jen tak něco sám a pro sebe. Velkou studnicí zkušeností bylo, že jsme dělali reálný projekt pro reálného zákazníka (reálný zákazník se pozná zejména podle toho, že neví určitě, co chce, ale zato ví přesně, že to chce hned - no, nejpozději do týdne).
Pak se to ale tak trochu zvrtlo, jak už jsem koneckonců psal. Přišla fáze, kdy už se moc nevymýšlelo a nenavrhovalo, ale spíš dodělávalo, testovalo, opravovalo, dokumentovalo.
A nejhorší zkušenost asi mám z posledních dvou tří měsíců, kdy jsme začali finišovat a připravovat finální podobu aplikace i dokumentace k odevzdání. Tam se podle mého největší přednost projektu, reálný zákazník, začala jevit jako podstatná překážka při obhajobě. Projektová komise má pravděpodobně suplovat "reálného" zadavatele projektům, které skutečného (čti komerčního) zadavatele nemají a zadává je škola. My zadavatele měli a požadavky komise se tváří v tvář tomuto faktu splňovaly těžko. Bylo nám v podstatě řečeno, že to, že máme reálného zadavatele, je náš problém, a k obhajobě že to půjde podle požadavků komise. Takže jsme vlastně museli udělat aplikaci splňující požadavky dvou "zadavatelů", leckdy dost odlišné až protichůdné.
Obhajoba například požaduje odevzdání "hotového díla". Že v reálu děláte aplikaci na zakázku, u které se vysloveně předpokládá průběžný vývoj ještě po několik let? Nezájem. Že návod k použití má podle dohody sepsat zadavatel podle svých představ? Ale komise chce mít návod k použití od vás.
Nakonec jsme kvůli obhajobě udělali dost reálně zbytečné práce a (s pomocí vedoucí) složitě formulovali, že to a to není součástí projektu, abychom mohli říct, že co bylo součástí, je hotové.
Zlášť otřesným zážitkem, co jsem slyšel od kolegů, byl přístup komise k obhajobě samotné. Na obhajobu se od začátku uráčil přijít jeden z devíti členů komise,
Na drouhou stranu pozitivní zkušeností, zlášť pro další generace matfyzáků, je, že v novém formátu už není vyžadována polovědecká objevná práce, ono dříve často zmiňované slibování hor a dolů. Obhájili jsme s projektem, ve kterém nebylo nic objevného, nebyla v něm použita žádná vyjímečná myšlenka, žádný extra algoritmus. Ale byl to projekt, na kterém jsme odpracovali podle našich záznamů 1650 hodin, trval 11 měsíců a byl z reálného světa. Nebyl to projekt, který by přinesl něco objevného světu, ale přinesl dost zkušeností nám. Tedy předmět, z něhož vytěžili primárně jeho studenti, ne fakulta.
Obecně
Tady je pár obecných pouček pro začátečníky, jako jsme (byli) my:
Komunikace - podle mě jsou zásadní pravidelné schůzky, e-mailová konference a ICQ nebo jiný instant messenger. Primárně jsme věci řešili přes mailing list, ICQ posloužilo pro rychlé řešení čehokoliv s jedním člověkem a týdenní schůzky se ukázaly nepostradatelné zejména kvůli motivaci - každý se snažil mít do schůzky to, co měl za ten týden udělat, opravdu hotové.
Repository - o nutnosti používat pro kód a další soubory repository, umožňující současnou práci celého týmu na projektu, snad ani nemusím psát. Zvolili jsme CVS. A protože jsme žili v reálném světě, nevyhnuli jsme se ani takovým libůstkám, jako je větvení.
Evidence chyb - používali jsme systém Mantis. Že to bez issue tracking systému nepůjde jsme zjistili, když jsme začali potřetí či počtvrté objevovat již jednou nalezené chyby, které ale v e-mailové konferenci "tak nějak zapadly".
Dokumentace - dokumentace v kódu je samozřejmostí, a ke konci začali už i moji kolegové zjišťovat, že není od věci popis funkce napsat dřív než její tělo. Kromě toho jsme myšlenky a návody k použití různých modulů aplikace dokumentovali s pomocí wiki (Mediawiki, konkrétně). Učesat nějak dokumentaci do odevzdatelné podoby, přidat uživatelskou a programátorskou příručku nám trvalo skoro půl roku.
Další dokumenty - je dobré si schovávat (nejlíp v repository) všechny dokumenty vzniklé při práci. A hlavně je užitečné schovávat si všechny dokumenty, které vám kdy zákazník poslal, nejlíp s datem přijetí. Kromě toho bych rozhodně doporučil zaznamenávat si důsledně počty odpracovaných hodin.
Modelování rozhraní aplikace - velice užitečná věcička. Protože naše aplikace byla webová stránka, použili jsme opět wiki (v ní se stránky a vazby mezi nimi dělají opravdu snadno a rychle). Nejen že nám model GUI umožnil najít místa, kde jsme zákazníka špatně pochopili, často taky našel místa, kde zákazník netušil, co chce, často ani netušil, že má něco chtít. Nad modelem to pak byl nucen domyslet. Zásadní je, že model se mění nesrovnale snáz, než výsledná aplikace.
Několik dokumentů, které jsme vytvořili (tedy hlavně já), když jsme se (všichni) učili se zmíněnými nástroji, jsem posbíral a nabízím vám je v tomhle ZIP archivu.
Trocha statistiky
Protože jsme si všichni víceméně poctivě psali odpracované hodiny, můžu posloužit několika grafy, které aspoň orientačně ukazují průběh naší práce.
Práce během měsíců v absolutních číslech:
Podíly jednotlivých druhů činností během měsíců:
Podíly druhů činností celkem:
