V posledních deseti letech se v Česku dostalo v oblasti softwarového vývoje do popředí zájmu agilní projektové řízení, zejména metoda Scrum. V dnešním článku se podíváme, jak a kdy ho využít při rozvoji podnikového informačního systému a kdy se ho raději vyvarovat. Co to je agilní vývoj Agilní projektové řízení se datuje do roku 1986, kdy Hirotaka Takeuchi a Ikujiro Nonaka přišli s novou metodou projektového řízení, která by se dala elegantně využít v automobilovém průmyslu a při vývoji počítačového hardwaru. Ani v jednom z těchto odvětví se jejich metoda publikovaná v Harvard Business Review moc neujala. Zato o dvacet let později začala zajímat softwarové vývojáře u nás. Do oblasti softwarového vývoje ji přitom už v roce 1995 přenesl americký vývojář Ken Schwaber. Ten původní metodiku doupravil do dnešní podoby Scrumu (slovo pochází z ragbyového termínu scrum, česky skrumáž, kdy před prvním výhozem stojí oba kompletní týmy uprostřed hřiště těsně naproti sobě). Agilní vývoj staví na jednoduché myšlence inkrementálního řízení projektu – tedy postupného zpracovávání úkolů po dílčích celcích, kdy jde vývoj kdykoliv zastavit, zrychlit, upravit apod. Potřebujete například rozšířit svůj ERP systém o procesy v HR oddělení? Nejprve pokryjete ty nejhlavnější v základních obrysech, pak začnete buď pokrývat další procesy, nebo detailněji rozpracovávat ty hlavní, již pokryté, a takto postupně jdete krok za krokem dál a dál. Těmto jednotlivým krokům se v agilním vývoji říká sprinty (termín pochází opět z ragby, kdy hráč s míčem se snaží doběhnout co nejdál, dokud ho někdo nezastaví). Jak probíhá agilní vývoj Agilní vývoj vychází z tzv. product backlogu, což je celkový seznam úkolů, které je potřeba udělat. Z nich si vývojáři spolu s vlastníky backlogu, v případě ERP systému s klíčovými uživateli, vyberou seznam úkolů pro další sprint. Ten je vždy striktně omezen délkou trvání; obvykle trvá jeden týden až jeden měsíc, přičemž nejčastější bývají dvoutýdenní sprinty. Výstupem sprintu mají být fungující funkční celky, které byly zadány. Pod pojmem „fungující“ se přitom skrývá absolvování celého vývojového cyklu, od zadání přes programování po integraci, testování a dokumentaci. Tedy fungující celek připravený k okamžitému nasazení. Při délce sprintu to ovšem znamená, že zadávané celky jsou často opravdu dílčí, jako třeba v našem příkladě pokrytí hlavních procesů v rámci HR popsané výše. Klíčovým úkolem je proto správné rozplánování sprintu. I to je metodicky přesně podchyceno a měl by se ho účastnit celý vývojový tým. Hlavní odlišností agilního vývoje od toho tradičního je však způsob řízení projektu, kdy vývojářský tým má obvykle každý den ráno scrum meeting, na němž si jednotliví vývojáři rozdělí dílčí úkoly, respektive si sdělí, jak se jim daří držet se plánu stanoveného den předtím. Na úkoly ze sprint backlogu, které mají zpoždění, je pak možné ad hoc přidělit další či jiné vývojáře, takže případné zpoždění se obvykle eliminuje do dalšího pracovního dne. Součástí každého sprintu je i sprint review na jeho konci, kdy se zhodnotí, co bylo dokončeno, práce se odprezentuje vlastníkům product backlogu a určí se náplň dalšího sprintu, a také sprint retrospective, kdy se zhodnotí, jak probíhal předchozí sprint a co by bylo možné do budoucna, zejména po stránce vývoje a práce vývojářského týmu, vylepšit. K čemu agilní vývoj v oblasti ERP využít Agilní vývoj má v oblasti ERP systémů nepochybně své místo. Jak můžete vyčíst z jeho fungování výše, je doslova ideální pro rozvoj systému v podobě jednotlivých dílčích releasů. Výhody agilního vývoje spočívají hlavně ve schopnosti rychle doručit fungující celky, což v této fázi životního cyklu podnikového informačního systému je obvykle žádoucí. Jakmile je systém nasazen do ostrého provozu, rozvojové úkoly se často soustředí na rychle proveditelné úkoly jako nové formuláře, nové workflow, nové integrace, nové reporty apod. Agilní vývoj se však hodí i tehdy, kdy si firma chce „vyzkoušet“ rozšíření stávajícího podnikového informačního systému do nějaké nové oblasti, kde si není příliš jistá náročností, výsledkem či finálním rozsahem využití systému a jeho funkcí. Právě pro oblast nejistoty je agilní vývoj velmi přínosný v tom, že umožňuje relativně málo nákladné a postupné rozšiřování funkcí. Tím, že základ může být hotový třeba za jeden sprint – tedy dva až čtyři týdny – dává možnost něco relativně rychle a levně vyvinout a uvést do provozu, pak to chvíli testovat a na základě zkušeností z reálného fungování rozhodnout, co a jestli dělat dál. Proto je také agilní vývoj ideálním nástrojem pro podporu inovací. Pokud se ve firmě objeví nápad na inovaci, který potřebuje i zásah do ERP systému, může být agilní vývoj ideální pro pomoc s otestováním nějaké myšlenky. Velká část inovací totiž ve firmách končí na tom, že po stránce IS/IT by to bylo „příliš drahé“ a dlouho by to trvalo. Kdy se agilní vývoj moc nehodí Při využívání agilního vývoje v oblasti podnikových informačních systémů je však potřeba myslet na to, že systém jako takový je jen nástroj, který je využíván zaměstnanci, obchodními partnery a zákazníky pro nějaký konkrétní účel. V případě ERP systémů tak samotný softwarový vývoj tvoří jen dílčí součást podstatně náročnějšího a komplexnějšího celku, kdy je potřeba mnohdy pomoci uživatelům vyvinuté části systému tuto část začít plně a správně využívat. Navíc většina změn ve firmě (a systému) nese své ovoce až s odstupem času, někdy i několika měsíců, či dokonce let (v případě např. sběru dat pro budoucí analýzu). V oblastech fungování firmy, kde se jedná o změny zahrnující více oddělení ve firmě či o realizaci strategické změny ve firmě, se tedy agilní vývoj příliš nehodí. Kvůli svému tlaku na rychlé doručení fungujícího produktu či funkcionality totiž neskýtá dostatek prostoru pro mnohdy velmi časově náročnou spolupráci se stakeholdery (zejména externími, jako jsou zákazníci), protože není připraven na to, že nějaký proces trvá blíže neodhadnutelnou dobu (např. typicky získání zpětné vazby od reálných uživatelů), která je navíc mimo kontrolu projektového manažera (scrum mastera). Obecně vzato tedy doporučujeme agilní vývoj spíše tam, kde je vývojovému týmu předáno konkrétní zadání ideálně dílčích celků, které je plně pod jeho kontrolou a nevyžaduje už žádné dodatečné externí vstupy a interakce s jinými subjekty mimo firmu. Pak může agilní vývoj fungovat velmi rychle a efektivně. zdroj: www.helios.eu The post Jak využít agilní vývoj při rozvoji podnikového informačního systému appeared first on QUORT SYSTEM, s.r.o..
Implementace nového podnikového informačního systému s sebou nese celou řadu úskalí. Na základě našich zkušeností z praxe českých podniků jsme dali dohromady deset nejkritičtějších. Na co si dát pozor? Pojďme se podívat na prvních pět bodů. Výběr ERP sys
prejsť na článokImplementace nového podnikového informačního systému s sebou nese celou řadu úskalí. Na základě našich zkušeností z praxe českých podniků jsme dali dohromady deset nejkritičtějších. Dnes si povíme o dalších pěti věcech, na které si dát pozor. I. díl člán
prejsť na článokMožná jste už slyšeli od svých obchodních partnerů či subdodavatelů tragické historky o tom, co ve firmě následovalo po spuštění nového podnikového informačního systému. Jak to ale vypadá, když je projekt dobře řízen, na co z oněch „hororových scén“ se sk
prejsť na článokImplementace podnikového informačního systému bývá poměrně náročnou operací, která jednou provždy změní další fungování vaší firmy. K tomu, aby to byla jednoznačná změna k lepšímu, je potřeba věnovat dostatek pozornosti naplánování celé operace. Jak si ce
prejsť na článokĎalším novým nájomcom najvyššej budovy vEÚ je SAP. Poľská pobočka renomovaného poskytovateľa podnikového softvéru sa presťahuje na 11. poschodie Varso... The post SAP sa sťahuje do Varso Tower appeared first on HB Reavis.
prejsť na článok