System4U
facebook LinkedIN LinkedIN - follow
Tematické sekce
 
Branžové sekce
Přehledy
 
Tematické seriály
 

GDPR

General Data Protection Regulation zásadně mění zpracování osobních údajů a zavádí nové povinnosti...

články >>

 

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 

Komplexní svět eIDAS

O nařízení eIDAS již bylo mnoho řečeno i napsáno. A proto jediné, o čem...

články >>

 

Trendy v CRM

Systémy pro řízení vztahů se zákazníky (CRM) prochází v posledních letech výraznou změnou. Zatímco dříve...

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 
Partneři webu
Compas automatizace
IT SYSTEMS 4/2011 , ITIL – Řízení IT

Jak proměnit vývojářský tým v sehranou kapelu



Mnoho dnešních organizací, které vyvíjí nebo spravují software, koketuje s myšlenkou agility, tedy kompaktnosti a flexibility, jako způsobu vývoje. Co ale vlastně agilita ve vývoji znamená a je vůbec prakticky nasaditelná v organizaci větší než tříhlavý tým?


Během posledních deseti let se způsob vývoje výrazně posunul technologicky, znalostně i organizačně. Před několika lety stačilo mít špičkového specialistu (vývojáře, databázistu atd.), na kterého bylo možné spoléhat. Dnešní projekty jsou tvořeny většími či menšími týmy lidí, kteří přicházejí s různými zkušenostmi, různými pracovními návyky a často i rozdílnou firemní kulturou. To klade logicky vyšší nároky na týmovou spolupráci a koordinaci.
Způsobů, jak práci v týmu organizovat, je hodně. Cílem většiny přístupů je vyladit týmovou spolupráci tak, aby fungovala jako dobře našlápnutá jazzová kapela. V takové kapele je totiž každý hudebník svébytným originálem s vysokou mírou kreativity. Dohromady ale musí tvořit sehraný tým, který si vzájemně naslouchá a vytváří neopakovatelné hudební dílo.

Agilní přístupy k vývoji softwaru

Aby bylo něco takového možné vytvořit i ve světě softwaru, je třeba pomoci jednotlivým specialistům zhostit se role kreativních a zkušených hráčů, kteří naslouchají svému okolí. To však není vždy jednoduché. Mnoho týmů se o to pokouší vlastními metodami (různé varianty vodopádového vývoje nebo jiné vlastní přístupy). Některé týmy se nechávají více či méně inspirovat klasickými vývojovými metodikami (např. Rational nebo Open Unified Process). Stále častěji se ale pozornost týmů stáčí na agilní přístupy. V obecné rovině koketuje s agilitou asi každý vývojový tým, jak ji ale uvést do praxe a na co se soustředit?
Co je agilní vývoj a na jakých principech stojí? Mnoho obecných agilních principů je popsáno už v dokumentu Agile Manifesto a mnoha studiích, které tyto myšlenky dále rozvíjejí. Většina těchto dokumentů se však nezaměřuje na její praktické nasazení.
Jak tedy prakticky s agilními přístupy začít? Jednou z cest je přijmout myšlenku, že v agilním světě se snažíme dívat optikou „just enough“. Je-li tedy cílem zefektivnit fungování týmu, pak může být dobrým krokem vpřed začít zjednodušovat vnitřní pravidla a procesy. A to nikoli proto, abychom některá důležitá témata mohli vynechat, ale proto, abychom se zaměřili na činnosti, které jsou pro dosažení našich cílů opravdu důležité. Agile requirements, agile testing atd. potom často znamená aplikaci pravidla „just enough“ na jednotlivé disciplíny softwarového vývoje. Nejde ale o to, vyhnout se správě požadavků či testování. Naopak jde o to, zaměřit se na co možná nejefektivnější sběr, sdílení a údržbu požadavků v aktuálním stavu bez zbytečného úsilí navíc.

Metodiky agilního vývoje

Mnoho týmů ale nechce experimentovat se zaváděním agilních principů do vlastních metodik, ale rozhodují se pro přechod na některou z osvědčených agilních metodik. I když jich existuje celá řada, jednou z nejčastěji používaných je Scrum.
Existuje mnoho popisů metodiky Scrum a řada firem nabízí školení s možností certifikace účastníků na Scrum mastery. To, co je ale velmi těžké prostřednictvím školení či dokumentu předat, je vlastní zkušenost se zaváděním takové metodiky. Malé týmy (do pěti až sedmi lidí) se často rozhodují pro adopci metodiky Scrum samy a učí se na vlastních chybách. Větší týmy se i vzhledem k souvisejícím rizikům obvykle rozhodují pro odbornou asistenci se zaváděním metodiky.
IBM má v oblasti zavádění agilních metodik bohaté zkušenosti. Celou řadu těchto zkušeností jsme získali, když jsme se před několika lety rozhodli převést pod vedením Scotta Amblera velkou část svého interního vývoje na agilně řízené projekty. Tyto agilně řízené projekty se velmi úspěšně rozvíjejí (jedním z příkladů je transparentní a otevřená týmová platforma Jazz – http://jazz.net). Mimo to interně zkoušíme i další přístupy, jako je například Kanban apod.
Důležitějším zdrojem zkušeností jsou pro nás praktické projekty, ve kterých jsme pomohli a dále pomáháme našim partnerům a zákazníkům úspěšně přejít například na metodiku Scrum. Mezi příklady zákazníků lze zařadit významné organizace z oboru bankovnictví, telekomunikací či logistiky, a to v celém regionu střední a východní Evropy, včetně České republiky. Ve všech zmíněných projektech klademe důraz na tři klíčové podmínky úspěšného zavedení nového přístupu k vývoji – metodiku, tým a nástroje.
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 nasazujeme. 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 uzpů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.
Klíčovým předpokladem úspěšně nasazené metodiky (a to jakékoli) je schopnost týmu 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 i pravidelný coaching či mentoring (po dobu pilotního projektu), který umožní jednotlivým členům týmu zodpovídat otázky. 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.

Nástroje pro podporu agilních metodik

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. Pokud ale chceme 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 Ganttových grafů) a managementem, který potřebuje dlouhodobě plánovat zdroje, finance, postup projektů pomocí tradičních přístupů.

Platforma Jazz

Příkladem řešení těchto problémů 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ů atd. a build/release managementem. Přináší jedno prostředí pro všechny členy týmů dostupné z webu nebo zaintegrované do 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.).
V oblasti plánování je důležitých hned několik rovin. Předně je to možnost rozpadu a zaplánování jednotlivých požadavků do sprintů (iterací) a následný přehled postupu prací včetně burn-down/up grafů, „team velocity“ a dalších ukazatelů. Asi nejdůležitější rovina plánování ve Scrum je plán týmu. Zde má vedoucí týmu možnost vidět aktuálně naplánované úkoly dle jejich vlastníků, vytíženost jednotlivých lidí v týmu, postup práce celého týmu i jednotlivců. Má tak jednoduchou možnost přeplánovat práci v týmu, je-li to třeba. To vše na úrovni času i náročnosti (story bodů). Šikovnou pomůckou je také grafická vizualizace aktivit jednotlivých členů týmu (ToDo - In Progress - Done), kterou týmy prochází při pravidelných schůzkách a diskutují o nich. Na úrovni jednotlivce pak plánování představuje jednoduchý ToDo list, který vždy aktuálně informuje o všech vlastních úkolech a umožňuje s nimi jednoduše a rychle pracovat.
Mimo plánování nabízí prostředí Team Concert verzování všeho, co je ve vývojovém projektu třeba verzovat (modely, kód, dokumentaci, testy apod.), a to i při paralelním způsobu vývoje (více vývojářů pracuje současně na stejném kódu). Oblíbenou součástí je i automatizace buildů, kdy při využití existujících kompilátorů (Ant, Maven, MS Build, perl kompilátory apod.) umožňuje prostředí Team Concert zapojit individuální, kontinuální, noční i integrační buildy (včetně unit testů) a udržovat automaticky vazbu mezi požadavky a úkoly, verzemi zdrojového kódu a buildy. Snadno a rychle je tak možné dohledat řádek i kontext nahlášené chyby i v hodně starých verzích kódu.
K příjemným vlastnostem modulu Team Concert patří jeho dostupnost (zdarma do deseti uživatelů) a možnost podpořit současně agilní i tradiční týmy (Scrum, OpenUP, Waterfall, vlastní procesy), jednoduchost a rychlost práce a nasazení s cílem omezit tradiční „projektovou byrokracii“ a široká podpora jak klientských (Java, .NET, PHP, System I, System P, Mainframe, Oracle), tak serverových prostředí (Jira, Subversion, Hudson, SharePoint, HP QC aj).

Shrnutí

Agilní vývoj sám o sobě nedokáže vyřešit problémy, které mezi sebou lidé ve vývojových projektech často mají. Začít používat agilní praktiky totiž předpokládá více než jen studium příslušné literatury. Nasazení agilního vývoje znamená, že se projektový tým (nejen vývojáři) naučí aplikovat konkrétní agilní praktiky, začne je každodenně využívat v nástrojích, které jsou k tomu účelu připravené, a bude se pravidelně učit ze svých chyb.

Zdeněk Borůvka
Autor působí v softwarové divizi společnosti IBM v regionu střední a východní Evropa.

Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.

Inzerce

Jste připraveni na budoucnost?

IT Systems 5/2021Pandemie jasně odhalila trend, na který v IT Systems upozorňujeme už řadu let, a sice že role technologií pro rozvoj a přežití firem je nezastupitelná. Dnes již lze dokonce říct, že nastupuje zcela nová éra, kdy spolu firmy soutěží mimo jiné i tím, jak umějí využít technologie. Dokládá to i aktuální studie společnosti Accenture, ze které vyplývá optimistické zjištění, že firmy, které investují do inovací, vyjdou z pandemie ještě silnější.