eduScrum príručka

A je to tu. Finálna slovenská verzia eduScrum príručky.

Verzia 1.0 – December 2013
Review: Jeff Sutherland
Slovenský preklad: Ján Majoroš & Pavol Gurbaľ
Jazyková korekcia: Edita Kočišková

Z príručky: “Máme veľkú dôveru v mladých ľudí. Sme presvedčení, že chcú viac a sú schopnejší ako oni sami alebo mnohí dospelí veria. eduScrum zaisťuje, že študenti získavajú čo najviac zo seba a ich tímu. To je to, čo robí vzdelanie hodnotným pre kohokoľvek kto sa zapojí! Výsledkom je, že mladí ľudia majú k sebe vzájomnú úctu. Tak dúfame, že môžeme prispieť k lepšiemu svetu.

Taktiež som vytvoril krátku prezentáciu: Introduction to eduScrum.

Ján Majoroš

eduScrum príručka (ne-revidovaná slovenská verzia)

S veľkou radosťou oznamujem zverejnenie ne-revidovanej slovenskej verzie eduScrum príručky.

Z príručky: “Máme veľkú dôveru v mladých ľudí. Sme presvedčení, že chcú viac a sú schopnejší ako oni sami alebo mnohí dospelí veria. eduScrum zaisťuje, že študenti získavajú čo najviac zo seba a ich tímu. To je to, čo robí vzdelanie hodnotným pre kohokoľvek kto sa zapojí! Výsledkom je, že mladí ľudia majú k sebe vzájomnú úctu. Tak dúfame, že môžeme prispieť k lepšiemu svetu.

Ján Majoroš

Scrum v školstve?

Áno, aj v posledných dňoch rezonuje v médiách téma kvality slovenského školstva. Problém je to komplexný, riešení málo a aj to málo nevedie k zvyšovaniu úrovne školstva. Preto ma veľmi pozitívne prekvapilo, že som našiel toto: eduScrum. Ide o implemntáciu Scrumu na školách. A vyzerá, že je týmto možné riešiť niektoré z problémov školstva. Môj príspevok k tomuto (po dohode s predstaviteľmi z eduScrum-u) bude preklad do slovenčiny, na ktorom pracujem s Palim G. a dúfam že sa skoro dočkáme.

Zatiaľ video o čo ide:

A krátke video od Jeffa Sutherlanda:

Ján Majoroš

Skúsenosti s rolou Product Ownera

Na našom poslednom stretnutí, kde bolo témou produktové vlastníctvo, som zdieľal moje skúsenosti s rolou Product Ownera (PO), v ktorej som už 3 roky a ide o oblasť vývoja software pre medicínu vo veľkom distribuovanom projekte (Nemecko, Slovensko, India). Tu je krátke zhrnutie.

Čo považujem za najdôležitejšie:

  1. PO musí byť dostupný pre svoje tímy a tým nemyslím len DEMO a Plánovací meeting. Ak sú tímy distribuované na rôznych miestach, treba byť s nimi fyzicky aspoň na 1 týždeň sprintu raz za čas. Najmä v iniciálnych fázach projektu častejšie, potom menej často. PO musí byť schopný odpovedať členom tímu na ich otázky bez zbytočných prieťahov. Ak má PO viac tímov, je dobré keď si definuje presné časy v priebehu dňa kedy členovia daného tímu môžu kontaktovať PO priamo telefonicky, cez Skype, chat a pod.
  2. PO je zodpovedný za produkt backlog, pričom priority sú dané zhora dole. PO takto maximalizuje biznis hodnotu produktu, t.j. najvyššie v produkt backlogu sú položky s najvyššou biznis hodnotou pre zákazníka. Tím implementuje položky z produkt backlogu s ohľadom na túto prioritu.
  3. PO reprezentuje biznis. PO musí mať doménové know-how a ľudia na neho pozerajú ako na niekoho kto vie relevantne odpovedať na všetky technické možné aj nemožné otázky ohľadne produktu.
  4. PO musí mať víziu produktu. PO plánuje releasy, t.j. kedy jednotlivé funkcie budú uvoľnené zákazníkovi.
  5. PO berie zodpovednosť za svoje rozhodnutia napr. či sa bude implementovať daná funkcionalita, s akou prioritou a kedy. PO reviewuje výsledky sprintu a spolu s tímom sa rozhoduje o možných alternatívach riešenia implementácie položiek z produkt backlogu.
  6. PO informuje manažment firmy aký je progres developmentu produktu a kedy môže očakávať release produktu pre zákazníkov.
  7. PO spolu so Scrum Mastrom motivuje tím a snaží sa naplno využiť potenciál svojho tímu.

Ako sa vlastne formuje a vzniká rola PO? PO môže vyrásť z vnútra firmy z niektorého člena tímu alebo môže byť prijatý z externého trhu t.j. z prostredia mimo firmy.  PO, podľa toho čo prevažuje môže:

  • mať primárne vzdelanie SW inžiniera a získať doménové know-how skúsenosťami v danej oblasti  (toto je môj prípad) alebo
  • mať primárne vzdelanie v danej doménovej oblasti a získať skúsenosti v oblasti SW inžinierstva praxou (a toto býva častejšie)

PO typicky komunikuje s:

  • Líniovým manažmentom firmy – reporting, komunikácia míľnikov, budget, problémy a risky, eskalácie
  • Oddelením marketingu a predaja – stratégia predaja, vízia releasov, roadmap, predajnosť
  • Developermi/tímami – definícia DOD, otázky na funkcionalitu produktu, akceptačné kritéria pre user stories, motivácia ľudí
  • Scrum Mastrom – plánovanie sprintov, meranie velocity tímu, odstraňovanie impedimentov, sprint burn-down chart
  • Koncovými zákazníkmi a používateľmi produktu – nová funkcionalita produktu, feedback na produkt, ROI pre jednotlivé user strories produkt backlogu, školenia produktu

Ján Majoroš

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š