Mnoho organizací, které vyvíjí nebo spravují software, koketuje s myšlenkou agility jako způsobu vývoje. Co ale vlastně agilita ve vývoji znamená a jak na ní?
Zavedení nové metodiky
Prvním z nich je tedy metodika samotná. Zavedení nové metodiky by mělo být samo o sobě projektem, který by měl mít své požadavky, svůj harmonogram i svá kritéria úspěchu. Metodiku hodně ovlivňuje typ a velikost projektu, kam agilní přístup nasazujete. Jinak je třeba nasadit SCRUM v agilním projektu vlastního vývoje, jinak ve velkém projektu s několika subdodavateli apod.
Obecně vzato čím větší daný projekt je, tím více se nová metodika uspůsobuje prostředí, kultuře a zvykům organizace. Navíc většina organizací nenasazuje agilní metodiku jako jedinou možnou, ale postupně ji zavádí na nových projektech a stávající projekty nechává obvykle dobíhat v zaběhnutých kolejích. Běžně tak lze vidět v jedné organizaci projekty, které běží na SCRUMu, vodopádově organizované projekty i projekty řízené metodikou vlastní (obvykle odvozené od RUPu).
Proces Scrum.
Klíčovým předpokladem úspěšně nasazené metodiky (a to jakékoli) je schopnost týmu/lidí začít dle metodiky pracovat. Tomu lze výrazně napomoci školením, které představí stávajícímu či novému týmu nový způsob práce.
Důležitou součástí je ale i pravidelný coaching/mentoring (po dobu pilotního projektu), který umožní jednotlivým členům týmu zodpovídat otázky (typický problém takovýchto inovací je, že pokud nějaká otázka není odpovězena dostatečně a včas, tazatel se uchyluje k původnímu stylu práce, protože je na to zvyklý; udělá-li to v projektu každý, dobrá snaha něco zlepšit vyšumí do ztracena). Po ukončení pilotního projektu odchází zpravidla jeho členové pracovat do jiných projektů jako mentoři, a tím se organizace stává do velké míry soběstačná. Motivovaní lidé, kteří šíří svou motivaci na ostatní, jsou nejlepším motorem adopce nové metodiky.
Důležitým aspektem zavádění nové metodiky jsou i nástroje, které agilní metodiky podporují. Pro agilní projekt není totiž vhodné používat klasické „rigidní“ nástroje. Jedním z důvodů je vysoká míra administrace (ať už pro udržení nástrojů v běhu, či běžné denní práci projektových týmů). Prostředí pro agilní vývoj by mělo být jednoduché, pružné a poskytovat vždy takovou informaci, kterou daný člověk právě potřebuje, „just enough“.
Lepidlo napříč vývojovým světem
Pokud ale chcete mít vždy ty správné informace, navíc v potřebném kontextu, je těžké nenutit uživatele vkládat velké množství dodatečných dat a tak zpětně nezvyšovat administrativu. Objevuje se problém, jak skloubit agilně fungující nástroje s potřebou sběru mnoha různých informací. Příkladem může být dilema mezi skutečně agilně fungujícím týmem (který typicky nepoužívá klasické projektové řízení prostřednictvím Gantt grafů) a managementem, který potřebuje dlouhodobě plánovat zdroje, finance, postup projektů pomocí tradičních přístupů.
Dnes asi nejpokročilejším řešením (dle nezávislých analytiků), které tyto problémy elegantně řeší, je platforma Jazz, konkrétně modul Rational Team Concert, který je na platformě Jazz založený. Jeho velkou předností je schopnost poskytnout kompletní podporu SCRUM týmu, a to nejen v oblasti plánování, ale i pokud jde o automatický sběr dat a návaznosti mezi plánováním, verzováním kódu, dokumentace, modelů testů apod. a build/release managementem. Přináší jedno prostředí pro všechny členy členy týmů dostupné z webu nebo zaintegrované do svých vývojových prostředí (např. MS Visual Studio, IDEA, Eclipse a další), a tím propojuje nejen členy v jednom týmu, ale i týmy navzájem (např. při vývoji core banking systému, kdy každou architektonickou vrstvu spravuje jiný tým v jiné technologii a často z jiné firmy).
Navíc umožňuje fungovat jako „lepidlo“, které umí využít a provázat jiné existující technologie napříč vývojovým světem (např. Subversion, Jira, HP QC, SharePoint, MS Project apod.).
