Plánování a řízení iterativně vedeného softwarového projektu. 

Plánování a řízení iterativně vedeného softwarového projektu.

Nějaký harmonogram projektu je nutný vždy, má pevné body, je nutné rozdělit zdroje…

Je nutné sledovat plán a reagovat na nečekané události

Začátku projektu – rozvržení celého projektu, hlavní cíle, odhady

Na začátku iterace – co se bude v dané iteraci provádět

V průběhu iterace se pokud možno neplánuje vůbec

Obecně: WBS -> PERT -> Gantt

Adaptivní plánování – detailně plánovat je možné jen to, na co máme data – tzn. V kroce N můžu plánovat jen na N+1. 

Stupně volnosti při plánování jsou 4: čas, zdroje, kvalita, funkčnost. Nejlépe se krátí ta funkčnost, ostatní faktory jsou víceméně neměnné.

Plán projektu – vize, milníky

Plánovací schůzka

Výběr funkčnosti, odhadování, commitment

Sledování průběhu

Burndown chart, případné přeplánování pokud se nestíhá

Plánovací schůzka - sledování průběhu - retrospektiva

Řízení

Iterace – plánování na začátku iterace, mají fixní deadline.

Řízení je možné dvěma způsoby:

Řízení riziky

Snažíme se nejprve eliminovat největší rizika, proto je plánujeme co nejdříve

Řízení zákazníkem

Necháme na zákazníkovi, aby nám řekl, co potřebuje jako první – jsme ale omezeni délkou iterace, tzn. Můžeme udělat jen to, co za tu iteraci stihneme

Při řízení je důležitý backlog, na základě kterého se nám generuje burndowsn chart, který nám říká, jak na tom jsme – jestli práce stagnuje, přibývá, nebo uspokojivě ubývá.

Nějaký plán je nutný vždy

Přiřazení zdrojů

Sledování plánu nutné vždy

Reakce na změny

Způsoby plánování

Obecně

Typické pro sekvenční postup

PERT - graf činností a jejich závislostí, hledá se kritická cesta

Gantt - graf, který ukazuje čas potřebný k dokončení projektu

Neznalost odhadů v době, kdy jsou potřeba

Měnící se požadavky -> rozsah projektu

Základní přístup

Detailně plánovat možné jen to, na co máme data

Přesnější odhady a plán až po nějaké době

Plán na N+1 krok zpřesněn (adaptován) poznatky z N

Globální (pevné) body v plánu dány/určeny předem

Stupně volnosti při plánování

Klasicky: čas, zdroje (cena), kvalita

Obtížně měnitelné, odhadovatelné

Kvalita obtížně řiditelná

Agilně: + funkčnost

Nejlepší faktor pro řízení projektu

Funkčnost je totiž na rozdíl od předchozích nejsnáze měnitelná

Vhodná granularita -> snadné a přesné odhady

Řízení riziky (rizika jsou přímá a nepřímá - ty nepřímá téměř nelze ovládat)

Začít částmi funkčnosti/designu s největší mírou rizika

Řízení prioritami klienta

Výběr funkčnosti je na zákazníkovi

Množství funkcí je omezeno délkou iterace

Umožňuje pružně reagovat na aktuální potřeby

Okamžiky plánování

Na počátku projektu

Na začátku každé iterace

Seznam aktivit (úkolů)

Odhadování pracnosti -> časů, zdrojů

Vyřazení dle priorit (rizika, klient)

V průběhu iterace

… se pokud možno neplánuje

Gantt chart - čas, zdroje

Plán pro řízení rizik

Plánování a řízení iterací

Cíl = podmnožina požadavků na kompletní produkt

Pieces: The basic playing piece is the UserStory. Each Story is written on an IndexCard. Stories have a value and a cost, although this is a little tricky because the value of some Stories depends on the presence or absence of other Stories (see StoryDependenciesInXp), and the values and costs change over time. 

Globální řízení iterativního projektu

Oddělené sekvenční fáze reprezentující „klasické“ inženýrské disciplíny. Každá fáze má jasné rozdělení cílů a výsledků. Skládá se z 1 až N iterací. Fáze:

Zahájení (1 – 2 iterace)

analytické činnosti, validace vize zákazníkem

analytické a designérské činnosti, ověřování prototypy, implementace

designérské a programátorské činnosti, změnové řízení, testování a ověřování

Nasazení (1 – 2 iterace)

Integrační a konzultační činnosti, ověřování provozem, náběh uživatelské podpory

Milníky voleny na základě stupních přesnosti (produktu) a míře rizika

Srozumění s rozsahem, cenou, harmonogramem

Souhlas s požadavky a jejich klíčovostí

Rizika identifikována a řešení známo

Seznam rizik a strategie jejich řešení

Slovník pojmů a přehled klíčových požadavků

Koncept technického řešení (architektura + prototypy)

Vize a klíčové požadavky jsou stabilní

Testy ověřily, ze architektura řeší rizikové požadavky/faktory

Jsou přesnější odhady pracnosti, na nich postaveny plány

Stakeholders: vize realizovatelná, spotřebované zdroje adekvátní

Dokument specifikace požadavků

Seznam rizik a strategie jejich řešení

Popis architektury, validační testy

Implementace je dokumentovaná, existují používané testy

Je rozpracována uživatelská dokumentace

Jsou aktualizovány popisy návrhu, datového modelu, požadavků

Uživatelská příručka

Uživatel je spokojen s produktem

uvést produkt do rutinního provozu – „krabice“ s produktem, website launch, raut :-)

Podpůrné materiály (uživatelská dokumentace)
