WEBOV APLIKACE FZE PLNOVN WATERFALL NEBO AGILE Waterfall
WEBOVÁ APLIKACE FÁZE PLÁNOVÁNÍ
WATERFALL NEBO AGILE • Waterfall je model lineárního životního cyklu, zatímco Agile je nepřetržitá iterace vývoje a testování v procesu vývoje softwaru. • Agilní technika umožňuje změny v požadavku na vývoj projektu, zatímco Waterfall nemá možnost změny požadavků, jakmile se začne vývoj projektu
• Jednotlivci a interakce před procesy a nástroji AGILNÍ MANIFEST • Fungující software před vyčerpávající dokumentací • Spolupráce se zákazníkem před vyjednáváním o smlouvě • Reagování na změny před dodržováním plánu
HLAVNÍ PRINCIPY • Nejvyšší prioritou je vyhovět zákazníkovi častým a průběžným dodáváním hodnotného softwaru. • Vítáme změny v požadavcích, a to i v pozdějších fázích vývoje. • Dodáváme fungující software v intervalech týdnů až měsíců, s preferencí kratší periody. • Nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace. • Hlavním měřítkem pokroku je fungující software. • Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu. • Jednoduchost – umění maximalizovat množství nevykonané práce – je klíčová. • Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů. • Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti.
ŽIVOTNÍ CYKLUS VÝVOJE WEBOVÉ APLIKACE • Je složen z fází: • Plánování • Sběr a analýza požadavků • Návrh (včetně návrhu databáze) • Vytvoření prototypu • Implementace • Testování • Provozní údržba
PROJEKT • Zadavatelé (Stakeholders) • Vlastník produktu (Product Owner – PO) • Vývojový tým (Agile team) • Team leader • SCRUM master - SM
PLÁNOVÁNÍ • Začínáme definicí produktu (aplikace). • Přesouváme se k hlavním částem. • Vymezíme malé jednotlivé kroky, které proměníme v akce na nichž můžeme začít pracovat. • Řešení těchto akcí nám umožní vytvoření zadaného produktu.
DEFINOVÁNÍ CÍLŮ APLIKACE • Abychom mohli definovat cíle aplikace, budeme postupovat od obecných cílů zpět směrem ke konkrétním akcím, na kterých lze pracovat. • Na konci bychom měli mít seznam akcí, které můžeme podniknout, abychom zahájili cestu vytváření aplikace. Výchozí určení aplikace - např. : • Aplikace pro online testy
VÝCHOZÍ URČENÍ ROZDĚLÍME NA HLAVNÍ CÍLE • Spravovat testy • … • Notifikace uživateli • Zobrazit test uživateli • … • Vyhodnocovat testy • …
KONKRETIZACE HLAVNÍCH CÍLŮ NA KROKY • Abychom mohli přejít od plánování k návrhu je potřeba jednotlivé hlavní cíle udělat tzv. činitelné – tedy převést na malé kroky. • Hlavní cíl: Zobrazit test uživateli • Zobrazit název, popis, časovou dotaci • Zobrazit testové otázky a testové odpovědi • Zobrazit odpočet zbývajícího času
SCRUM
Vyjádření kroku jednou větou, formou KDO, CO a PROČ STORY • KDO – pro koho story dělám • CO – co je obsahem story • PROČ – proč story dělám • Příklad: Jako uživatel, chci mít možnost obnovit si heslo, protože ho po čase zapomenu. • Story je vhodné rozdělit po uživatelských vlastnostech na user story. • Po přečtení všech story, by si člověk měl udělat o produktu jasnou představu. • Story pointy – hodnoty určující složitost story ve vzájemném porovnání. • Stupnice: • Číselné
EPIC STORY • Logické seskupení více story. • Více méně koresponduje s hlavními cíli, ale může vznikat i samostatně a následně se rozdělí na story. Příklad: • Zobrazení testu uživateli.
• Představují vývojové úkoly k dosažení jednotlivých story. TASKY • Obecně ne více než jednodenní úkoly. • Na základě tasků, můžeme vytvořit odhad času pro jednotlivé story. Příklad STORY: Jako uživatel, chci mít možnost obnovit si heslo, protože ho po čase zapomenu. • Tasky: • Design formuláře pro obnovení hesla. • Implementace do HTML a CSS. • Validace zadaného loginu/emailu. • Vyhledání uživatele podle loginu v databázi. • Zaslání hesla na email uživatele. • Ošetření chybových stavů. • Neexistující uživatel. • Nedoručení emailu. • Přesměrování na cílovou stránku.
BACKLOG • Jednorozměrný seřazený seznam všech story. • O každých dvou story lze říci, která má větší prioritu. • Story řadí PO na základě produktové priority, jejich ohodnocení a rychlosti týmu.
SPRINT (ITERACE) KRÁTKÝ ČASOVÝ ÚSEK, KDY TÝM PRACUJE NA STANOVENÉM MNOŽSTVÍ STORY A JEJICH TASKŮ.
• Společná aktivita celého týmu. • Výběr položek: PO – SM – Team. • 2 základní otázky: PLÁNOVÁNÍ SPRINTU 1. Jaká práce se vytvoří? 2. Jak bude práce označena za hotovou? • Stavy tasků: • Nevyřízen (To. Do) • Probíhá (In Progress) • Hotovo (Done) • Po dokončení sprintu probíhá předvedení výsledků zúčastněným. • Předem určená doba sprintu – např. týden.
SCRUMBOARD • Tabule s přehledem aktuální činnosti ve sprintu. • Řádek určuje story a obsahuje jednotlivé tasky. • Sloupec určuje stav. • Postupuje od prioritních story (ty nahoře) • Ideální varianta nástěnná tabule a sdílené aplikace.
VYTVOŘTE SI VÁŠ SCRUMBOARD • Váš team si sám vybere variantu podle preferencí. • Existují free online tools, zkuste najít ten Váš. • Například nástroj TRELLO.
SCHŮZKY Estimation – hrubé ohodnocení story Grooming – přesnější ohodnocení story Zavazování – naplánování story do sprintu Analýza – technické rozpracování nového sprintu Standup – každodenní informativní schůzka Review – předvedení novinek zákazníkovi Retrospektiva – zhodnocení spolupráce
ESTIMATION • Hrubé porovnání velkého balíku story. • Každé story jsou přiřazeny story pointy. • Jde o hrubý odhad, aby PO dostal představu o plánu. • Nepravidelná
GROOMING • Nejdůležitější schůzka procesu plánování. • PO přednese jednotlivé story. • Tým položí otázky k ujasnění zadání. • Pokud je nutné, tým na tomto základě tvoří user stories. • Pravidelná
ZAVAZOVÁNÍ A ANALÝZA • PO předkládá požadované story, které by chtěl v dalším sprintu vykonat. • Tým vyhodnocuje proveditelnost. • Vývojový tým (už bez PO) se domluví na technických detailech implementace. • Vývojový tým si rozdělí jednotlivé úlohy. • Začátek sprintu
• Každodenní schůzka k pravidelné informovanosti celého týmu. • Neměla by trvat dlouho a proto se stojí. STANDUP • Každý by měl: • Říct na čem pracoval od minulého standupu • Říct na čem bude pracovat nyní • Pokud má problém, požádat o pomoc • Pomoci ostatním, pokud mají problém
REVIEW • Předvedení nově implementovaných story zákazníkovi. • Předvádí se jen hotové story. • Tolerovány jsou jen drobné bugy. • Na konci sprintu
RETROSPEKTIVA • Nejdůležitější schůzka vzhledem k fungování týmu. • Prostor pro tým, aby si řekl: • Co se povedlo • Co by chtělo zlepšit • Na konci sprintu
TO BE CONTINUED
- Slides: 30