Praktická zkušenost s programováním větších projektů v týmu je určitě důležitá. O to více, vyjde-li člověk školu a rovnou se do nějakého vznikajícího projektu zapojí. V tomto ohledu mají pravděpodobně výhodu studenti jiných škol, např. ČVUT, kde je (alespoň podle mých informací) tato praktická zkušenost zdůrazňována více a častěji než na MFF. Hlavní přínos tohoto předmětu spočívá ve zkušenosti samotné a tedy je důležité, aby v projektu nastaly problémy, které řešitelé musí překonat. V tomto bodě se přínosy nepříjemně mísí s negativními zkušenostmi - např. přespříliš optimistickou analýzou a plánováním projektu nebo “netýmovými” či “špatně programujícími” kolegy. Úspěšný projekt si tedy vyžádá mnohem větší časové vstupy řešitelů a to je asi vůbec nejhorší negativum tohoto předmětu. Přestože v praxi to velmi často probíhá podobně, účastníci jsou za svou práci placení a mají tedy motivaci i čas do projektu vkládat velké úsilí. Ve školním projektu jsou ovšem studenti výrazně omezeni prací na jiných předmětech, někdy nejspíš i motivací, a výsledkem je tedy neúplné dílo s horší kvalitou. Předmět má svoje velké klady i zápory a určitě nebude prospěšný pro každého. Podle mého názoru je pro obor SW systémů (alespoň pro zaměření SWI) povinný z velmi dobrého důvodu. Zrušení předmětu by učinilo studium jednodušším, na druhou stranu se velmi vyplatí si touto zkušeností projít nanečisto. Jakmile půjde v praxi do tuhého, může absolvování tohoto předmětu znamenat rozdíl mezi úspěchem a nezdarem, zmařenou investicí, případně i dluhy. Jinými slovy: “mějte předcházející poselství na paměti a nenechte se rozházet případnou obtížností/nespravedlností řešení projektu - v praxi na vás ohledy také nikdo brát nebude”. Abychom to shrnuli, co by si absolventi měli z tohoto předmětu odnést a nad čím by se měli budoucí řešitelé hluboce zamyslet: 1) Specifikace "Třikrát měř, jednou řež”. Specifikace by měla být co nejjednodušší a co nejméně svazovat - jak technologicky, tak i algoritmicky. Dále je velmi důležité před zadáním specifikace skutečně “vyzkoušet", že zvolené technologie řeší daný problém dobře a že na sebe dobře navazují, jak z hlediska programu tak i reálného nasazení na reálný stroj. 2) Hlubší pochopení vlastních limitů Zpočátku se často zdá, že SW dílo nebude vyžadovat příliš moc námahy. Realita ovšem bývá naprosto opačná, protože nastanou nečekané implementační a technické problémy. Nespoléhejte se na vlastní odhady - počítejte s dostatečně dlouhou rezervou (ideálně jednou tolik, co si podle plánu vyžádá samotné řešení projektu) a především v případě, kdy je zadáním vašeho projektu přepsat již existující SW někoho jiného. 3) Dobrý vedoucí - Najděte si vedoucího, který bude průběžně kontrolovat vaši práci a její kvalitu a pokládat vám smysluplné otázky ohledně vašeho řešení. Jestliže váš vedoucí nemá v úmyslu váš projekt tolik řešit, je dobrou praxí vybrat si mezi sebou člověka, který se toho chopí nebo se dohodnout, že si budete práci kontrolovat navzájem (také viz níže). - Nikdy neztrácejte čas a udržujte se při řešení projektu v “rytmu” - podřiďte tomu své ostatní aktivity. 4) Dobrá organizace týmu - Jeden (někdo spolehlivý a již s trochou zkušenosti) by měl zastávat pozici vedoucího, který bude mít méně programovací práce a více administrativní, plánovací, kontrolovací a motivační. Jeden člověk by měl mít v hlavě projekt jako celek a jeho detailní vizi a podobu. V případě nejednoznačnosti způsobů řešení dílčích problémů by měl rozhodovat. - Dohodněte se na jednotné úpravě zdrojového kódu a používejte nástroje statické analýzy. Výsledný kód bude mít mnohem větší kulturu, výsledný projekt bude kvalitnější a umožní vám to větší dynamiku, kdyby např. někdo z týmu vypadl. - V návaznosti na předchozí bod - kontrolujte si práci navzájem. Často se stane, že si navzájem zpozorujete chyby a problémové, nesrozumitelné nebo nedostatečně okomentované části kódu. - Vyplatí se mít v týmu znalce daných technologií a praktického užití, ale při dobré organizaci týmu to není příliš důležité. - Komunikujte spolu a řešte všechny větší problémy spolu, ať už se jedná o vybírání nejlepší alternativy dílčího problému nebo implementační záležitosti. Větší počet hlav je téměř vždy mnohem schopnější než jedna. 5) Výběr týmu a lidský faktor - Vyberte si lidi, kteří jsou ochotní projektu věnovat čas a úsilí a chtějí ho zdárně dovést do konce. - Nezabývejte se tolik spravedlivostí a nešiřte nespokojenost a rozkoly - “ten udělal to, ten zas to a ten toho udělal málo, tak mu toho dáme víc”. V praxi tomu vždy někdo z vás dá víc než někdo jiný, tomu se nevyhnete. Nejste nepřátelé ani konkurenti - jste v tom spolu a všichni máte zájem na úspěšném projektu. Spravedlivostí se zabývejte až v okamžiku, kdy někdo z vás na projekt vysloveně kašle nebo je jeho přínos skutečně malý. Budete-li dodržovat tyto základní dobré rady, měli byste být schopni v rámci předmětu obhájit i nadstandardně velké projekty.