- Přehledy IS
- APS (20)
- BPM - procesní řízení (22)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (33)
- CRM (51)
- DMS/ECM - správa dokumentů (20)
- EAM (17)
- Ekonomické systémy (68)
- ERP (77)
- HRM (27)
- ITSM (6)
- MES (32)
- Řízení výroby (36)
- WMS (29)
- Dodavatelé IT slueb a řeení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (39)
- Dodavatelé CRM (33)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (71)
- Informační bezpečnost (50)
- IT řeení pro logistiku (45)
- IT řeení pro stavebnictví (26)
- Řeení pro veřejný a státní sektor (27)
ERP systémy
CRM systémy
Plánování a řízení výroby
AI a Business Intelligence
DMS/ECM - Správa dokumentů
HRM/HCM - Řízení lidských zdrojů
EAM/CMMS - Správa majetku a údrby
Účetní a ekonomické systémy
ITSM (ITIL) - Řízení IT
Cloud a virtualizace IT
IT Security
Logistika, řízení skladů, WMS
IT právo
GIS - geografické informační systémy
Projektové řízení
Trendy ICT
E-commerce B2B/B2C
CAD/CAM/CAE/PLM/3D tisk![]() | |
| Přihlaste se k odběru newsletteru SystemNEWS, který kadý týden přináí výběr článků z oblasti podnikové informatiky | |
![]() | |
Potřeby klientů se rychle mění, agilní metody vývoje jsou nezbytné
Je to jen pár let zpátky, co vývoj systémů připomínal stavbu domu. Projekt se nejprve analyzoval, potom se navrhlo řeení a nakonec přila realizace. Po dlouhém testování se produkt připomínkoval a případně upravoval. Fungovalo to tedy podobně, jako kdy se začíná navrením plánu stavby, podle něj se postaví celý dům. Ovem oblast informačních technologií a potřeby klientů se dnes mění tak rychle, e za tři měsíce nebo půl roku u nemusí jejich poadavky odpovídat realitě.

Programování proto směřuje k agilním metodám, které umoňují, aby se vyvíjený kód neustále opravoval nebo měnil. Představy zákazníků o vyvíjené aplikaci se toti v průběhu procesu mění, přichází různé mylenky na její zlepení a dochází tak k častým změnám zadání. Původní waterfallové metody tuto flexibilitu neumoňovaly. Kdy zákazník nebyl s výsledkem spokojený, celý proces se vrátil na začátek nebo se kód dlouhé měsíce opravoval, čím se celá realizace protahovala a zvyovala rozpočet.
Metoda iterace neboli opakování
Dnes pracujeme metodou iterace, při ní pravidelně komunikujeme se zákazníkem, plníme jeho přání a potřeby, a zároveň s ním provedení dílčích úkolů pravidelně vyhodnocujeme. Základem je vytvořit projektový tým, kde vichni táhnou za jeden provaz, čím se také stírají dřívějí role dodavatel a odběratel. Společným cílem je vyvinout něco smysluplného a zákazníkům proto vdy říkáme, e to bude bolet. Společnost klienta toti musí vyčlenit člověka, který má zodpovědnost, dostatečné pravomoci a zároveň také dostatek času. A přestoe jsou to nai zákaznicí, dostávají od nás úkoly, které musí plnit. Pokud výe uvedené nejsou schopni zajistit, zpravidla to nedopadne dobře.
Narozdíl od waterfallu se v agilním procesu na začátku neřeí ve do posledního detailu. Úlohy se rozdělují do dílčích úkolů, které je třeba ve stanoveném čase poskládat do funkční podoby. Poté se jednotlivé segmenty mohou podle poadavků klientů upravit nebo nahradit jinými, ale narozdíl od waterfallových metod se vdy pracuje pouze s malými úseky. Aby takto průběný vývoj dobře fungoval, je nutné mít aplikace pokryté automatickými testy. Zákazník si současně testuje aplikaci i sám a po celou dobu tak vidí průběh vývoje, čím lze včas odladit řadu chyb a nedostatků.
Rychlost a průběné opravování chyb
Výhodou této metody je i rychlost a kontrola nad termínem. Díky iteracím a průběné validaci jednotlivých úkolů se dobře ukazuje postup vývoje a jasně pak také vidíme, jestli se zadání stíhá, nebo naopak jsme s vývojem pozadu. Díky tomu dokáeme se zákazníkem realizaci průběně vyhodnocovat a případné problémy operativně řeit. Navíc u nemůe dojít k tomu, e po několika měsících práce je zákazník zklamaný, protoe finální produkt nesplňoval jeho očekávání, co se dříve běně stávalo. Výhodou agilní metody je, e zákazník má celý proces pod kontrolou, ve je transparentní, a to i proto, e sám je důleitou součástí týmu.
Aplikace jako puzzle
V současnosti nejsou aplikace psány v jednom jazyce, je to kombinace různých programovacích jazyků, ve finále se tak jedná o skládačku mnoha slueb a nástrojů. Aby taková skládačka mohla vzniknout, je důleité, aby při vývoji rovně fungovala spolupráce mezi administrátory serverů a vývojáři. K tomu dnes slouí DevOps neboli Development and (IT) Operations, co je přístup k vývoji softwaru, kdy vývojáři komunikují a spolupracují s odborníky na infrastrukturu a provoz, tedy zpravidla s administrátory. DevOps tedy není o jednotlivcích, ale o spolupráci funkčních týmů.
K celkovému zlepení a hladí implementaci aplikací přispívá také kontejnerizace, kdy kadý vývojář pracuje ve svém izolovaném prostředí, které lze potom snadno přenést do produkce. Jedním z nástrojů, který toto umoňuje je Docker. Jedná se o software, jeho cílem je poskytnout jednoduché rozhraní pro izolaci aplikací do kontejnerů a zajistit jednotné vývojářské a produkční prostředí. Tato řeení jsou dobře kálovatelná, je ovem důleité, aby vývojáři s administrátory spolupracovali u od samého počátku a správně nastavili celý DevOps proces.
![]() |
Karel Divi Autor článku je spoluzakladatel a výkonný ředitel vývojářské společnosti IDC-softwarehouse, která se zabývá kompletním outsourcingem IT a vývojem software na zakázku. Mimo jiné stál u zrodu Letuka.cz, prvního on-line rezervačního systému pro nákup letenek ve střední a východní Evropě. |




















