Publikujeme

Nacházíte se zde: Úvodní stránka > Publikujeme > Blog > Agilní vývoj z pohledu firemních cílů

Agilní vývoj z pohledu firemních cílů

Agilní vývoj z pohledu firemních cílů 123

V následujících odstavcích nenaleznete popis nebo vysvětlení principů agilního vývoje. V tomto článku se chceme podívat na téma agilního vývoje trochu z jiného pohledu a to z pohledu firemních cílů a jejich propojení na cíle IT.

Sdílej na sociálních sítích:

V dnešní době je IT stále často chápáno jako náklad, jelikož není na první pohled vidět jeho přínos pro firmu. Problém je, že neměříme nic ve vztahu k firemním cílům, nýbrž k IT samotnému. Proto je důležité propojit cíle firemní s cíli IT. Jedna z možností jak toto propojení realizovat je na počátku definovat firemní cíle (např. zvýšení obratu o 5%) a tyto cíle dále rozdělit na cíle operativní, ke kterým lze přiřadit sadu agilních praktik z oblasti IT, které nám pomohou tyto operativní cíle naplnit.

Mezi základní operativní cíle patří:

  • Zvýšení produktivity: zde nás zajímá především rychlost implementačního cyklu nebo průměrný čas požadavku nebo chyby ve frontě. Toho můžeme dosáhnout zrychlením produkce funkčností či eliminací částí, které přináší malou nebo žádnou hodnotu firmě.
  • Zlepšení kvality: sledujeme počet opakujících se incidentů, trendy otevřených/uzavřených incidentů, dodržování SLA, procento pokrytí kódu testy a další. Toho dosáhneme redukcí chyb, zlepšením kvalitativních atributů nebo prevencí chyb samotných.
  • Velikost a komplexnost: sledujeme poměr navržených a implementovaných změn. Tohoto cíle lze dosáhnout kombinací rychlé zpětné vazby, široké spolupráce mnoha stran či znovupoužitelností.
  • Termíny a plány: sledujeme rychlost dodávky, od zadání po nasazení do produkčního prostředí. Jedna z možností je zrychlení doby počátku vývoje k jeho prvním přínosům (Time-to-Market).

Následující tabulka propojuje operativní cíle firmy s agilními praktikami v IT.

Operativní cíl

Relevatní praktika

Zvýšení produktivity

Iterativní přístup

 

Párová práce

 

Neustálá integrace

 

Retrospektiva

 

Vizualizace

 

Nástroje a jejich propojení

Zlepšení kvality

Iterativní přístup

 

Refactoring

 

Konvence pro zápis kódu

 

Testy řízený přístup

 

Neustálá integrace

 

Párová práce

 

Vizualizace

 

Retrospektiva

 

Riziky řízený přístup

 

Decentralizované verzování

Velikost a komplexnost

Iterativní přístup

 

Refactoring

 

Retrospektiva

Termíny a plány

Iterativní přístup

 

Učení se a reálné práci

 

Retrospektiva

 

Nástroje a jejich propojení

Výše uvedené praktiky reprezentují ideální stav, jejich nasazení ve firmě není vždy jednoduché a vyžaduje nejen pochopení vedení, ale i dávku odhodlání a odvahy k jejich prosazení. Proto vždy začněte jednou praktikou, vyhodnoťte její přínos a postupně zavádějte další.

Nyní v krátkosti představíme některé z výše uvedených praktik.

Iterativní přístup

Základem této praktiky je definování fixního intervalu (1 týden až 1 měsíc), ve kterém se snažíme dokončit určitou funkcionalitu, ale může se také jednat například o sepsání dokumentace. V každé iteraci se opakuje sled činností tj. itertivní plánování, denní schůzky, samotná realizace, demo, retrospektiva a zhodnocení.

Každá budoucí iterace není přesně plánována předem a její obsah je určen aktuálními potřebami.

Přínosem tohoto přístupu jsou tedy rychlejší dodávky, lepší reakce na změny a dřívější identifikace problémů.

Konvence pro zápis kódu

Pravidla pro psaní zdrojových kódů jsou velmi cenná především při údržbě systému a v případech kdy je kód sdílen mezi více vývojáři. Výhodou je také podpora IDE nástrojů, která nám usnadní dodržování těchto pravidel. Dále je důležité zmínit, že nejde pouze o zápis zdrojových kódů v programovacích jazycích, ale také:

  • Názvy balíčků.
  • Názvy souborů.
  • Pojmenování databází a tabulek.
  • A další.

Testy řízený přístup

Každý kód, který vytvoříme nebo změníme, je nutné otestovat. Jednak, abychom zlepšili svůj způsob programování, ale také abychom neopakovali pořád stejné chyby. Důležitým parametrem je rychlost zpětné vazby. A to je právě kámen úrazu při testování lidmi. Z důvodů rychlé zpětné vazby a také z důvodů zvýšení kvality práce existují vývojářské neboli unit testy.

Pokud půjdeme dál a zavedeme metodiku páce s testy zvanou Test Driven Developement (dále jen TDD), máme vyhráno. Tento způsob práce spočívá v tom, že před samotným kódem píšeme nejdříve testy, které tento kód ověřují, to nám pomáhá daleko lépe přemýšlet nad návrhem našeho kódu.

Problémem uvedeného přístupu je častý střet s realitou nákladů a termínů u některých projektů. Ano, tento přístup vyžaduje čas navíc a to může být v případě výběrových řízení, kde většinou rozhoduje cena, problém. A na argument o budoucí úspoře nákladů a času nikdo v danou chvíli neuslyší.

Ideálním stavem je 100% pokrytí kódu testy.

Refaktoring

Je jakýkoli zásah do zdrojového kódu, jenž zlepšuje jeho čitelnost nebo je strukturu bez změny chování. Místa pro zlepšení odhalíme pomocí těchto symptomů:

  • Dlouhé metody.
  • Mnoho odpovědností.
  • Duplicitní kód.
  • A další.

Refaktoring je z našeho pohledu často velmi náročná činnost a proto je dobré tuto praktiku zkombinovat s unit testy a automatizovanými nástroji např. v IDE.

Párové programování

Zajímavá technika převzatá z extrémního programování, kdy dva vývojáři sedí u jedné klávesnice, jeden píše například testy a druhý přemýšlí nad implementací dané třídy. Vývojáři se u klávesnice střídají. Tato technika přináší tyto výhody:

  • Větší kvalitu kódu, dvě hlavy více nápadů (psychologický efekt, snaha vytáhnout se).
  • Konstatní revize kódu, tzn. není potřeba dalších schůzek.
  • Zvýšená morálka, kolega je jednak motivací a zároveň se více pracuje a méně surfuje na internetu.
  • Mentoring, předávání znalostí přirozenou cestou.
  • Větší sounáležitost týmu, kolegové se lépe poznají.
  • Vývojáři jsou méně vyrušováni, rozptylováni ostatními.

Opět i v tomto případě uvedená praktika naráží na názor manažerů o neefektivitě tohoto přístupu. Řada empirických výzkumů však dokazuje opak (http://www.cs.pomona.edu/classes/cs121/supp/williams_prpgm.pdf). 

Neustálá integrace

Jde o sestavení komponent a jejich integrace do spustitelné verze služby nebo některé její části včetně spuštění testů a dalších volitelných úkolů. Jádrem celého řešení je integrační platforma, která automatizovaně po provedení nějaké změny provede definované činnosti. Těmito činnostmi může být natažení zdrojových kódů z repozitáře, spuštění automatických testů, sestavení aplikace, zálohování, úpravy datových struktur a další. Výhodou principu je včasné odhalení problémů, automatizace, která eliminuje lidský faktor při opakujících se činnostech, reporting a jeho vyhodnocování. Ačkoliv neustálá integrace a její možnosti závisí na nástroji, který použijeme, jde především o přístup k vývoji.

V rámci nástrojů, které jsou dnes k dispozici, toho můžeme dělat samozřejmě daleko více, například si můžeme vytvářet zálohy, publikovat rovnou na určeně servery, spouštět analýzy nad zdrojovými kódy a zjišťovat tak například duplicity, odchylky od konvencí. Na konci každé integrace by měla následovat zpráva například formou e-mailu. V případě, že testy neprojdou je možné celou integraci ukončit jako neúspěšný a upozornit na to vývojový tým. Nutíme tak vývojáře dodržovat firemní pravidla.

Tento přístup tedy navazuje a podporu již zmíněné přístupy jako automatizované testování, refaktoring.

Retrospektiva

Na konci vývojového cyklu provedeme zhodnocení naší práce pomocí tři základních otázek:

  • Co fungovalo?
  • Co nefungovalo?
  • Co bychom měli dělat jinak?

Cílem je tedy nastavit mechanismus kontroly a ponaučení, což je v prostředí neustálých změn důležitým aspektem. Výhodou pravidelné retrospektivy je rychlá zpětná vazba a rychlá reakce na potřeby či nedostatky. Snahou je tedy co nejrychlejší nasazení změn hned po jejich identifikaci.

Závěrem bychom rádi řekli, že krása IT oboru spočívá v tom, že je tak mladý a stále přináší mnoho nových technologií, postupů a názorů. Pokud budete chtít něco z výše uvedeného zavést u vás ve firmě tak neváhejte a jděte do toho, po čase si společně sedněte s vývojáři i managementem a zhodnoťte, zda daná praktika pomohla při naplňování podnikových cílů a její integrace do vašeho vývoje bude trvalá nebo ji dokonce budete dále prohlubovat.

Agilním praktikám zdar.

Autor: Ondřej Tyrychtr

Přejít na začátek stránky

Mapa stránek

© Copyright 1998-2014 AMI Praha a.s., powered by AMIGO CMS