Konferencia CzechTest 2014

CzechTestV dňoch 26. a 27. júna 2014 sa v Prahe (Clarion Congress Hotel ****, Praha) uskutoční štvrtý ročník medzinárodnej konferencie CzechTest zameranej na testovanie softvéru a systémov. Ide o jedinú konferenciu svojho druhu na území Českej Republiky a Slovenska.

Program konferencie obsahuje množstvo prednášok, ktoré odprezentujú nielen skúsení profesionáli z “našich krajov” ale aj medzinárodne uznávaní zahraniční experti zvučných mien z oblasti testingu. Pod vedením niektorých z nich je možné deň pred konferenciou, 25. júna, absolvovať aj špeciálne tréningy (pre-conference tutorials) zamerané na získavanie a zlepšovanie praktických testovacích zručností.

Účastníkov minuloročnej konferencie nepochybne očarila Julie Gardiner, ktorú sa podarilo získať na konferenciu tento rok opäť. Časť programu sa zaoberá agilnými prístupmi a jedným z prednášajúcich bude aj dobre známy slovenský agilný hrdina Dušan Kocúrek.

Súčasťou konferencie je každoročne súťaž o zaujímavé ceny (napr. iPad), prezentácie hlavných sponzorov, predaj špecializovanej literatúry a stravovanie pre účastníkov priamo v hoteli.

Účastníci, ktorí sa prihásia do 17. júna získavajú zľavu 20% z registračného poplatku, držitelia certifikátu ISTQB získavajú takisto zľavu 20%, študenti rovnako zľavu 20% pričom tieto zľavy sa kumulujú a je teda možné získať celkovú zľavu až 60%.

Agilné kontrakty

Tento článok je venovaný obchodníkom, šéfom firiem, právnikom a business developerom – ľudom ktorí tvoria a sú zodpovední za kontrakty pre agilné softvérové tímy. Popisuje typy kontraktov pre agilné projekty, ich výhody a nevýhody.

Kontrakt pre agilný projekt by mal riešiť podobné témy a problémy ako kontrakt pre tradičný model vývoja softvéru: cena, termíny, rozsah dodávky, záruka, odstraňovanie chýb a pod. Kľúčový rozdiel je pochopenie ako prebieha dodanie výsledného produktu v agilnom projekte. Ľudia, ktorí uzatvárajú kontrakt, musia rozumieť agilným princípom. Dodávky produktu v iteráciách a skorá kolaborácia medzi zákazníkom a dodávateľom pomáha znižovať riziká projektu. Kontrakt pre agilné projekty by mal byť založený na transparentnosti a dôvere. A tak ako sa vyvýja vzťah medzi zákazníkom a dodávateľom, tak sa musí vyvíjať aj kontrakt – presne v zmysle princípu:  “Customer collaboration over contract negotiation”, http://agilemanifesto.org.

Je to zmena myslenia? Áno – prioritou pre všetkých je úspešná realizácia projektu, nie “právnicky bezchybný” kontrakt, ktorý nevedie k úspešnému dokončeniu projektu.

Ako vyzerá “tradičný” kontrakt? Kopíruje tradičný model vývoja softvéru:

  • zmluva obsahuje veľmi detailnú špecifikácia požiadaviek,
  • termín dodania produktu je veľmi vzdialený, nezriedka rok a viac,
  • feedback od zákazníka je poskytnutý neskoro, niekedy až po finálnej dodávke produktu,
  • platba dodávateľovi je za finálnu dodávku produktu,
  • problémy ak projekt je nie je dokončený do konca s kompletnou funkcionalitou,
  • rozsiahla klauzula o rizikách, testovaní, záruke, náhrade škody a odstraňovaní chýb,
  • je použitá právnická terminológia, samotné koncipovanie a odsúhlasenie zmluvy trvá dlhý čas.

Kontrakt pre agilné softvérové tímy je akýmsi protipólom predchádzajúcich bodov, ideálne len definuje framework pre agilný štýl vedenia projektu. Vďaka fungujúcemu produktu, ktorý máme k dispozícii na konci každej iterácie a skorému feedbacku od zákazníka, môžeme zmeniť pohľad na kontrakt a riziká súvisiace s projektom.

Fixed Price

Fixed Price kontrakt je najjednoduchší typ kontraktu. Fixná je cena, obsah a aj čas dodávky softvéru. Zákazník platí dodávateľovi určitú čiastku z celkovej dohodnutej sumy zvyčajne na konci každej iterácie.

Tento typ kontraktu môže fungovať ak funguje dôvera medzi zákazníkom a dodávateľom a ak zákazník dostáva na konci každej iterácie požadovaný softvér. Dodávateľ môže akceptovať zmeny v pôvodne dohodnutých požiadavkách, pokiaľ je zachovaná komplexita a zložitosť. Potom sa zákazník nemusí sústrediť na samotný kontrakt, ale kooperuje s dodávateľom a ak táto spolupráca naozaj funguje – všetko je v najlepšom poriadku.

Fixed Price kontrakt však často vedie k situácii kedy zákazník nedostane čo pôvodne chcel alebo dodávateľ je v strate. Môže sa tiež stať, že dodávateľ, v snahe dodať čo sľúbil v rámci fixnej ceny, znižuje kvalitu dodávky – chybový kód, chýba dohodnutá funkcionalita alebo testy. To vedie k ešte vačším celkovým nákladom vzhľadom na opravu a následnú údržbu.

Najväčšie riziko pri Fixed Price kontraktoch je na strane dodávateľa. Dodávateľ si môže toto riziko premietnúť do svojích odhadov nákladov a akceptovať trebárs menej user stories pre dannú iteráciu. Toto však bude viesť k strate transparentnosti, dôvery a ku snahe dodávateľa hrať na väčší zisk.

T&M

T&M – Čas a materiál je typ kontraktu kedy zákazník platí dodávateľovi za vopred dohodnutú hodinovú sadzbu a za použitý materiál ako napr. licencie alebo HW.

Tento typ kontraktu je vhodný pre agilné projekty. Je jednoduchý, jasný a podpruje agilitu. Typická dilema zákazníka je kedy bude ukončený projekt, či neuviazne v nikdy sa nekončiacich platbách dodávateľovi a či dostáva primeranú hodnotu za svoje peniaze. Tieto obavy sú eliminované každú iteráciu prostredníctvom:

  • jasnej informácie o rýchlosti softvérového tímu –  meranej pomocou implementovaných user stories alebo user features,
  • vysokej miere transparetnosti a
  • možnosti ukončiť kontrakt na konci hociktorej iterácie.

T&M kontrakt vyžaduje vysoký stupeň dôvery na oboch stranách a to tak ako pri každom inom vzťahu medzi ľudmi nefunguje okamžite ale vyvýja sa. Je fajn začať  budovať tento vzťah prostredníctvom Fixed Price kontraktu a postupne prejsť na T&M typ kontraktu.

Target Cost

Target Cost kontrakt je výsledkom spoločnej zodpovednosti oboch stán: zákazníka aj dodávateľa. Kontrakt je často dokonca komunikovaný všetkým zamestnancom a tí majú záujem kolaborovať, efektíve riešiť problémy a tak dosahovať spoločné ciele.

Tento typ kontraktu používa napr. Toyota s cieľom dosiahnuť dlhodobý vzťah s dodávateľmi založený na dôvere a vzájomnej podpore.  Samotný kontrakt prebieha v dvoch fázach:

  1. Inciálna fáza – zákazník a dodávateľ spoločne identifikujú, analyzujú a odhadujú všetky požiadavky projektu a náklady možných zmien počas trvania projektu. Z tohto sa vypočítaju plánované náklady. Následne sa určí cieľový profit (napr. 15% z pánovaných nákladov). Všetky tieto detaily sú zdieľané zákazníkovi.
  2. Vykonanie projektu – počas ktorej sú kalkulované skutočné náklady na vykonanie napr. čas programovania, čas strávený na meetingoch, HW. Tieto informácie sú zdieľané zákazníkovi, najlepšie online.

Teraz príde najzaujímý aspekt tohto typu kontraktu. V prípade rozdielu medzi plánovanými a skutočnými nákladmi je vyrovnanie vypočítane tak, že sa zdieľajú náklady alebo profit medzi zákazníkom a dodávateľom. Napr:

Vyrovnanie rozdielu = (Skutočné náklady – Plánované náklady) * Konštanta zdieľania

Platba dodávateľovi = Skutočné náklady + Cieľový profit + Vyrovnanie rozdielu

Ako je vidieť vyrovnanie rozdielu môže byť kladné alebo záporné. Ak skutpočné náklady sú vyšsie ako plánované, zákazník aj dodávateľ spoločne zdieľaju tieto náklady. Ak skutočné náklady sú nižśie, obaja zdieľajú aj tento profit. Výsledkom tohto celého potom je to, že obe strany kontraktu sa snažia redukovať náklady.

Profit Sharing

Profit Sharing typ kontraktu je založený na spoločnom joint venture zákazníka a dodávateľa. Zákazník poskytuje peniaze na rozvoj dodávateľovi a obidne strany prosperujú a zdieľajú príjmy v prípade zisku. Tento model je zložitejší na realizáciu a má určité nevýhody z toho vyplývajúce.

Progressive

Progressive kontrakt predstavuje framework pre spoluprácu medzi dodávateľom a zákazníkom. Popisuje vzťah medzi oboma stranami, ale nie priamo obsah dodávky alebo cenu. Samotný kontrakt sa tvorí pre každú iteráciu a typicky sa vyvýja cez Fixed Price kontrakt, T&M kontrakt až k Target Cost kontraktu. Výhodou je značná flexibilita. Nevýhodou to, že pre každú iteráciu musíme vytvoriť nový kontrakt.

 

Na záver len zhrniem vzťah rizika medzi dodávateľom a zákazníkom pri rôznych typoch kontraktov:

  • Fixed Price kontrakt – riziko je na strane dodávateľa,
  • T&M kontrakt – riziko je na strane na zákazníka,
  • Target Cost a Profit Share kontrakt – riziko sa zdieľa medzi obe strany.

RizikaKontraktu

Ján Majoroš

Daily stand-up dobre IV – scrum master. A?

BatmanScrum master pečie denný chlieb tímu na dennom stretnutí.

Práve počas tohto stretnutia sa prejavujú schopnosti scrum mastra. Niečo o scrum mastershipe sa síce dozviete počas certifikačných a iných školení, no iba prax vás naučí.

Tím dobrého scrum mastra nemá problém so samoorganizáciou úloh, s komunikáciou a ani výrazné problémy so stavom úloh. Navyše v takom tíme je vysoká miera sebadisciplíny a zodpovednosti.

Disciplinovaný scrum master pred samotným daily mítingom :

  1. preverí stav nahlásených problémov a zaktualizuje ich zoznam, resp. časť tabule s problémami,
  2. skontroluje aktuálnosť stavu implementačných úloh na Kanban tabuli,
  3. skontroluje, či úlohy majú aktualizovaný zostávajúcu čas implementácie,
  4. skontroluje, či tok (flow) úloh je v poriadku,
  5. preverí, či členovia tímu sa snažia uzatvárať user stories a nie otvárať ďalšie úlohy,
  6. identifkuje novopridané úlohy, ktoré by moli zmeniť záväzok tímu daný na začiatku sprintu,
  7. preverí si vyťaženie členov tímu tak, aby ich naviedol pri samoorganizácii počas mítingu,
  8. overí dohodnuté WIP limity,
  9. spolu s produktovým vlastníkom preveria, či nie sú nutné zmeny v backlogu sprintu,
  10. spolu s inými scrum mastrami overí stav závislých prác, prípadne potreby iných tímov,
  11. preverí, či manažment nemá niečo dôležité z pohľadu organizácie, čo je potrebné odkomunikovať,
  12. skontroluje priebeh burn-down grafu a identifikuje otázne hodnoty, ktoré má s tímom prediskutovať,
  13. prípraví priestor pre denné stretnutie,
  14. pripraví nástroje (napr. zobrazí elektronickú kanban tabuľu),
  15. a  v neposlednom rade vymyslí ako otvorí stretnutie tak, aby sa tím pozitívne naladil.

Čo zmeníte na svojom scrum mastershipe zajtra?

Odkazy:

Daily standup dobre – I. Prečo?

Pôvodný článok na http://scrum.sk/index.php/daily-standup-dobre-cast-1-preco/

Denný stand-up je základnou ceremóniou v Scrum, ktorá je (chvalabohu) v slovenských dolinách aplikovaná často aj bez toho, aby bola oficiálne formalizovaná. Predovšetkým v malých firmách, kde ešte stále je rozhovor základom spolupráce.

Často však po niekoľkých mesiacoch zrazu tieto stretnutia nemajú “šťavu”. Mnoho ľudí nám pri koučingu namieta, že je to strata času. Prečo?

Pripravili sme preto pre Vás krátku sériu článkov o typických chybách, ktorými tímy samé brzdia svoju agilitu.

Čo je cieľom vášho standupu?

Najčastejším problémom je nepochopenie cieľa tohto stretnutia. Členovia tímu a scrum mastri ho považujú za stretnutie, na ktorom sa má reportovať stav projektu formou odpovedí na tri otázky: “Čo si spravil včera, čo budeš robiť dnes a aké máš problémy.”. Áno je pravda, že tieto otázky sú odporúčané. No nie je pravdou, že ich najväčší prínos je v reportingu.

Cieľom standupu je rozpoznať čo náš tím obmedzuje v dokončení našich zámerov dohodnutých počas plánovania, ku ktorým sme sa zaviazali.

Má to teda byť stretnutie viac o blízkej budúcnosti, než stretnutie o tom, čo sa stalo. Má to byť o tíme, nie o jednotlivcoch.

Tím sa má sústrediť na to ako dokončiť prácu, nie na to, ako je implementácia rozpracovaná. Agile je totiž založené na podpore dodávania funkčných výsledkov, ktoré ak nie sú dokončené, tak jednoducho nie sú použiteľné. Navyše trh je nevyspytateľný a zmeny sú dnes už konštantou.

Práve preto by ste ako tím mali byť pripravení aj počas sprintu dodať už dokončené user stories, resp. opravené chyby. Kedykoľvek.

 

Stavy v procese, stĺpce na Kanban tabuli

Článok je prebraný z http://scrum.sk/index.php/stavy-a-stlpce-na-kanban-tabuli/

Kanban tabuľa

Kanban tabuľa je skvelou pomôckou agilného tímu. Vizualizácia stavu úloh umožňuje tímu sa efektívne samoorganizovať a zároveň budovať dôveru v tíme aj mimo neho.

Každý stĺpec tabule označuje stav. A práve počet stĺpcov, teda stavov, je jednou z prvých otázok scrum mastrov počas prípravy tímu.

Odpoveď závisí od spôsobu akým ste sa rozhodli zavádzať Agile. Ste otvorení väčším zmenám? Alebo radšej opatrne a postupne?

Veľká zmena – maximalizácia minima

Pred niekoľkými mesiacmi sme začínali transformáciu v tíme, ktorý vytvára komplexný informačný systém už niekoľko rokov. V skutočnosti to boli štyri tímy so zložitejším procesom vývoja a teda aj s viacerými stavmi.

Ešte pred začatím transformácie sa však tím rozhodol maximálne zjednodušiť workflow tak, aby sa nemuseli vývojári zamýšľať kedy dať kartu do akého stavu. Pre svoju Kanban tabuľu preto zaviedli iba tri stavy.

Kanban simple workflow proces

Výhody sa ukázali okamžite:

  • Jednoznačný stav. Úlohu je nutné spraviť, alebo sa na nej pracuje, alebo je hotová.
  • Veľa kariet. Aj keď to znelo ako zvýšenie byrokracie, v skutočnosti sa ukázalo, že toto rozhodnutie viedlo tím k lepšej príprave počas plánovania. Požiadavky sú rozdelené na viaceré úlohy, ktoré jasnejšie popisujú prístup k riešeniu požiadavky.
  • Lepšie odhady – každá karta má svoj jednoznačný odhad. Je jasné, koľko sa na kartu plánuje a koľko času ešte zostáva. V predchádzajúcom workflow mal tím špeciálny stav označujúci čakanie. A práve v takomto stave karty ‘viseli’ , no tím nesledoval ich trvanie.
  • Organizácia tímu – každá  karta má svojho riešiteľa. Tak je možné lepšie rozdeliť úlohy medzi členov tímu.
  • Adresnosť problému – v prípade problému pri riešení úlohy je možné ľahko identifikovať, ktoré úlohy majú problém a zviditeľniť ich.

Pomalá zmena

Iný tím sa rozhodol, že zavedenie troch stavov nie je možné vzhľadom k ďalším firemným procesom, no identifikovali, že zjednodušenie je nutné. Otázne bolo ako zmeniť proces čo najmenej a zároveň najefektívnejšie.

Jedným z agilných princípov je pozorovanie a adaptácia. Preto sme v tíme začali s vizualizáciou aktuálneho workflow. Od momentu vzniku požiadavky až po dodanie výsledku používateľom. Táto technika sa volá Value Stream Mapping. Obrázok ilustruje príklad výrobnej fabriky.

Value Stream Mapping

Ďalším krokom bolo meranie trvania spracovania úloh v jednotlivých stavoch a pri presunoch medzi nimi. Keďže hlavným cieľom transformácie bolo skrátiť čas dodávky používateľom, zamerali sme na najdlhšie časti, ktoré stálo zato optimalizovať. Optimalizácia však neznamenala, že sa meranie skončilo. Každá lokálna optimalizácia má dopady na celkový proces, a preto je nutné pokračovať v meraní a ďalšej optimalizácii. Je to v podstate neustály proces.

Vizualizácia a meranie zároveň pomohli identifkovať stavy, v ktorých sa úlohy dlho ‘neohriali’. Úlohy boli cez nich iba presúvané. Tieto stavy boli z workflow odstránené čo zjednodušilo aj samotný proces.

Čo sa pýtať pri vytváraní Kanban tabule?

  • Prečo potrebujeme daný stav?
  • Kto potrebuje daný stav?
  • Ako dlho zostáva úloha v danom stave?
  • Má stav zmysel aj v prípade, že úloha nie je vývojová, ale napr.  napísanie dokumentu?
  • Potrebujete stav merať a vykazovať? Pre koho a prečo? Má to súvis s biznis hodnotou?
  • Čo je zbytočné?
  • Neexistujú iné workflow pre rôzne činnosti vývojového tímu? Napr. riešenie podpory, spracovanie kritických požiadaviek, požiadavky na súčinnosť.

Pr_duktívne plánovanie

Článok je prebraný z http://scrum.sk/index.php/produktivne_planovanie/

Počas niekoľkých posledných mesiacov sa mi naskytla príležitosť zúčastniť sa viacerých plánovacích stretnutí tímov s rôznou dobou nasadenia agile. Od úplných začiatočníkov až po starých harcovníkov, ktorí agile aplikujú už viac ako päť rokov.

Zaujalo ma na nich to, že:

  1. Efektivita plánovania nezávisí od trvania aplikácie agile.
  2. Tímy bez feedbacku upadajú do stereotypov a iba aplikujú procesy.
  3. Tímy sa zamerajú na zjednodušenie práce (rozumej lenivejú) a úplne zabúdajú na dôvôdy prečo sa plánuje.
  4. Výsledkom nie je plán, ktorému všetci rozumejú.
  5. Plán nie je plánom tímu, ale plánom jednotlivcov.
  6. Nesprávne pochopenie kedy a ako aplikovať story pointy a kedy hodiny.
  7. Nepochopenie, prečo vlastne odhadovať čas.
  8. Sprinty napriek plánovaniu aj tak nie sú ukončené načas a tím napriek tomu necíti zodpovednosť.

 

Možno predpokladáte, že tieto chyby mali tímy, ktoré začínali. No nebolo to tak. Tieto chyby sa objavili v skúsených tímoch. Vedené certifikovanými scrum mastrami.

 

A výsledok? Frustrácie manažmentu z nejasného termínu dodania, čo vedie k neustálym zmenám priorít. To prirodzene frustruje zákazníka aj tím. Navyše to prispieva k nemožnosti plánovania, práve kvôli častým zmenám. A začarovaný kruh je na svete. Plánovanie je frustrácia, ktorá bolí a preto ho chceme mať z krku. Preboha, veď za tie 4 hodiny sa dá toho tak veľa stihnúť naprogramovať.

Pravda starých otcov

Jeden z mojich prvých manažérov ma učil pravidlo brúsenia sekery. Jednoducho povedané, nedá sa len stínať stromy. To aj drevorubač sa musí zastaviť, vybrať si ten správny smer, vybrať stromy a nabrúsiť sekeru. Až potom rúbať stromy tak, aby vládal aj na ďalší deň. Ako je to v IT? (Lepší?) Vývojár chce vyvíjať. Všetko ostatné je balast. Sekera sa brúsi iba ojedinele.

No to brúsenie sekery má niečo v sebe…

Pravda starých agilistov

Agilné princípy ukazujú ako z tejto frustrácie von. Začať treba Agilným Manifestom, ktoré dáva do popredia funkčný softvér. Vytvorený v spolupráci tímu, zákazníka tak, aby bol pripravený na zmeny.

Účelom plánovania je robiť plánovanie, nie vytvárať plány.

Teda:

  • spoznať čo ideme dokončiť počas sprintu,
  • chceme začať s čistým stolom, začať novú iteráciu,
  • stanoviť si tímový záväzok k tomu, čo vieme dokončiť a koľko vieme dokončiť,
  • vytvoriť priestor pre spokojnosť. Spokojnosť tímu, klientov aj manažmentu.

Agenda

Často odpozorovanou chybou je úplne chýbajúca agenda stretnutia. Nepripravenosť z pohľadu organizácie času, postupu, priestorov a potrebného materiálu. Tím jednoducho prišiel na plánovanie a nechal sa unášať. V takýchto prípadoch začujete najčastejšie otázku ”Kedy vlastne máme obed?”. Áno, najčastejšie je práve táto prvou otázkou.

Čo je teda potrebné na plánovanie? Tu je niekoľko postrehov.

Čas

Predpokladajte  trvanie asi 2-4 hodiny podľa pripravenosti backlogu. Je to dlho? Radšej si sadnúť na dve hodiny a dohodnúť než potom zmätene hľadať spôsob riešenia niekoľko dní…

Pripravenosť

Dobrý scrum master pripraví miestnosť. Projektor, laptop, funkčné pripojenie k elektronickej tabuli. Telefón(y), web kamery ak je to potrebné.  Viditeľný časový rámec jednotlivých aktivít. Stopky alebo hodiny merajúce čas. A samozrejme pozve ľudí aj poslaním udalosti do kalendára. Dostatočne vopred. Najmenej 2 týždne vopred.

Dobrý produktový vlastník príde na plánovanie s pripravenými požiadavkami, ich prioritami. S odhadnutou biznis hodnotou, rizikom a MoSCoW. S akceptačnými kritériami. Vo forme, ktorú tím považuje za stav pripravený (definition of ready).

Dobré tímy už vedia čo v sprint backlogu je. Už si ho vopred každý preštudoval, napísal si pripomienky, resp. otázky a vie čo musí spraviť pre dokončenie požiadaviek. Má predpripravené konkrétne úlohy.

P1030082

V takomto prípade dokončí 10 ľudí plánovanie sprintu do 2 hodín určite. Postrehli ste ale tú disciplínu v príprave?

Kartičky

Budete potrebovať kartičky, kartičky, kartičky. A ešte raz kartičky. Zabudnite na notebooky. Plánovanie má byť tímovou prácou (manifesto).

S kartami sa ľahko manipuluje, ľahko sa prioritzuje, delí, vytvára nový obsah. Backlog sa jednoducho dá rozdeliť medzi viacero ľudí, zparalelniť prácu. Plánovanie tak bude intenzívne, efektívne a produktívne. Až keď skončíte plánovanie, až potom zadajte všetky karty do nástroja. Ak to urobíte všetci z tímu, tak zadať niekoľko desiatok kariet vám nezaberie viac ako pol hodinu.

P1050046

Aké je to s jedným laptopom a projektorom? Prduktívne. Všetci sedia okolo stola so založenými rukami a v tom lepšom prípade pozerajú na stenu. V bežnom prípade sa hrajú s telefónom pod stolom. Preto prduktívne.

Hmm, notebook

Ok, maximálne jeden, ak váš backlog je v elektronickom nástroji. Aby ste sa vedeli prehrabať v referenciách a ďalších potrebných informáciách. No prineste sprint backlog aj na kartičkách. Malá komplikácia, ktorá zvyšuje produktivitu.

Definícia Hotovo

Prineste si aj vašu definíciu Hotovo. Aby vám pomohla ako šablóna pri písaní úloh. Možno budete potrebovať viacero definícií. Pre user stories alebo chyby.

DoD

Rýchlosť a história

Aby ste sa vyhli zbytočnému deleniu požiadaviek na úlohy, do sprintu má produktový vlastník zaradiť iba toľko stories, koľko tím stihol dokončiť v predchádzajúcich sprintoch. Koľko story pointov bolo realné dokončených.

velocity

Kapacita

Zrátajte kapacitu tímu. Koľko dní budú členovia tímu v práci. Koľko hodín denne sa vedia venovať backlogu. Každú úlohu potom odhadnite v hodinách a nakoniec skontrolujte, či ich stihnete dokončiť.

Aby ste si vedeli overiť, či náhodou ste si nenaplánovali príliš veľa práce na sprint, ktorú nemáte možnosť stihnúť.

Kapacita

A výsledok plánovania?

Výsledkom dobrého plánovania sú:

  • prioritizované user stories,
  • dohodnuté akceptačné kritériá,
  • identifikované riziká,
  • rozdelené user stories na implementačné úlohy podľa definície hotovo a podľa charakteru požiadaviek,
  • odhadnutý čas imlementácie úloh,
  • overená možnosť dokončenia sprint backlogu podľa kapacity tímu a podľa dostupnosti jednotlivých členov tímu,
  • pocit, že vieme takýto sprint dokončiť.

Pocit je často pravdivejší než akákoľvek matematika….

Veľa úspechov pri plánovaní ďalších sprintov, ktoré sa vám podarí dokončiť.

Agile Manifesto slovensky

Som hrdý a veľmí rád, že po niekoľkotýždňovom úsilí sa podarilo niečo jedinečné.

Agile Manifesto v slovenskom preklade je oficálne dostupné na stránkach http://agilemanifesto.org/iso/sk/.

Pred niekoľkými rokmi sme v Agile@Slovakia iniciovali preklad použitím nástrojov, ktoré dala k dispozícii Agile Alliance. Bohužiaľ sa však táto aktivita zastavila. Napriek počiatočnému úsiliu sa ukázalo, že ľudia si museli na preklad násť dostatok času, no iterácie použitím nástrojov boli pomalé.

Premýšľali sme ako tento preklad dokončiť. Mnoho zo Scrum Mastrov potrebuje aplikovať koučing princípov a v mnohých firmách je anglický jazyk stále problémom.

Najlepším riešením sa ukázalo aplikovanie agilných princípov. Ľudia a komunikácia sú viac než procesy a nástroje. Rozhodli sme sa preto priniesť manifesto čo najbližšie k vám. Tak, aby sme stihli preklad iterovať počas 1 hodiny.

Tri slovenské mestá. Viac ako 50 ľudí. Aplikovanie agilnej techniky známej ako Triple Nickel. Ukázali sme tak účastníkom aj nový spôsob ako pracovať tímovo pri spodrobnení požiadaviek alebo počas retrospektív.

Na preklade sa podieľal Andrej Rehák,Barbora Moravcová,Dada Babušíková,Dušan Kocúrek,Dušan Mušák, Eva Kišoňová,Gabriel Kaputa,Ivan Kopčík,Iveta Tonhauserová,Ján Krajčík,Ján Polák,Ján Šimko, Jaroslav Kotuľák,Jaroslav Rybak,Karol Konkoly,Ľubomír Bogola,Ľuboslav Jochman, Marcel Majerník,Marcel Miklúš,Marek Kuzma,Marián Tkáčik,Martin Brzjak,Martin Kobyľan,Martin Kovač,Martin Major,Matúš Ferko,Matúš Kosa,Michal Bábics,Michal Augustín,Michal Dobiš,Michal Harhaj,Miroslav Mészáros, Oliver Textor,Ondrej Kubo,Ondrej Makši,Peter Kažimír,Peter Nosál,Peter Špireng,Peter Urban,Peter Užek,Radovan Balvan,Radovan Staš,Róbert Hájek,Robert Šoffa,Roman Pieron, Slavomír Bača,Tibor Szabó,Vladimír Olekšák,Vladimír Pavlík,Zdenko Vrábeľ,Zoltán Šipkai.

Ďakujeme všetkým za Vašu pomoc a podporu!

Konferencia CzechTest 2013

CzechTestV dňoch 21. a 22. marca 2013 sa v Prahe (Clarion Congress Hotel ****, Praha) uskutoční tretí ročník medzinárodnej konferencie CzechTest zameranej na testovanie softvéru a systémov. Ide o jedinú konferenciu svojho druhu na území Českej Republiky a Slovenska.

Program konferencie obsahuje množstvo prednášok, ktoré odprezentujú nielen skúsení profesionáli z “našich krajov” ale aj medzinárodne uznávaní zahraniční experti zvučných mien z oblasti testingu. Pod vedením niektorých z nich je možné deň pred konferenciou, 20. marca, absolvovať aj špeciálne tréningy (pre-conference tutorials) zamerané na získavanie a zlepšovanie praktických testovacích zručností.

Tom Gilb

Tom Gilb

Časť programu sa zaoberá agilnými prístupmi a medzi “ťahákov” konferencie patrí rozhodne Tom Gilb. Jeho koncpet EVO (Evolutionary Project Management), ktorý sformuloval ešte v 70-tych rokoch minulého storočia je považovaný za jeden zo základných kameňov na ktorých Agile staval.

Súčasťou konferencie je každoročne súťaž o zaujímavé ceny (napr. iPad), prezentácie hlavných sponzorov, predaj špecializovanej literatúry a stravovanie pre účastníkov priamo v hoteli.

Účastníci, ktorí sa prihásia do 20. februára získavajú zľavu 20% z registračného poplatku, držitelia certifikátu ISTQB získavajú takisto zľavu 20%, pričom tieto zľavy sa kumulujú.

40 výhod agilných prístupov

Minulý rok sa ma viacerí pýtali na výhody Agile v porovnaní s tradičnými prístupmi k tvorbe produktov, resp. riadeniu projektov.  Spravili sme teda vo firme krátky brainstorming a tu je náš zoznam.

  1. Zákazník dostáva hodnotu priebežne už v prvých týždňoch vývoja
  2. Produkt použiteľný po prvých dvoch týždňoch
  3. Priebežná redukcia rizika od začiatku projektu
  4. Rýchlejšie dostupné výsledky
  5. Vysoká angažovanosť klienta
  6. Jednoduché prispôsobenie produktu trhu
  7. Vyššia konkurencieschopnosť
  8. Vysoká angažovanosť tímov
  9. Tímy poznajú a chápu biznis model
  10. Prioritizácia úloh podľa biznis hodnoty a rizika
  11. Vyššia produktivita
  12. Vyššia kvalita
  13. Väčšia znalosť o produkte v tíme
  14. Manažment viac vedie, menej riadi
  15. Odstránenie mikromanažmentu
  16. Veľká viditeľnosť do stavu produktu
  17. Neustály proces zlepšovania procesov a technik
  18. Neustále prehodnocovanie vízie a stratégie produktu
  19. Jednoduché metriky umožňujúce operatívne validovať stav produktu a meniť jeho smerovanie podľa potrieb
  20. Vyššia rýchlosť dodania na trh
  21. Vyššia dôvera zákazníka
  22. 3* úspešnejšie projekty (podľa Chaos Manifesto)
  23. Motivácia výsledkom
  24. Stmelenejšie tímy
  25. Priebežné opravy chýb
  26. Zintenzívnenie spolupráce a komunikácie v tíme a aj so zákazníkom
  27. Pravidelný rytmus synchronizácie tímov
  28. Lepšia predvídateľnosť dodávok
  29. Vyššia spokojnosť klienta
  30. Vyrovnanejšie náklady vývoja
  31. Zameranie tímu na výsledok
  32. Efektívne riadenie projektov aj napriek častým zmenám
  33. Vyššia morálka a disciplína tímov
  34. Zlepšené inžinierske praktiky
  35. Jednoduchší a efektívnejší proces vývoja
  36. Dobré prispôsobenie procesu firemnej kultúre
  37. Lepší ROI
  38. Holistický prístup k vývoju, od techník vývoja, nástrojov, cez budovanie tímov až po procesy a firemnú kultúru
  39. Výrazné zlepšenie prezentačných schopností
  40. Nemotivovaní jedinci sa často sami rozhodnú zmeniť pôsobenie.

Článok bol pôvodne uverejnený na http://scrum.sk/index.php/vyhody-agilnych-pristupov/