Založení softwarového vývoje v inovativním prostředí větší společnosti

I v dnešním světě plném inovací a překotného rozvoje je šance začít něco zcela od začátku vzácná. Pokud se neocitneme v nejistém světě start-upů, většinou dostaneme za úkol stavět na něčem již existujícím. Proto jsem nemohl odolat nabídnuté příležitosti v Konica Minolta vybudovat něco zcela od začátku ve start-upovém duchu, ale pod záštitou silné společnosti. Následující řádky zachycují příběh a zkušenosti z této stále ještě živé příležitosti.

Založení softwarového vývoje v inovativním prostředí větší společnosti


Na počátku je myšlenka, později vizi následuje vypracování byznys konceptu a sada výzkumů trhu. Nic zajímavého pro SW development samotný, přesto je to to jediné, co člověk má na začátku. 

Samotná vize sice přináší jen velmi hrubé informace, prakticky žádnou architekturu a o detailních specifikacích je možné nechat si jen zdát, přesto je to dostačující na to, aby se mohl začít formovat tým. Než se vrhnete na jeho formování asi si budete chtít rozmyslet metodiku vývoje, protože to může výrazně ovlivnit výběr vývojářů a spojených rolí.  

I když se může zdát, že některá z agilních technik je jasnou volbou, není tomu tak.  

Jedním z důvodů, který není možné opominout, je společnost, ve které vývoj zakládáme. Jednou chceme hotový produkt předat k užívání mateřské organizaci, ta se na to musí chystat, být informována a držet krok s vývojem, aby byla připravena, jakmile bude hotovo. Přestože tedy hlavním kritériem se může zdát být efektivita vývoje, pokud okolní organizace není schopna stejným tempem formulovat požadavky, bude vývoj vyvíjet něco jiného, než je původní záměr. 

Druhý důvod je více technický. Pro tvorbu softwaru s fixně a přesně danou známou funkcionalitou, jež ona samotná, ba ani její kvalita, nemůže být předmětem diskuze, může být tradiční vodopád výhodnější. Dalším příkladem může být i vytvoření infrastrukturní vrstvy těch částí budoucího produktu, jež sestávají z robustních, pomalu a málokdy se měnících komponent, které samy o sobě funkcionalitu nepřinášejí, ale jsou nutné pro všechno ostatní. Pokud na začátku víme, že je to něco, co uděláme a pak to dlouho nebudeme měnit, protože je to jen podklad pro tu vrstvu, která přináší skutečnou hodnotu, a zde oceníme jen spolehlivost, tradiční metody mohou být vhodnější i s ohledem na množství zkušeností z jiných podobných projektů. Pokud je ale zrovna tato vrstva zdrojem inovace, je dobré tuto inovativní část oddělit či řešit celou infrastrukturní část agilně. 

Naopak u částí, kde je jen vize či s trochou štěstí koncept, je agilní vývoj tou správnou volbou. Zde nám nezáleží na podrobné jednotlivé funkcionalitě, ale na naplnění cíle, kterými budou jistě spokojený uživatel produktu a finanční ředitel společnosti. A kterou konkrétní metodiku zvolit?  To do značné míry závisí na tom, jak progresivní metody jste schopni začlenit do rámce společnosti a jak velký a vyspělý tým budujete. Je nutné se i připravit na možnost, že zejména v počátku zvolíme agresivnější metodiku jako třeba kanban a později zvolníme na scrum, když bude větší potřeba napojení se na další skupiny projektu.  

S ohledem na výše uvedené jsou výběr vývojářů a také struktura týmu klíčové. Je potřeba se uvědomit, že agilní metody mají spoustu předpokladů. Jedním z nich je, že tým je sebeorganizující. Abychom tohoto docílili, musíme mít lidi, kteří vědí, co potřebují k práci. Toho se těžko dociluje, pokud najmeme skupinu studentů či zasloužilé vývojáře, kteří deset let vyvíjeli pod přísným mikromanažujícím projektovým vedoucím. Na druhou stranu je třeba zvážit, jak se zachovají čisté start-upové typy, pokud jim sebeorganizování omezíte firemními pravidly, nakolik ta mohou a nemusejí být užitečná. Dále tito vývojáři musejí být nachystaní na vyšší míru prototypování. Z toho plyne, že je třeba naplnit nový tým z nadpoloviční většiny ze zkušených vývojářů, kteří jsou na výši nejen odborně, ale hlavně zkušenostně. Jakkoliv externí konzultant ohledně scrumu může pomoci a věci urychlit, nemůže nahradit zkušenost v týmu.  

Scrum také předpokládá, že členové týmu ochotně dělají i práci mimo svoji hlavní odbornost, pokud pro ně zrovna není práce v jejich odbornosti, a je to nutné k dokončení sprintu. Ne každý je ochoten se učit věci mimo svoji expertizu. Navíc se na našem pracovním trhu zcela běžně setkáváme s vývojáři, kteří se specializují výhradně na vývoj back-endu anebo front-endu. To pochopitelně povede k otázkám, jak organizovat tým. Možností je hned několik. Nejdříve uvažme, jaké odbornosti budeme potřebovat. Bude to architekt (ano, i při agilním vývoji potřebuje lidi s architektonickými dovednostmi), vývojáři pro back-end, front-end, quality assurance a případné doprovodné role. Bohužel nám nenastane případ, kdy máme tým plný univerzálních vojáků schopných dělat cokoliv. Takže si musíme zvolit mezi přísně funkčními tými skládajícími se z jedné odbornosti, anebo plnohodnotnými týmy skládajícími se ze všech potřebných dovedností v jednom týmu, či nějakou hybridní možností.  

Vše je to o rozdělení zodpovědnosti a o řízení komunikačního overheadu. Scrum nás vede spíše k plnohodnotným týmům, kdy nám však při více týmech vznikne potřeba koordinovat jednotlivé odbornosti skrze týmy k zajištění stejných technologických postupů a kvality. Výhodou je, že tým je schopen dodat celou user story jako celek. Zcela jistě nastanou potíže při odhadech jednotlivých stories vyžadujících více odborností. Ač se dá vymyslet velmi komplikovaný způsob, nejjednodušším a správným řešením je jeden odhad za celý tým bez ohledu na jednotlivé odbornosti. To vyplývá z hlavního významu odhadů komplexity stories, čímž je odhad náročnosti pro celý scrum tým, nikoliv plánování náročnosti v člověkohodinách pro jednotlivé odbornosti. Pokud jsou týmy menší, nastane riziko, že nějaká znalost z týmu zmizí (nemoc, dovolená atp.). Proto je u tohoto modelu nezbytně nutné podporovat rozvoj vzájemné zastupitelnosti v týmu.

Naopak funkční týmy je jednodušší řídit z hlediska jedné odbornosti a mohou být výhodné, pokud je nějaká odbornost klíčová a sjednocující pro celý produkt. Je tu také vyšší zastupitelnost, kterážto výhoda se však zmenšuje s počtem odborných domén na produktu. Rizikem pak je rozpad stories na stories pro jednotlivé odbornosti a komplikované udržování jejich vazeb k původní user stories. Protože zodpovědnost jednotlivých týmů se tříští na jejich odbornost, vzniká vyšší zátěž na straně produkt ownera vše organizovat. 

A na závěr bych zvolil to nejdůležitější. Můžeme mít ten nejlepší vývojový tým, ale pokud mu nedáme směr a zadání, nezískáme kýžený výsledek. Proto bych se rád věnoval roli produkt owner v rámci inovačního vývoje.  

Na rozdíl od zaběhnutého produktu, který si je možné nastudovat a kde si můžeme přímo pohovořit se zákazníky o jejich potřebách, u nového či výrazně inovačního projektu tuto možnost nemáme. U zcela nového produktu nemůžete dokonce ani opisovat od konkurence. Proto náročnost práce produkt ownera na takovémto projektu je mnohonásobně vyšší. Typická schopnost uchopit byznys požadavek a přeložit jej do story se zde násobí na schopnost uchopit ideu a tu (přes několik úrovní) přeložit do stories. Navíc chápání agilního přístupu, kdy vyvinu jednu malou funkci a tu pak rozšiřuji podle zpětné vazby, je zde zásadní. Nejen s ohledem na vývoj samotný, ale i na schopnost nalézt onu zpětnou vazbu. Dále přidání nové funkce do již fungujícího produktu nám zjednodušuje situaci o existenci kontextových informací a zaběhlých rámců. U nového produktu nic takového nemáme a od začátku je nutné řešit i detaily, které by na vyzrálém produktu byly jasné samy o sobě. Je tedy zřejmé, že i zkušený produkt owner se pořádně zapotí a množství práce, které musí odvést, je násobně vyšší než u práce na zaběhlém produktu. U rozsáhlejších projektů, jako třeba u nás v Konica Minolta, je nezbytné mít organizovanou skupinu pro definici produktu. A zde opět přichází na scénu již zmiňovaná zkušenost vývojářů. Jedině ti budou schopni podpořit produkt ownery v jejich obtížném úkolu a navrhováním možností a hledáním, jak úkol splnit, mohou nastolit produktivní situaci. Nováčci, pasivní jedinci a vývojáři nezkušení v agilním vývoji se mohou rychle ocitnout ve velmi frustrující situaci, zatímco ti zkušenější si užívají možnosti být kreativní. Pokud však bude skupina produkt ownerů slabá, hrozí riziko, že vývoj bude řízen vývojáři a bez ohledu na krásu výsledného produktu zamýšlený bussiness goal nemusí být naplněn. Klíčová se mi zdá role přispívajících scrum masterů, kteří jsou ti první, kdo podávají pomocnou ruku produkt ownerům vědouc, že se to v dobrém vrátí jim i jejich týmům.  

Založení nového týmu pro nový produkt nás nutí položit si spoustu základních otázek, které jakkoliv mohou znít triviálně, návod na zodpovězení každé z nich by vydal na samostatný článek. Na druhou stranu si přiznejme, že řešit problémy tohoto typu je vlastně krásné a zábavné, a i když se člověk zapotí, rozhodně bych to nevyměnil za poklidnou rutinu. 

Milan Jedlička, Head of Software Development, Konica Minolta

Úvodní foto: konica minolta










Komentáře