Vývojářské nástroje potřebují týmovou spolupráci

Trendu vzájemné kooperace se přizpůsobily i nástroje pro podporu vývoje aplikací. A mají nemalé ambice – zrychlit dodávky softwaru, zlepšit kvalitu, pružněji reagovat na změny. Čím toho chtějí dosáhnout?

Na začátku byl kód…
Hlavním nástrojem vývojáře je odedávna IDE (Integrated Development Environment) – prostředí, které mu umožňuje psát kód a generovat z něj spustitelnou aplikaci. Později vznikly specializované nástroje i pro ostatní úlohy jako UML modelování, testování apod.

Někdy koncem 90. let tak bylo snem většiny vývojářů mít na své stanici nejlepší IDE pro Javu, nejlepší IDE pro C++, nejlepší nástroj pro modelování atd. –, než zjistili, že donutit všechny tyto nástroje mezi sebou alespoň trochu spolupracovat je disciplínou samo o sobě.

Logickým krokem proto bylo přestat šít vývojářské nástroje na míru úlohám, ale raději lidem, kteří na nich pracují. Vznikly tedy platformy jako Eclipse, které umějí nabídnout více funkcí na jednom místě – vývojář si tak mohl více či méně pohodlně vygenerovat z připraveného UML modelu základní strukturu kódu, hotový kód pak uložit do verzovacího systému a výslednou aplikaci si ještě otestovat. Přitom mu stačilo znát ovládání jednoho nástroje.

Od ALM k CALM
Specializace jednotlivých profesí (a tedy i nástrojů) v softwarovém vývoji vedla k tomu, že bylo nutné je nějak propojit, umožnit výměnu informací mezi jednotlivými členy týmu a hlavně začít celý proces vývoje pořádně řídit.

Tak vznikly platformy ALM (Application Lifecycle Management), které obvykle představují jedno centrální úložiště, workflow engine a sadu nástrojů pro konkrétní projektové role. Jejich pojetí se mezi výrobci značně liší – někdy je jejich středobodem řízení kvality, jindy správa požadavků nebo konfigurační management.

Účel je nicméně vždy stejný – zajistit kontrolu nad celým procesem vývoje softwaru, ideálně od sběru požadavků na nový systém až po jeho (případné) vyřazení z provozu.

Dnešní svět zbožňuje komunikaci a sdílení informací, čím rychlejší, tím lepší. A ve vývoji softwaru tomu není jinak, proto je posledním trendem snaha trochu rozbít dosavadní rigidní procesy, podpořit vzájemnou komunikací spolupráci jednotlivých členů týmu, a celou tuto tak náročnou disciplínu tím více „polidštit“.

Před zkratku ALM tak přibylo písmeno C (od anglického collaborative). Od něj odvozené české přídavné jméno je kvůli naší historii poněkud zprofanované, takže se raději trochu kostrbatě opisuje jako „spolupráce v rámci týmu“. O co v podání softwarových nástrojů jde?

Informace po ruce
Potřeba sdílet během tvorby softwarového produktu informace vyplývá prakticky ze všech vývojářských metodik. Třeba ty agilní jsou na snadné a co možná nejpřímější komunikaci mezi členy týmu přímo založeny.

Klasické nástroje, instalované samostatně na jednotlivých stanicích, ale tuto potřebu příliš nezohledňují a nutí vývojáře vyměňovat si informace jinými cestami. Tím ovšem přicházíme o dohledatelnost komunikace a provázanost informací.

Proto u všech ALM řešení lze najít jednotící prvek v podobě centrálního serveru, který sdružuje a propojuje všechny myslitelné „produkty práce“ (označované jako work items – v podstatě jakékoliv úkoly a výstupy vznikající v rámci projektu) jednotlivých členů týmu.

Analytik například vytvoří zadání (a rovnou i příslušný testovací případ) a propojí jej s dalšími, již existujícími artefakty, jako jsou související požadavky, návrhy obrazovek, modely atd.

Příslušný vývojář si pak zadání otevře, naprogramuje požadovanou funkčnost a kód uloží do verzovacího systému. ALM nástroj automaticky propojí původní požadavek s příslušným kusem kódu a verzí, ve které byl dodán.

Z kódu vznikne spustitelná aplikace, která je dodána do testů. Tam je ověřena vůči zadání podle připraveného testovacího případu, v případě pochybností si tester přímo z něj otevře původní zadání. Pokud je nalezena chyba, k vývojáři se vrací rovnou i s informací, ve které verzi a kterému kusu kódu se váže, kdo jej vytvořil, co všechno daná chyba ovlivňuje atd.

Červená nit softwarového vývoje
Statisticky více než polovina chyb ve výsledném softwarovém produktu spočívá v chybě v zadání, resp. v nedorozumění mezi zadavatelem a realizací. Je proto logické stanovit „požadavek“, tj. zadání, jako hlavní pilíř komunikace napříč celým vývojovým cyklem.

Požadavky pak mohou sloužit jako červená nit, která propojuje celý životní cyklus informačního systému (analýza, vývoj, testy, provoz) a všem zainteresovaným rolím zajišťuje stálou kontrolu, že se jejich práce ubírá správným směrem.

A co s tím mají společného ALM platformy? Ty totiž pomáhají řešit řadu typických problémů v oblasti správy požadavků (requirements management) jako třeba:

• Řízení návrhu a implementace přímo z validovaných požadavků (odbourání duplicitního zadání vznikajícího v IT).
• Celkový obraz projektu je sdílen mezi všemi zainteresovanými osobami od byznys zadání až po výsledné zpracování požadavku (celý tým ví, na čem má pracovat).
• Včasná validace požadavků a eliminace přepracovávání výstupů.
• Provázanost a dohledatelnost požadavků a souvisejících výstupů.
• Auditovatelnost a dohledatelnost změn.
• Propojení requirements managementu a release managementu, baselining (co bude kdy dodáno).

K tomu se výborně hodí právě vazby, které vznikají mezi artefakty v rámci ALM řešení – například při jakékoliv změně požadavku je hned zřejmé, kde všude bude mít změna dopad a zda je ještě vůbec reálná.