Agile, Scrum, Waterfall, DevOps…Pojmy v oblasti vývoje SW jen lítají, a to se ještě držíme hodně při zemi. Pokud už jste vývoji SW nakoukli trochu pod pokličku, určitě jste zaznamenali, že se vlastně v každé firmě vyvíjí trochu jinak. Proč tomu tak je a jaké jsou tedy přístupy a způsoby vývoje SW? Připravili jsme pro vás průvodce základy, díky kterým možná trochu zastavíte ty točící se mozkové buňky a zpřehledníte si situaci.
Spolu s tímto článkem doporučujeme mrknout i na základní pozice, se kterými se během vývoje SW můžete setkat.
Ať máme hned na začátek jasno: proces vývoje SW můžeme nazývat také životní cyklus vývoje SW. Tvoří ho 5 základních fází, díky kterým vznikne finální produkt: software v jakékoliv podobě vás jen napadne (aplikace, platforma, webovka…).
Zajímá vás oblast IT a hledáte pracovní pozice a pracovní příležitosti v IT oboru? Ať už jste programátor, developer, tester, analytik nebo software architekt, ozvěte se nám a my vám z naší nabídky IT práce najdeme IT projekt na míru. Podívejte se, jaká volná pracovní místa v IT oblasti momentálně nabízíme. Pomůžeme vám najít nové pracovní výzvy a příležitosti. Těšíme se na spolupráci s vámi!
Vývoj SW není disciplína, kde by vystupovala tvrdá fakta jako například v medicíně, chemických pokusech nebo fyzice. Je to proces založený na zkušenostech a ověřených aktivitách. Abychom na konci procesu dosáhli žádoucího výsledku, rozumějte funkčního SW, potřebujeme vědět, co, kdy a kdo má v daném okamžiku dělat a proč to má dělat. Tyhle zásadní věci popisuje a shrnuje metodika. Metodika tedy určuje, jak k vývoji přistoupíme a jak dosáhneme právě toho finálního produktu. A právě tyto přístupy se poměrně výrazně liší.
Tradičně, agilně nebo raději DevOps?
Přístupy k vývoji, neboli metodiky, můžeme úplně základně rozdělit do 3 kategorií:
- tradiční způsoby vývoje
- agilní způsoby vývoje
- DevOps přístup k vývoji
U tradičních přístupů k vývoji jsou klientské požadavky definovány hned na začátku procesu a v průběhu vývoje se už nemění. Tým je tedy se zákazníkem v kontaktu na začátku ve fázi analýzy a pak až na konci, když se mu představuje hotový produkt nebo jeho prototyp, v průběhu se se zákazníkem vůbec nekomunikuje.
Hlavní metodiky tradičního způsobu vývoje:
- Build and Fix: model „napiš – oprav“
- Stagewise: striktní posloupnost fází
- Waterfall: vodopádový model
- Spirálový model
- Další metodiky: RUP, USDP, …
Agilní přístupy vývoje reagují na zrychlování doby i na potřeby zákazníka. Ten často na začátku neví, co přesně chce nebo se mu v průběhu změní podmínky, zdroje a on na to musí reagovat. Agilní metodiky proto kladou důraz na kontakt se zákazníkem i během řešení, priority se průběžně přehodnocují. Dobrého výsledku se dá dle „agilu” dosáhnout jedině tak, že se co nejrychleji navrhne nějaká část SW, předloží se zákazníkovi a na základě jeho zpětné vazby se upravuje.
Hlavní metodiky agilního způsobu vývoje:
- Adaptivní vývoj softwaru
- Extrémní programování
- Lean Development
- SCRUM
- Crystal metodiky
- Test-Driven Development
- Feature Driven Development
Jedním z novějších a v posledních letech čím dál tím rozšířenějších přístupů k vývoji je DevOps. Jak již samotný název napovídá, vychází ze spojení Development a Operations. Pochopení tohoto přístupu znamená v podstatě úplnou změnu myšlení nad tím, jak probíhá vývoj SW: Takže jednoduše zapomeňte, co jste si dosud přečetli. Máme pusto prázdno? Tak si pojďme vysvětlit DevOps.
Velice zjednodušeně SW doposud vznikal takto: Lidé zodpovědní za vývoj vytvořili aplikaci a předali ji systémovým administrátorům, kteří ji nasazovali pro užívání zákazníkům. Máme tedy vývoj (Development) a provoz (Operations), dvě skupiny, které jsou na sobě závislé. Pro dobrý výsledek je jejich komunikace klíčová, ale v praxi velmi složitá a často z různých důvodů nedostatečná. Věci, které jsou jednoduché z pohledu vývoje, nemusí být implementovatelné na serverech z pohledu infrastruktury. A to, co je velice snadno řešitelné v infrastruktuře bude zase velice těžký oříšek pro vývojáře.
Co když ale tyto dva „tábory” propojíme? Vznikne DevOps specialista, který napomáhá hladké spolupráci vývoje a provozu prostřednictvím vysoké úrovně kooperace, sdílení rizik, transparentnosti, automatizace a přijímáním změn.
Oproti ostatním stylům vývoje totiž realeasují produkt nebo aplikaci do ostrého prostředí mnohem častěji, což týmu umožňuje rychle opravovat chyby a zaručují krátkou dobu dodávky.
|
Waterfall |
Agile |
DevOps |
|
|
základní filozofie |
- požadavky zákazníka se v čase nemění - vše lze předpokládat a specifikovat dopředu |
- požadavky zákazníka se v čase mohou měnit |
- požadavky zákazníka se v čase mění |
|
jak vypadá dokumentace |
velmi detailní a srozumitelná |
spíše vágnější, jen základní body |
spíše vágnější, jen základní body |
|
využití automatizace |
nízké |
záleží na projektu |
vždy vysoké |
|
doručování výstupů zákazníkovi |
pomalé (v řádech měsíců) |
rychlé (v řádech týdnů/dní) |
nepřetržitě |
|
schopnost reakce na zákaznické změny |
velmi limitovaná, specifikace je od začátku hodně detailní |
ve fázích, reaguje na změny priorit |
velmi dobře průběžně reaguje na změny |
|
spolupráce |
týmy pracují oddělené dle svých funkcí |
zákazník je zahrnutý v jednotlivých vývojových cyklech |
všichni stakeholdeři jsou zahrnuti od začátku do konce |
|
riziko |
s postupujícím projektem stoupá |
s postupujícím projektem klesá |
s postupujícím projektem klesá |
|
pro jaké se hodí projekty |
- projekty, kde je kladen velký důraz na stabilitu, bezpečnost, nemohou si dovolit chyby a je tedy potřeba velmi detailní testování |
- projekty, jejichž produkt může mít několik různých podob |
- projekty v odvětvích, které jsou samy o sobě velmi dynamické a plné změn |
Vybrané metodiky zblízka
Pojďme si vzít lupu, prozkoumáme 3 základní přístupy ještě do trochu většího detailu.
SCRUM
Z agilních metodik je jednozańačně nejpoužívanější SCRUM. Nový projekt se zahájí představením vize výsledného produktu. Definují se vlastnosti, které má SW obsahovat a na základě nich se popisují tzv. User Stories.
Jak může vypadat User Story?
Jako uživatel CMS můžu:
- nahrát fotografie
- oříznout fotografie
- změnit název fotografie
- zobrazit změny provedené na fotografii
Všechny popsané User Stories se sepíší pod sebe do tzv. Product Backlogu. Následně se určí priority, na kterém úkolu se má začít pracovat nejdříve. Odhadne se čas, který může jejich tvorba zabrat a na základě toho se určí, kolik úkolů se stihne zpracovat v prvním sprintu. Sprint trvá ve Scrumu 2 týdny, maximálně měsíc.
Během sprintu si tým každý den organizuje 15 minutové porady, říká se jim denní scrum. Řeší se především problémy a věcné připomínky k vývoji.
Po dokončení sprintu se předvádí produkt klientovi. Vlastnosti, které se nestihly dokončit, jsou skryty, klient tedy uvidí pouze dokončenou práci. Dané vlastnosti jsou vždy vyvinuty a otestovány. Klient ví, které úkoly se nestihly a může se rozhodnout, zda se dokončí. Implementace produktu do ostrého prostředí se dělá až na konci, kdy jsou vyvinuté a otestované všechny požadované vlastnosti produktu.
Ve Scrumu je kladen velký důraz na na analýzu rizik. Revize rizik na konci každé interakce, ale i v průběhu každodenních schůzek.
Výhody
- pružná reakce na změny
- větší volnost týmu - metoda není tolik zaměřená na dokumentaci, ale spíš na kreativitu řešení
- zapojení klienta do vývoje
Nevýhody
- kvůli častým změnám může dojít k velkých odchylkám při odhadech ceny
- úspěch z velké míry závisí na ochotě klienta spolupracovat
- je potřeba poměrně seniorní a samostatný tým
WATERFALL
Metodika waterfall má spoustu kritiků, ale stále je ještě u některých projektů tím nejlepším možným řešením. Tento přístup k vývoji rozděluje projekt na jednotlivé fáze, které se snaží oddělovat, druhá fáze může začít až poté, co finálně skončila první atd…Většinou se setkáme s pěti základními fázemi:
Filozofie waterfallu spočívá v tom, že se na začátku stanoví poměrně detailní a striktní pravidla, kterých se následně všichni drží. Projektový tým má minimální prostor na změny.
Výhody
- dobře se plánuje a kontroluje
- umožňuje jasně určit zodpovědnosti
- produkt je možné dodat i s méně kvalitním, juniornějším týmem
Nevýhody
- poměrně neefektivní způsob vývoje
- málo zpětné vazby od zákazníka
- malá možnost reakce na změny
DEVOPS
A nakonec se ještě pojďme podívat na zoubek pár detailům DevOps přístupu.
Filozofií této metodiky je rozdělit projekt do menších vývojových celků, které umožní prezentovat zákazníkovi funkční produkt v co nejkratším čase a získat tak okamžitou zpětnou vazbu.
Základem jsou 3 principy:
- průběžná integrace (continuous integration)
Pomáhá odhalit problémy už ve fázi kódování. Jakmile developer implementuje nějakou část hotového kódu do verzovacího systému, robot zkontroluje současnou verzi a upozorní na případné chyby.
- automation testing
Časové efektivitě této metodiky nahrává hojné využívání automatizovaného testování. Testy si většinou developeři napíší sami a nemusí čekat na výsledky manuálního testingu. Pokud bychom měli tuto myšlenku dotáhnout až ad absurdum, měly by se nejdřív naprogramovat testy a pak až funkce.
- průběžné nasazování (continuous deployment)
Průběžné nasazování hotových částí produktu do ostrého prostředí umožňuje efektivnější a flexibilnější dodávání produktu.
Výhody
- kratší čas vývoje
- spolehlivé releases nových částí produktu
- rychlejší oprava chyb
Nevýhody
- nutnost automatizovaného testingu
- používání velkého množství nástrojů, mezi kterými se často přepíná
- zatím je náročné získat odborníky s těmi správnými znalostmi a zkušenostmi
Závěrem ještě připomeneme to, že každý projekt je jiný a málokde se opravdu setkáte s tím, že bude praktické používání metodiky 100% zrcadlit teorii. Firma si vždy potřebuje vše přizpůsobit tak, aby to co nejlépe vyhovovalo jejím potřebám. To jen tak na okraj, aby se ty mozkové buňky, které jsme na začátku uklidnili, moc nenudily. :)
Přístupy k vývoji SW jdou stále krok po kroku dopředu, reagují na změny doby, požadavky klientů a samozřejmě i na časovou a finanční efektivitu.
🟡 Hledáte zajímavý projekt? Mrkněte, jak to u nás chodí a jaké kolegy aktuálně hledáme.
🟡 Máte kolegu nebo kamaráda, který se poohlíží po novém projektu? Zapojte se do našeho referral programu Doporuč a získejte finanční odměnu za doporučení.
🟡 Chtěli byste začít pracovat v IT? Stáhněte si náš ebook ZAČNĚTE PRACOVAT V IT: aneb od prvních krůčků po vysněnou práci, ve kterém vás provedeme krůček po krůčku informacemi, kurzy i praxí, které jsou tolik potřebné nejen pro ty, kteří chtějí změnit obor, ale i pro ty, kteří se chtějí pracovně posunout a dále se vzdělávat.
🟡 Víte, jak si co nejjednodušeji a nejefektivněji připravit půdu pro nové pracovní začátky? Mrkněte na náš ebook: Připravte se na nová pracovní dobrodružství - Průvodce k úspěšné změně zaměstnání. Dream job je za dveřmi, stačí jen vzít správně za kliku.
Nebo sdílejte tento článek, který třeba poslouží i vašim známým.
