Počítačové hry

Proces a řízení projektu
Práce v týmu; větší projekty
Literatura





Steve McConnell. Software Project Survival Guide, Redmond,
Washington USA: Microsoft Press, 1998
Alistair Cockburn. Surviving Object-Oriented Projects, Indianapolis,
Indiana USA: Addison-Wesley, 1998
Tom DeMarco a Timothy Lister. Peopleware: Productive Projects and
Teams 2nd Ed., New York, New York USA: Dorset House, 2001
Tom DeMarco a Timothy Lister. Waltzing With Bears., New York, New
York USA: Dorset House, 2001
Na MFF UK se o procesu vývoje software přednáší v těchto kurzech:
 Vedení databázových aplikací a jazyk UML
Tomáš Rubač, zimní semestr
 Softwarové inženýrství
Jan Pavelka, letní semestr
Proces



Formalizované postupy
Práce navíc, která se dá plánovat, místo práce
navíc, která je zbytečná
Proces jsou dvě různé věci:


lineární proces, od začátku projektu po jeho
dokončení
cyklický proces, 'metodika', způsob, jak se na
projektu pracuje
Proces vs. zbytečná práce
vynaložená práce

Každý projekt používá proces; přijde na to, kdy
práce navíc
užitečná práce
práce navíc
užitečná práce
proces
trvání projektu 
proces
trvání projektu 
Metodika
Každodenní práce na projektu
Součásti metodiky


metodika vs. Metodika
Metodiku tvoří:





Standardy a výstupy
Nástroje
Postupy a techniky
Role, týmy a dovednosti
Waterfall vs. Agilní Metodika

kompromisní popis podle McConnella/Crystal
Standardy a výstupy

Standardy



např. MS VC++ Express/Python
nejde ani tak o to, jaké jsou, ale o to, že jsou
Výstupy


specifikace toho, co jednotlivé týmy vytváří
např.:




Design dokument
kód pro revizi
testovací případy
atd.
Nástroje

Musí podporovat





správu verzí
komunikaci
sledování projektu
testování
Mluvíme o souboru nástrojů

ne jednom universálním nástroji
Role, týmy a dovednosti


každý člověk může mít více rolí a být součástí
více týmů
Typické role a dovednosti






Architekt
Vedoucí projektu
Hlavní programátor/návrhář* (kódu, ne hry!)
Programátor/návrhář
Tester
Návrhář interfacu
*Budeme odlišovat návrh (programu) a design (hry)
Role, týmy a dovednosti

Typické týmy






Funkční týmy
Infrastrukturní týmy
Testovací tým
Sledování projektu
Architektonický tým
…
Vlastnictví


Každý modul (třída) má svého vlastníka
Každý výstup (požadovaná funkčnost) má vlastníka
Vlastníci funkcí:
Matice vlastnictví: funkce x komponenty
Vlastníci tříd: Class A
(Adam)
Funkce 1, 3, 9
(Cyril)
Funkce 2, 4, 8
(Adam)
Funkce 5 - 7
(Blanka)
Class B
(Blanka)
Class C
(Cyril)
Postupy a techniky









Plánování
Postupné odevzdávání – fáze, iterace
Řízení rizik
Kontrola změn
Testování – QA
Průhlednost projektu
Pracovní prostředí
Evidence času, měření produktivity
Zapojení uživatelů
Plánování

Plánování má dvě části:



Plán procesu
Odhady času – více v části o Vývoji projektu
Proces






Plán vývoje
Plán testování
Struktura týmu
Zdroje a kde je vzít
Proces tvorby odhadů, kontroly změn
Nástroje, metody a techniky
Postupné odevzdávání*




Projekt prochází několika stádii (plánování,
implementace, ...)
Funkčnost je dodávána v průběhu iterací
Každá iterace má (pokaždé stejné) fáze
(určení cílů, tvorba, testování, integrace)
Různý přístup k apriorní definici obsahu
inkrementů
*Staged delivery
Stádia, releasy a iterace




Projekt prochází několika stádii
V jednom stádiu je jeden nebo více releasů
V každém stádiu probíhají iterace
Iterace má fáze, podobně jako projekt
Projekt
Preprodukce
prepr. release
#1
#2
Produkce
prod. release 1
#3
#4
Dokončení
= Stádium
prod. rel. 2
fin. rel. 1
fin. rel. 2
= Releasy
#5
#6
#7
= Iterace
Iterace

Součásti iterace





Specifikace
Návrh
Konstrukce
Test
Mezi iteracemi



Zhodnocení průběhu projektu
Učení se
Změny kursu
*Stage
Iterace (pokr.)

Vlastnosti



Fixní délka
Nevyřešené problémy se přesouvají do další
iterace
Problémy


Ulpívání na prototypech
Spirála smrti
Řízení rizik*



Riziko je problém, který ještě nenastal, zatímco
problém je riziko, které se realizovalo
Inventarizace rizik
Pro každé riziko určíme:





odhad pravděpodobnosti
způsob detekce
preventivní opatření a jejich cenu
cenu a způsob řešení následků
rozhodnout, zda je výhodnější podnikat preventivní opatření
nebo ne
*Risk management
Riziko a plánování

Datum dokončení projektu známe jen s jistou
pravděpodobností
14
Pravděpodobnost (%)
Pravděpodobnost (%)
20
15
10
5
0
12
10
8
6
4
2
0
0 5 10 15 20 25 30 35 40 45 50
0 10 20 30 40 50 60 70 80 90 99
Prodloužení (%)
Prodloužení (%)
Kontrola změn*

Vývoj probíhá ve dvou fázích:




Prvotní vývoj (bez kontroly změn)
–– Odborné posouzení ––
Úpravy (schválené VPKZ)
Výbor pro kontrolu změn (VPKZ)



Zástupci všech 'stakeholders' projektu
1-3 lidi
Má finální slovo ohledně všech dodatečných změn
*Change control
Postup při změně

Návrh na změnu obsahuje:







Co se bude měnit
Důvody změny
Cena a výhody změny z hlediska navrhovatele
Výbor určí, koho se změna týká a pošle jim návrh na
posouzení
Oslovení určí cenu a výhody změny ze svého hlediska
Výbor vyhodnotí tato data a rozhodne se změnu
zamítnout, odložit nebo provést
Výbor uvědomí všechny zúčastněné o svém
rozhodnutí
Testování/QA

Posuzování (review)






Testování


rozeslání
příprava
schůzka
zpráva
implementace
provádí sám autor
Systémové testování

'klasické' testování
Systémové testování


Součástí vývoje je specifikace 'testovacích
případů'
Korespondence mezi požadavky a testy:
Požadované funkce:
Dostupné testy:
Funkce 1, 3, 9
Funkce 2, 4, 8
Funkce 5 - 7
Test A
Test B
Test C
Agilní a iterativní metodika



Scrum, Evo, Extreme programming, ...
Kratší iterace
Jakkoliv jsou to důležité věci, dáváme
přednost:




jednotlivcům a interakci před procesem a nástroji
funkčnímu softwaru před úplnou dokumentací
spolupráci se zákazníky před vyjednáváním o
smlouvě
přizpůsobení se změnám před plněním plánu
Scrum






tým se sám řídí a organizuje
během iterace se nesmí přidávat práce
denní schůze ve stoje, s povinnými otázkami
iterace trvá právě jeden měsíc
demo pro externí účastníky po každé iteraci
po každé iteraci se plán adaptuje podle
klienta
Scrum (pokr.)

Standardy a výstupy


Postupy a techniky




Backlog
Sprint – plánování, review
Společná místnost
Denní scrum
Role, týmy a dovednosti



Vlastník projektu
Scrum team, Scrum master = prasátka
Slepičky
Extreme programming






Plánovací hra
Malé, časté releasy
Systémové metafory
Jednoduchý design
Testování
Refaktoring
(předělávání)






Programování ve
dvojicích
Tým vlastní kód
Nepřetržitá integrace
Udržitelné tempo
Tým je pohromadě
Standardy kódu
Extreme prg. (pokr.)

Standardy a výstupy


Postupy a techniky





Příběhové kartičky, nákresy, seznam úkolů
Jednoduchý design, časté změny
Programování ve dvojicích
Zákazník na místě
Napřed se píše test, pak kód
Role, týmy a dovednosti



Zákazník
Programátor, tester
Trenér, sledovač