Nástroje pro prototypování GUI

Pokud dneska navrhuji novou aplikaci, tak si to bez prototypování uživatelských obrazovek vůbec nedokážu představit. O to více se divím, že byli dříve časy, kdy jsem byl schopný si vystačit pouze s textem. Což samozřejmě nikdy moc dobře nefungovalo.
Je nutné minimalizovat nejasnosti a nedorozumění mezi vývojovým týmem a zákazníkem, předcházet neočekávanému. Je potřeba mít "něco" nad čím se můžu se zákazníkem bavit ještě dříve než vývojový tým začne programovat, "něco" co mi umožní získat co nejdříve zpětnou vazbu na to, jak to celé má vypadat a fungovat.

Z tohoto pohledu se mi jeví jako ideální drátěné modely (wireframes). Používáme k velké spokojenosti Balsamiq Mockup. Je to nástroj postavený nad flashem, nabízí jak webovou, tak desktopovou verzi, dokonce i pěkný plugin do Confluence a JIRY. Mezi všemi verzemi funguje bezproblémový export/import.

Při výběru jsme prošli a vyzkoušeli hodně nástrojů, na některé z nich přikládám odkaz a krátký komentář.

Balsamiq Mockup

• Nástroj pro rychlý návrh mockup a drátových modelů.
• Desktop aplikace, web aplikace, plugin do dalších systémů (Google Drive, Confluence, JIRA, XWIKI, …)
• Desktop aplikace - 79$ na jednoho uživatele, Web aplikace – od 12$/měsíčně 
  Pluginy – ceny se liší v závislosti na použitém systému a způsobu licencování
• Desktop aplikace – Windows, OS X, Linux, ostatní platformy s podporou Adobe AIR.
  Web aplikace a pluginy – Internetový prohlížeč + Flash 

UXPin

• Komplexní nástroj pro designéry.
• Web aplikace - Internetový prohlížeč
• Předplatné od 7$/měsíčně

Inpreso Screens

• Nástroj pro vytváření kvalitních mockup modelů.
• Desktop aplikace – pro chod aplikace je nutný Adobe AIR
  Web aplikace - Internetový prohlížeč + Flash
• Omezená verze zdarma, předplatné 29$/rok na jednoho uživatele

Lumzy

• Nástroj pro vytváření prototypů. Lze jít nad rámec vytváření drátových modelů a prototypů přidáváním událostí.
• Web aplikace - Internetový prohlížeč
• Zdarma

 GUI Design Studio

• Nástroj pro vytváření návrhů pro prostředí Windows. Lze ho použít k rychlému vytvoření prototypů kreslením obrazovek s využitím standardních Windows prvků a jejich propojením, aby bylo možné následně simulovat chování.
• Desktop aplikace – Windows
• Od 129$ za jednu licenci

Justinmind

• Silný nástroj pro vytváření drátových modelů aplikací.
• Desktop aplikace – Windows, OS X
• Desktop aplikace - Omezená verze zdarma
  Pro verze 495$ za licenci

Pidoco

• Webový nástroj pro rychlé vytváření drátových modelů a prototypů GUI pro web, mobilních a podnikových aplikací. Umožňuje pohodlné testování použitelnosti a inteligentní spolupráci.
• Web aplikace - Internetový prohlížeč
• Předplatné od 9$/měsíčně

Další nástroje a odkazy bez komentářů:

• Pencil Project
• iPlotz
• HotGloo
• fluidIA
• MockFlow
• Google drawings
• OhBoard
• App Sketcher
• Mockup Builder
• DesignerVista
• Mockup tiger
• článek "20 Free Wireframe and Mockup Applications"

Odhadování projektů

Přečetl jsem nedávno knížku Odhadování softwarových projektů a protože mi knížka přišla povedená, tak bych rád publikoval pár faktů/myšlenek, které mě zaujaly:

• Dobrý odhad je odhad, který poskytuje dostatečně jasný pohled na realitu projektu, aby vedení projektu mohlo dělat dobrá rozhodnutí, jak projekt vést, aby bylo dosaženo cíle. (pozn. text označený kurzívou je citací z uvedené knihy)

• správný/špatný odhad pracnosti projektu má často zásadní vliv na celkový výsledek projektu. Je proto pro mě překvapivé, jak málo se ve firmách věnuje správnému odhadování. Přitom podle odhadu se stanovují termíny, alokují zdroje, vytváří se rozvrh, ...

• odhady budou vždy tak přesné, jak budou přesné informace, podle kterých se odhaduje. Odhad nemůže být přesnější, než je na dané pozici projektu podél kužele možné (viz obrázek). Odhady je nutné postupně zpřesňovat.
  

•  je velké množství způsobů, algoritmů a postupů, jak odhadovat, ale jeden ze všech mi přijde nejvěrohodnější a přitom jednoduchý - odhady nového projektu na základě historických dat. Každá firma, které má za sebou realizaci nějakých projektů, může s velkou pravděpodobností očekávat, že další projekty budou podobné, že se pracnost významně nezmění. Přitom by stačilo tyto historická data ve firmě shromažďovat a za každou realizací se na chvíli otočit a říci si, co se povedlo a co ne a hlavně se z toho poučit.

• Záměrně nepodhodnocujte. Cena za podhodnocení je vyšší než za nadhodnocení. Problémy s nadhodnocením řešte plánováním a řízením, ne posuny odhadu. 

• vývojáři mají často příliš optimistické odhady

• Technickým pracovníkům patří odhady, netechnickým pracovníkům (obchod, marketing) pak cíle. Techničtí pracovníci mají udělat co nejlepší odhady a být schopni je zdůvodnit, netechničtí pracovníci pak musejí být schopni rozhodnout. Obě skupiny lidí by měli být schopni se na výsledných závazcích společně domluvit.

• často se odhady mění pod tíhou jednání s vedením, což je špatně - odhady nelze měnit, pouze lze měnit závazky, ke kterým se zavazujeme (verze aplikace bude bez určitých funkcí, termín vydání verze se posune atd.).

• vyhněte se uspěchaným odhadům, později toho budete litovat

• pokud je potřeba provést kvalifikovaný odhad, pak je nutné použít více metod odhadování. Pro různé fáze projektu (viz kužel) se hodí různé metody odhadování. Výsledky různých metod by se neměly lišit o více než 5%. Jinak hledejte důvody, proč tomu tak je.

• Rozložte velké odhady na malé části, abyste využili zákona velkých čísel: chyby na dolní stráně se do určité míry vyruší s chybami na straně horní. Tím lze do jisté míry eliminovat různé předsudky a subjektivní myšlení lidí, kteří odhady provádějí.

• Neřešte nejistotu v odhadu posunem. Vypořádejte se s ní tak, že odhad vyjádříte s jistou neurčitostí. 

• Je chybou vyjadřovat odhad právě jedním číslem, protože je to hodně zavádějící. Buď zvolit interval odhadu (odhad 50-70MD vyjadřuje jiný vztah k riziku než 60MD) a nebo prezentovat jeden odhad, ale spolu s pravděpodobností jeho dosažení (projekt zrealizujeme za 50MD s 50% pravděpodobností). Závazek ale již musí být jasný a konkrétní.

• Různé studie ukázaly, že většinou není problém v samotném odhadu, ale v tom, že se na spoustu věcí zapomene a ty pak v odhadu nejsou zohledněny. Proto je dobré mít nějaký standardizovaný postup, nějakou šablonu všech opakujících se funkčních/nefunkčních požadavků a z té vycházet.  

• Soustřeďte se nejprve na odhad velikosti. Pak z něj vypočtěte práci, rozvrh, cenu a vlastnosti.

• Nezkracujte odhad rozvrhu projektu bez navýšení odhadu práce.

Pár zkušeností z code review

Již je to nějaký pátek co jsem ve firmě zavedl code review a za tu dobu mám zapsaných pár poznámek, které bych rád publikoval:

• úplně na začátku jsem měl snahu o čisté code review, ale s postupem času se více začalo jednat o pravidelnou programátorskou schůzku, kde je sem tam i "veřejné" code review. Důvody jsou asi dva - kvalitní code review vyžaduje přípravu a řekl bych, že délka přípravy celkem odpovídá výslednému efektu code review. Bohužel jsem vždy neměl pocit, že code review mělo ten výsledný efekt, který jsem očekával, takže postupně jsem i já sám do toho přestal dávat tolik času a energie. Dalším důvodem je pak nástroj Crucible, který jsme začali používat.

• současná podoba programátorské schůzky je asi tato: každý týden půl hodiny, kde probíráme změny v API, jaké koncepční změny se udály nebo teprve přijdou a samozřejmě probíráme i kód, který v pozitivním/negativním smyslu má cenu ukázat veřejně a nějak ho zhodnotit.

• všechny důležité a odsouhlasené věci je nutné vždy někde evidovat, protože hned druhý den si to nikdo nepamatuje. Navíc sem tam někdo chybí na schůzce, takže je potřeba toto publikovat pro všechny.

• schůzka má vždy jednoho moderátora

• procházení, komentování a veřejné ukazování zdrojových kódů je hodně o "sociálním cítění", o komunikaci, protože spoustu programátorů bere "svůj" kód za čistě svojí věc, navíc dost lidí není připraveno na veřejnou kritiku své práce. Vždy se tedy snažím před code review odmazat jakékoliv jména osob, aby hned na první pohled nebylo zjevné, komu daný kód patří. A musím prostě volit velice opatrný přístup, když něco/někoho chci kritizovat. Cílem těchto schůzek není někomu ukázat, že je špatný, ale ukázat možné chyby, problémy, které může dělat úplně každý. Tento bod hodně souvisí se složením týmu - dělal jsem v týmu, kde člověk mohl říci jakoukoliv kritiku, všichni to brali úplně v pohodě a všichni věděli, že jde hlavně o tým. Jiné týmy mají více individualistů, introvertů apod. a tyto věci tak dobře nefungují. To tak prostě je a zde je vidět, že vývoj není jen o technických znalostech, ale vůbec o schopnosti komunikace.

• programátorské schůzky mám často spojené se zaváděním nových věcí - nové konvence psaní kódu, nové API k použití apod. Pokud chci aplikovat nějaké nové pravidlo, tak musí být jasné a definované (ideálně bez výjimek) v jedné, dvou větách. Obrázky vše mnohem lépe vysvětlují. Jakmile je cokoliv složitějšího, úspěch je předem nemožný.

• pokud objevím nějakou chybu v mém kódu, která stojí za ukázání ostatním, tak ji vždy ukazuji - pokud se já snažím ostatním říkat, že něco mají špatně nebo mohli by mít lépe, pak musí všichni cítit, že každý dělá chyby (i já), a že je to naprosto normální. Jen je potřeba se toho vyvarovat do budoucna.

• pokud chci něco změnit v aplikaci resp. zavést nějaké nové pravidlo, tak se mi často vyplatilo, že jsem to sám v celé aplikaci upravil. Programátoři často bez přemýšlení kopírují kód a díky tomu  se špatný kód šíří mnohem rychleji než ten dobrý. 

Jaké jsou vaše zkušenosti s code review nebo obecně s programátorskými schůzkami?

Crucible - nástroj na code review

Crucible je další z nástrojů od Atlassianu (kromě již známých nástrojů JIRA a Confluence).  Crucible je nástroj na code review. Umožňuje prohlížení zdrojových kódů a vytváření jeho review včetně workflow kolem. Crucible slouží jako komunikační kanál mezi vývojáři nad zdrojovým kódem - vše na jednom místě, vše sledovatelné a dohledatelné.

Přínos efektivního code review je zřejmý, ale často je problém, jak vlastně code review dělat, aby bylo opravdu efektivní. Efektivní code review musí z mého pohledu splňovat tyto podmínky:

• šíření informací všem členům týmu
• vše zpětně dohledatelné
• minimální časová náročnost resp. čím méně času, tím lépe
• nesmí nabourávat vztahy v týmu (není vždy jednoduché být kritický a nikoho se tím osobně nedotknout)

Když jsme s code review začínali,  tak to vypadalo přibližně tak, že jsme se každý týden na půl hodiny až hodinu potkali osobně, kde jsme procházeli části kódu, upozorňovali na časté nedostatky nebo informovali se o změnách v našich interních API. Toto nejčastěji prováděl team leader. Tento přístup má řadu nevýhod:

• každý nemůže vždy přijít na osobní setkání, takže se k němu dané informace nedostanou (je pravda, že důležité věci, případně nějaká rozhodnutí jsme zapisovali do interní wiki, ale i tak spoustu informací ze samotného code review nikde zaznamenána nebyla)
• chybí jedno místo, kde lze informace z code review hledat. Něco se řekne na schůzce, něco se pošle mailem a pak je problém se k některým tématům vracet, dohledávat je
• samotná kontrola zdrojového kódu probíhá ručně, často náhodným výběrem několika tříd. Chybí nástroj, který vás v tomto podpoří, přidá do toho trochu nějaký systém.
• vždy bylo nutné mít zdrojový kód v repository, aby si ho někdo další mohl prohlížet

Kvůli těmto nedostatkům jsme začali hledat vhodný nástroj a Crucible nám je pomohlo odstranit.  Crucible nabízí integraci s dalšími svými sourozenci, zejména s JIROU - není tedy problém vytvořit nové review přímo z JIRY k souborům napojených k danému tásků. I na podporu v IDE se nezapomnělo - mohu přímo v IDE vybrat soubory a vytvořit k nim nové review v Crucible (podpora je zatím jen pro IDEU, pro Eclipse zatím chybí). 

Máme teď tedy v týmu nástroj, který umožňuje komukoliv a kdykoliv založit požadavek na review vybrané části kódu a tím získat zpětnou vazbu. Když si člověk uvědomí, že žádné API není hned v první verzi dokonalé, že je potřeba získávat zpětnou vazbu na svoje návrhy a svoji práci, tak máme nástroj, který nám s tím dokáže pomoci.

Standardně součástí Crucible je i FishEye, což je taková hodně komfortní prohlížečka zdrojových kódů v repositářích. Za FishEye je ale nutné platit nemalé peníze navíc, tak zatím používáme samotné Crucible - chybí několik zajímavých pohledů do repositářů, ale z pohledu samotných review se nic nezměnilo.

Zkušenosti s Bootstrap

Znáte Bootstrap, řešení pro prezentační vrstvu od Twitteru? My jsme ho měli možnost vyzkoušet na menším projektu pro administrační část a rád bych se podělil o naše zkušenosti:

• Bootstrap jsem objevil někdy minulý rok na podzim a od té doby ho sleduji a je vidět, že se rozvijí, že žije. Množí se také informace na internetu, začíná se to používat. Např. článek To Bootstrap or Not?
• nám se hodně libí jednotnost a jednoduchost celého řešení, nemusíme řešit jednotlivé prohlížeče, celkem rychlý vývoj. Úvodní konfigurátor je pak jen taková třešnička na dortu.
• od začátku jsme měli jasno, že chceme Bootstrap použít jen na admin část a pro tento účel jsme byli spokojeni. Nicméně si nemyslím, že by to bylo vhodné řešení pro jakékoliv webové řešení, zejména pro ty složitější (např. naše snaha o výběr technologie na klienta).
• náš technologický stack byl následující: Spring MVC, Freemarker, Sitemesh, Bootstrap, jQuery
• jako nedostatek bereme nepřítomnost komponenty pro výběr datumu. Museli jsme tedy vzít tu z jQuery - nebyl to žádný velký problém, ale už jsme museli trochu řešit jednotnost vzhledu a upravovat to
• další výtka míří k dokumentaci - na první pohled je moc pěkná, vše hezky vizuálně zdokumentované, ale pokud pak člověk jde do detailu, tak ty informace sem tam prostě chybí. V lepším případě je člověk dohledá na internetu a nebo nejsou. Vzhledem k tomu, že se jedná o firemní framework publikovaný ven, tak oni ve firmě to know-how zřejmě mají, jen se všechno nepodařilo zdokumentovat pro ostatní. Diskuzní fórum jsme nenašli.
• kolegům se nepodařilo vůbec rozchodit dvě věci - Transitions (jQuery plugins) a hover popover.

 Máte vy nějaké zkušenosti z Bootstrap?