pondělí 31. března 2014

Problematika hostování menších projektů na Kenticu

Hostování Kentica bylo opředeno tajemstvími. Alespoň pro mě dlouhou dobu bylo. Pokládal jsem si otázky: Kde hostovat a za kolik? Vyplatí se to? Existuje vůbec nějaký hosting s dobrým poměrem cena/výkon? To vše v kontextu menších webových projektů, které s oblibou dělávám pro menší podnikatele a přátele.

Cesta od hostingu k hostingu

Už v minulosti jsem si pořídil webhosting, kde běželo Kentico. Prvně u firmy Emwac Group. Byli velmi vstřícní a se vším mi pomohli a Kentico s mojí sajtou uvnitř dodnes běží úplně bez problémů. A za docela slušný peníz (tuším asi 1600Kč za celou instanci i se supportem). Kdyby hosting Kentica na svém webu ještě nabízeli, hned bych Vás poslal za nimi a tento článek by končil. Ale není tomu tak.

Druhá štace je Active24, u kterého jsem zkoušel hostovat jinou sajtu. Po slibech toho, že jsou Kentico partneři mi nebyli schopni nabídnout hosting s dobrým poměrem cena/výkon, tak jsme ihned ukončili spolupráci. Ani se se mnou moc nebavili. Nebrat.

Třetí štací je Bluesoft. Dělají websajty na Kenticu, ale primárně nenabízí webhosting. Mno, každopádně nabídli mi podobné podmínky jako Emwac Group, takže sajta spokojeně běží. Nevýhodou Emwacu i Bluesoftu však je to, že nenabízejí k hostingu administrační rozhraní, abych si mohl databázi a application pool spravovat sám. Takže s každým požadavkem je musím otravovat a je to takové na delší lokte. Tedy chtěl jsem něco s administračním rozhraním.

Čtvrtou štací je ASPone. Zase Kentico hosting partner. Nevím, jestli se k nim mám vůbec vyjadřovat. Pořídil jsem si u nich vyšší a už poměrně drahou variantu hostingu, která však výkonově nestačila k hostování Kentica. Support odpovídal rychle, ale celá konverzace se stočila od nápomocného řešení problému k docela hulvátské nabídce příplatkových služeb. Nebrat.

Pátou štací je Windows Azure. Ten je sám o sobě tajemný, tak jsem ho zkusil. Byl jsem velmi mile překvapen velmi pokročilým administračním rozhraním. Vytvoříte si free trial účet, v něm pak intanci websajty a jednu databázi. Pak si stáhnete WebMatrix, nahodíte v něm Kentico a přes rozhraní nahodíte na Azure instanci. Docela intuitivní. Mno, jinak Azure je škálovatelné prostředí, takže si můžete za běhu přidávat/ubírat zdroje. Nutno říci, že po nahození Kentica mi aplikace asi 2x spadla, ale pak se to nějak vzpamatovalo a docela slušně to běželo. Takže úsměv na tváři byl vykouzlen. Pak jsem si tedy šel nastudovat pricing a to už mě zase úsměv spadl. Je velmi komplikovaný díky škálovatelnosti. Nicméně základní informací je, že pokud chcete sajtu provozovat na své doméně, musíte si pořídit minimálně shared verzi hostingu a to vás bude stát asi $10 za sajtu měsíčně plus příplatky za další vyčerpané zdroje. Jelikož sajty, co chci hostovat, jsou spíš menšího charakteru, tak ani tato varianta není nikterak výhodná. Spíše nebrat.

Transparentnost

Touto cestou bych rád upozornil na netransparentnost nabídky Kentico hosting partnerů. Jsou sice takto zalistovaní, každopádně nenabízí služby, alespoň v nižších cenových relacích, uzpůsobené výkonnostním požadavkům Kentica. A mám pocit, že to ty webhostery vlastně ani netrápí a sami neví, jak Kentico pořádně hostovat. Určitě bych byl pro zlepšení situace. V první řadě by alespoň odpovídajícím variantám svých hostingů mohli dát nálepku "Kentico hosting". V řadě druhé by mohli vytvořit speciální nabídku výkonnostně ušitou Kenticu. Tzn. s větší operační pamětí. 

Náročnost na operační paměť

Abych uvedl na pravou míru, kde je zakopaný pes. Kentico pro svůj běh nepotřebuje mnoho místa - asi 300MB. Resp. oproti jiným CMSkům ano, ale webhostingy většinou nabízí dost místa, takže toto není úplně palčivý problém. Databáze je na tom podobně. S čím je problém, je operační paměť. Kentico dokumentace uvádí jako minimální operační paměť 500MB, což pro běh aplikace by snad aji stačilo. Jenže když instalujete databázi či vytváříte novou sajtu, tedy provádíte podle Kentico terminologie import/export operace, tak si aplikace pěkně vyžírá RAMku a aplikace se restartuje a máte po importu/exportu. Takže s minimální konfigurací si sajtu a ani snad samotné CMSko stejně na hostingu nerozjedete.

Tedy teoreticky byste mohli, ale vážně pouze teoreticky. Import/export je operace nad databází a ty lze provádět přes SQL Server Management Studio. Takže kdybyste si vyvinuli sajtu lokálně a pak přes SQL Studio nahráli na live hosting, tak máte vyhráno. Nižší hostingy, tedy chápejte NE třeba virtuální servery, vám nedovolí se přes SQL Studio k databázi připojit s create/modify právy. Takže máte po ptákách.

Co z toho?

Kentico je samo o sobě velká aplikace s množstvím funkcionality. A díky tomu potřebuje i větší výpočetní výkon. Webhosteři většinou nejsou schopní nabídnout konfigurace s větší operační pamětí za rozumný peníz - pod 300kč měsíčně. Takže s menším projektem si moc nezabrnkáte. Když chcete hostovat Kentico, tak asi jedině ve velkém stylu.

I když z příkladu Emwac Group a Bluesoftu je patrné, že i v malém to docela jde.

Máte-li nějaké zkušenosti s hostováním Kentica, podělte se, prosím.

pátek 28. března 2014

Smashing Conference Oxford 2014: Krásně strávené dny

Smashing magazine, který je jedním z nejinspirativnějších a co se týče kvality obsahu jedním z nejlepších zdrojů pro webové návrháře a vývojáře, pořádá i konference, na které zve přední světové speakery. První dvě se konaly v německém Freiburgu v letech 2012 a 2013. Letos, v roce 2014, se její konání přesunulo do britského Oxfordu a také do amerického New Yorku. Já jsem se zúčastnil té oxfordské, 2 dny trvající, události a prostřednictvím toho článku bych vám rád zprostředkoval své dojmy a krátké shrnutí všech přednášek.

Místo konání a organizace

Prostě Oxford, to už mluví samo za sebe. Malé britské městečko plné historických kostelů, škol a louko-parků. Řekl bych, že ideální místo pro konference. Samotná událost se konala v místní radnici v obrovkém kopulovitém sále. Účastníků bylo na 350 a všeci se spokojeně vlezli. Párty, které jsou vždy součástí konferencí, se konaly každý večer sousedící s každým dnem konference plus byla ještě jedna před tím. Takže dokopy 4. O párty píšu proto, že šlo především o takové malé barcampy, kde měli předem vybraní účastíci konference přednášky a v přestávkách se volně diskutovalo. Všichni se zapojovali, bylo to moc hezké.

Co jsem si odnesl

Odnesl jsem si především poznání, že v Kenticu nejsme looseři. Bylo tam dosti lidí z celé Evropy i dál, se kterými jsem se bavil a bylo fajn slyšet, že řeší problémy podobné našim nebo řešíme problémy složitěší. A také že máme třeba rozumnější fungování UX. Ono totiž dosti účastníků bylo freelance nebo pracovali pro agenturu, kde řeší menší projekty než my v Kenticu. A dost si jich taky fičí na Wordpressu, kde se tolik nemusí štvát se zadrátovaným kódem atp. Co se týče toho UX, tak mě pobavil hovor s designéry jedné londýnské firmy, kde UX dělají tak, že mají jednoho big bosse, který jim "z uživatelského" hlediska hodnotí jejich návrhy - zkrátka si práci neověřují uživatelskými testy. Další věc, co jsem měl možnost vidět bylo to, že se k vývoji a návrhu nepřistupuje stylem right first time, jak to děláme. Tedy, že se neimplementuje na první dobrou, ale člověk si udělá pořádný reseach, zkusí několik přístupů k danému problému a pak z nich vybere ten nejlepší.

Přednášky

Pozvaní speakeři byli opravdu třída a rád bych shrnul jejich přednášky... zkrátka co jsem si odnesl:

  • Seb Lee-Delisle, který se zabývá tvorbou laser show na začátku i na konci konference jednu takovou předvedl. Zároveň měl přednášku o JS canvasu a jen tak from scratch psal algoritmy, které dělají podobé věci, jak v laser show, kterou předvedl.

  • Addy Osmani mluvil o tvorbě webových komponent pomocí document.registerElement. Jde o novou ne přiliš prohlížeči podporovanou featuru, která dovoluje tvořit registrovat vlastní html tagy a tvořit pro je JS API. Tuto funkcionalitu lze zprovoznit napříč prohlížeči pomocí knihovny Polymer. http://www.polymer-project.org/
  • Lea Verou, jež je členkou W3C mluvila o budoucnosti CSS4. Konkrétně se zaměřila na barvy a prozradila, že nová specifikace bude obsahovat funkce pro intuitivnější zacházení s barvami. Bude existovat nová hodnota pro barvu a to currentColor a nově bude i čtyřmístný hexakód pro barvy, kde poslední znak bude indikovat průhlednost. http://leaverou.github.io/chroma-zone/
  • Joe Leech hovořil o web designu, který je intuitivní a vede ke konverzím. Především apeloval na to, že náš mentální model je založený na předchozích zkušenostech, proto radí, abychom se ve svých návrzích vyvarovali přílišným inovacím. Dále zdůraznil, že pokud uživatele přimějeme nemyslet u používání webu, tak náš design bude přinášet ovoce. No a nakonec je prý důležité vyvolávat v lidech emoce, aby se ztotožnili s tím, co jim web nabízí a soustředit se na základní lidské "potřeby" jako je jídlo nebo nebo ukazování lidských tváří.
  • Dave Rupert je známý v komunitě hlavně díky svému podcastu Shop Talk Show. Shrnul problematiku web designu od jeho prvopočátků, kde porovnal časy starého způsobu, kdy se kódily weby pixel perfect podle grafického návrhu a časy responsivního designu, kdy se způsob návrhu zresponsivnil a weby jsou doménou i mobilních zařízení s pomalým připojením. http://shoptalkshow.com/
  • Guy Podjarny srovnával míru a způsob komprese obrázkových formátů. Mluvil o novém formátu WebP.
  • Fabio Carneiro je vývojářem emailových template v Mailchimpu. Měl zajímavé poznatky o jejich návrhu a vývoji. Při návrhu je třeba myslet na to, že mailové klienty podporují různě staré webové standardy občas obskurním způsobem. Apeluje aby jsme navrhovali maily pro lidi - kvůli mobilům musí být jednoduchý stručný a použitelným jedním prstem. Typy mailů rozkategorizoval: Buy me, Join me, Read me, Transakční (info o platbách). Zdůraznil, že email nejsou webové stránky a proto by tak měly i vypadat. Pokud je mail responsivní, mělo by i jeho CTA vést na responsivní sajtu. Říkal, že sám má pro testování asi 7 tabletů, stejný počet smartphonů a také 3 počítače.
  • Paul Boag nedávno napsal knihu Digital Adaption, která není pro lidi co dělají weby, ale pro jejich klienty. Přednáška na toto téma navazovala. Hovořil, že webové stránky jsou už něco víc než jen jedna z platforem pro prezentaci firmy. Že do budoucna firmy budou postupně přecházet do online světa a webdesigneři už nebudou jen ti, co dělají a updatují web, ale jejich posláním bude připravoval ostatní spolupracovníky na fungování firmy v digitálním prostoru. Paul má též svůj podcast BoagWorld. http://www.smashingmagazine.com/2014/03/27/the-digital-adaptation-book/ http://boagworld.com/
  • Josh Clark hovořil o tom, že dnešní weby jsou hezky navržené, aby běžely na různých zařízeních. Co však postrádají je kooperace mezi zařízeními. Z výzkumů je prý patrné, že lidi často střídají svá zařízení aby dokončili započatou práci. Avšak weby nejsou na takového sitace příliš připraveny - aby uživatel začal na svém mobilu tam, kde skončil u počítače. Ukazoval různá cool řešení a pak se dotkl technologického řešení např pomocí WebRTC nebo pomocí knihovny sonicnet.js
  • Jon Hicks hovořil o druzích ikon, které můžeme používat na webu a popisoval jejich výhody/nevýhody. Konkrétně CSS sprity, Font ikony, SVG ikony.
  • Scott Kellum hovořil o webových článcích, jež nejsou podle nějaké jednotné template, ale jsou speciálně navržené. Jejich typografie, grafika, obsah mají dát uživateli pocit, že čtou něco speciálního. Hovoří, že má celý kreativní tým pro tento účel a ukazoval nástroje, které si vyvinuli pro automatizaci některých věcí. Např. vytvořili si vizuální elementy, které mohou vkládat do stránky a customizovat si je.
  • Zoe Mickley Gillenwatter detailně popisovala chování a syntaxi flexboxu.
  • Wilson Page hovořil o webových komponentách a tvorbě API. Důležité poznámky, co měl, jsou, že aplikace by měla být rozdělena do metod a ty volat pouze pomocí eventů. Metody by neměly být závislé na aplikaci, ale naopak.
  • Mark Dugonjic velmi do detailu rozebíral webovou typografii. Otevřel celý vesmír. Tvoří typografii pro Smashing magazine. Při své práci bere v potaz vzdálenost čitatele od obrazovky, světelné podmínky, šířku displejů atp. A pro každý takový stav popisoval, jak k tomu přistoupit z pohledu typografie. A to nejen teoreticky, ale ukazoval i kód.
  • Tyler Mincley přednášel na trochu vzdálené téma a to je návrh hw pro Apple. Neb několik let dělal designéra zařízení v Applu v Číně.
  • Andrew Clarke měl naprosto ultimátní přednášku o životě web designera a jeho přístupu k práci. Byl to celý vesmír. http://www.smashingmagazine.com/2014/03/25/a-modern-designers-canvas/

Detailní popisy přednášek jsou k nalezení zde: http://decadecity.net/blog

pátek 21. února 2014

MLOC.JS 2014: Nabyté zkušenosti

V Budapešti, hlavním městě maďarském, se 13.-14.2.2014 konala konference MLOC.JS, která se věnovala jazyku JavaScript. Propagační web konference lákal na to, že se návštěvníci dovědí rady, jak udělat JavaScript chytřejším, rychlejším a sexy. Mno tedy, když mě můj velmi dobrý kamarád upozornil, že se taková konference koná kousek od naší matičky vlasti, neváhal jsem s pořízením vstupenky. Kdo by nechtěl psát sexy JavaScript. Faktem je, že právě na tato marketingová slova jsem se nechal nachytat a nevzal na těžkou váhu věty, které obsahovaly slovní spojení jako "kompilace C++ kódu do JavaScriptu".

Jak vypadala realita?

Konference se konala v sídle docela velkého startupu Prezi, jehož snahou je dát lidem nástroj, který umožní dělat zábavnější prezentace, než třeba Powerpoint. Nutno říci, že prostory mají vskutku pěkné. Taková kombinace historična a industrialu. Oproti jiným konferencím jsem byl překvapen, že mě při registraci nikdo nezasypal tunou reklamních letáků. Faktem je, že jsem dostal jen rukavice s featurou možnosti pracovat s touch screenem. Praktické, avšak mají hnusnou barvu.
Zpět k obsahu konference a k JavaScriptu. Nebudu zde rozepisovat každou přednášku, ale spíše shrnu trend, ve kterém se přednášky unášely. Je nutno říci, že sexy to úplně nebylo. Tedy ne pro člověka, jež neřeší akademické, ale spíše praktické problémy.

Šup z odjinud do JavaSriptu

Metarovina, jež se prolínala všemi přednáškami, naznačovala snahu vývojářů převádět své aplikace, napsané ať už v čemkoliv, do JavaScriptu. Mnoho přednášek bylo věnováno přepisu a kompilaci různých jazyků do JavaSriptu. Občas to bylo dosti obskurní. Řešila se Java, C++ či Haskell.

Prohlížeče chtějí též stíhat

Dvě přednášky vedli zástupci z řad vývojových týmů Google Chrome a Mozilla. Popisovali algoritmy optimalizace kódu při interpretaci JavaScriptu prohlížečem. Těmto pánům a jejich týmům přeji mnoho zdaru, neb jejich snahou je co nejvíce zrychlit běh aplikací a interpretaci kódu, neb se všeci snaží rozběhat své aplikace na JavaScriptu v prohlížeči. Webové prohlížeče musí být vážně okno do světa. Jedna z přednášek byla věnována vývoji 3D her v JavaScriptu, kdy přednášející plakal nejen nad tím, že JavaScript není moc vhodný jazyk pro takové projekty, ale i nad tím, že prohlížeče nejsou dostatečně rychlé a nepodporují potřebné technologie.

Optimalizace rekurze

Několik přednášek bylo věnováno psaní vlastních kompilátorů JavaScriptu pro jeho rychlejší běh, kdy přednášejí, většinou akademik, procházel své algoritmy a ukazoval, co dělají a proč jsou skvělé. Nevím, zda to byla náhoda či cíl organizátorů konference, ale asi tři z těchto přednášek řešily optimalizaci běhu rekurzivních algoritmů.

Přišel a změnil svět

Dalším typem přednášek bylo to, že přednášející vývojář rozjímal o svém životním příběhu, jak přišel do enterprise firmy plné oldschool programátorů a měnil jejich mindset. Že je přesvědčil, jak skvělý je JavaScript a jak lehce převedli jejich starou a pomalou aplikaci a skvělou node.js aplikaci. Šlo o zajímavé příběhy a pokaždé je to dojímavé, avšak po všech těch barcampech a podobných akcích, kde slýcháváme podobné příběhy, nijak informačně hodnotné.

Drb o Prezi

Nevím, zda jde o pravdivou informaci, ale po oušku jsem zaslechl důvody výběru témat a přednášejících. Prezi jako spoluorganizátor konference vyvíjí strašně cool aplikaci. Nicméně jim to celé běží na Flashi a zjevně z toho nejsou úplně nadšení. Rozhodli se tedy sezvat odborníky z celého světa a nechat si od nich poradit, jak to celé zmigrovat do JavaScriptu. No, a aby využili nashromážděných chytrých hlav v Budapešti, uspořádali konferenci.

Abych to nějak uzavřel. Pro mě jako pro člověka, jež řeší praktické problémy při vývoji webových stránek, tato konference nebyla úplně nejpřínosnější. Nicméně jsem měl možnost dostat se do zajímavé subkultury programátorů, jež řeší jazyk, se kterým pracuji. Nicméně nepoužívají ho k vývoji aplikací, ale jejich snahou je optimalizovat jeho běh. To je první zkušenost. Další cennou zkušeností je, že se mám pořádně pídit po obsahu konference, než na ni jedu. I když to mnohdy bývá těžké, když se vás tam snaží jen a jen nalákat sladkými slovy… Jo, a abych nezapomněl. Měli tam dobrý jídlo.

sobota 8. února 2014

Výkonnostní problémy Front-Endu, se kterými se často setkávám

"Chceme tvořit věci, jež jsou přátelské vůči budoucnosti", píše se v manifestu hnutí Future Friendly. Tento manifest pokazuje na momentální a pravděpodobný budoucí stav média Web, jehož obsah lze prohlížet na velkém množství rozmanitých zařízení. Samozřejmě není v lidských silách testovat webové projekty na všech typech zařízení. Nicméně existují techniky a pracovní postupy, které pomáhají webovým vývojářům tvořit projekty přátelštější vůči budoucnosti.

V několika posledních dnech jsem měl možnost nakouknout pod pokličku několika desítkám projektů a posoudit kvalitu jejich zpracování z pohledu front-end vývoje a Future Friendly filozofie. Byl jsem až překvapen, jak moc stejné, z velké míry výkonnostní, neduhy se vyskytovaly napříč všemi projekty. V následujících řádcích bych tedy rád upozornil ty nejzávažnější z nich.

Carousely všude, kam se podíváš

Velmi dobře chápu, že je třeba návštěvníka webové stránky upoutat nabídkou skvělých produktů nebo ukázat silné stránky organizace. Sahat však prvoplánovitě po carouselu je z designerského hlediska krátkozraké. Jaké jsou důvody, proč doporučuji zamyslet se nad jiným návrhovým vzorem, než je carousel?

  • Na základě časového intervalu rotace carouselu si uživatel nestihne dočíst či dostatečně prohlédnout obsah slajdu. Může ho to naštvat či zmást.
  • Přepínání mezi slajdy vyžaduje interakci a uživatel často neví, co uvidí na dalším slajdu.
  • Carousely jsou JavaScriptové knihovny. Některé z nich vyžadují jQuery nebo jinou podpůrnou knihovnu. Zvětšuje to velikost načítaných dat a počet requestů na stránku.
  • Samotný grafický návrh webu většinou zasazuje do carouselů mohutné fotografie, což též zvětšuje velikost načítaných dat a počet requestů na stránku.
  • Carousely často nebývají připraveny pro zobrazení na mobilních zařízeních. Tedy nepodporují resposivitu a dotyková gesta. A pokud jsou připraveny, vývojáři neintegrují tuto funcionalitu do konečné podoby webové stránky.

Nechci nabádat ke kategorickému vyhýbání se carouselům. Používejte je pokud jste si jisti, že jde o tu nejsprávnější volbu návrhového vzoru. Avšak když 2/3 revidovaných webů měly na homepage carousel, je jasné, že je něco špatně.

Tuny dat a requestů, i když není třeba

Jsem nadšen, že implementace responsivního web designu začíná být standartem a vídám ho u čím dál většího počtu projektů. Nicméně podoba, v jaké ho vídám není dostačující. Vývojáři se soustředí pouze na responsivní layout webu. Co však opomíjí, jsou data.

Adaptaci na malé displeje vývojáři často řeší triviálním nastavením "display: none" elementům, jež nechtějí vidět na malém displeji. Ovšem načítaná data na pozadí nikterak neřeší. V konečném důsledku bývám svědkem více než stovky requestů na stránku, kdy se stahují data v jednotkách megabajtů. Bez rozdílu, zda jde o desktopové zobrazení či mobilní, kde bývá kvůli malému displeji polovina obsahu a grafických pozlátek.

Řešením je podmíněné načítání obsahu. Tedy na základě různých podmínek, kterými může být šířka displeje či podpora určité technologie zobrazovacího zařízení, požadujeme data ze serveru.

V reálné situaci to může vypadat tak, že pokud na malém displeji nechcete vidět např. carousel, tak na základě šířky displeje budete či nebudete žádat obrázky a JavaScriptové knihovny ze serveru. Tyto podmínky lze pro specifické situace vyřešit jednoduchou JS podmínkou či můžete použít komplexnější řešení, jakým je Modernizr s integrovaným YepNopem. Blíže se této problematice věnuje Jeremy Keith ve svém článku.

Neminifikovaný a nekonkatenovaný kód

Třetím častým neduhem je používání přehnaného množství JavaScriptových a CSS knihoven, které jsou jednotlivě nalinkovány do hlavičky webové stránky. Takto znovu narůstá velikost stahovanýh dat a počet requestů na stránku. Jestliže chceme používat různé knihovny, či si píšeme vlastní, je vhodné tyto knihovny pro produkční prostředí minifikovat a následně zkokatenovat. Sníží se jak velikost dat, tak i počet requestů, tedy čas potřebný k načtení webové stránky.

Samozřejmě je ke zvážení, co vše konkatenovat. Mohou být různé důvody, proč určitý kód nechat v samostatném souboru. Jak jsem uvedl výše, některý kód můžete načítat podmíněně nebo načítat z CDN. Je tedy vždy vhodné zhodnotit, který kód se načítá vždy z vašeho hostingu a stojí za to ho zkonkatenovat, a který načítáte podmíněně či z CDN. Pro nejen tyto úkoly rád doporučím nástroj Grunt.

Tento článek byl zaměřen na časté problémy, jež vídám u webových projektů. Z velké míry jde o výkonnostní neduhy, které zpomalují rychlost načítání stránky. Jestliže snížíme čas potřebný pro načtení webové stránky, uděláme naše uživatele šťastnějšími, což se v konečném důsledku pozitivně odrazí na našem úspěchu, případně úspěchu našich klientů.

pátek 31. ledna 2014

Front-end vs. Back-end ve Scrum týmu

My v Kentico fičíme na agilní metodologii Scrum. Všechny vývojové týmy. Já patřím též do jednoho z vývojovýho týmů, avšak ne ledajakého. Narozdíl ode všech ostatních týmů, které tvoří naše bezva produkty Kentico CMS a Kentico EMS, my fungujeme jako taková malá webová angetura. Vytváříme software, webové stránky a aplikace pro interní účely, aby se firma prezentovala prostřednictvím média internet jak se sluší a patří a interní procesy držely po kopě.

Zavádění Scrumu

V době, kdy jsme zaváděli Scrum, jsme všichni byli v silném psychickém napětí, neb všichni museli měnit své mindsety a zažívat si nová, občas na první pohled podivná, pravidla. Jednou z hlavních překážek bránící efektivní týmové spolupráci bylo dělení user stories mezi členy týmu. Scrum totiž ve svém základu počítá s tím, že na jakékoliv user story je schopen pracovat jakýkoliv člen týmu. U nás to však nebylo dost dobře možné. Neb je náš tým sdílený zdroj pro celou firmu a je po něm žádáno pracovat na velmi rozličných úkolech. Od práce s datovými sklady, back-end programování v C#, přes front-end programování v JavaScriptu, tvorbu webových šablon až po prototypování, tvorbu grafiky a uživatelské testování. Takový rozptyl si vyžaduje specialisty a po odborníkovi na tvorbu webových šablon přeci nemůžu najednou chtít, aby psal rozsáhlé dotazy do databáze.

T-Shaped lidé nestačí

Náš vývojový tým se skládá ze tří back-end vývojářů, dvou front-end vývojářů/designerů a testera. Už před nasazením Scrumu náš tým pracoval ve stejném složení na stejném rozptylu typu úkolů s tím, že si je dle domluvy dělil, případně na nich spolupracoval. Se Scrumem však najednou přišel tlak na to, aby každý z týmu byl schopný pracovat na jakémkoliv typu úkolu, což bylo vskutku vyčerpávající. A i když už z předchozích bezscrumových dob jsme se cítili jako nabušení T-Shaped lidé, jednotlivci nebyli schopni pokrýt celý rozsah úkolů směřovaných na tým. Věděli jsme, že děláme někde chybu.

Řešení

Abychom situaci vyřešili, celý tým jsme se sešli, zamysleli se nad situací a podnikli akční kroky:

  1. Sepsali jsme si typy User stories, které jako tým dostáváme (navrhnout webovou stránku, synchronizovat data napříč databázemi, zajistit asynchronní načítání dat na webové stránce, ...).
  2. Sepsali jsme členy týmu a jejich schopnosti (Milan - návrh wireframe, HTML, CSS, JS, ...).
  3. Přiřadili členy týmu podle schopností k daným user stories.
  4. Analyzovali a seskupili jsme členy týmu, jež mají podobné schopnosti a jsou schopni dělat na stejných user stories.

V konečném důsledku nám krásně vyšlo logické rozdělení Back-end vs. Front-end, kdy Back-end členové týmu jsou schopni se starat o serverovou část projektů a Front-end o klientskou.

  1. Vytvořili jsme labely "back-end" a "front-end", které při Backlog groomingu přiřazujeme jednotlivým user stories.
  2. User stories, jež vyžadují spolupráci se vytvoří sub-tasky, které dostanou tyto labely.
  3. Při Planning meetingu si dáváme do sprintu User stories přibližně v poměru velocity Front-end a Back-end členů týmů.

Tým v konečném důsledku pracuje tak, že specialisté pracují na User stories, jež odpovídají jejich odbornosti a celková komunikace mezi členy týmu se zefektivnila. Je nutno přiznat, že jsme Scrum trošku poprznili, nicméně práce jde jako po drátkách a celkově se uvolnilo napětí.

středa 29. ledna 2014

Proč selhávám při psaní blogu

Každodenní průlet svým Twitter účtem, jež používám spíše jako RSS čtečku, mi dává zamyslet se nad podmínkami pro pravidelné publikování příspěvků autory jednotlivci. Zajímá mě jaká je jejich motivace, jakým způsobem si vyhrazují čas pro psaní a další aspekty, jež jsou základními podmínkami pro pravidelné publikování. Sám jsem několikrát jako pravidelný přispěvovatel na úrovni osobně profesionálního Twitter účtu a blogu selhal. Tedy začal jsem se pídit po domněnkách, proč selhávám.

Stabilní emoční pohoda

Ač má flegmatičnost je vskutku veliká, byla období, kdy se v mém okolí střídaly velmi silné emoční nálady, čímž velmi trpí soustředěnost na oblast zájmu, které se chcete věnovat a o nichž chcete publikovat. Ať je to nenávist či zamilovanost, velkou měrou ovlivňuje člověka jako osobnost a odvádí ho od racionálních cílů. Proto se šíleně nezamilovávejte ani v sobě neprohlubujte nenávist.

Nadšení

Jde o to, aby měl člověk o čem psát. Přirozeně. Ale musí být též do svého oboru nadšený. Pak je i slušná pravděpodobnost, že nadšení zvětší hloubku znalostí. A ta hloubka se nakonec třeba i rozvine jako smysl pro inovaci. Člověk opravdu musí mít nadšení pro svoji oblast zájmu a musí chtít publikovat. No a když se chce, tak se prostě musí.

Motivace

Pro mě hůře uchopitelná metarovina osobnosti. Množství druhů motivace je nezměrné a každého z nás motivuje úplně něco jiného. Může to být vnitřní motivace jako třeba výzva, samaritánství či egoismus nebo vnější jako peníze nebo uznání druhých. Každopádně určitý druh motivace, tedy toho, co žene člověka dopředu a podmiňuje jeho činnost, tam prostě musí být.

Prostředky

Život je pes, ale bez peněz a času si nezaštěkáte. Když už máte na zaplacení účtů a na pivo, je třeba si vydobýt čas pro zamýšlení se, inovace a psaní. Lidé na volné noze si vyhrazují čas snáze, neb propagují sami sebe, což je slušný motivátor. Nicméně když pracujete osmičky v korporaci, je výzva přesvědčit vedení, že vyhrazení placeného času pro sebevzdělání a aktivity, jakou je třeba i publikování, může být dlouhodobou hodnotou, ze které může firma jen těžit. Výzva drsná, nikoliv však nezvládnutelná.