úterý 28. října 2014

(Ne)marný boj s technologickým dluhem

Naše řešení je technologicky složité a bylo by složíte, i kdybychom nestříleli sami sebe do nohou. Pokud děláte distribuovaný systém, bude ten systém prostě složitý. Máme složitý systém, který je navíc okořeněný různorodostí jazyků a middlewaru, a proto je důležité bojovat s technologickým dluhem, aby na nás neustále nepadal nějaký kostlivec ze skříně. Nám se to v GoodData daří se střídavými úspěchy. V tomhle článku jsem zkusil sepsat pár postřehů a technik, které jsme vyzkoušeli.


Škatulata, škatulata hýbejte se


Dlouhou dobu jsme měli celé řešení rozdělené horizontálně, kdy si každý tým spravoval svojí vrstvu respektive službu. V tomhle rozpoložení se nám s technologickým dluhem nedařilo moc dobře bojovat a nejenom to. Vázl nám i vývoj regulérních produktových požadavků a to především pokud bylo potřeba týmovou spolupráci. Udělali jsme velký třesk a týmy jsme přestavěli na vertikální. Před reorganizací jsme měli tým erlangových vývojářů, java vývojářů, javascriptových vývojářů a perlových vývojářů. Teď máme týmy, kde je obrazně řečeno jeden erlangista, jeden javista, jeden perlista a jeden javascriptař.

Tohle rozložení, už z podstaty, moc nenahrává splácení technologického dluhu. Nebo lépe řečeno, nepozoruji žádný významný rozdíl. Troufám si tvrdit, že jsme si ověřili, že hýbání lidí zleva či zprava nemá na technologický dluh žádný vliv (přestože to nebyl hlavni cíl reorganizace).


Přiznejte si, že máte problém a ten kvantifikujte ho

Je to jako na sezení anonymních alkoholiků, tedy ne že bych tam někdy byl, musíte si nejprve přiznat, že máte nějaký problém. My jsme si udělali seznam s popisem jednotlivých oblastí a určili jsme si jejich priority. Seznam nám visí na vstupních dveřích kuchyňky, aby ho nikdo nemohl minout - viditelnost. Důležité je, že je to něco konkrétního, kvantifikovatelného, nejenom něco abstraktního.


Shoda, že s dluhem hodláte něco dělat

Důležitá je shoda s managementem, že je v zájmu všech s dluhem něco dělat. Management má někdy tendence tyhle problémy bagatelizovat, proto je důležité vysvětlovat, vysvětlovat a zase vysvětlovat a to i opakovaně. Technologický dluh nezmizí mávnutím kouzelného proutku. Alergie managementu na jakoukoliv zmínku o technologickém dluhu vyplývá ze snahy inženýrů vždy a za každých okolností se na něj vymlouvat. Právě proto se musíte shodnout, že s ním chcete bojovat.


Boj musí být priorita

Každý kvartál začínáme se seznamem priorit, na které se budeme zaměřovat. Pokud se nám tam nedostal konkrétní bod z výše uvedeného seznamu, nikdy se nic nestalo, dluh zůstal dluhem. Dávat si za prioritu cíl bojovat s technologickým dluhem nestačí. Vyberte si konkrétní bod ze seznamu, se kterým chcete bojovat a tomu dejte stejnou prioritu, jako produktovým požadavkům. Ve scrumu jsme zkoušeli rezervovat část kapacity týmu, ale i to nemělo zářné výsledky. Pocitově mi přišlo nejlepší, když byl celý sprint dedikovaný právě na konkrétní oblast technologického dluhu.


Vlastnictví

Technologický dluh se často obnaží v místech, které jsou vlastněné všemi a zároveň nikým. Je to podobné, jako s kurtizánou, se kterou obcuje půlka fotbalového mužstva, a když otěhotní, nikdo se k tomu nemá, protože to může být kohokoliv. A je úplně jedno jestli se jedná o část code base a nebo nějakou sdílenou službu. Jasné vlastnictví umožňuje lepší plánování a alokaci zdrojů. Pokud není možné určit jednoznačného vlastníka, musí se daná věc nějakým způsobem rozsekat. Pokud to není možné, většinou to indikuje nějaké nezdravé závislosti. Jejich rozmotání bývá často zdrojem všech problémů.


Trpělivost

Obrňte se trpělivostí, protože splácení technologického dluhu je běh na dlouhou trať. Boj s větrnými mlýny je to ve chvíli kdy máte nejasné vlastnictví, kolidující priority a zároveň musíte hasit požáry. V tom případě začněte od začátku výše uvedeného seznamu.

neděle 21. září 2014

QA v roli Důmyslného rytíře dona Quijote de la Mancha

Čas od času slýchám, jak si někdo v agilním vývoji stěžuje na nedostatečnou kvalitu a zároveň vzývá QA inženýry a jejich klíčovou roli. Mýtus spočívá v přesvědčení, že především QA zajišťuje v agilním vývoji kvalitu. Použiji sportovní paralelu. To, že máte v brance nejlepšího brankáře na světě, ještě nic neříká nic o tom, kolik gólu inkasujete. Defenziva je věcí celého týmu nikoliv jednotlivce. Brankář podobně jako QA inženýr je pomyslný dirigent s nejlepším přehledem o celém dění. S architekturou a dalšími aspekty vývoje je to velmi podobné. Ať již vezmeme jakýkoliv aspekt, je za něj vždy odpovědný tým jako celek. V týmu, kde se kvalita produkovaného softwaru odsouvá kamsi na pozadí, vám nepomůže ani QA s brokovnicí mířící na zátylek každého vývojáře. Jaká je tedy role QA v agilním vývoji?


Předně je stejně důležitá, jako jakákoliv jiná v daném týmu. Stejně jako nemůžete hrát bez brankáře (až na malé výjimky jako je hra bez brankáře v hokeji), nemůžete fungovat bez kvaliťáka. A to bez ohledu na to, jestli z vás padá kód s jednou nebo deseti chybami. Čím lepší kvalitu produkovaný kód vykazuje, tím rozdílnější roli bude QA člen týmu hrát. V jakémkoliv případě bude jeho role nezastupitelná, protože vždy může nabídnout minimálně jiný úhel pohledu na daný problém. Roli QA lze rozdělit podle toho, jak je tým zkušený, kdy zkušenost je přímo úměrná důrazu na kvalitu. Čím zkušenější tým, tím větší pozornost věnuje kvalitě.


Nezkušený tým

QA zde funguje jako bič na vývojáře. Je to autorita, která nejenom rozhoduje o tom, co splňuje či nesplňuje kritéria kvality, ale zároveň působí jako mentor pro vývojáře. Jejím úkolem je vysvětlovat vývojářům roli testů, pomáhat se zaváděním automatických testů (cukr) a držet štábní kulturu psaní testů. Samozřejmě pokud testy neprocházejí je jeho důležitou povinností vývojáře tepat. Nezkušené týmy mnohdy chtějí psát testy, jenom nevědí jak na to. Právě proto je důležité, aby fungoval nejenom v roli represivní, ale i v roli osvětové. Přerod nezkušeného týmu přichází ve chvíli, kdy tým začne chápat přínos testů jako integrální součásti vývoje a nijak jej nezpochybňuje např. výmluvami na nedostatek času.

Středně zkušený tým

Tým už chápe všechny výhody, oceňuje přínos testů a role QA je postrčit na další úroveň. To mohou být další řekněme specializované testy např. výkonu, výdrže nebo různých katastrofických scénářů. QA hraje opět roli osvěty a pomáhá se zaváděním. Větší roli začíná hrát automatizace celého testovacího procesu - testovací pipeline - a vůbec měření kvality a sledování trendů. Role QA je stále nezastupitelná například během odhadování míry rizika regrese a definice akceptačních testů. Obecně by se dalo říci, že jeho role se pomalu posouvá směrem od mentora k partnerovi.

Zkušený tým

Testovací pipeline je nastavená, tým koučuje, co se testů týká, sám sebe, a QA role se posunula. QA je partner, který poskytuje podporu při testování. Jeho role je klíčová v tom, že jednak nabízí pohled nezatížený vlastním vývojem a jednak pomáhá se složitějšími případy testování - to mohou být testy ve specifickém prostředí nebo testy speciálních okrajových případů. QA již nehraje roli represivní složky a vývojáři velmi dobře chápou, že jim QA usnadní život a nikoliv hází klacky pod nohy.

Hranice mezi zkušeností týmu, rolí a konkrétními aktivitami QA se může prolévat a mnohdy závisí i na jiných okolnostech jako je například firemní kultura a procesy. Rád bych ješte jednou zdůraznil, že QA samo osobě nikdy kvalitu nezajistí, pokud ji jako nedílnou součást nepřijme vývojářský tým. V jakémkoliv jiném případě hraje totiž QA roli Důmyslného rytíře dona Quijote de la Mancha.

neděle 14. září 2014

CZ Podcast 105 - Osmibity

Do dalšího dílu jsme pozvali Martin Malého alias A. Denta, nestora osmibitové scény, aby zavzpomínal na staré dobré osmibitové počítače. Tenhle díl stojí za poslechnutí ať již osmdesátá léta a hrátky s osmibitovými počítači pamatujete či nikoliv.

čtvrtek 4. září 2014

CZ Podcast 104 - Akka, Spray, Play

Hostem 104. dilu je Jan Macháček, autor několika knih například Pro Spring, který se nyní věnuje vývoji reaktivních aplikací nad TypeSafe stackem tj. Scala, Akka, Play.io, Spray.io.