Nov trendy v projektovm zen Agiln pstupy Teorie

  • Slides: 52
Download presentation
Nové trendy v projektovém řízení: Agilní přístupy Teorie omezení Capability Maturity Model

Nové trendy v projektovém řízení: Agilní přístupy Teorie omezení Capability Maturity Model

Tradiční x agilní metodiky Tradiční přístup - požadavky jsou stanoveny na začátku vývojového procesu

Tradiční x agilní metodiky Tradiční přístup - požadavky jsou stanoveny na začátku vývojového procesu a jsou neměnné. Proměnné jsou zdroje a čas. Agilní přístup považuje za neměnné zdroje a čas, předmětem změn je funkcionalita. Na počátku projektu se stanoví nejdelší možný čas a náklady. Tým v průběhu zakázky komunikuje se zákazníkem a průběžně přehodnocuje priority.

Svět se mění – zákazník očekává kvalitu, ale není ochoten na ni dlouho čekat.

Svět se mění – zákazník očekává kvalitu, ale není ochoten na ni dlouho čekat. Tento rozpor se snaží řešit agilní metody snahou o užší sepětí zákazníka s vývojovým týmem.

Teze agilního manifestu • Přijmout a umožnit změnu je efektivnější než se změně bránit

Teze agilního manifestu • Přijmout a umožnit změnu je efektivnější než se změně bránit • Je třeba být připraven na nepředvídané události – „jedinou jistotou na projektu je změna“.

Manifest agilního vývoje software Cílem manifestu je zlepšit metodu vývoje software. Základními principy agilního

Manifest agilního vývoje software Cílem manifestu je zlepšit metodu vývoje software. Základními principy agilního přístupu je: • Lidé a jejich spolupráce mají přednost před procesy a nástroji • Funkční software je důležitější než vyčerpávající dokumentace • Spolupráce s klientem má přednost před domlouváním smluv • Reagovat na změny je důležitější než dodržování plánu

12 základních principů manifestu • • • Nejvyšší hodnotu je uspokojit zákazníka rychlými a

12 základních principů manifestu • • • Nejvyšší hodnotu je uspokojit zákazníka rychlými a trvalými dodávkami kvalitního software Změnové požadavky jsou vítány a to i ke konci vývoje. Agilní procesy je zpracují tak, aby zákazníkovi přinášely výhody Dodávat funkční software často, v intervalech týdnů až měsíců se snahou o kratší intervaly mezi dodávkami Lidé z businessu a vývojáři musí na projektu denně spolupracovat Základem projektu jsou motivovaní lidé. Musí mít dobré pracovní podmínky, podporu a důvěru, že svou práci odvedou. Nejúčinnější cesta k efektivnímu sdílení informací při vývoji je osobní přímá komunikace Hlavním kritériem postupu je funkční software Agilní procesy propagují udržitelný vývoj. Sponzoři, vývojáři i uživatel musí být schopni dodržovat stálý výkon neomezeně dokud je třeba bez stanoveného konce Trvalé střežení co nejvyšší úrovně technického řešení a dobrý návrh posiluje agilní přístup Jednoduchost - umění co nejvíce práce vůbec nedělat - je nezbytná Nejlepší architektura, požadavky a návrh pocházejí ze samoorganizovaného týmu Tým pravidelně vyhodnocuje svou prácí a upravuje své postupy tak, aby byl co nejefektivnější Manifest je překladem z originálního Manifesto for Agile Software Development (http: //agilemanifesto. org/)

Fáze celého projektu v agilních metodikách 1. 2. 3. 4. 5. 6. Nultá iterace

Fáze celého projektu v agilních metodikách 1. 2. 3. 4. 5. 6. Nultá iterace – první krátká analýza a naprogramování nějaké základní činnosti. V agilním týmu nejde příliš o to, co se v této části bude implementovat. Podmínkou je, aby na konci byl hotový kousek aplikace, který se dá předvést (tedy i klientovi). Analýza změny (výběr toho, co se bude implementovat, analýza a designování změn). Samotná implementace požadované vlastnosti (či vlastností). Předvedení klientovi. Pokud není produkt hotov, zpět na bod 2. Pokud ano, následuje údržba, rozvoj (rovněž v iteracích). Body 2– 4 se označují jako jedna iterace. Tyto body se opakují tak dlouho, dokud není vývoj ukončen (úspěchem, odložením projektu, proto, že dojdou peníze, změnou priorit klienta).

Agilní metodiky • • • Adaptivní vývoj softwaru Extrémní programování Lean development SCRUM Crystal

Agilní metodiky • • • Adaptivní vývoj softwaru Extrémní programování Lean development SCRUM Crystal metodiky Test-Driven Development

SCRUM • • • Krátké denní meetingy -> úkoly Vývoj po etapách („sprinty“) Flexibilní

SCRUM • • • Krátké denní meetingy -> úkoly Vývoj po etapách („sprinty“) Flexibilní harmonogram a dodání Malé týmy, časté revize Blacklog – informace o vlastnostech, funkcích a činnostech, které je třeba implementovat

Lean Development Lean znamená rychlost, jednoduchost, přehlednost, bezchybnost, vytváření produktů či služeb bez zbytečných

Lean Development Lean znamená rychlost, jednoduchost, přehlednost, bezchybnost, vytváření produktů či služeb bez zbytečných činností a zásob, omezení plýtvání, vyvažování procesů a navázání procesů na zákazníka.

Principy Lean Development • štíhlost, jednoduchost a přehlednost procesů, • aplikaci zdravého rozumu a

Principy Lean Development • štíhlost, jednoduchost a přehlednost procesů, • aplikaci zdravého rozumu a jednoduchých přístupů k řízení procesů a činností podle požadavků zákazníka, • zkrácení doby potřebné k provádění činností, • využívání kapacit na aktivity přidávající hodnotu výrobku nebo služby v očích zákazníka • omezení zbytečného plýtvání, • omezení zásob materiálu, jejich jednoduché řízení, a tím zlepšení finančních toků, • omezení nákladů.

Lean Development • Toyota: – odstranění všeho zbytečného a minimalizace zásob • Šest druhů

Lean Development • Toyota: – odstranění všeho zbytečného a minimalizace zásob • Šest druhů plýtvání: – – – nadvýroba čas ztracený čekáním plýtvání související se zpracováním nefektivní práce defekty ve výrobcích

Feature Driven Development • Hlavní roli mají vlastnosti produktu – řídí vývoj • „Vlastnost“

Feature Driven Development • Hlavní roli mají vlastnosti produktu – řídí vývoj • „Vlastnost“ (feature) – malý výsledek (funkčnost) užitečná z pohledu zákazníka – Měřitelnost – Srozumitelnost – Realizovatelnost • Vhodné pro menší projekty

Kdy není agilní vývoj vhodný • Kritické systémy, kde je nutné přesně dodržovat dohodnuté

Kdy není agilní vývoj vhodný • Kritické systémy, kde je nutné přesně dodržovat dohodnuté (technologie) • Rozsáhlé systémy, které se nedají dobře dekomponovat • Nejsou k dispozici kvalitní řešitelé • Není ochota se domlouvat o cíli za pochodu (jak uzavřít smlouvu, jak sankce za neplnění)

Srovnání klasického a agilního přístupu

Srovnání klasického a agilního přístupu

Tradiční x agilní Tradiční přístup Důraz na procesy a nástroje Obsáhlá dokumentace Uzavírání smluv

Tradiční x agilní Tradiční přístup Důraz na procesy a nástroje Obsáhlá dokumentace Uzavírání smluv s restrikcemi Striktní plnění plánu Agilní přístup Komunikace, individualita (kreativita) Provozuschopný software Spolupráce se zákazníkem Reakce na změnu

Tradiční metodika: Model vodopád (Waterfall) • 1970 Winston Royce • Každá etapa má stanovený

Tradiční metodika: Model vodopád (Waterfall) • 1970 Winston Royce • Každá etapa má stanovený přesný cíl a dokumenty, které musí v jejím průběhu vzniknout • Na konci každé etapy dochází k jejímu vyhodnocení a případně přepracování nebo opravení • Možnost vrátit se zpět do předchozí etapy • Pokračuje se teprve tehdy, je-li etapa zcela dokončena a schválena (pak již návrat není možný)

Klasický přístup projektování: Vodopádový model

Klasický přístup projektování: Vodopádový model

Model „Vodopád“ Výhody: - Jednoduchý - Ideální pro řízení - Vnáší disciplínu do vývoje

Model „Vodopád“ Výhody: - Jednoduchý - Ideální pro řízení - Vnáší disciplínu do vývoje

Model „vodopád“ Nevýhody: - Dodávka formou „velkého třesku“ - Určitá nepružnost - V době

Model „vodopád“ Nevýhody: - Dodávka formou „velkého třesku“ - Určitá nepružnost - V době mezi analýzou a nasazením se mohou změnit požadavky

Spirálový (iterakční) model • 1985, Barry Boehm • Zavádí iterativní přístup a opakovanou (důslednou)

Spirálový (iterakční) model • 1985, Barry Boehm • Zavádí iterativní přístup a opakovanou (důslednou) analýzu rizik Rizika – situace nebo události, které mohou způsobit nesplnění cílů projektu. Vychází se z předpokladu, že na začátku je obtížné nebo až nemožné přesně specifikovat všechny funkce.

Princip spirála

Princip spirála

Spirálový model Nevýhody: • Celková komplikovanost • Software není uvolněn před dokončením posledního cyklu

Spirálový model Nevýhody: • Celková komplikovanost • Software není uvolněn před dokončením posledního cyklu • Změna požadavků je možná pouze po dokončení cyklu • Pro nové druhy aplikací (např. internetové) je nepružný Je vhodnější pro rozsáhlé projekty!

Další tradiční metodiky RUP – Rational Unified Process • Iterace; dělí se na 4

Další tradiční metodiky RUP – Rational Unified Process • Iterace; dělí se na 4 fáze: zahájení, projektování, realizace, předání (zákazníkovi nebo do další fáze vývoje). • Robustní, propracovaná metodika, vhodná pro větší projekty a rozsáhlejší týmy. • Komerční produkt

Klíčové principy metodiky RUP • Iterativní vývoj softwaru (vychází ze spirálového modelu, průběžná detekce

Klíčové principy metodiky RUP • Iterativní vývoj softwaru (vychází ze spirálového modelu, průběžná detekce rizik) • Správa a řízení požadavků (požadavky se v čase mění) • Použití komponentové architektury • Vizuální modelování softwaru (za účelem porozumění systému; UML) • Průběžné zajišťování a ověřování kvality (po předání je nalezení problému dražší) • Řízení změn (počítáme s tím, že změny nastanou, neřízení změn vede k chaosu)

Výhody RUP • • • Obecnost a mohutnost Iterativní přístup – včasné odhalení rizik

Výhody RUP • • • Obecnost a mohutnost Iterativní přístup – včasné odhalení rizik Snazší správa změn Provázanost s notací UML, dokumentace Výrobce průběžně pracuje na zlepšování metodiky • Existence doplňkových nástrojů

Nevýhody RUP • Komerční, placený produkt • Rozsáhlost RUP může být na škodu u

Nevýhody RUP • Komerční, placený produkt • Rozsáhlost RUP může být na škodu u malých týmů – tým stráví spoustu času implementací metodiky • Její použití vyžaduje hluboké studium, týká se i projektových manažerů

Fáze RUP

Fáze RUP

Capability Maturity Model (CMM) • je framework popisující klíčové části nutné pro efektivní vývoj

Capability Maturity Model (CMM) • je framework popisující klíčové části nutné pro efektivní vývoj software. Jde o popis přechodu pomocí postupných evolučních vylepšení od ad hoc neoptimalizovaného řízení procesů až po plně optimalizovaný vývoj s průběžným zaváděním dalších zlepšení. • CMM je založena na 5 stupních hodnocení a zahrnuje praktiky pro plánování, navrhování a řízení projektu.

Úrovně CMM

Úrovně CMM

Procesní oblasti nutné ke splnění druhé úrovně jsou: • Řízení požadavků (RM) – Určení

Procesní oblasti nutné ke splnění druhé úrovně jsou: • Řízení požadavků (RM) – Určení požadavků, které má klient a vyjasnění, že dodavatel jim správně rozumí. • Plánování projektů (PP) – Sestavení realizovatelného plánu, kde je vyhodnocena náročnost implementace a také projektového řízení. Asi každý, kdo někdy navrhoval nějaký projekt moc dobře ví, že tento bod je zcela zásadní a bez jeho kvalifikovaného zpracování nelze projekt úspěšně řídit. • Sledování a vyhodnocování projektů (PT) – Vytvoření mechanizmů, které projekt zpřehlední tak, že v případě, že projekt se zásadně odchýlí od projektových plánů, je možné patřičně zasáhnout. • Řízení subdodavatelů (SM) – Tomuto bodu se věnuje zvláštní pozornost v CMM, – Ověřování kvality (QA) – Tento bod je úzce spojen s PT, kdy zde je kladen především důraz na ověřování kvality, „code-review“, testování atd. Pochopitelně vedení projektu je informováno o všech výsledcích díky zde získaným. • Konfigurační řízení (CM) – Jeho cílem je vytvořit a udržovat integritu vyvíjených produktů v průběhu celého životního cyklu projektu.

Třetí úroveň CMM: • Definování organizačních procesů (PD) – Vytvoření přehledu aktivit, které jsou

Třetí úroveň CMM: • Definování organizačních procesů (PD) – Vytvoření přehledu aktivit, které jsou přínosem pro celý proces vývoje. • Vzdělávací program (TP) – Vytvoření přehledu znalostí i s ohledem na předpokládaný budoucí rozvoj společnosti a podle něj vést zaměstnance k dalšímu vzdělávání. • Integrované řízení vývoje (IM) – Integrace vývoje realizace projektu společně s projektovým řízení, na základě definovaných standardních procesů organizace. • Koordinace projektových týmů (IC) – Cílem koordinace projektových týmů je vzájemně integrovat činnost různých vývojových skupin a t nejen inženýrských, ale i ostatních (definujících implementované procesy, kontrolních atd. ). Cílem je co nejlépe uspokojit zákazníky, a proto se snažit o nejefektivnější propojení jednotlivých aktivit a v důsledku zrychlení jejich práce a zvýšení efektivity (snížení redundantních aktivit, optimální časové provázání atd. ). • Interní kontroly (PR)

Pro zvládnutí čtvrté úrovně jsou definované tyto klíčové oblasti: • Kvantitativní řízení procesů –

Pro zvládnutí čtvrté úrovně jsou definované tyto klíčové oblasti: • Kvantitativní řízení procesů – Účelem je kvantitativní sledování projektů a vyhodnocování, jak jsou projekty plněny. Především se kvantitativní řízení procesů soustředí na sledování a měření procesů IM (Integrované řízení vývoje), IC (Koordinace projektových týmů) a PR (Interní kontroly). • Řízení kvality (QM) – Řízení kvality se soustředí na stanovení kvantitativních cílů, které slouží pro měření kvality vyvíjených produktů.

Pro poslední a nejvyšší úroveň jsou určeny následující klíčové oblasti: • Prevence vad (DP)

Pro poslední a nejvyšší úroveň jsou určeny následující klíčové oblasti: • Prevence vad (DP) – Prevence vad si klade za cíl najít možné vady, při implementaci projektu, analyzovat tyto vady a zjistit jejich příčiny a ty se následně snažit odstranit. • Řízení inovace technologií (TC) – Jak již název napovídá, účelem této klíčové oblasti je průběžně monitorovat technický pokrok a snažit se uplatit nové trendy, technologie a metodologie do vývojových procesů organizace. Tyto technologie pak nasazovat do organizace za účelem neustálého zlepšování procesů, snižování nákladů a zvyšování efektivity • Řízení zdokonalování procesů (PC) – Zdokonalování procesů je se snaží o zajištění kontinuálního rozvoje všech procesů, zlepšování kvality a zkracování vývojového cyklu softwarových projektů. Přitom využívá poznatky získané z DP a TC a navzájem je koordinuje a prosazuje do celé organizace.

Výhody CMM • je založena na současných postupech (praxi) • reflektuje nejlepší zkušenosti z

Výhody CMM • je založena na současných postupech (praxi) • reflektuje nejlepší zkušenosti z praxe • reflektuje potřeby jednotlivců provádějících zlepšení softwarových procesů a jejich hodnocení • je plně dokumentované • je veřejně dostupné

Co lze po aplikaci CMM očekávat? • Zpřehlednění celého projektu a jeho řízení •

Co lze po aplikaci CMM očekávat? • Zpřehlednění celého projektu a jeho řízení • Lepší časování v důsledku rozboru jednotlivých kroků vývoje • Upřesnění rolí účastníků projektu • Vylepšená dokumentace • Zlepšení kvality • Kontinuální snižování nákladů a zvyšování efektivity • Měřitelnost výsledků

TOC Teorie omezení (Theory of Constraint)

TOC Teorie omezení (Theory of Constraint)

 • ucelená manažerská filozofie nabízející nový přístup k řízení a trvalému zlepšování činnosti

• ucelená manažerská filozofie nabízející nový přístup k řízení a trvalému zlepšování činnosti organizací • možné využití k efektivnímu řízení podnikových procesů

 • autoři: dr. Eliyahu M. Goldratt Jeff Cox • poprvé představena r. 1984

• autoři: dr. Eliyahu M. Goldratt Jeff Cox • poprvé představena r. 1984 - The Goal

Rozdílná disponibilita kapacit projektových procesů proces A B C D E výstupy vstupy 7

Rozdílná disponibilita kapacit projektových procesů proces A B C D E výstupy vstupy 7 9 5 8 6 11 Možná kapacita Požadavek projektu

Principy zlepšení (TOC) • Použití Sokratovské metody dotazování (kladení otázek s cílem přivést k

Principy zlepšení (TOC) • Použití Sokratovské metody dotazování (kladení otázek s cílem přivést k řešení) • Princip pěti kroků TOC • Techniky postavené na principech kauzality následek/příčina/následek Jestliže - pak And

Princip pěti kroků TOC 1. Najděte omezení systému. 2. Rozhodněte se, jak omezení využít.

Princip pěti kroků TOC 1. Najděte omezení systému. 2. Rozhodněte se, jak omezení využít. 3. Pořiďte vše ostatní předchozímu rozhodnutí. 4. Rozšiřte kapacitu omezení. 5. Celý postup opakujte – ale tak, aby se omezením systému nestala jeho setrvačnost.

Systémový pohled na podnik Potřebné výstupy Potřebné vstupy transformace

Systémový pohled na podnik Potřebné výstupy Potřebné vstupy transformace

Základní paradigma podniku dle TOC průtok investice Provozní náklady

Základní paradigma podniku dle TOC průtok investice Provozní náklady

Ukazatelé 1. průtok (Througput) - množství peněz generovaných z prodeje hotových výrobků 2. zásoby

Ukazatelé 1. průtok (Througput) - množství peněz generovaných z prodeje hotových výrobků 2. zásoby (Inventory) - peníze vydané na nákup materiálu, zboží… 3. provozní náklady (Operating expens) - náklady na transformaci zásob na prodejné výrobky

Trendy důležitých metrik při dosahování podnikového cíle Čistý zisk průtok ROI zásoby Cash flow

Trendy důležitých metrik při dosahování podnikového cíle Čistý zisk průtok ROI zásoby Cash flow Provozní náklady

Koncept řešení změny v podniku podle TOC Co změnit: Následný krok: Strom současné reality

Koncept řešení změny v podniku podle TOC Co změnit: Následný krok: Strom současné reality Nežádoucí efekty Management projektu Klíčový problém Strom přechodu Cíl Dílčí efekt Činnost Strom předpokladů Cíl Překážky Jak způsobit změnu: Dílčí cíl Diagram konfliktu Cíl Potřeby Požadavky Strom budoucí reality Žádoucí efekty injekce Na co to změnit: START:

Strom současné reality Problém (př. Maximalizace výkonu – vede ke snížení kvality and Chybně

Strom současné reality Problém (př. Maximalizace výkonu – vede ke snížení kvality and Chybně zvolená metrika (tuny/hod. ) if

Proč TOC přináší výsledky? • Její řešení jsou konstruována na základě jediného nezpochybnitelného cíle,

Proč TOC přináší výsledky? • Její řešení jsou konstruována na základě jediného nezpochybnitelného cíle, který je určen typem organizace; u komerčních organizací je jím vydělávat co nejvíce peněz dnes i v budoucnosti. • Klíčovou myšlenkou je tvrzení, že každý systém v sobě skrývá minimálně jedno úzké místo - omezení. Kdyby tomu tak nebylo, pak by systém (podnik) dosahoval svého cíle v neomezené míře. • Poskytuje metodiku, jak omezení nalézt a účinně je využívat; zaměřením úsilí na nejslabší článek je dosaženo rychlých a reálných přínosů.

Projektové řízení v praxi - vývoj nových výrobku - inovace a rekonstrukce výrobku -

Projektové řízení v praxi - vývoj nových výrobku - inovace a rekonstrukce výrobku - zavádění nových technologií - zavádění nových výrobku do výroby a na trh - návrh a realizace investičních akcí - návrh a realizace stavebních akcí - návrh a realizace informačních systému - zavádění systému řízení jakosti podle ISO 9000 - příprava marketingových akcí - zpracování podnikatelských záměrů - generální opravy strojů - plán a realizace reorganizace firmy - realizace podnikatelských záměrů - příprava a realizace zakázek v kusové výrobě

Shrnutí • • Jaké jsou současné trendy v PM Agilní přístupy Model zralosti Teorie

Shrnutí • • Jaké jsou současné trendy v PM Agilní přístupy Model zralosti Teorie omezení