1. Práca vývojárskeho tímu
Martin Šutka [MCSD, MCPD]
team leader of web development, software architect, Zymestic Solutions, s.r.o.

2. Obsah
Role na projekte
Organizácia vývoja
Firemná agenda
DEMO

3. Role na projekte Product-owner (u zákazníka) Project manager
Kľúčová rola pre úspech projektu
Určuje priority
Prostredník do vnútra firmy
Pri niektorých (štátnych) zákazkách chýba
Project manager
Prostredník medzi PO a Dev team-om
Sleduje termíny, kapacity
Implementácia nastupuje po získaní projektu.
Úplne kľúčová rola pre úspech projektu je „Product Owner“. Človek na protistrane, ktorý má kompetencie aby rozhodoval aké sú priority, čo tam má nemá byť ako to má fungovať. Mal by byť prostredníkom do vnútra firmy. Nie vždy sa obraciame len na neho, ale je hlavný vstyčný bod, ktorý tiahne projekt dopredu.
Pri niektorých zakázkach (väčšinou štátnych) takáto rola chýba, nahrádza sa rôznymi výbormi a komisiami – skupinka ľudí, z ktorých každý ma iný názor, končí sa vždy nejakým zápisom, ktorý vlastne hovorí akurátne, že sa na ničom nezhodli, projekt nepostupuje a na konci sa akurátne dohodnú na tom, že to chceli úplne inak.
Project manager – prostredník medzi Product Owner-om a Dev tímom. Funguje ako proxy. Komunikuje medzi Dev tímom a product ownerom, sleduje termíny, kapacity.

4. Role na projekte Riešiteľ projektu (team leader) „Mozog“ projektu
Tvorí architektúru projektu
Určuje: Čo? Kto? Kedy? V akej kvalite?
Tvorí odhady
CodeReview
Garancia kvality
Team Leader – jeden z vývojárov, ktorý je v podstate mozgom projektu, rozdeľuje prácu, tvorí hlavnú štruktúru projektu, architektúru projektu, určuje čo ako bude fungovať. Tvorí odhady, CodeReview, kontrola a garancia kvality.

5. Role na projekte Dev team Vývojari Testeri Technical writer
Team leader
Dev Team – podľa príručky 3 developeri, 2 testeri, 1 technical writer a team leader.

6. Role na projekte Analytický team Komunikácia so zákazníkom
Vytvára „obecný koncept“
Návrh riešenia nie však implementácie
Tvorba užívateľských príručiek
Konfigurácia prostredí
Nasadzovanie aplikácií
Školenia
Analytický team – zodpovedný za analýzu, zúčastňuje sa na projekte ešte pred dev teamom. Komunikuje so zákazníkom a zisťuje jeho požiadavky a predstavy. Výsledkom práce je analýza a návrh riešenia – „obecný koncept“ – v prípade veľkých zákaziek (štátnych) výsledkom je kvantum dokumentácie. Návrh riešenie nie je návrh konkrétnej implementácie. Napr. návrh riešenia je že to bude webová aplikácia, ale to že či to bude WebForm, MVC, SPA, atď. je už v réžii architekta riešenia. Zúčastňujú sa na projekte aj počas jeho implementácie. Tvorba užívateľských príručiek, konfigurácia prostredí, nasadzovanie aplikácií, školenia.
PM syslí informácie!

7. Organizácia vývoja Iterácie Backlog „Krátke“ časové horizonty
Implementácia dohodnutých funkčností
Výsledok diskusie medzi PM a TL
Backlog
Pool funkčností požadovaných zázkazníkom
Obsahuje User Stories
Zdroj pre iterácie
Iterácie alebo bloky, sú krátke časové horizonty, zvyčajne jeden týždeň počas ktorého sa implementujú dohodnuté funkčnosti. To, že ktoré funkčnosti sa implementujú je výsledkom diskusie medzi Product Ownerom alebo PM a riešiteľom/Team Leadrom. Nie je dobré ak je iterácia dlhšia ako mesiac, pretože už to nespĺňa ten správny účel.
Blacklog – Je v podstate pool, ktorý obsahuje zoznam User Stories, inak povedané zoznam funkčností, ktoré požaduje zákazník. U nás je User Story jeden Use Case – použitie aplikácie. Pred začatím každej iterácie sa podľa odhadu pracnosti pre jednotlivé User Stories a velocity teamu vyberie zoznam User Stories, ktoré sa majú v danej iterácii implementovať.

8. Organizácia vývoja User stories Requirements
Use Case – použitie aplikácie
Náročnosť určená v Story point-och (napr. MD)
Príklad: meranie
Requirements
Konkrétna požiadavka na funkčnosť
Podrobnejšia špecifikácia
Príklad: meranie bodom, líniou, ...
User Story – u nás use case, reprezentuje blok funkčnosti, ktorú požaduje zákazník. Náročnosť implementácie sa určuje v story pointoch, čo je virtuálna jednotka, u nás sa používajú MD, ktoré sú potrebné pre plánovanie PM. Príkladom môže byť napríklad „Meranie“.
Requirement – konkrétna požiadavka na funkčnosť, s podrobnejšou špecifikáciou. Napríklad merať bodom, líniou, polygónom, zobrazenie výsledkov merania, ....

9. Organizácia vývoja Tasks Konkrétna implementačná úloha
Priraďuje ich TL
Odhad v hodinách
ID úlohy sa páruje so zmenami v Source Control
Code Review
Príklad: tlačítko v toolbare, ...
Task – konkrétna implementačná úloha, priraďuje sa developerovi, priraďuje ju team leader, zadáva sa odhad času v hodinách, každá úloha ma identifikačné číslo, pod týmto číslom sa aj comittujú zmeny do TFS, aby bolo vidieť aké zmeny boli v rámci danej úlohy vykonané. Napríklad implementovanie tlačítka do toolbaru, ktoré spustí meranie líniou atď. Team leader následne po implementácie vykoná code review, a pošle na prípadné dopracovanie developerovi. Následne sa task uzavrie, vyplní sa čas strávený implementáciou a nastaví sa, že remaining je nula. Ak sa zimplementujú všetky úlohy na danej user story, je táto pripravená na testovanie.

10. Organizácia vývoja Test Case Buildy po iteráciách
Testovacie scenáre pre User Stories
Testovanie prebieha po nasadení buildu
Nájdené nedostatky sa zaznačia ako Bug-y
Bug opravený v nasledovnej iterácii
Buildy po iteráciách
Done vs. Technický dlh
Prototypovanie
Čo najjednoduchší workflow
Testovanie testerom prebieha na builde a po jeho následnom nasadení do testovacieho prostriedia. Prípadné nájdené nedostatky za zaznačia ako bugy, pričom sa určí v ktorej verzii aplikácie bol bug nájdený, pripoja sa screenshoty, postup imulácie bugu. Bug sa naviaže na User story ktorej sa týka. V tomto prípade bug nahrádza Requirement, a stáva sa súčasťou Backlogu. Každý bug by mal byť opravený v nasledovnej iteracií, nie vždy to tak je. Pre bug sa opäť vytvoria tasky, ktoré treba implementovať aby bol bug odstránený. Nie každý bug je bug. Nie každý task viac ako 8 hodín.
Dôležité je po každej/pred každou iteráciou mať stretnutie so zákazníkom / Product ownerom, aby sme si vedeli ujasniť či projekt sa uberá správnym smerom, na aké možné problémy sme narazili atď. Krátke len neformálne zápisky, tie sa pošlú všetkým účastníkom, ale čisto len kvôli archivácii, nečaká sa, že účastníci budú teraz revidovať daný zápis. Spresňujú sa odhady. Odhad je na riešiteľovi pričom treba brať ohľad na člena tímu, ktorému tá úloha je priradená.
Je vhodné na začiatku savyhnúť nejakej enormne veľkej špecifikácii, čo však pri štátnych zakázkach nie je veľmi možné. Nakoniec je výsledkom špecifikácie veľká kopa zmien, viď zmena legislatívy.
Ak sa aj snažíte dodržať špecifikáciu, tak nakoniec sa môže stať že výsledkom je niečo čo nie úplne zákazník hcel, pretože tie jeho požiadavky sa časom menia.
Pomocou iterácií je možné postupne ukrajovať a neustále sa adaptovať na potreby zákazníka.
Buildy po iteráciach a priebežné nasadzovanie je dobré aj preto, že zákazník vidí čo sa robí, a nečaká povedzme rok na nejakú verziu, ktorú následne týždeň testuje, z čoho vypadnú púripomienky, ktoré sa zas možno po pol roku zapracujú, a vtedy si už zákazník ani nepamatá možno prečo napísal to čo napísal, alebo ešte lepšie medzi časom zistil že pripomienka s pred pol roka, ktorá sa už zapracovala nie je aktuálna lebo, ... A teda ajzbytočná práca sa urobila.
Na konci iterácie by mal byť hotový blok, práce, na ktorom už nikto nemusí nič robiť, definícia toho čo je „Done“, problém je technický dlh, ktorý ak sa vyskytuje po konci iterácie, pvoezdme že niečo nie je úplne otestované, prípadne viete že tu som nedal komentáre atď, tak ani zázkaník to potom nepovažuje za ukončené, nevenuje tomu pozornosť, často sa na to zabudne s tým, že neskôr sa k tomu vrátime, to sa nabaľuje a anak onci projektu zistíme že vlastne htové je všetko ale nie ´plne a nič nefunguje tak ako to malo fungovať a len čiastočne, veľ achýb atd. Tehcnický dlh podvedome vytesňujete. I keby sa malo použiť vetvenie kódu, na konci každej iterácie proste nič rozpracované nemá byť. Vyyhnúť sa prekrývaniu. Ak to bude takto že po iterácií je uzavretá funkčnosť, a zákazník si to môže v nejakom staging prostredí otestovať prípadne používať, každé ďalšie požiadavky je možné riešiť ako change requesty, zákazník nikdy nevie čo chce. V priebehu iterácie sa už nebude nič meniť.
Ak počas iterácie zistíme že niečo nie je to čo sme chceli, tak to z iterácie vyjemme a urobíme to bez toho. Zákazník sa snaží do iterácie pridávať funkčnosť – viď štýl bolo by super keby to vedelo ešte toto a toto, toto proste nie je možné takto robiť lebo sa to rozbije.
Prototypovanie – niečo sa skúsi, niečo čo sa možno aj zahodí, zákazník na to musí pristúpuť a akceptovať, má to výhody, je možné zákazníkovy ukazáť nejakú úzku funkčnosť aby mal lepšieu predstavu, kde pri zložitej architekúre je pomerne ťažké v krátkej dobe niečo ukázať (viď snapovanie na živej aplikácií)
Workflow – New -> Open -> Rejected / Resolved, vs. Predošlý worklfow, ktorý mal veľa stavov, nebolo to dobré. Čím jednoduchšie tým lepšie.

11. Firemná agenda Dev meeting Koordinačné porady 1 krát za 2 týždne
Kto, čo robil, bude robiť
zápis
Koordinačné porady
1 krát za týždeň
per project

12. Firemná agenda Stand-up denný Kick-off, Ad-hoc, Review Timesheet
Čo budem robiť
Čo som spravil
Bez zápisu
Kick-off, Ad-hoc, Review
Timesheet
Výkaz pre zákazníka (PM)
Lepšie začať s tým čo idem robiť ako s tým čo som robil, ľudia sa rozrozprávali o tom čo všera urobili, a strácal sa dôraz na to, že čo ma čaká kam napredovať.
Timesheet – v SharePoint-e, je možné exportovať do excelu, výhodné pre PM, je to ale otrava. Spomeň Brno kde sa timeshet bral ako výkaz práce a počítala sa zneho produktivita a odmeny.

13. DEMO
Locator

14. Odkazy

15. ?

16. Ďakujem za pozornosť