Späť
Základné a nadstavbové vzdelávacie programy pre tím.
Dlhodobá podpora tímov mentormi.
Spoznajte potenciál pre zlepšenia tímu.
Príprava a nastavenie tímu pre tvorbu komplexných produktov škálovaným Agile.
Ucelený a zmysluplný rozvoj tímu
Základné a nadstavbové vzdelávacie programy pre Scrum Mastrov.
Dlhodobé programy rozvoja schopností.
Identifikujte svoje potenciály pre ďalší profesionálny rozvoj.
Príprava Scrum Mastrov pre prácu v škálovanom Agile.
Základné a nadstavbové vzdelávacie programy pre Produktových vlastníkov.
Pripravte sa na prácu produktového vlastníka škálovaného portfólia produktov.
Vzdelávanie pripravujúce firmu pre zavedenie Agile.
Dlhodobé rozvojové programy pre zavedenie agilných praktík do firmy.
Hodnotenie agility firmy a identifikácia potenciálov pre ďalšie zlepšovanie.
Príprava firmy pre škálovanie agilných praktík.
Naše služby
TRÉNINGY
ROZVOJ
HODNOTENIE
ŠKÁLOVANIE
Ďalšie odkazy
Domov / Knowhow / Inkrement produktu
Tvorba produktov sa v agilných tímoch deje najčastejšie v sprintoch, dvoj-trojtýždenných iteráciách. Pri tvorbe produktu je však dobré sa zamyslieť aj nad dlhším obdobím, napr. nad tzv. Program Increment – PI.
Inkrement produktu je základným artefaktom Scrum.
Inkrement programu nemusí primárne označovať balíček zmien dodaných klientovi. V kontexte plánovania ide o časové obdobie, počas ktorého sa typicky tvorí tzv. major verzia, napr. v.3. Počas sprintov sa potom tvorí minor verzia, napr. v.3.1. Ak agile bude fungovať výborne, budete schopní dodávať aj viacero verzií počas jedného sprintu. V ScrumDesku sme napr. schopní dodávať priebežne novú verziu každých 3-5 dní po ukončení jednotlivých user stories. V takomto nastavení sme boli nútení zaviesť ďalšie číslo verzie označujúce build, napr. v.3.1.15.
Na obrázku je vidno, že inkrement programu je počas jeho plánovania rozdelený na jednotlivé sprinty, do ktorých sú zaradené jednotlivé požiadavky, tzv. user stories (žlté, zelené a modré štvorce).
Iba prvý sprint má však user stories (žlté karty) rozdelené na konkrétne implementačné úlohy (čierne štvročeky). Aplikujeme tak lean princíp ALAP (tak neskoro ako sa dá) a zároveň nemíňame energiu na spodrobnenie požiadaviek, ktoré môžu byť neskôr zo sprintu odstránené z biznis dôvodov.
Takto naplánovaný inkrement programu má požiadavky odhadnuté v story pointoch. Do verzií a sprintov sú zaradené karty podľa typickej rýchlosti tímu (velocity).
Na obrázku sú karty rozdelené do sprintov v dvoch riadkoch. Každý tento riadok reprezentuje samostatný tím, ktorý sa podieľa na vývoji produktu. V prípade viacerých tímov tak vedia tímy dosiahnuť plánovanie závislostí a vzájomnú synchronizáciu počas sprintov samotných.
Komplexnejšie produkty/programy potrebujú koordinovať vývoj viacerými tímami. V tomto prípade je vhodné uvažovať nad Scaled Agile Framework (SAFe), LeSS, alebo inými komplexnejšími agile frameworkami.
Nenechajte si ujsť výber toho najlepšieho z Agile, s čím sa stretli naši mentori. Nielen zo sveta produktov, vývoja, tipov a trikov, ale občas aj humoru. Posielame pravidelne, raz za občas :) #QualityOverQuantity
