Cyk­lus vývo­je soft­waru se zrych­lu­je. A je přit­om kvalitnější

His­to­rie vývo­je soft­waru je bohatá a způ­sob práce v této oblasti se za desítky let hod­ně změnil. K největším změnám dochází v posled­ních dekádách, kdy dra­mat­icky narost­lo množství vyví­jeného soft­waru, ale zároveň doš­lo také k nárůs­tu poža­davků na rychlost a kval­i­tu vývo­je. Nové metody práce vývoj usnadňu­jí a i ve zdán­livě nepřehled­ných obje­mech urych­lu­jí a zpřehledňují.

Od kla­sick­ého water­fall vývo­je a jas­ně defi­no­vaných spe­cial­i­zo­vaných rolí zúčast­něných přeš­ly orga­ni­zace k takz­vaným agilním metodám. Napřík­lad agilní meto­da LESS přináší sdíle­nou zod­pověd­nost a svým způ­sobem po členech týmu chtějí, aby měli celkově širší záběr. Hod­ně je tato změ­na vidět tře­ba v bankovním prostředí, které si i v České repub­lice proš­lo v oblasti IT od konce první dekády toho­to tisí­ciletí výz­nam­ný­mi změnami.

Názorným přík­la­dem je Česká spořitel­na. Největší česk­ou banku ještě před 10 lety asi málok­do vní­mal jako výz­nam­ného hráče na poli IT. Dnes patří Spoř­ka k největším IT zaměst­na­vatelům v Česku. Toho­to posunu dosáh­la mimo jiné i dra­mat­ick­ý­mi změ­na­mi právě v oblasti vývo­je softwaru.

„Změ­na je obrovská. Ještě před deká­dou řešili téměř vešk­eré dodávky soft­waru externí doda­vatelé. Asi před sed­mi lety proběh­la první trans­for­ma­ce banky směrem k agilním metodám řízení vývo­je soft­waru vlast­ní­mi sil­a­mi a teď u nás dochází k druhé trans­for­ma­ci, kdy se při využití dalších agilních metod nově soustředíme na navýšení při­dané hod­no­ty vyví­jeného soft­waru,“ vysvětlu­je Vítězslav Hubený, Soft­ware Engi­neer­ing Area Lead České spořitelny.

Právě při­daná hod­no­ta zna­mená, že se ban­ka při vývo­ji soft­waru soustředí na řešení, která mají pro zákazní­ka co největší prak­tický přínos. ​„Pokud nemá tech­nolo­gie byznysové opod­stat­nění, tedy přínos pro zákazní­ka, nemá sama o sobě hod­no­tu,“ říká Hubený. Cílem je tedy vyví­jet soft­ware efek­tivně: s ohle­dem na potře­by zákazní­ka, rych­le a přit­om spolehlivě. 

„Obec­ně se pře­sou­váme ke způ­sobu práce, kdy se snažíme být co nejblíže zákazníkovi,“ dodává Hubený. Pro­to doš­lo ke zmíněné­mu posunu od water­fall metod vývo­je (násle­dovaly jed­notlivé cyk­ly vývo­je po sobě) k agilním metodám s větší flexibilitou.

Zároveň je tu i ona rov­ina sdílené zod­pověd­nos­ti. Týmy pracu­jí společně, cílem je snížit množství předávek mezi jed­notlivý­mi čle­ny a vytvoření společné zod­pověd­nos­ti týmu, kdy každý ví, jaký má odvést díl práce. Podle Hubeného to zároveň zna­mená, že si IT týmy budu­jí u vedení čím dál větší důvěru: ​„A čím větší důvěru v to, že umíme vyřešit poža­davky zákazní­ka, budeme mít, tím větší vol­nost dostaneme,“ pokračuje.

Díky tomu podle něj v bance mohou dostat pros­tor vývo­jáři, kteří nej­sou jen úzce spe­cial­i­zo­vaní, ale mají širší záběr. ​„Když umíte nejen pro­gramo­vat, ale víte něco o agilním řízení, něco o fron­tendu, umíte trochu testo­vat nebo psát doku­mentaci, pak do toho­to nového mod­elu skvěle zapad­nete,“ říká Hubený. Spe­cial­isty ale samozře­jmě ban­ka potře­bu­je pro určité úkoly také.

Důležitá je vždy adap­tivi­ta. Ať už v tom, co daný vývo­jář dokáže dělat, nebo tře­ba ve schop­nos­ti rych­le pře­jít z jed­no­ho úkolu na jiný. Pri­or­i­ty se totiž mohou při mod­erních metodách vývo­je soft­waru rych­le měnit. Už tře­ba pro­to, že jed­nou z rel­a­tivně nových metod je takz­vané pro­to­ty­pování. Při něm může orga­ni­zace rych­le zjis­tit, zda zamýšlené řešení vede k požadované­mu cíli. Když né, ihned tuto ces­tu opustí.