Zlepšujeme se? Source: Standish Group, 2004 Third Quarter Research Report, CHAOS Research Results Překročení rozpočtu klesá 200% 150% 100% 50% 0% 1994.

Prezentace na téma: "Zlepšujeme se? Source: Standish Group, 2004 Third Quarter Research Report, CHAOS Research Results Překročení rozpočtu klesá 200% 150% 100% 50% 0% 1994."— Transkript prezentace:

1

2 Zlepšujeme se? Source: Standish Group, 2004 Third Quarter Research Report, CHAOS Research Results Překročení rozpočtu klesá 200% 150% 100% 50% 0% 1994 1996 1998 2000 2002 2004 Procent překročení Dobrá zpráva Za neúspěch teď platíme méně

3 Forrester definuje ALM jako: Koordinaci aktivit životního cyklu aplikace včetně požadavků, modelování, vývoje, sestavení a testovaní pomocí Vynucení procesů, které pokrývají tyto aktivity Řízení vztahů mezi výstupy z vývoje, které tyto aktivity používají nebo produkují Sledování a reportování celkových metrik softwarového projektu

4 Vyhodnoťte fungování vaší organizace Identifikujte hlavní nedostatky Prioritizujte oblasti ke zlepšení Zavádějte nové přístupy postupně, vyhodnocujte zkušenosti, postupujte projekt od projektu

5

6 Nástroje VSTS jsou vytvořeny k podpoře hodnotocentrického přístupu Obsah dnešního semináře není vázán na MS produkty a nástroje Jsou použity jako ilustrace přístupu http://www.teamsystem.cz

7 Přístupy, které s vámi chceme sdílet, jsou vyzkoušené a fungují: Neříkáme, že za všech podmínek Pokud si myslíte, že u vás nebudou fungovat, může to být: Pravda Pocit „to se nezaplatí“ – prvotní náklady vs. průběžné dlouhodobé přínosy Obava ze změny...

8 Budeme analýzu dělit na menší a menší části tak dlouho, až bude rozdělena na elementární kroky, ve kterých „nelze“ udělat chybu. Poté implementujeme. Přístup odráží vysokou cenu vytvoření verze v dřívějších dobách Stále má své zastánce, ale odumírá

9 Řešení budeme vytvářet v definovaných krocích (iteracích), abychom snížili rizika a měřili postup. Jednotlivé kroky budeme řídit striktním procesem. Iterace jsou umožněny nízkou cenou za vytvoření verze (důsledek komfortu vývojáře) Přiznává „právo dělat chyby“ Vhodné pro projekty s velkou mírou rizika, ale dosti nákladné Představitelé: RUP (Rational Unified Process) – nejznámnější MSF (Microsoft Solution Framework)

10

11 Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan www.agilemanifesto.org Minimalizuje byrokracii a formálnost Snížení ceny je vyváženo zvýšením rizik Představitelé: Fundamentalisté – Extreme Programming (XP), Continuous Integration (CI), Test-Driven Development (TDD),... Pragmatici – MSF for Agile Dev. (MSF4AD), Feature Driven Development (FDD), SCRUM,...

12

13 Stavebnictví Rizika designu jsou nízká Náklady na design jsou relativně malé ve srovnání s náklady na stavbu Zřídka se objeví příležitost pro postupné dodání hodnoty Rizika designu jsou nízká Náklady na design jsou relativně malé ve srovnání s náklady na stavbu Zřídka se objeví příležitost pro postupné dodání hodnoty Tvorba software Design se může vyvíjet jak získáváme další informace Náklady na design a stavbu jsou skoro stejné Je žádoucí dodávat přidanou hodnotu postupně Design se může vyvíjet jak získáváme další informace Náklady na design a stavbu jsou skoro stejné Je žádoucí dodávat přidanou hodnotu postupně

14 Plan Task 1 Task 4 Task 3 Task 2 HodnotocentrickyÚkolocentricky V tradičních projektech rozdělujeme plány do pracovních položek ty jsou postupně plněny Hodnotocentrické metody dodávají v každé iteraci zákazníkovi další hodnotu

15 ÚkolocentrickyHodnotocentricky Plánovací a změnové procesy Naplánujeme a navrhneme správně hned na začátku Změna je běžná, pracujeme s ní Primární měření Ukončení úkoluVytvořená hodnota pro zákazníka Definice kvality Shoda se specifikacíHodnota pro zákazníka Akceptace odchylek Stanovení nových úkolů a jejich deterministický odhad Odchylky jsou součástí procesního toku Meziprodukty Nevyhnutná je dokumentace, modely, atd. Jen tolik abychom zamezili nejistotě Přístup k řešení problémů Čas, zdroje, funkčnost a kvalitaNalezneme a odstraníme úzká místa Přístup k důvěře Sledování a měření výkonu vůči plánu Hrdost na profesionalitu a týmovou spolupráci

16 Zvyšujeme návratnost investic (ROI) zaměřením se na stálý tok hodnot Získáváme spolehlivé výsledky zapojením zákazníků v pravidelných intervalech Očekáváme nejistotu a připravujeme se na ní (pomocí iterace, předvídání a adaptace) Umožníme kreativitu a inovaci tím, že uznáme individualitu jako zdroj hodnot Zvýšíme výkon pomocí skupinové odpovědnosti Zvýšíme efektivitu a spolehlivost pomocí specifických strategií, procesů a praktik

17 Tok je základem pro hodnotocentrické myšlení a praktiky Fungující software a hotová dokumentace jsou produkty, které se počítají Hodnotu software pro zákazníky pravidelně měříme Dodáváme zákazníkovi fungující software v pravidelných intervalech Měříme spokojenost zákazníka v pravidelných intervalech

18 Nárůst v oblasti Resolved indikuje úzké hrdlo v testování Sklon křivky Closed do konce iterace nedosáhne výšky naplánované práce

19 Manuální sledování postupu projektu je neefektivní Manuální procesy a oddělené nástroje vedou k nesprávným informacím Promrháme příliš mnoho času a úsilí Nástroje potřebujeme abychom Snížili náklady Vytvořili automatizovanou podporu procesů Měli auditovatelné změnové řízení (legislativa apod.)

20 Jediná databáze pracovních položek Pro sledování naplánované, aktivní a ukončené práce Většinu dat získáme automaticky Součást provádění denních aktivit Pracovní položky Metriky Zdrojový kód Excel / Project Reporty IDE Instrumentace denních aktivit

21

22 Každý projekt by měl mít vizi Měla by být srozumitelná pro všechny zúčastněné Měla by zahrnovat důvod, proč se projekt dělá Měla by být jasná a stručná Vize je důležitá, protože pomáhá definovat cíl a soustředit se na jeho dosažení Pro velké strategické projekty by měla mít formu krátké obhajoby („elevator pitch“) Pro adaptivní projekty popis a důvod změny

23 Všechny požadavky typicky nelze zachytit předem Snaha o to může vést k “analýze-paralýze” „Analýzu máme hotovou již 3 roky...“ Hodnotocentrický přístup předem počítá s tím, že se požadavky „podléhají zkáze“: Mění se prostředí, pro které projekt vytváříme Znalosti zastarávají, objevují se nová fakta Kapacita týmu zvládat požadavky je limitována Každá iterace přináší poznatky ovlivňující příští iterace

24 Detailnost Pochopitelnos t Ideálně popsané požadavky Leffingwell and Widrig, Managing Software Requirements (Boston, MA: Addison-Wesley, 2000), 273

25 Funkční Popisují, co by měl produkt umět Ostatní (Quality of Service) Popisují okolnosti a kvality fungování Např. výkonnost, škálovatelnost, bezpečnost, udržovatelnost, použitelnost,... Je nutné zaznamenat oba dva typy Pokud jsou QoS požadavky splněny, nikdo o nich ani neví, pokud ne, je velký problém

26 Zastupuje skupinu uživatelů Reprezentována jedním členem Dobrá persona je snadno zapamatovatelná, plastická Popis persony zahrnuje její návyky, pracovní prostředí, motivaci, chování,... Persona by měla být užitečnou pomůckou při rozhodování Persona by měla mít zapamatovatelné jméno

27 Persona Kroky potřebné k dosažení cíle Scénář Cíl Začněte cílem Popište kroky k dosažení cíle: Osoba udělá..., aplikace zareaguje... Používejte jazyk persony, pro kterou scénář je Alternativní cesty, výjimky,... dopisujte až později

28 Zákazník nadšen Zákazník znechucen Vlastnost chybí Vlastnost plně implementována Uspokojující scénář (satisfier) Potěšující scénář (exciter) Nezbytnosti (dissatisfier)

29 Různá hlediska: Podle Kanovy analýzy Podle míry rizika Podle pracnosti Podle persony, pro kterou jsou určeny Volte jednoduchost (např. A,B,C) Klasifikace vám pomůže v rozhodování, které scénáře kdy implementovat

30 V počátečních iteracích se snažte implementovat scénáře s vysokou hodnotou Věnujte obzvláštní pozornost scénářům a QoS, které jsou „nezbytnosti“ Nejprve se soustřeďte na maximální srozumitelnost scénáře Během iterace můžete scénáře upřesňovat a rozvíjet, soustředit se na přesnost a úplnost V pozdějších iteracích přidávejte další scénáře

31

32 Jeho funkce je založena na několika předpokladech: Procesy běží hladce Produktivita zdrojů je rovnoměrně rozdělena Malý rozptyl v efektivitě provádění úloh V systému nejsou žádné nevyužité kapacity

33 Klíčová je identifikace příčin rozptylu pro rozlišení projektů, které jsou a nejsou pod kontrolou Vyhýbá se používání preskriptivních metrik Počet úloh dokončených v čase Počet nalezených chyb Počet vyúčtovaných pracovních hodin Používání týmových metrik, raději než individuálních Využívání vícerozměrných pohledů, kombinace

34 Uvažte, co může být výsledkem, když: Hodnotíte vývojáře na základě počtu napsaných řádků kódu Hodnotíte vývojáře na základě počtu opravených chyb Odměníte tým za dosažení 90% pokrytí kódu testy Měříte testery na základě počtu objevených chyb

35 Výkonnost Čas Sledované metriky Skutečný výkon Source: Robert D Austin, Measuring and Managing Performance in Organizations, 1996

36 Metriky nejsou cíle, jsou pouze aproximací cílů Pozor na zploštění pohledu Pokud měříte pouze podle jedné dimenze, nezbytně dosáhnete změny chování lidí Získávání dat z více zdrojů je bez moderních nástrojů velmi pracné Metriky mohou vytvářet nesprávnou motivaci Měřte tým za jeho výsledky, ne za jeho metriky Očekávejte rozptyl způsobený běžnými příčinami

37 Plánovan á práce Hotová práce

38

39

40

41

42 Všechny šťastné rodiny jsou si podobné; každá nešťastná rodina je nešťastná svým vlastním způsobem. L.N.Tolstoj, Anna Karenina Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему.

43 Pomalý postup vpřed spojený se škrty v dané iteraci, ale přesunů do dalších iterací není dost Neustálý postup vpřed, ale je příliš pomalý

44 Nárůst šířky pásma pro implementované, ale neuzavřené scénáře znamená buď nedostatek testerů anebo nízkou kvalitu implementace

45 Roste počet reaktivovaných chyb vyžadujících opakovaný zásah vývojáře i testera

46 Klesá pokrytí kódu testy Vysoké množství změn v kódu Klesá podíl úspěšných testů, stoupá podíl nerozhodných

47 “Temná hmota“, která nafukuje rozsah iterace Vytlačování plánované práce

48 Počet nalézaných chyb je dlouhodobě větší než opravených

49 Vysoká míra variability v denních přírůstcích značí nekonzistentní rozdělení práce a brání efektivnímu měření

50 Náhlý pokles v toku hodnoty znamená pravděpodobně odliv zdrojů na jinou práci

51

52 Úkolem architekta je přeměnit požadavky (zejména ne-funkční) v návrh aplikace Dobrá architektura je dobře srozumitelná, použitelná a dlouhodobě udržitelná Možnosti zapojení architektury Cílená, předem vytvářená, nezávislá na implementaci NEBO Vycházející z implementace a pružně reagující na nové poznatky a změny Cílená, předem vytvářená, nezávislá na implementaci NEBO Vycházející z implementace a pružně reagující na nové poznatky a změny Formální přístup Agilní přístup

53 Zachycují důležité vlastnosti produktu, které nesouvisí s funkční specifikací Quality of Service, non-functional,... Pokud je nepodchytíte a nezahrnete do návrhu aplikace, důsledkem bude zaručeně nespokojenost zákazníka Příklady: Bezpečnost Výkonnost, škálovatelnost Spravovatelnost Použitelnost Soulad s prostředím zákazníka

54 Architektura musí být explicitně dána, ale může vyvstat až z implementace Základní (baseline) architektura: Podmnožina celého systému navržená tak, aby ověřila správnost implementace nejdůležitějších scénářů Měla by být vždy spustitelná (prototyp) Důležitá je hlavně dodaná hodnota: Úlohou je snížit technologická rizika Zajistit splnění požadavků v budoucím produktu

55 Pro vývojáře: Stabilní platforma s nastavenou infrastrukturou, protokoly,... Pro provoz: Předvídatelnost a plánování pro nasazení a správu aplikace

56 Hodnotocentrické principy vedou k průběžnému učení se a aplikaci zkušeností získaných v předchozích iteracích Lepší návrh architektury zpravidla vyvstává až během vytváření systému Důležité je porozumět rozdílu mezi rozhodnutími, která musí padnout okamžitě a těmi, která mohou být učiněna až během pozdějších iterací Vytvořte základních architekturu, kterou potom můžete upřesňovat v pozdějších iteracích Shora dolů Zdola nahoru Požadavky, Qos, omezení Validace prostřednictvím spustitelných částí aplikace

57

58 Soustřeďte se na aktivity přinášející hodnotu, kterou je zákazník schopen ocenit Používejte techniky pro zvýšení kvality kódu od začátku vývoje Soustřeďte se na zlepšení procesů a činností, o nichž víte, že produkují kód špatné kvality Používejte nástroje pro zvýšení kvality kódu během celého vývoje

59 Špatně pochopené, špatně napsané, zastaralé požadavky Chyby vývojářů Špatně fungující zpětná vazba z testování „Rozjetí“ verzí (version skew) Míchání verzovaných a neverzovaných položek (konfigurace, databáze,...) Nedostatečná průhlednost vývojového procesu Např. reporty emailem

60 Okamžitá zpětná vazba o správnosti kódu usnadňuje vývoj navazujícího kódu Časté testování umožňuje sledovat metriky, jež jsou dobrým ukazatelem zdraví vývojového procesu Umožňuje včas odhalovat chyby vnesené novým vývojem, refaktorizací, opravou jiné chyby (regrese),...

61 Test Driven Development (TDD): Lze považovat za lehce extermistické pojetí Nejprve píšete selhávající testovací případy podle požadavků a teprve poté implementujete funkčnost Pomáhá dobrému porozumění požadavků Zachycuje nejasnosti a chyby včas: Dříve než se napíše nesprávný kód Zaručuje postup vpřed v měřitelných krocích Zabraňuje psaní kódu, který není nutný Zvyšuje celkovou kvalitu kódu

62 Statická analýza: Manuální nebo automatizovaná kontrola kódu pomáhá odhalit chyby vývojáře Měla by se provádět v definovaných fázích procesu vývoje: Před provedením check-inu Při automatickém buildu Dynamická analýza: Profilování běžícího kódu k odhalení výkonnostních slabých míst Pragmaticky – často se používá až při objevení problému

63 Databáze je spravována stejným způsobem jako kód „Offline“ vývoj databázového schématu „Master“ schématu databáze je v definičních souborech Změny nemají okamžitý efekt, provádí se explicitní nasazení změn do databáze Podpora generování dat a spouštění testů jednotek nad databázovou logikou Databáze využívá jednotný proces pro kvalitu

64 Bez automatického buildu není správa verzí v systému kompletní... Systém buildů by měl minimálně: Automaticky vytvořit vytvářený produkt Poskytnout maximum reálných a možných kontrol kvality Analýza kódu Spuštění testů (BVT, build verification tests)

65 BVT jsou testy běžící jako součást automatického buildu BVT odhalí, zda je build zralý na uvolnění k funkčnímu testování BVT by měly zahrnovat Veškeré automatizované funkční testy, které nevyžadují manuální zásah Většina testů jednotek – všechny, které je realistické pouštět automatizovaně Důležitou metrikou BVT je pokrytí kódu testy

66 Integrace systému správy změn a systému pro sledování postupu práce (scénářů, úloh, chyb) – ideálně obousměrně: Zajišťuje trasovatelnost změn – kdo, kdy a proč změnil tento soubor/tento řádek kódu Integrace systému správy změn a buildu Umožňuje automatické vytváření reportů o buildu: K jakým změnám v kódu došlo od posledního buildu? Jaké scénáře byly implementovány? Jaké chyby byly opraveny?

67

68 Posoudit hodnotu pro zákazníka Úloha testera Tester je advokátem zákazníka Podpořit vývoj produktu Úloha vývojáře

69 Snažte se, aby testování co nejdříve odhalilo velké problémy, teprve potom se soustřeďte na detailnější oblasti. Důležité problémy identifikujte co nejdříve Snažte se soustředit na oblasti největšího rizika, ostatním oblastem ale věnujte také přiměřenou pozornost (pokud by analýza rizik nebyla správná...) Soustředění na riziko Zkoušejte různé testovací přístupy a úhly pohledu Maximální rozmanitost Zjištění informace o kvalitě produktu je důležitější než absolutní hodnota čísel Vyhněte se nadužívání metrik

70 ChrisAnna Subsystem1 10020 Subsystem2 06 Subsystem3 06 Subsystem4 06 Subsystem5 06 CELKEM10044

71 Scénáře jsou primárním představitelem hodnoty pro zákazníka Dobré otestování scénářů je nutnost Někdy může otestování identifikovat nové scénáře Testování scénářů může být automatizováno Výhody: Lze dosáhnout výrazně vyššího pokrytí testované funkčnosti Testy mohou být používány opakovaně bez dodatečného nákladu Nevýhody: Nákladné vytvoření Ještě nákladnější udržování Nemohou posoudit hodnotu pro zákazníka

72 Co nebylo testováno? Více odpovědí na jednu otázku: Které požadavky nebyly otestovány? Který kód nebyl otestován? Která možná selhání nás nenapadla? Závěr: Nespoléhejte se bezhlavě na metriky vytržené z kontextu

73

74 Pro každý check-in (pokud je to reálné): Nově implementovanou funkčnost a funkčnost zjevně zasaženou změnami Pro denní build Nově implementovanou funkčnost a funkčnost zjevně zasaženou změnami Pro iteraci: Zahrňte ad-hoc testování Pro finální produkt: Testujte splnění všech požadavků a kritérií