Odhadování pracnosti a PM
Agenda Docházka Odhadování Neohlášený test Vedení projektů Historie projektů
PM, odhadování, historie
Odhadování Snaha určit rozsah. Důležité ležité pro stanovení ceny a termínu
Do
nabídek.
Vyžaduje velké znalosti a zkušenosti Tím přesnější, čím ím více informací máme
změnových řízení bývají řádově přesnější než odhady vývoje z nuly
Odhady
Většinou nejvíce potřeba řeba na za začátku projektu Není
dostatek informací Kužel nejistoty
Kužel nejistoty
Odhadování – metody
Dekompozice - počítání ítání entit Obrazovky Požadavky Programy Každé
entitě se přiřadí adí komplexita. Z ní se vytvoří vytvo odhad v MD.
Analogie Snažíme
se najít podobný projekt Nutnost uchovávat historická data
Odhadování
Dva extrémy Příliš
široké odhady
Bude to hotové za dva měsíce mě až dvacet let
Příliš
úzké odhady
Bude to hotové za 2000 až 2001 dní
S přibývajícími ibývajícími zkušenostmi jsou odhady zpravidla pesimističtější. č ější. Juniorská
konstanta 4 :--)
Odhadování - kvíz
Doplňte te dolní a horní hranice, tak aby správný výsledek v daném intervalu ležel s 90% pravděpodobností: pravd 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Povrchová teplota Slunce Zeměpisná šířka ka Šanghaje Plocha asijského kontinentu Rok narození Alexandra Velikého Celkový objem měny ny USA v oběhu ob roku 2004 Celkový objem velkých jezer Celosvětové příjmy íjmy z filmu Titanic Celková délka pobřeží eží Tichého oceánu Počet et knih vydaných v USA od roku 1776 do roku 2006 Nejtěžší žší zaznamenaná modrá velryba
©2006 Steve McConnel. All Rights Reserved.
Vyhodnocení kvízu
Za každou správnou odpověď odpov máte 1 bod 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
6000°C 31° severní šířky 44 390 000 čtverečních ních kilometrů kilometr 356 bc 719,9 miliard dolarů 23 000 krychlových kilometrů kilometr 1,835 miliardy dolarů 135 663 kilometrů 22 milionů 170 tun
Odhadování - závěr Potřeba eba historická data => m měření Přesnost odhadů se zvyšuje s množstvím informací a se zkušeností odhadovatelů odhadovatel Lidé mají sklony k podceňování podce (viz kvíz). Dobrý odhad je základem úspěchu úsp (rentability) projektu.
Project management
Co je to projekt? Formální
definice: viz. Google („define: project“) Způsob sob jak vyvinout softwarový produkt.
Co je to management? Vedení,
řízení
Project management =
Vedení projektu Zjednodušeně – přidělování ělování práce vývojářům vývojá tak, aby se vše stihlo včas as a kvalitně. kvalitn
Odbočka – modely SDLC Zvolený model výrazně ovlivňuje způsob řízení projektu. Waterfall (vodopád) Agilní metodiky
Extrémní SCRUM
programování
Waterfall
Klasický model. Učí
se na školách
Vhodný pro změnová nová řízení, nevhodný pro vývoj z nuly. U
větších projektů je prakticky nemožné vytvořit vytvo kompletní analýzu na začátku. zač
Jednotlivé fáze SDLC jdou po sobě sob Požadavky,
Analýza, Design, Programování, Testování a pak předání edání zákazníkovi Dokumentuje se průběžně ěžně
Agilní metodiky
Základní myšlenky: Iterativní vývoj Přizpůsobování změnám nám (namísto slepého následování
plánu). Úzká
spolupráce (mezi vývojáři vývojá i se zákazníkem) Méně dokumentace, více testů test http://agilemanifesto.org/
SCRUM Zaměřený ený
na management projektů projekt
Extrémní programování Zaměřené ené
na programování
Agilní metodiky (2)
Praktiky (ne všechny se používají všude): Test
driven development Párové programování Continuous integration
Project management
Každý projekt (softwarový) je kompromisem mezi
Cenou (pracností) Časem (termínem dokončení) čení) Rozsahem (množství funkcí) Kvalitou (množství chyb, usabilita, …)
Smlouva (a specifikace) určuje uje meze daných veličin.
Project management
Největším tším otloukánkem je kvalita Těžko
se měří. Když jde do tuhého, zpravidla se první krátí testování.
S termínem se většinou tšinou dá hýbat Cena se dá navyšovat jen obtížně obtížn
říci: íci: „My jsme si mysleli, že to bude jednoduše implementovatelné, ale není. Tak připlaťte“. p
Nelze
Dobré stanovení rozsahu (dobrá specifikace) je pro úspěch ch projektu naprosto zásadní
Reálný život
Rozsah má tendenci bobtnat Na
začátku átku není možné vše přesně p vyspecifikovat Zákazník si vymýšlí Projektový manažer (nebo někdo n jiný – podle organizace firmy) tomuto musí bránit.
Odhady jsou nepřesné Lidé dělají chyby => PM je obtížný úkol. Není to exaktní věda. v
Plán
Dokument obsahující:
Harmonogram práce Přidělení úkolů jednotlivým lidem Deadlines
Nezáleží na formě
MS Project je fajn, ale Excel je taky fajn
Dlouhodobý výhled ů na další týden až 14 dní Podrobný rozpad úkolů WBS = Work Breakdown Structure
Rizika
Věci, ci, které mohou potenciáln potenciálně ohrozit projekt nemoc klíčového čového vývojáře, vývojá výbuch serverovny …
Například
Atributy rizika Dopad
na projekt (jak zásadní?) Pravděpodobnost, podobnost, že nastane
Sepsat seznam (na začátku zač projektu) a průběžně ho aktualizovat Průběžně
přijímat ijímat protiopatření protiopat (tam, kde se to
vyplatí)
Fishbone diagram
Měření ení a historie
Měření je důležité ležité pro PM V
jakém stavu je projekt (oproti plánu) Podklad pro přijímání ijímání opatření opat Například íklad žádost o nové zdroje (lidi, HW, …) Změna procesů (například říklad pokud roste chybovost).
Co měřit Počet et
zkonzumovaných MD Počet řádek kódu Počet chyb Cokoliv, co má nějakou jakou vypovídací hodnotu
Jak získat metriky Měřit průběžně Bugzilla CvsStat / StatSVN, … Libovolný systém pro vykazování času (Excel, homemade, open source, …)
StatSVN
Diskuse
Komentáře Otázky Připomínky Upřesnění Poznámky …
