Agile Prague Conference 2011 - ohlédnutí

Ve čtvrtek a v pátek se v Praze konal první ročník konference o agilním přístupu k vývoji - Agile Prague Conference, které jsem se zúčastnil.

Pokud bych měl krátce zhodnotit akci jako takovou, tak moc nevím, co bych ji vytknul - vše probíhalo podle plánu, catering fungoval jak měl, na žádné nedostatky technického rázu jsem nenarazil. Kvalita přednášek a přednášejících byla nadprůměrná - z mého osobního pohledu se mi více líbil pátek a až na jednu hodně slabou přednášku ve čtvrtek jsem byl celkově spokojený. Nejvíce mě zaujaly čtyři "case-study" přednášky českých firem, které se podělili se zkušenostmi se zavaděním agilních metodik u nich ve firmě. Také asi pro mnoho lidí bylo překvapením, že o jednotlivých metodikách se skoro vůbec nemluvilo, vše bylo spíše o důvodech pro agilní vývoj, o organizaci týmů, o zkušenostech ze zavádění agilních přístupů.

Dále nechci procházet jednotlivé přednášky a hodnotit je, chci zmínit zajímavé postřehy a myšlenky, které jsem si odnesl:

• agilní přístup k vývoji má velice úzký vztah ke správné organizaci/struktuře společnosti - pokud chce být firma "agilní", tak musí být agilní celá a ne jen vývojové oddělení a i organizace jako taková tomu musí být přizpůsobena - místo klasické hierarchie šéf - product manager - project manager - tým vytvářet Self Organizing Teams, tj. reorganizovat odpovědnosti na celý tým, podpořit kreativitu a přenést zodpovědnost na všechny členy týmu.
• všechny case-study přednášky se týkaly firem, které mají produkty, takže zákazníkem vývoje jsou interní product manažeři. Hodně by mě zajímal pohled na agilní firmu, které funguje zakázkově pro externí zákazníky (a ještě navíc pro státní sektor)
• došel jsem k názoru, že pro úspěšné zavedení agilních metodik je nezbytné využití externího konzultanta, který díky tomu, že je externí, má mnohem lepší přesvědčovací pozici než interní vedení. Nejčastějším přístupem lidí při zavádění agilních přístupů je, že říkají, že to nebude fungovat, že my máme něco speciálního, co jinde nemají a proto to zde nemůže fungovat. Toto dost často externí člověk může vyvrátit.
• dále mi přišlo velice důležité začínat pilotním týmem/projektem, protože ve všech firmách, které své zkušenosti prezentovali, byla skladba lidí před zaváděním přibližně tato - třetina se moc těší, třetině to je jedno a třetina lidí si myslí, že to nemůže fungovat. Pilotní projekt dokáže hodně lidí z poslední skupiny přesvědčit, že to fungovat může.
• stále více se mi líbí Kanban, jako metodika pro vývoj softwaru - jednoduché, názorné, zábavné a "hravé".
• pro mě osobně nový zajímavý pojem Lean software development
• bez osobního potkávání a intenzivní spolupráce to nejde. Pokud chci co nejvíce omezit psaní dokumentace a pokud chci co nejvíce zodpovědnosti přenést na celý tým, pak musím tento tým dát dohromady, na jedno místo. I když preferuji práci na dálku (zejména kvůli mému osobnímu pohodlí), tak sám vím, že je něco úplně jiného mít tým v jedné kanceláři, kde lítají myšlenky vzduchem, kde všichni táhnou za jeden provaz.
• zpětná vazba od zákazníka musí být co nejkratší - pokud chci něco řídit (viz Teorie řízení z kybernetiky), tak kvalita řízení je přímo úměrná kvalitě zpětné vazby. Na jedné přednášce byla prezentována přímá úměra mezi délkou sprchy a nastavením správné teploty vody. Jak trefné :)
• Dnes (snad již) nikdo nevěří tomu, že vodopádový model může efektivně fungovat. Mnoho firem postoupilo o krok dále a praktikují iterativní způsob vývoje a včetně zavedené postupné integrace. To je ale pořád jen víceméně technický posun, ale pokud se nezmění organizace práce, struktura firmy a předání odpovědnosti týmům, pak není možné se bavit o agilním způsobu vývoje.
• Líbila se mi přednáška, kde přednášející trefně říkal, že dlouhá léta se softwarové inženýrství snažilo okoukávat přístup k vývoji a řešení problémů od průmyslu, který tu už přes sto let byl a dobře fungoval. Až nyní v poslední době se ukázalo, že vývoj softwaru potřebuje zcela něco jiného.

A nakonec přidám ještě pár hesel, které mě zaujaly:

• Vždy bude více požadavků než jaké jsou možnosti realizace - nutná prioritizace požadavků, čím kratší a rychlejší zpětná vazba, tím lepší.
• Častěji bych se měl ptát, zda dělám správnou věc než zda dělám danou věc správně.
• Posunu resp. zlepšení není možné dosáhnout beze změn.
• "When in doubt, leave it out" - pokud si nejsme jisti při výběru a návrhu nějaké nové funkce, tak to raději nechme ať zákazník sám řekne, jak a co chce.
• Kvalitní zpětná vazba od zákazníka není možná bez kvalitní komunikace s ním.
• Čím jednoduší je architektura celého systému, tím rychlejší je přidávání nových vlastností do systému. I proto refaktoring je tolik důležitý.
• Realita se mění, to je realita. Pokud chci vytvářet reálnou aplikaci, pak musím být na každodenní změny připravený.
• Kód píšeme kvůli tomu, že ho ještě nikdo jiný před námi nenapsal. Pokud již někdo napsal, pak není důvod to psát znovu.

Zkušenosti ze zavádění testování

Bude to již skoro dva roky, kdy jsem začal zavádět testování ve firmě (viz článek Největší problémy při zavádění testování). Teď jsem se dostal do stavu, že si potřebuji vše zpětně zhodnotit a posunout to ve firmě zase o kousek dále.

Co se povedlo:

• základní principy a přínosy testování zná v týmu snad každý, každý až na nějaké výjimky již má zkušenosti s napsáním vlastních testů. V tomto ohledu se to rozjíždělo pomaleji než jsem na začátku čekal, trvalo chvíli než se dostavil efekt sněhové koule. Nejdříve jsem psal testy jen já, pak se začali postupně přidávat po jednom další a další až nyní je nás většina. Ovšem samozřejmostí je to pořád jen pro pár lidí. Také pomohlo několik případů, kdy nebylo jiné možnosti než napsaní aut. testů, protože ruční vytváření testovacích dat bylo strašně moc komplikované a zdlouhavé.
• technické řešení resp. podpora pro psaní testů byla již od samého počátku hotová, v průběhu těch dvou let jsem toho zase tolik nemusel přidávat. Naše řešení je postavené nad vlastním frameworkem pro vytváření testovacích dat (viz článek Vytváření testovacích dat), doplněné o některé zajímavé vychytávky pro snadnější psaní testů - Testování webových služeb nebo Plošné vypnutí povinného @Autowired.
• téma testování se začíná ve firmě prosazovat, nejen ve vývoji, ale zejména v konzultantské části firmy. V tomto ohledu také nastává posun z manažerského pohledu - ze začátku bylo testování, dle mého názoru, podporováno hlavně kvůli tomu, že o tom hodně lidí mluvilo, a že jsem byl schopen říci jak s testováním začít, jak to celé uchopit. Nyní je to spíše o snaze celé testování více zefektivnit, případně začít více měřit. Je tedy např. snaha o lepší spolupráci mezi konzultanty (zadavateli úkolů) a vývojáři tak, aby již zadání obsahovalo podpůrné informace pro co nejefektivnější psaní unit testů, které by ve výsledku měli ulevit právě konzultantům.
• testy jsou součástí automatického buildu

Co se nepovedlo:

• stále jsou zarytí jedinci, kteří testování "odolávají". Neustálá argumentace a úsilí mě celkem vyčerpává, ale je to vlastně má jediná zbraň, takže musím vydržet
• bylo ode mě na začátku celkem naivní si myslet, že když někdo "prasí" produkční kód, tak testy na tom budou lépe. Spíše naopak. Testy jsou prostě považovány za něco "méně kvalitního", co nepotřebuje komentáře, vše se může psát bez nějaké struktury pod sebe. Tento bod nesouvisí nejen s testy, ale je to spíše úkol pro celý tým - používat a dodržovat konvence pro psaní zdrojového kódu.
• unit testy fungují víceméně jako nástroj vývojáře, aby si svůj kód alespoň párkrát spustil a ověřil, že to plus mínus funguje. Z mého pohledu je potřeba zlepšit předávané informace od konzultantů, aby již v zadání úkolů byly uvedeny informace na co je vhodné se během testování zaměřit tak, aby to v konečném důsledku pomohlo nejen vývojářům, ale i konzultantům, kteří to vše musí převzít a sami ověřit, že je implementace správná.
• chybí nám měřitelná zpětná vazba, neumíme říci, že díky pokrytí určité části testy se zlepšila chybovost o tolik a tolik. Neumíme říci, zda vynaložený čas na psaní testů je v konečném důsledku opravdu přínosem nebo není. Já jako vývojář vím o hodně výhodách a bez testů si to už nedovedu představit, ale má podobný názor i vedení? Obávám se, že zatím ne.
• od začátku jsme chtěli, aby se testy co nejvíce efektivně, tj. psát testy jen k tomu, kde to má přidanou hodnotu. Vymysleli jsme to tak, že každý kdo bude chtít psát nějaké testy, tak přijde za mnou a zkusí mě přesvědčit, že daný test má smysl. Na první pohled dobrý nápad, ale ve výsledku špatné - potřebovali jsme motivovat vývojáře ke psaní testů a ne jim házet klacky pod nohy. Od tohoto jsme postupně opustili, bohužel zase mám někdy pocit, že některé testy mi nepřijdou moc efektivní. Ale asi je lepší mít více testů než méně.

Co dále v nejbližší době?

• v rámci code review se více zaměřím právě na testy
• chtěl bych zlepšit dokumentaci testů resp. JavaDoc testů. Jsem toho názoru, že každý by měl umět před implementací metody popsat, co daná metoda bude dělat. Pokud toho není schopen, pak vlastně přesně neví, co daná metoda má dělat. To samé platí o testech - každý si musí před každým testem říci, co chce testovat, jaké budou vstupy a jaké očekávané výstupy. Zde bych to chtěl nějak standardizovat, ale ještě nevím jak - nějaká jednotná JavaDoc šablona nebo nějak úplně jinak? Budu rád za nápady, jak se to řeší jinde.
• musím zrychlit běh testů na build serveru. Je pravda, že build server je přetížený, ale i tak je hodně, pokud nám celý build včetně všech testů běží skoro hodinu. Zpětná vazba musí být rychlejší. (pozn: máme cca 700 tabulek, k tomu odpovídající Hibernate entity, které se musí vždy všechny inicializovat. Dokončení modularizace aplikace s možností vypnutí/zapnutí modulů bude až tak příští rok). Zde by možná mohl pomoci systém agentů, který znám z TeamCity. Nebo vhodně definovat testovací profily a pouštět to na více strojích vždy pouze s daným profilem.

Proč nechci použít Hibernate na dalším projektu

Minulý týden se mě kolega zeptal, zda bych použil znovu Hibernate na dalším projektu? Já jsem mu po krátkém zamyšlení řekl, že již ne, že bych Hibernate (a obecně žádné jiné ORM řešení) nepoužil. Následovala diskuze, kde jsem se snažil obhájit mojí odpověď:

• ORM nástroje se snaží vývojáře odstínit od konkrétního úložiště dat, snaží se vývojáře držet pouze v objektovém světě bez ohledu na to, že nejčastěji ukládáme data do relačních databází. Je naivní si myslet, že napíši kvalitní aplikaci bez znalostí databází a SQL.
  
  
• ORM nástroje (pozn. konkrétně Hibernate, protože s ním několik let pracuji, ale myslím si, že to lze zobecnit pro všechny ORM nástroje) přidávají do projektů další velkou složitost, nároky na znalosti a zkušenosti. Toto má vliv na spoustu dalších věcí - výběr vhodných lidí do týmu, architektura systému, větší pravděpodobnost chyb, plnění termínů atd.
  
  
• znalost SQL mi přijde natolik rozšířená a základní, že v tomto nevidím další znalostí zátěž pro vývojáře
  
  
• používání ORM odstiňuje vývojáře od přímé práce s databází, což často vede k tomu, že vývojáři vůbec vlastně nevědí, jak jsou určité operace náročné, kolik se vlastně výsledně musí zavolat SQL dotazů, aby se jedna Hibernate operace vykonala
  
  
• Hibernate přináší do vývojového týmu prvek náhodnosti, špatné říditelnosti - pokud vím, že mám napsat 3 dotazy přes JDBC, tak je to tak jasná a ohraničená věc, že není co dalšího řešit. Místo toho implementovat DAO pomocí Hibernatu, to moc jasné být nemusí - nikdy člověk neví, na čem se může zaseknout nebo jak se bude Hibernate v určitých kritických stavech chovat.
  
  
• při porovnávání JDBC vs. ORM přístupů je potřeba také zmínit, že databáze často mnohonásobně přežijí aplikace, které je využívají. Technologie pro server a klienta se mění mnohem rychleji než relační databáze a jazyk SQL. Z tohoto pohledu je základem správný návrh databáze bez ohledu na to, jakou architekturu pak aplikace bude mít.
  
  
• kolikrát se na projektu měnila databáze? Možná lepší otázka - stalo se již někomu, že se během projektu měnila databáze? Když pominu vývoj aplikací pro více databází, tak naopak si myslím, že napojení na konkrétní databázi mi nabízí mnohem více než když jsem odstíněný přes ORM.
  
  
• ladění složitějších HQL nebo Criteria dotazů moc nejde a já osobně jsem vždy skončil u SQL. Někdy postupuji i naopak - pomocí SQL si vyzkouším, že daný dotaz je možné vytvořit, a že je správný a pak ho přepisuji pomocí Hibernatu.
  

Myslím, že nejsem sám, kdo má dnes podobný názor k této problematice jako já, viz např. článek Problems with ORMs jako jeden z nich.

Základní otázkou ale zůstává, co tedy jiného místo toho? Mě zde bohužel chybí osobní zkušenost, ale určitě bych se vydal cestou přes JDBC, tedy jako vhodné řešení mi přijde použití MyBatis nebo Spring JDBC nebo Spring Data nebo to celé nějak zkombinovat dohromady.

Znáte SPL (Software Product Line)?

SPL je zkratka pro Software Product Line. Jedná se o styl vývoje podobný tomu, jak se vyrábí mobily nebo auta. Není to tedy vhodné pro jednorázové projekty, ale spíše pro produkty - firma má představu, jaký produkt nabízet na trhu, navrhne možné varianty a ty se pak snaží nabízet zákazníkům.

Je to opravdu hodně podobné výrobě aut. Výrobci znají segment cílových zákazníků, ví, že to například směřujeme na střední vrstvu, která si ráda připlatí za navigaci, tempomat, xenony, automatickou převodovku atd. Je tedy nutné navrhnout takový výrobní proces resp. architekturu auta, aby toto všechno šlo zákazníkovi dodat, ale klidně s určitými omezeními, např. pokud tempomat, tak ano, ale pouze s aut. převodovkou. I u aut může chtít někdo něco opravdu speciálního, co v nabídce automobilky není - pak osloví třeba nějaký specializovaný servis, který mu upraví motor dle jeho přání. To už ale je něco opravdu specifického a zákazník musí počítat s tím, že si to také pořádně zaplatí.
Automobilka nevidělá tím, že prodá jedno, dvě auta, ale třeba až tisíc, kdy se ty náklady na vývoj a implementaci vrátí.

Zpět k SPL. My nenavrhujeme auto, ale produkt, o kterým si myslíme, že ho máme komu nabídnout a nabídku opakovat. Musíme vědět možné variace a závislosti mezi nimi, tak abychom nenabízeli jeden uzavřený produkt, ale aby si zákazník mohl vybrat - chcete Oracle nebo MS SQL? Chcete zabezpečení přes HTTP, NTLM nebo OpenID? Chcete systém nasadit na vlastní server nebo na náš server nebo do cloudu? Naopak není třeba nutné, aby zákazník měl mít možnost vybrat jaký DMS systém chce - u auta si také nemůžete vybrat z více podvozků.

Asi nejvíce se mi ze SPL líbí přístup k vytváření interních megalomanských frameworků - budu citovat "Rather than put general software components into a library in the hope that opportunities for reuse will arise, software product lines only call for software artifacts to be created when reuse is predicted in one or more products in a well defined product line."

Pokud si o tom chcete přečíst více, pak doporučuji následující zdroje:

• Introduction to the Emerging Practice of Software Product Line Development
  
• A Framework for Software Product Line Practice
  

Přenositelnost zkušeností

Konečně jsem si opět našel chvilku a píši na můj blog. Poslední měsíce jsem byl extrémně vytížený, protože se mi stalo, že se mi sešlo několik termínů dokončení projektů a já nevěděl co mám dělat dříve. Samozřejmě jsem to takto vůbec neplánoval, bylo to způsobené standardně tím, jak se všechny projekty protahovaly až se to vše potkalo v jeden termín.

Práci na volné noze mám natolik rád, že to považuji za jednu velkou výhodu, nicméně zde se ukazuje jedna malá nevýhoda - nedokážu říci svým stálým a dlouhodobým zákazníkům NE, protože se bojím o ztrátu zákazníka. A proto se mi to pak někdy takto vyboulí. Sám ale cítím, že je to takto špatně, protože pokud je někdy hodně práce a nevíte co dříve, pak zákonitě musí trpět kvalita, i když si to člověk nepřipouští.

Dnes ale chci psát o něčem jiném - v poslední době stále více dostávám prostor v různých firmách radit s optimálním nastavením vývojového procesu. Musím se přiznat, že mě někdy překvapuje, jak některé zavedené firmy, které jsou maximálně profesionální ke svým zákazníkům, se snaží odpovědět na základní otázky týkající se interního procesu vývoje.

Často jsem se v této souvislosti zamýšlel, jak nejlépe v této oblasti předávat moje zkušenosti nabité z působení v řade firem, vždy by se dalo říci s unikátními a vlastními postupy vývoje aplikací. Pokud někomu předáváte ryze technické informace a zkušenosti, tak to každý většinou vezme a ani nepřemýšlí o tom, že by to mohlo být jinak. U předávání ryze praktických zkušeností to takto nefunguje a mám prostě pocit, když to trochu přeženu, že pokud si na to každý nepřijde sám, tak tomu neuvěří. Jen je potřeba správně určit mantinely, aby člověk znovu neobjevoval kolo.

Celkem se mi zdá rozumné, když si firma na tyto konzultace a rady najímá někoho externího, protože jeho slovo má "větší" váhu, není zasažen interními vztahy, historií firmy a má celkový nadhled nad celým procesem.

Snad v každé firmě, ve které jsem byl, tak byl specifický proces vývoje, nějak specificky upravená metodika. Jsou určitě rozdílné nároky na vývoj jednorázových aplikací nebo produktů, ale proč to musí být všude jinak, když existuje opravdu jen několik rozumných metodik, které má cenu zvažovat a nasadit?

Je také zajímavé vidět, kdo v jaké firmě je ten "nejdůležitější" - jednou to jsou obchodníci, podruhé konzultanti a někdy dokonce vývojáři jsou ti, kteří mají největší hlas v tom, jak se co bude dělat. Myslím, že toto je většinou dáno tím, jak firma vznikala - pokud firma začínala s několika programátory, tak i nyní, když má přes sto lidí, má vývoj největší slovo.