Úvod pro neznalé

Softwarový projekt je jednou z peripetií, kterou si musí projít studenti softwarových systémů na Matematicko-fyzikální fakultě. Na rozdíl od individuální diplomové práce je cílem tohoto předmětu naučit studenty pracovat v týmu na společném díle. Tento článek je tedy věnován budoucím řešitelům projektu a případným zájemcům o studium na MFF (aby věděli, co je čeká) a v menší míře všem, kteří se chystají do programátorské práce v menším týmu.

Je třeba říci, že tato studijní povinnost vždy patřila k těm velice obávaným, protože vyžaduje opravdu hodně práce a různé prodlužování, protahování, neshody v týmech, nestíhání deadlineů a probdělé noci strávené debugováním byly vždy standardní součástí.

Po dokončení je projekt obhajován před komisí složenou z matfyzáckých celebrit a řešitelé jsou po obhajobě požádáni o sepsání postřehů a zkušeností z projektu. A to je právě to, co začínáte číst :o). Všechny zkušenosti jsou shromažďovány na stránkách projektové komise a budoucím řešitelům se doporučuje si je pročíst, aby věděli, co je čeká.

Pokud prolistujete pár zkušeností, uvidíte, že mnoho z nich je hodně negativních (řešitelé je využívají jako platformu, na které si konečně můžou postěžovat) – viz třeba David Majda nebo Johanka Doležalová. Obvykle se opakují tyto výtky:

• projekty jsou příliš náročné, zpočátku se neodhadne množství práce, mnoho lidí si kvůli projektu prodlužovalo studium
• chybí finanční ohodnocení (představte si, že rok pracujete zadarmo na projektu – takový poloviční úvazek to dá – a k tomu ještě máte chodit do školy a třeba ještě do další „opravdové“ práce). Některé projekty vznikají ve spolupráci s komerčními firmami, ale běžné to není
• jsou problémy s prací v týmu – někdo z týmu se fláká, ale je už pozdě ho vyhodit (protože to by se to už vůbec nestihlo) nebo se fláká míň, ale ne zas tak moc, že by to bylo hned na vyhazov, jiné donucovací prostředky ale studenti k dispozici nemají. Dalším často zmiňovaným problémem bývá nezkušenost vedoucích s vedením týmů – „manažerským hlediskem“.

Nedávno byly softwarové projekty trochu „zlidštěny“ – mají trvat devět měsíců (dříve rok) a je za ně míň kreditů a tím pádem by měly být jednodušší.

Nyní tedy přikročím k vlastním zkušenostem s projektem XCase. Základní informace o projektu najdete zde a tady je o něco detailnější popis. Tedy jen v rychlosti – XCase je něco jako UML editor a návrhář XML schémat.

Práce v týmu    

Problémy s týmovou prací – pro softwarové projekty typické (soudím podle výše zmíněných zkušeností a rozhovorů s jinými řešiteli) – se nám docela vyhnuly. Na schůzky chodili všichni a probíhaly většinou v dobré náladě (trocha stresu se přidala asi tři týdny před odevzdáním, ale nebylo to nic strašného). Nepamatuju se na žádné rozbroje, nebylo ani nutné nějak silou rozdělovat práci, vždy se někdo ujal toho, co bylo potřeba zrovna udělat, a vývoj celkem plynule postupoval. Týmová práce byla prostě bezproblémová. 

Všichni řešitelé doporučují pravidelné schůzky nejlépe každý týden – i já se přidám (my jsme se toho drželi, kromě letních prázdnin, kdy jsme neschůzovali). Párkrát se sice stalo, že nebylo moc o čem se bavit (asi dvakrát), ale v závěru se zase začínaly schůzky hodně protahovat :o).

Úloha vedoucího

Naším vedoucím byl Martin Nečaský a celý projekt byl vlastně realizací jeho disertační práce, byl tedy do projektu sám zainteresován a myslím, že se nám věnoval v nadstandardní míře – účastnil se téměř všech schůzek (i když byly brzy ráno:o)), dobře nám popsal, co se po nás vlastně chce, pomáhal nám i s rozmyšlením základní architektury návrhu. Když už program pomalu začínal něco dělat, osvědčil se i jako tester:o).

Je sice pravda, že před zahájením projektu nám nasliboval, že i programovat s námi bude, od čehož pak ustoupil, ale i bez toho nám hodně pomáhal.

Použité nástroje

Vyvíjeli jsme v C#, .NETu 3.5 a WPF. Aplikace je desktopová, nemultithreadová, nedistribuovaná, z pohledu vývoje a ladění tedy ideální. Občas byly problémy s WPF designérem ve Visual Studiu, něco se zlepšilo se Service Packem Visual Studia a .NET frameworku, přesto ale tahle část Visual Studia není ještě úplně odladěná. Ale mě přišlo, že se s tím pracovat dá, i když kolega Jakub Klímek měl právě s designérem mnohem větší problémy (v pozdějších fázích mu skoro ani nešel otevřít).

Větší problém byl s repository – nakonec jsme skončili na veřejném CodePlexu, který bohužel není nejrychlejší. Tam jsme se ale přemístili až po dlouhých peripetiích s Team Foundation Serverem nainstalovaným na malostranském serveru edgar.ms.mff.cuni.cz. Připojit se na tento server z kolejní sítě bylo totiž téměř nemožné (mě se to nepovedlo ani jednou, Katce Opočenské prý párkrát ano, ale pak už vůbec). Snažili jsme se to řešit jak se správou kolejní sítě, tak s administrátory malostranské sítě a Team Foundation Serveru, ale jedni nás vždy odkázali na ty druhé s tím, že jejich problém to není (správci KolejNETu také prohlašovali, že problém je na našich stanicích – přitom připojit se z domova a z práce s tím samým notebookem nebyl problém).

Po přechodu na CodePlex jsme tedy měli repository + issue tracker (nahlašovadlo chyb), pro emailovou komunikaci jsme používali Google Groups. 

Testování

Vytvářet testy během vývoje by bylo bývalo určitě dobré – jenže my jsme to po většinu doby nedělali. Ne, že bychom byli přímo líní, ale nepodařilo se nám nalézt žádný testovací framework pro desktopovou aplikaci používající WPF – a přitom bychom potřebovali hlavně „testovat GUI“. Nakonec jsme měli tedy jen jakýsi minimalistický framework pro testování modulu provádějící překlad XML schémat. Ale toho, že nám chybí testy pro GUI, jsem litoval mnohokrát. WPF je docela mladá technologie, věřím, že se nějaký framework na testování brzy objeví a další řešitelé ho budou moci použít.

Nějaká doporučení

• často schůzujte, i když se vám podaří rozdělit práci mezi členy týmu tak, aby si moc nelezli do zelí (u nás to šlo), ostatní členové vás mnohdy upozorní na něco, co vás samotné nenapadlo, a přitom se vás to týká
• bez repository, issue trackeru, mailové konference to dobře nepůjde. Někdo doporučuje i wiki, ale my jsme se bez ní obešli docela dobře.
• týden na dokumentaci je málo. To jsme věděli, ale přesto jsme tak taky dopadli – ale naštěstí jsme ten týden dokumentaci mohli věnovat (už bylo naprogramováno a odladěno, až na pár drobností) a uživatelská dokumentace už byla hotová, ten poslední týden byl jen na programátorskou. I tak to ale bylo dost nakvap.
• snažte se mít testy, nám chyběly
• snažte se mít i živé testery, my měli jen pana vedoucího;-) (a v závěru ještě Láďu, ale to už bylo skoro po boji…)
• agilní přístup může fungovat docela dobře, některé projekty nepotřebují nutně několik měsíců analýz (samozřejmě ne všechny) 
• office (nebo openoffice) není nic, za co by se měl programátor stydět – tištěnou dokumentaci jsme psali ve Wordu, a kdybychom se měli patlat s LaTeXem, tak ji asi píšeme dodnes. Exportovat do PDF se to dá, tak co. Pokud je v týmu alespoň jeden, který LaTeX neumí, vůbec bych o něm neuvažoval (u nás naštěstí tenhle návrh nepadl).

Závěrem

I po výše zmíněném „zlehčení“ softwarový projekt není žádná dávačka a člověk se docela nadře. I tak ale byla skutečnost o dost příznivější, než jsem se obával po přečtení a vyzvědění zkušeností ostatních řešitelů. 

Třeba takové OSy (pro nematfyzáky: předmět Operační systémy, součástí absolvování je napsat ve třech lidech operační systém) byly pro mě po všech stránkách horší – zoufalství a stres z deadlineů a z nefungujícího kódu, problémy s používanými nástroji, nefungující tým, obsazení veškerého času… to mě stálo víc šedivých vlasů, než projekt. Děkuju zbytku týmu, dobře to dopadlo!

Sekce webu:

• Programování
  • C#, ASP.NET
  • PHP
  • Webdesign
  • Software
• Deskové hry
• Všelicos
  • Ekologie
  • Kultura
  • Úřady a papírování
  • Rozčiluje mě
• Matfyz
  • Ročníkový projekt
  • Bakalářská práce
  • Softwarový projekt
• Blog
  •