Dalším z klíčových prvků plánování je rychlost, kterou tým pracuje. Měří se samozřejmě na body, které si tým započítává za dokončené úlohy. Na začátku každého projektu budete mít pozvolný náběh, kdy se tým seznamuje s úkolem, specifikací, technologií a architekturou. A učí se. Učící křivka bude stoupat po dobu cca 1-3 sprintů v závislosti na projektu. Pak tým najede na svůj limit a pracuje konstantní rychlostí až do konce projektu.
Konstantní rychlost a pravidelnost odevzdávání dílčích výsledků je jedním z klíčových prvků Agile metod, takže jen shrnu, co chceme docílit. Pravidelnost jde spolu s předvídatelností. Jen tak že tým odevzdá každý sprint konstantní počet bodů, bude datum dokončení projektu dostatečně důvěryhodné číslo. Z pohledu týmu je účelem udělat plánování jednodušší, když se to tak na začátku nezdá a oprostit jednotlivé členy týmu od stresu, ale zároveň je na výsledku motivovat. Tým naplánuje jen to, co věří, že stihne udělat. Ostatně úlohy jsou obodovány a tým ví, že je schopen udělat 20 bodů za sprint, a tedy že stihne zase 20 bodů. Samozřejmě může se stát, že se to ve vyjímečných případech nepodaří, ale troufám si říct, že je pak pravděpodobné, že něco nefunguje úplně ideálně a stálo by to za Vaši pozornost. Pracuje tým opravdu týmově? Jak probíhá plánování? Rozumí pojmu bod? …
Zavádíte-li s Vašimi lidmi první Agile projekt, je velmi pravděpodobné že se to budete nějakou dobu učit. Můj odhad je tak 5-8 sprintů. Tým se musí naučit chápat a vnímat co je to bod, jak dělat plán a jak spolupracovat opravdu týmově. Na začátku bylo obvyklé, že tým vykazoval naprosto nerovnoměrné výsledky v rozmezí od 0 do 2.5 násobku plánovaných bodů. Jedním z velmi důležitých pravidel je tým nechat samostatně pracovat po dobu sprintu, a neorganizovat ho zvenku, ale na konci sprintu věnovat čas na reflexi a vysvětlení.
Na závěr ještě jednu radu. Vaším cílem je být efektivní. A platí, že dobrý tým je vždy efektivnější než samostatní jedinci. Proto neporovnávejte a nehodnoťte jednotlivé lidi podle toho, kolik dokončili úloh a za kolik bodů ty úlohy byly, ale hodnoťte vždy jen tým jako celek. Motivujete tím tým na výsledku a tedy i jeho jednotlivé členy na vzájemné spolupráci. Navíc máte-li týmy dva a více, vzbudíte tím zdravou soutěživost, a vytvoříte dobrou referenční soustavu.
Naučte se, jak transformovat firmy, měnit firemní kulturu a leadership pomocí Agilního & Enterprise Koučinku. Podívejte se na vypsaná školení zaměřených na Agile a Scrum na Sochova.cz. Pořiďte si kopii populární knihy The Great ScrumMaster: #ScrumMasterWay, Skvělý ScrumMaster #ScrumMasterWay, Agilní lídr: Využití síly vlivu nebo Agilní Metody Řízení Projektů.
Zdravím, narazil jsem na tenhle blog a musím říct že je to moc fajn počtení. Obzvlášť se mi líbí že to je napsané srozumitelně a viditelně opřené o praxi. Zároveň by mě zajímalo pár věcí:
Hodnota bodu: chápu dobře že bod je vlastně relativní jednotka – mám story 1,2 a 3 a body říkají například že story 1 zabere 20% času, story 2 30% a story 3 50% času? Takže když body vynásobím třeba 10x tak se vlastně nic moc nestane?
A druhá otázka, jak se dá nasadit SCRUM ve firmě kde vývojáři řeší i chyby a úpravy ve svých starých projektech, a tedy se dá špatně odhadnout kolik času se budou skutečně věnovat aktuálnímu projektu? Jde vůbec v takovém prostředí scrum nasadit? Mám se vzdát pevného časového rámce pro sprint a definovat sprint jako počet dní v kterých se vývojáři věnují danému projektu, i když to bude rozložené do většího časového úseku a co hůř, pokaždé jiného (a časem odvodit průměrnou skutečno délku sprintu) nebo mám raději zachovat pevný časový rámec a odkadnout kolik průměrně času se tomu budou vývojáři věnovat (případně to nechat odhadnout samotné vývojáře a nechat je to zahrnout do plánu na sprint). Neztratím tím motivaci vývojářů dokončit naplánované úkoly na sprint, protože se budou “vymlouvat” že na to (tentokrát) neměli dost času?
Dobry den, planovala jsem jeste dalsi prispevky na toto tema, ale pokusim se ve zkratce odpovedet.
S hodnotou bodu mate naprostou pravdu. Na velikosti nezalezi. Tym tim, jak s body pracuje postupne tuto hodnotu nejak iterativne nastavi, pochopi a posleze je v ni velice dobre schopen pocitat a odhadovat praci. Procenta jsou dobrou pomuckou, neni je ale moc k cemu vztahnout. Proto je bod bezrozmeru. Aby bylo odkud zacit, na zacatku se nastavi 1bod jako 1 man/day.
Druha otazka je slozitejsi. Zalezi asi hodne na povaze projektu, na tom jak casto se vam meni priority a tak. Jeden podobny projekt mame. Vzhledem k velkemu mnozstvi prace typu bugfixing, ktera ma vetsinou high priority, jsme nastavili Sprinty tydenni. Na zacatku udelate plan, kolik toho vyvinete, kolik casu budete fixovat resty – i tuto praci nakonec muzete ohodnotit body a zahrnout. Pak bude krivka vysledku rovnomerna. Pokud to z nejakeho duvodu neni vhodne, muzete udelat kazdy sprint plan na jiny pocet bodu, pokazde jiny pomer features/bugfixing. Obecne si myslim ze po case zjistite ze to ma nejakou zakonitost a tu buete schopen predpovidat a planovat s ni konecne datum. Ohodnoceni uloh bych urcite nechala delat vyvojare, rozhodnuti kolik casu venovat bugfixum a kolik vyvoji features, to zalezi na zvyklostech. My na to mame core team.
Pokud byste mel pocit ze vyvojari se vymlouvaji ze nemeli dost casu, … zkuste je opravdu nechat spojit tyto dve aktivity do planu, at uz body ziskaji bugfixem nebo vyvojem, je to ok. Pak je videt rovnomena rychlost tymu, tym pracuje na obou typech uloh a obe jsou jeho prioritou. Mate-li u bugfixu vetsi prioritu a prichazeji-li i v prubehu sprintu, nechte tym plan upravovat v prubehu (features vymenit za bugfix). Chce to jen sikovneho couche, aby vysvetlil priority, anomalie a nastavil cile. Vy ostatne na konci sprintu muzete pro sve ucely vyvoje kreslit jen krivku vyvojovych aktivit, a z nejakeho odhadu poctu chyb udelat odhad konce projektu. Pro tym bych ale zachovala obe aktivity v jednom grafu.