Počítačový průmysl je plný nejednoznačných jazyků, drsného žargonu a složitých myšlenek, kterým je těžké porozumět a mohou vaši mysl uvrhnout do šílenství výpočetního vyrovnávací paměti.
Vodopád? Skrumáž? Agilní?
Pokud jsou vám tyto fráze zcela cizí, nebojte se; váš užitečný tým techniků HashDork je tu, aby vám pomohl porozumět rozdílům mezi těmito zásadními fázemi vývojového procesu, abyste se mohli naučit.
Agilní, scrum a vodopádové techniky budou všechny popsány v tomto příspěvku na blogu, spolu s tím, jak každá z nich může pomoci vašemu týmu jako celku.
Začněme s agilním a zbytek poneseme.
Co je to Agile?
Agilní vývoj softwaru se řídí iterativním, inkrementálním přístupem. Namísto rozsáhlé přípravy na začátku projektu jsou agilní techniky flexibilní vůči měnícím se potřebám v průběhu času a podporují neustálou zpětnou vazbu od koncových uživatelů.
Mezifunkční týmy pracují na iteracích produktu v průběhu času a tato práce je kategorizována do nevyřízených záležitostí a prioritizována na základě obchodní nebo zákaznické hodnoty. Účelem každé iterace je vytvořit použitelný produkt.
Vedení podporuje spolupráci, odpovědnost a komunikaci tváří v tvář v agilních metodologiích.
Obchodní partneři a vývojáři musí spolupracovat, aby zajistili, že produkt splňuje požadavky spotřebitele a cíle společnosti.
Fráze „agilní vývoj“ se vztahuje na různé metody a rámce, které jsou založeny na ideálech a zásadách uvedených v Agilní manifest.
Odborníci doporučují dodržovat agilní principy a hodnoty a používat je jako vodítko při rozhodování o správných akcích, které je třeba podniknout v konkrétním prostředí při vývoji softwaru.
Kolaborativní a samoorganizující se tým jsou hlavními oblastmi, na které se komunita agilních vývojářů softwaru zaměřuje.
Týmy mohou autonomně rozhodovat o tom, jak budou řešit konkrétní projekt, ale to neznamená, že supervizoři neexistují. Agilní týmy jsou tedy mezifunkční.
V agilním paradigmatu jsou manažeři stále nezbytní. Zajišťují, aby každý člen týmu měl nebo získal potřebné schopnosti pro projekt.
Manažeři v agilním rámci fungují tak, že podporují atmosféru, která přináší to nejlepší v týmu. Ale spíše než aby se ujali vedení, často se upozadí a nechají tým rozhodnout, jak budou věci dodávat.
Manažeři se zapojují pouze tehdy, když se týmy opakovaně bez úspěchu pokoušejí řešit problémy.
Agilní vývojový cyklus
Fáze agilního vývojového cyklu jsou uvedeny níže. Je důležité mít na paměti, že tyto fáze by neměly probíhat popořadě, protože jsou flexibilní a neustále se mění. Mnoho z těchto fází probíhá současně.
- Plánování: Poté, co se projektový tým rozhodne, že nápad je praktický a proveditelný, začnou hledat funkce. Cílem této fáze je upřednostnit každý prvek a přiřadit jej k iteraci po rozdělení myšlenky na menší obrobky (funkce).
- Analýza požadavků: K určení obchodních požadavků tento krok zahrnuje několik diskusí s manažery, zainteresovanými stranami a uživateli. Kdo bude produkt používat a jak jej bude využívat, patří mezi podrobnosti, které musí tým shromáždit. Tyto normy musí být specifické, použitelné a kvantitativní.
- Design: Požadavky zjištěné v předchozí fázi se používají k přípravě návrhu systému a softwaru. Tým musí zvážit vzhled produktu nebo řešení. Testovací tým také vypracuje strategii nebo plán testu.
- Implementace, kódování nebo vývoj: Tato fáze se zaměřuje na vytváření a hodnocení funkcí a plánování nasazení iterací (podle přístupu iterativního a přírůstkového vývoje [IID]). Protože nejsou poskytovány žádné funkce, začíná iterace 0 vývojového období. Dokončením činností, jako je uzavírání smluv, nastavení nastavení a financování, poskytuje tato iterace základ pro budoucí růst.
- Testování: Poté, co byl kód vytvořen, je testován podle požadavků, aby bylo zajištěno, že produkt skutečně uspokojuje požadavky uživatelů a splňuje obchodní cíle. V této fázi se provádí testování jednotky, integrace, systému a přijatelnosti.
- Rozvinutí: Po otestování je produkt zaslán klientům, aby jej mohli používat. Projekt však není po nasazení dokončen. Zákazníci se mohou setkat s dalšími problémy poté, co začnou produkt používat, což bude vyžadovat, aby projektový tým našel řešení.
Výhody
- Rychlejší, kvalitnější dodání: Rozdělením projektu na iterace (spravovatelné jednotky) se tým může soustředit na kvalitnější spolupráci, vývoj a testování. Když se testování provádí s každou iterací, problémy jsou nalezeny a opraveny rychleji. Navíc díky neustálým následným revizím může být tento vysoce kvalitní software dodáván rychleji.
- Změna je vítána: Přestože jsou plánovací cykly kratší, je snadné přijmout a přizpůsobit změny v kterémkoli bodě projektu. Nevyřízené položky lze vždy vylepšit a změnit jejich prioritu, což týmům umožní provést změny v projektu během několika týdnů.
- Konečný cíl nemusí být znám: Agile je vynikající pro projekty, kde není jasně definován konečný cíl. Jak se projekt posouvá dále, cíle budou jasné a vývoj bude schopen pohotově vyhovět těmto měnícím se potřebám.
- Neustálé zlepšování: Agilní programy podporují vstup uživatelů a týmů ve všech fázích projektu, což umožňuje aplikaci toho, co se naučili, ke zlepšení další iterace.
- Názory zákazníků jsou ceněny: Zákazníci mají několik příležitostí sledovat dokončovanou práci, nabízet zpětnou vazbu a skutečně ovlivnit konečný výsledek. Díky tak důvěrné interakci s projektovým týmem si mohou vyvinout pocit vlastnictví.
- Silná týmová práce: Agile zdůrazňuje význam pravidelné komunikace a osobních setkání. Lidé mohou při práci v týmech převzít odpovědnost a vlastnit určité součásti projektu.
Nevýhody
- Členové týmu musí mít znalostie: Agilní týmy jsou často malé. Členové týmu tedy musí mít širokou škálu dovedností. Navíc musí chápat a cítit se pohodlně pomocí vybrané agilní techniky.
- Plánování by mohlo být méně přesné: Někdy může být obtížné určit přesné datum dodání. Agile je postavena na časově omezeném poskytování a projektoví manažeři často mění priority úkolů. Je tedy pravděpodobné, že některé dodávky, které byly původně naplánovány k dodání, nebudou dokončeny včas. Kromě toho lze kdykoli během projektu přidat více sprintů, čímž se prodlouží celý plán.
- Dokumentace může být ignorována: Někteří členové týmu se mohou domnívat, že soustředit se na dokumentaci je méně důležité, protože Agile Manifesto upřednostňuje funkční software před důkladnou dokumentací. Agilní týmy by měly dosáhnout ideální rovnováhy mezi dokumentací a dialogem, i když důkladná dokumentace nemůže sama o sobě zaručit úspěch projektu.
- Konečný výstup se může výrazně lišit: Možná neexistovala jasná strategie pro počáteční agilní projekt, a proto se konečný výsledek může výrazně lišit od toho, co se původně očekávalo. Podstatně odlišný konečný výstup může být výsledkem přidání nových iterací založených na změně vstupu klienta, protože Agile je tak přizpůsobivý.
- Časová náročnost vývojářů: Vývojový tým musí být plně oddán projektu, aby byl agilní efektivní. Agilní metoda, která trvá déle než konvenční přístup, vyžaduje neustálou aktivní účast a spolupráci. Navíc to znamená, že se vývojáři musí zavázat k plné délce projektu.
Co je Vodopád?
Nejoblíbenější iterace životního cyklu vývoje systému (SDLC) pro softwarové inženýrství a IT projekty je známá jako „vodopádový přístup“, který sleduje sekvenční lineární postup.
K plánování se příležitostně používá Ganttův diagram, forma sloupcového diagramu, který zobrazuje datum začátku a konce každé zakázky.
Po dokončení jedné z osmi fází vývojový tým postoupí na následující úroveň. Tým se nemůže vrátit do předchozí fáze, aniž by musel restartovat celý postup.
Kromě toho může být nutné, aby klient vyhodnotil a přijal požadavky, než tým postoupí na další úroveň.
Model vodopádu byl vyvinut ve vysoce organizovaném prostředí výrobního a stavebního sektoru, kde mohou být úpravy neúměrně drahé nebo dokonce nemožné.
Technika vodopádu je tak pojmenována, protože má proudit pouze jedním směrem – dolů – stejně jako vodopád. Jeho fáze zahrnují analýzu, zahájení, testování, návrh, budování, nasazení, údržbu a testování.
Vodopádová technika má několik výhod, stejně jako každá jiná strategie. Jedním z nich je, že fáze plánování a návrhu projektu jsou lépe zavedené.
Zákazníci a vývojový tým jsou více sladěni, pokud jde o výstupy projektu, zatímco používají vodopádový vývoj softwaru. Vzhledem k tomu, že jste si od začátku vědomi rozsahu projektu, vývoj vodopádu také usnadňuje sledování pokroku.
Proces vodopádu využívá specialisty, vývojáře, analytiky a testery, aby se soustředili na svou práci v projektu, místo aby celý tým zdůrazňoval jeden krok.
Fáze vodopádu
Všech šest kroků vodopádu musí proběhnout jeden po druhém:
- Shromažďování a ukládání požadavků: Měli byste shromáždit důkladné znalosti o tom, co tento projekt v současné době vyžaduje. Existuje několik technik pro sběr těchto dat, včetně rozhovorů, průzkumů a kolaborativního brainstormingu. Potřeby projektu by měly být zřejmé v době, kdy tato fáze skončí, a váš tým by měl obdržet kopii dokumentu s požadavky.
- Návrh systému: Systém je navržen vaším týmem pomocí předem stanovených specifikací. Během této fáze se neprovádí žádné kódování, ale tým nastavuje požadavky na hardware nebo programovací jazyk.
- Implementace: Tato fáze zahrnuje kódování. Data z předchozí fáze používají programátoři k vytvoření použitelného produktu. Kód je často implementován v malých kouscích, které jsou kombinovány na konci jedné fáze nebo na začátku druhé.
- Testování: Produkt může začít testovat po dokončení kódu. Jakékoli problémy jsou pečlivě nalezeny a hlášeny testery. Pokud se objeví závažné problémy, váš projekt se možná bude muset vrátit do první fáze za účelem přehodnocení.
- Dodání/rozmístění: Produkt je v tomto okamžiku dokončen a váš tým odešle výstupy k nasazení nebo vydání.
- Údržba: Klient obdržel produkt a používá jej. Váš tým možná bude muset vyvinout opravy a aktualizace, když se objeví problémy, aby je odstranil. Opět platí, že významné problémy mohou vyžadovat návrat k prvnímu kroku.
Výhody
- Jednoduchá obsluha a správa: Přístup Waterfall je jednoduchý na použití a pochopení, protože každý projekt je zpracován stejným sekvenčním způsobem. Před zahájením projektu Waterfall nemusí tým mít žádné předchozí odborné znalosti nebo školení. Vodopádový přístup je velmi přísný; každá fáze má sadu výstupů a kontrolu, což usnadňuje správu a údržbu.
- Vyžaduje se dobře zdokumentovaná metodika: Dokumentace, kterou vyžaduje metodologie vodopádu, pomáhá objasnit důvody testů a kódu. Kromě toho vytváří papírovou stopu pro případ, že zúčastněné strany chtějí další informace o určité fázi nebo o jakýchkoli budoucích iniciativách.
- Prosazování kázně: Každý krok v projektu vodopádu má začátek a konec, takže je snadné sdělit pokrok zainteresovaným stranám a klientům. Tým může snížit možnost zmeškání termínu tím, že před vytvořením kódu uvede požadavky a design jako první.
Nevýhody
- Může být obtížné shromáždit přesné požadavky: Rozhovor se spotřebiteli a zainteresovanými stranami za účelem zjištění jejich potřeb je jednou z počátečních fází projektu Waterfall. V této rané fázi projektu může být náročné zjistit jejich konkrétní požadavky. Zákazníci se často o svých požadavcích dozvídají v průběhu vývoje projektu, místo aby je předem vyjadřovali.
- Změny se těžko přizpůsobují: Po dokončení fáze nemůže posádka pokračovat v práci. Je velmi těžké a nákladné vrátit se a opravit jej, pokud se během testovací fáze dozví, že funkce chyběla během procesu požadavků.
- Software je poskytován po datu splatnosti: Před zahájením skutečného kódování musí být dokončeny dvě až čtyři fáze projektu. Výsledkem je, že zúčastněné strany uvidí funkční software až na konci životního cyklu.
Co je Scrum?
Jedním z nejoblíbenějších procesních rámců pro uvedení Agile do praxe je Scrum, což je podmnožina Agile.
Jedná se o iterativní paradigma pro řízení tvorby komplexního softwaru a produktů. Sprinty, což jsou iterace s pevnou délkou, které běží jeden až dva týdny, umožňují týmu vydávat software podle pravidelného plánu.
Zainteresované strany a členové týmu se po každém sprintu sejdou, aby prodiskutovali další kroky. Role, odpovědnosti a schůzky ve Scrumu zůstávají konstantní.
Scrum například specifikuje plánování sprintu, denní stand-up, demo sprintu a retrospektivu sprintu jako čtyři rituály, které poskytují strukturu každého sprintu.
Tým bude během každého sprintu využívat vizuální artefakty, jako jsou tabulky úkolů nebo grafy vyhoření, aby ukázal pokrok a získal přírůstkovou zpětnou vazbu.
Ve scrumu tým a vlastník produktu úzce spolupracují, aby identifikovali a upřednostnili funkčnost systému. Dosahují toho vytvořením produktového backlogu, který obsahuje všechny úkoly nezbytné k vytvoření softwaru, který funguje tak, jak má.
Záplaty chyb, nefunkční požadavky a funkce by měly být zahrnuty do fronty. Mezifunkční týmy musí odhadnout a přihlásit se k poskytování softwarových přírůstků během nepřetržitých sprintů, které obvykle trvají 30 dní, jakmile byly stanoveny cíle.
Pouze tým může přidat funkcionalitu do sprintu po potvrzení nevyřízené položky pro tento sprint.
Dodávka příštího sprintu, produktový backlog je posouzen a v případě potřeby upravena jeho priorita a jako součást následujícího sprintu je vybrána následující sada výstupů.
Proces scrumu
- Nevyřízené produkty: Pro objednání položek v produktovém backlogu se sejdou Product Owner a Scrum Team (práce na produktovém backlogu vychází z uživatelských příběhů a požadavků). Produktový backlog je spíše seznamem všech požadovaných funkcí produktu než seznamem úkolů, které je třeba dokončit. Poté vývojový tým vybere úkoly z produktového backlogu, které se mají provést během každého sprintu.
- Plánování sprintu: Před každým sprintem dodá Product Owner týmu na schůzce plánování sprintu hlavní položky v nevyřízeném sprintu. Skupina pak vybere položky z produktového backlogu, které může dokončit během sprintu, a přesune je do backlogu sprintu (což je seznam úkolů, které je třeba ve sprintu dokončit).
- Upřesnění/úprava nevyřízených položek: Aby bylo zajištěno, že backlog bude připraven na následující sprint, tým a produktový vlastník se setkají na konci jednoho sprintu. Tým může odstranit uživatelské příběhy, které již nejsou relevantní, přidat nové, upravit pořadí, ve kterém by měly být řešeny, nebo rozdělit uživatelské příběhy na menší úkoly. Během této „groomingové“ schůzky bude zajištěno, že nevyřízené věci obsahují pouze věci, které jsou relevantní, do hloubky a v souladu s cíli projektu.
- Scrum setkání každý den: Na 15minutovém stand-up setkání zvaném Daily Scrum každý člen týmu diskutuje o svých cílech a jakýchkoliv problémech, které se objevily. Každý den po celou dobu sprintu se tým účastní denního scrumu, který udržuje všechny na úloze.
- Setkání k posouzení sprintut: Tým prezentuje svou práci na schůzce k přezkoumání sprintu na konci každého sprintu. Místo zprávy nebo powerpointové prezentace by toto setkání mělo obsahovat skutečnou ukázku.
- Retrospektivní sprintové setkání: Tým diskutuje o všech úpravách, které je třeba provést v následujícím sprintu, a také o tom, jak dobře pro ně Scrum funguje na konci každého sprintu. Tým může diskutovat o pozitivních a negativních aspektech sprintu a oblastech pro zlepšení.
Výhody
- Více odpovědnosti ze strany týmu: Neexistuje žádný projektový manažer, který by scrum týmu dával pokyny, co a kdy dělat. O práci, která může být dokončena v každém sprintu, rozhoduje tým jako celek. Všichni spolupracují a vzájemně si poskytují ruku, čímž zlepšují týmovou práci a podporují individualitu každého člena týmu.
- Lepší viditelnost a transparentnost projektu: Je méně nedorozumění a nejistoty, protože každý v týmu si je vědom své odpovědnosti díky častým schůzkám vestoje. Tým se může vypořádat s problémy dříve, než se vymknou kontrole, protože problémy jsou zjištěny předem.
- Lepší snížení nákladů: Neustálá komunikace informuje tým o jakýchkoli problémech nebo změnách, jakmile nastanou, což pomáhá šetřit náklady a zlepšovat kvalitu. Menší části funkcí poskytují nepřetržitou zpětnou vazbu a umožňují včasnou opravu chyb dříve, než bude náprava větších chyb příliš drahá.
- Jednoduché přizpůsobení změnám: Je jednodušší vypořádat se a přizpůsobit se změnám, když dochází k častým zpětnovazebním smyčkám a krátkým sprintům. Pro ilustraci, pokud tým během jednoho sprintu narazí na zcela nový uživatelský příběh, může tuto funkci rychle přidat do následujícího sprintu na schůzce k upřesnění nevyřízených záležitostí.
Nevýhody
- Nebezpečí plížení rozsahu: Kvůli chybějícímu stanovenému datu dokončení mohou některé projekty Scrum čelit plížení rozsahu. Zúčastněné strany by mohly být lákány k tomu, aby nadále požadovaly další funkce, pokud nebude stanovena lhůta pro dokončení.
- Špatný Scrum Master může všechno vykolejit: Projektový manažer není totéž co scrum master. Scrum Master musí týmu, na který dohlížejí, věřit a nikdy mu nedávat pokyny. Scrum Master nemá moc nad týmem. Projekt selže, pokud se scrum master pokusí řídit tým.
- Problémy s přesností mohou vyplývat ze špatně zadaných úkolů: Pokud úkoly nejsou jasně specifikovány, nebudou výdaje a plány projektu přesné. Plánování se stává náročným a sprinty mohou trvat déle, než se očekávalo, pokud nejsou definovány počáteční cíle.
- Zkušenosti a odhodlání jsou pro tým nezbytné: Aby byl tým úspěšný, musí být jasně definovány role a povinnosti. Scrum tým vyžaduje členy týmu s technickými dovednostmi, protože neexistují žádné jasně definované role (vše dělají všichni). Tým se také musí zavázat k účasti na každodenních sezeních Scrum a držet spolu po celou dobu trvání projektu.
Agilní versus Scrum
Přestože Agile a Scrum používají stejnou metodologii, existují mezi nimi určité rozdíly. Agile Manifesto nastiňuje soubor principů pro vytváření softwaru prostřednictvím iterativního vývoje.
Scrum je na druhé straně soubor pokynů, které je třeba dodržovat při vývoji agilního softwaru. Agile je koncept, zatímco Scrum je technika pro jeho uvedení do praxe.
Scrum je metoda implementace Agile, proto mají oba mnoho společného. Oba přístupy jsou iterativní, upřednostňují včasné a časté dodávání softwaru a přijímají změny. Podporují také otevřenost a neustálý rozvoj.
Agilní vs vodopád
Rigid vs. flexibilní nejlépe popisuje rozdíly mezi Waterfall procesem a Agile. Zatímco Agile je plynulá a neustále se mění, Waterfall je mnohem přísnější a přísnější metodika.
Tyto další rozdíly mezi nimi jsou následující:
- Agile nevyžaduje lineární přístup, zatímco Waterfall je sekvenční.
- Zatímco potřeby jsou v projektech Waterfall často předdefinovány, v agilních iniciativách se očekává, že se budou měnit a přizpůsobovat.
- Na rozdíl od Agile projekty Waterfall neumožňují provádět úpravy díla, které bylo dokončeno v předchozí fázi.
- Vodopád je organizovaný postup, ve kterém musíte dokončit každý krok, než přejdete k dalšímu. Agile je však flexibilní metodika, která vám umožní pokračovat v projektu svým vlastním tempem.
Agilní vs vodopád vs Scrum
- Vodopád zvyšuje důvěru v to, co bude poskytnuto velmi brzy po jeho naplánování. Agile se spoléhá na osvědčené postupy vývojového prostředí. Zde lze dobře řídit řadu rizik projektu, protože výsledky jsou průběžně vyhodnocovány.
- Waterfall nepředpokládá, že tým a projekt budou sídlit na stejném místě. Zatímco scrum a agile potřebují společné umístění zaměstnanců.
- Agile se zaměřuje na snížení přepracování projektu a podporuje začlenění změn mnohem dříve. Na rozdíl od vodopádu, který reaguje jinak, scrum také umožňuje včasné odhalení změn.
- Kompaktnější plán pro konečný produkt poskytuje agilní a scrum. To vytváří problém se sliby danými kupujícímu. Oproti tomu vodopádová grafika dává klientům a vývojářům lepší dojem z hotového výsledku.
- Každá z těchto technik má sadu nástrojů pro organizaci a simulaci úkolů spojených s jejich tvorbou.
Proč investovat do čističky vzduchu?
Pokud jste postupovali až sem a jste si jisti svými znalostmi o rozdílech mezi procesy Waterfall, Agile a Scrum, měli byste již vědět, která strategie bude pro vás a váš tým nejlepší.
Technika Waterfall, která je pro projekty s určitým rozsahem, časovým rámcem a rozpočtem, může být vaší nejlepší volbou, pokud máte rádi tvrdá pravidla a postupy a zjistíte, že přinášejí jasnost.
Na druhou stranu, pokud vás svoboda a přizpůsobivost, které Agile nabízí, inspiruje, mohlo by to být místo, kam byste měli zaměřit svou pozornost.
Scrum je správná cesta, pokud si přejete trochu disciplíny uvnitř flexibilního rámce.
Tyto přístupy však musíte zvážit ve světle projektu, na kterém pracujete, a vašeho konečného výsledku.
Napsat komentář