Web technology, project, agile, SCRUM, communication

1. TNPW2 2013/2014
Mgr. Lukáš Vacek
lukas.vacek@uhk.cz
Úvodní informace k předmětu

2. „I am still learning“ – Michelangelo (as 87 yo)
2

3. Agenda
•
Obsah předmětu
•
Vstupní předpoklady
•
Podmínky pro zápočet
•
Požadavky na projekt
•
Osnova dokumentace
•
Aktuální informace k předmětu na webu
•
Rady, co se mi nikam nevešly…
3

4. Internet?
• (Skoro) každý ví, co je to Internet! Dokonce i Věra Pohlová 
•
•
•
•
•
Význam Internetu ve společnosti neustále roste
Důležité médium (tisk, rozhlas, televize…)
Vysoká míra interakce s koncovým uživatelem
Komunikační prostředek (informace) a platforma pro poskytování služeb
Flexibilní prostředí (ekosystém) s velmi dynamickým vývojem
(několik let zpátky = internetový středověk)
• Více možností přístupů, různá zařízení, vyšší rychlost (konektivita), 24/7 – odkudkoliv,
kdykoliv!
Infografika: The Evolution of the Web… http://evolutionofweb.appspot.com/
• Exponenciálně roste počet uživatelů a množství dat, která Sítí protečou
4

5. 5
Zdroj Intel

6. Témata přednášek
• Co jsou to webové aplikace?
• Základní přehled používaných technologií, podrobněji
• JavaScript
• PHP
• ASP.NET
• Bezpečnost webových aplikací
• Aktuální trendy
• Cloud computing
• Mobilní aplikace
• XML
• Cílem je navázat tam, kde skončil předmět TNPW1
6

7. Vstupní předpoklady
• Absolvování předmětu TNPW1 (zápočet, zkouška)
• Praktická znalost (X)HTML
• Schopnost používat CSS při definování vizuálních vlastností WWW stránek
• Problematika webových aplikací vás zajímá jako technologie/business
7

8. K čemu je to dobré?
•
•
•
•
•
•
•
Perspektiva ICT – jeden z nejlukrativnějších oborů, rychle se rozvíjí
V kurzu je Internet, mobilní app, systémová integrace, DWH, BD, Java, .NET
Vaše cena na trhu práce bude vyšší, když budete mít potřebné know-how
Chápejte čas a úsilí věnované svému vzdělávání jako INVESTICI!
Vzdělávání absolventů je dnes pro firmy drahé a riskantní
Nikdo si z Vás nesedne na zadek!
V reálném životě to je vždy trochu jinak, než jak si to ve škole představujeme
• Není nic špatného na tom, když něco nevíte nebo neumíte…
špatné je, když s tím nic neděláte!
• Nesvádějte svoji lenost nebo blbost na druhé!
8

9. Podmínky pro zápočet
• Účast na mých cvičeních není povinná! Ostatní cvičící to mohou mít jinak!
• Pro získání zápočtu je třeba odevzdat závěrečný projekt.
• Projekt lze osobně prezentovat v termínech vypsaných v ISITu nebo na cvičeních
kdykoliv v průběhu semestru.
• Součástí projektu bude stručná dokumentace (stačí heslovitě na 1x A4).
9

10. Obecné požadavky na projekt
• Projektem je webová aplikace, vytvořená ve Vámi zvolené technologii
• Součástí projektu bude vhodně zvolená integrace sociálních sítí
• Připravíte si powerpointovou prezentaci a ukážete funkční projekt, který má smysl provozovat
a používat!
• Projekt představíte jako šéfové vývojového týmu:
• O co jde?
• Komu je určen? (cílový uživatel)
• Proč by jej měl uživatel používat? (výhody)
• Porovnáte se s konkurencí (v čem je lepší/horší)
• Kolik MD stála implementace, za kolik je prodáváte?
• Výhled do budoucna (rozvoj, nové funkce, sociální sítě apod.)
• Pokud nejste programátor, někoho si na implementaci sežeňte. Ale budete tomu rozumět a
dokážete odpovědět na moje technické dotazy!
10

11. Technologické požadavky na projekt
• Skriptovací jazyky (PHP a spol.) používejte na projektech povinně v kombinaci s aplikačním
frameworkem (např. Nette, Zend...)!
• Výsledný zdrojový kód stránek bude validní HTML5!
• Aplikace bude fungovat i v mobilním prohlížeči (responsive web design)
• Struktura aplikace, navigace a vzhled stránek budou respektovat aspoň základní pravidla
pro přístupnost a použitelnost (znáte to z TNPW1!)
• Veškerá vizuální nastavení (layout, fonty, barvy apod.) budou definována v CSS (včetně
formátování pro tisk)
• Aplikační data budou uložena v databázi na serveru
• Všechny datové vstupy od uživatelů budou odpovídajícím způsobem ošetřeny (na straně klienta
je to vhodné, na straně serveru povinné), včetně zabezpečení proti opakovanému zápisu dat přes
obnovení stránky apod.
• V projektu bude vhodně využita technologie XML (např. RSS kanál s novinkami, export/import
dat apod.), pokud to má smysl
• Výjimky jsou přípustné, pokud je dokážete obhájit!
11

12. Osnova dokumentace
•
•
•
•
•
•
•
Cíl projektu
Jméno autora!
URL adresa projektu
Popis řešení
Popis použitých technologií
Popis zabezpečení
Odhadovaná pracnost a cena projektu
• K prezentaci si přineste aspoň jeden výtisk! Neposílejte mi osnovu mailem!
12

13. Aktuální informace k předmětu na webu
Na serveru http://tnpw2.webnode.cz najdete
•
•
•
•
•
Informace k předmětu TNPW2
Přednášky ke stažení (ve formátu PDF)
Zdrojové kódy ukázkových příkladů
Seznam doporučené literatury
Odkazy na Internetu
13

14. Rady, co se mi nikam nevešly…

15. Projekt… KDO je tady ŠÉF?
• Jednoduchá odpověď… ten kdo to platí! Obvykle business 
• Zákazník není váš soupeř, ale spoluhráč!
• Při rozhodování používejte ověřitelné argumenty (výpočet, porovnání)
• Cílem je úspěšná implementace projektu (s ohledem na podmínky)
• Potřeby zákazníka
• Harmonogram
• Peníze
• Kapacity (know-how)
• Hledejte nejjednodušší řešení požadavků!
• Nehledáme dokonalost, čistotu… „Done is better than perfect.“
• Udržitelnost v. neudržitelnost!
15

16. Komunikace na projektu – I.
• Komunikace je králem!
• Efektivní komunikace je klíčem k úspěšnému projektu
• Musíte být schopni vysvětlit své návrhy/nápady pokud možno stručně –
stostránkový dokument (skoro) nikdo nečte! Hlavně ne zákazník 
• Nebojte se používat názorné obrázky, buďte srozumitelní
• Vždy musíte vědět, kdo je vaše publikum… komu prezentujete/vysvětlujete
• Prezentujte realitu (funkce, stav projektu), nestavte vzdušné zámky (= zklamání)
• Co zákazník potřebuje (očekává)? Konkretizujte (pro různé role!)
• Pozor! Ne vždy je splnění všech zadaných požadavků možné
• Odporující si požadavky, termíny, cena, technologie, další omezení…
• Neodkládejte problémy (o kterých víte) na později!
16

17. Komunikace na projektu – II.
• Když vám něco (cokoliv) není jasné, zeptejte se!
• Průběžná zpětná vazba od zadavatele!
• Rozhodování o cílech probíhá na strategické, taktické a operační úrovni!
• Důležité je jednoznačné rozdělení zodpovědnosti na projektu (kdo-co?)
• Nenechte se vydírat!
• Žádný zákazník není důležitější než dobrý produkt (opakované řešení)
• Přínos pro jednoho zákazníka může být komplikací pro ostatní >> problém
• Pozor na statistiku (ankety… vědí lidé, o čem hlasují?)
• Naučte se říkat NE. Žádné „možná“ nebo „později“, prostě řekněte NE!
• Nebojte se! Nezapomeňte na to, že úplně KAŽDÝ MÁ SVÉHO ŠÉFA 
17

18. Projektové požadavky
• Motto: „Když něco nemůžete změřit, nemůžete to ani řídit“ – Peter Drucker
• Požadavky na informační systém určuje business!
• Zohlednit potřeby zákazníka, jejich pokrytí funkcionalitou systému
• Měřit přínos jednotlivých požadavků (ROI, TCO) – vyplatí se to, za jakých podmínek?
• Návrh architektury musí být v rovnováze – business/technologie – z krátkodobého
i dlouhodobého hlediska!
• Náklady ovlivňují zvolené technologické řešení
• Důležitá je zpětná vazba od businessu v průběhu všech etap řešení
• Kvalita výstupu je přímo úměrná kvalitě vstupních informací
• Implementace řešení, odhady pracnosti, náklady, termíny, pokrytí požadavků
• Kvantifikujte požadavky
• Obecné pojmy (např. rychle, flexibilně, rozšířitelně) nemají jednoznačný výklad
• Upřesněte, co konkrétní požadavek znamená? (např. Průměrná doba odezvy je… )
18

19. Příklady obvyklých požadavků a potřeb uživatelů
• Koncový uživatel – intuitivní a správné chováním, výkon, spolehlivost,
použitelnost, dostupnost a bezpečnost
• Administrátor – přehlednost chování, jednoduchost správy, nástroje pro
monitorování provozu
• Pracovník businessu – konkurenceschopné funkce, co nejkratší dobu pro
uvedení do provozu, porovnání s konkurenčními produkty/službami a cenou
• Zákazník – zajímá ho cena, stabilita a termín dodání
• Vývojář – očekává jasně specifikované požadavky, a jednoduchý, konzistentní
přístup k dobře zdokumentovanému návrhu, snadné provádění změn
• Projektový manažer – vyžaduje předvídatelnost při sledování projektu, termínů,
rozpočtů a možnost produktivního využití zdrojů
• Zdroj: Monson-Haefel, Richard – 97 klíčových znalostí softwarového architekta
19

20. Projektová dokumentace
• Nepodceňovat!
• Často vychází z metodiky nebo z požadavků zákazníka
• Místo pro důležité informace o projektu… požadavky, design, protokoly,
provozní příručky apod.
• Nespoléhejte na lidskou paměť, dokumentace je spolehlivější
• Dokumentaci ukládat na jedno místo… do projektové knihovny!
• Pečlivě vše dokumentujte (požadavky i návrh architektury)
• Co, kdo, kdy, proč, jaká omezení?
• Všechny požadavky jednoznačně identifikujte (číslování!)
• Jedině s dokumentací lze rozhodnout, je-li dodávané řešení v souladu
s požadavky
• Kvalitní dokumentace zjednodušuje provoz a případný další rozvoj systému
20

21. Projektové metodiky
• Různé možnosti, asi žádná není úplně 100% univerzální
• Kritéria pro výběr: znalost, zkušenost, flexibilita, norma/zákon
• Požadovaná metodika je často v zadávací dokumentaci
• Pokud si nějakou vyberete pro projekt, držte se ji
• Každá metodika se přizpůsobuje projektu (FTFP?) a lidem! Chce to čas!
• Některé jsou velmi robustní, jiné jsou jednoduché
• Podporují snahu MNG mít správné lidi ve správnou chvíli na správném místě
• Přehled metodik… Wiki
21

22. Agilní metodiky
• Jsou hodně trendy (konstatování)
•
•
•
•
•
•
•
Extrémní programování (XP)
Scrum
Vývoj řízený vlastnostmi (FDD – Feature Driven Development)
Lean software development
Vývoj řízený testy (TDD – Test Driven Development)
Crystal metodiky (Alistair Cockburn)
Sprint method (Jiří Knesl)
22

23. Agilní metodiky – SCRUM (Role I.)
• http://www.zdrojak.cz/clanky/agilni-vyvoj-scrum/
• Product owner (pigs)
• Zastupuje zákazníka (business, který projekt platí)
• Určuje priority jednotlivých požadavků, implementační detaily, co bude ve kterém sprintu...
• Team member (pigs)
• Implementuje produkt/projekt, různé role (analýza, programování, testování apod.)
• Zodpovídá za chyby nebo úspěch svých úkolů
• Sám si organizuje práci na přidělených úkolech
• Scrum master (pigs)
•
•
•
•
Odstiňuje vývojáře od problémů okolního světa (zajišťuje funkční HW, SW licence…)
Učí, implementuje scrum metodiky
Kontroluje, že jsou realizovány správně
Zajišťuje potřebnou dokumentaci (Backlog, harmonogram, plán iterací, alokace kapacit...)
23

24. Agilní metodiky – SCRUM (Role II.)
• Stakeholders (chickens)
• Lidé od zákazníka, testeři, připomínky zvenčí
• Managers (chickens)
• Lidé ovlivňující prostředí projektu, nejsou pigs
• Nezapomeňte na ně, i když stojí jakoby mimo implementaci
24

25. Agilní metodiky – SCRUM (Sprint)
• Projekt je rozdělen do jednotlivých etap/iterací (sprintů)
• Plán sprintu… Co se bude dělat? A jak se to bude dělat?
• Jeden sprint cca 2-4 týdny (může být i kratší)
• Důležitá pravidla!
• V průběhu sprintu nejsou akceptovány žádné změny!
• Každý sprint musí být naplánován před svým zahájením!
• Často probíhá tzv. nultá iterace – řešení nějakého jednoduchého nebo naopak
důležitého úkolu v rámci týmu, resp. školení, příprava prostředí apod.
25

26. Agilní metodiky – SCRUM (Product backlog)
• Seznam všech známých požadavků (tasks, tickets...) na projekt/produkt
• Každý požadavek má stanovenou prioritu (určuje ji Product owner a SCRUM
master)
• Všichni členové týmu mají přístup!
• V rámci sprintu má požadavek svého vlastníka (zodpovídá za implementaci,
výsledek)
• Pokud člen týmu stihne přidělené úkoly v rámci sprintu rychleji, může dostat
z backlogu další (po dohodě se SCRUM masterem!)
26

27. Agilní metodiky – SCRUM (Scrum meeting)
• Daily SCRUM (povinně!)
•
•
•
•
•
Každý den ráno schůzka všech členů týmu, cca 15 minut
Co jste udělali od poslední schůzky?
Co máte naplánováno do další schůzky?
Jsou nějaké problémy, na které jste narazili? Kdo je může pomoct vyřešit?
Organizuje a řádně dokumentuje SCRUM master!
• SCRUM review meeting (povinně!)
• Probíhá na konci každé iterace (sprintu)
• Ukázka toho, co už je hotové
• Zpětná vazba
• Retrospektivní SCRUM meeting (doporučeno)
• Obvykle jen členové týmu a SCRUM master
• Získané zkušenosti, problémy, co a jak zlepšit?
27

28. Agilní metodiky – SCRUM (Doporučení)
•
•
•
•
•
•
•
Používejte zdravý rozum!
Implementace SCRUM metodiky potřebuje čas!
Není to univerzální kráječ (řešení každého problému)!
Je to přístup k vývoji software
Je rychlý a flexibilní
Je orientován na závazky (osobní zodpovědnost)
Je založen na srozumitelnosti, kontrole a přizpůsobení
• Pozor na FTFP projekty!
28

29. Design aplikace (Co je dobré vědět?)
• Čistota návrhu nikdy nesmí být na úkor použitelnosti nebo výkonu!
• Používejte vhodné návrhové vzory a doporučení (SOLID, GRASP …)
• Udělejte řešení co nejjednodušší (KISS)
• Příliš mnoho uživatelských konfigurací vede ke složitosti (a k problémům)
• Neopakujte se (DRY)
• Implementujte jen ty funkce, které jsou skutečně potřeba (YAGNI)
• Rozsah práce (bude to rychle) není důvodem pro implementaci funkce!
• I malá (nepromyšlená) změna může mít velký dopad
• Spousta špatných nápadů má rychlou/levnou implementaci 
29

30. Zdrojové kódy
• Ukládat na jednom místě v repository (Git, TFS…)
• Definovat programátorské konvence
• Verzovat kód, používat tzv. labels
• Používat komentáře (lepší pochopení geniality autora kódu )
• Vždy dodržovat pravidlo GET – BUILD – RUN!
30

31. Testování
• Testujte všechno, co jde (funkční, zátěžové, integrační, unit…)
• Pokud se vám vyplatí testy automatizovat, udělejte to (hodně iterací, rozsáhlé
systémy, hodně dodavatelů, refaktorizace…)
• Lidský faktor selhává, automatický test proběhne vždy stejně
• Automatické testy lze dobře propojit s ukládáním změn do repository
• S automatickými testy souvisí přístup Continuous integration
• K tématu… Robert Dresler: Snižování rizikovosti softwarových projektů
31