Your SlideShare is downloading. ×
Support team vz. Feature team
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Support team vz. Feature team

990
views

Published on

Roman Pieron

Roman Pieron


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
990
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Feature team vs. Support team Roman Pieron Agile SK, Bratislava 21.11.2011
  • 2. Projekt č.1 - m aintenance
    • Minimum vývoja, väčšina času venovaného riešeniu problémov, reportovaných užívateľmi (nie je bug ako bug)
    • veľký počet subsystémov, malý počet developerov
    • distribuovaný team, komponentová zodpovednosť, žiadne zdieľané know-how
    • Produkt vyladený, dlhodobo používaný, takže reportované bugy zákerné a ťažko ich nasimulovať
    • Dlhý čas potrebný na vyriešenie (vrátane konzultácie so zákazníkom) - aj mesiac…
    • žiadna automatizácia testov, dlhé obdobie medzi vyvinutou funkcionalitou a hlásením o chybe
    • Náročné odhadovať, plánovať, trackovať progres (Sprint = 2 týždne)
    • Maintenance backlog, maintenance buffer, maintenance sprint...
  • 3. Projekt č.2 - Vývoj
    • 8 aplik á ci í
    • 8 developerov onsite SK a 5 testerov GR
    • asi 100 z á kazn í kov po celom svete s celo š t á tnou p ô sobnos ť ou
    • Výsledný produkt tvorili viaceré technologicky odlišné komponenty (Chill, C++)
    • Nové funkcionality + maintenance (v menšej miere)
    • Do roka očakávaný nárast teamu o dalších ľudí, ktorí ale nemali potrebné programátorské know-how
    • Nová výzva a najmä zobrať si ponaučenie
      • Nezaťažovať developerov hľadaním symptómov bugov a dlhou komunikáciou
      • Zaškoliť ďalších ľudí, ktorí majú ešte povinnosti na technologicky inej časti produktu
  • 4. Teamy
    • Feature team
      • Team, zodpovedný za dodanie SW podľa požiadaviek PO (zložený z developerov)
      • team v Scrume so svojím PO a SM
    • Support team
      • Skupina jednotlivcov, zodpovedných za:
        • prvý kontakt so zákazníkom
        • Komunikáciu, pochopenie problému, zozbieranie symptomov, reprodukovanie chyby
        • Príprava požiadaviek na novú funkcionalitu
        • Samozrejme riešenie úloh na pôvodnom komponente
        • Osoby medzi teamami neboli zdieľané
      • Queue manager
        • Nie čo ako PO, zodpovedá za prioritizáciu požiadaviek na Support team
  • 5. Support developer
    • Očakávané problémy
      • Potrebné know-how na riešenie problémov budú členovia Support teamu žiadať od Feature teamu
    • Support developer
      • Rola, nie osoba
      • Na začiatok každý deň iná osoba z feature teamu
      • Vyhradená kapacita v každom Sprinte
    • Úlohy
      • Pomoc support teamu
      • Samotné fixovanie nájdených bugov
      • Bežné úlohy zo Sprintu
  • 6. Prax
        • Support team mal niečo ako Kanban tabuľu (aj zoznam bugov)
    • Zo začiatku bol support developer veľmi vyťažený
    • Support team popri iných aktivít aj zaškolenie do novej technológie
    • Bugy občas fixovali aj iní členovia feature teamu, podľa vyťaženia
    • Support developer začal chodiť na stand-up meeting support teamu
    • Každodenné rotovanie nie moc vyhovovalo, prešlo sa na dobrovolnosť - rebríček vyťaženosti
    • Support team nebol plnohodnotný team - chýbalo spoločné zdieľanie know-how
    • Predpríprava požiadaviek support teamom na novú funkcionalitu bola dosť slabá, tu bolo ešte veľa čo zlepšovať
    • Nízka disciplína v support teame (slabý Queue manager)
  • 7. Ponaučenie do budúcnosti
    • Ako dočasné riešenie je to schodný systém
    • Aj Kanban team potrebuje svojho coacha
    • PO stratil prehľad o chybovosti aplikácie, takže aj support team by mal byť aspoň čiastočne pod jeho kontrolou
    • PO musí komunikovať s Queue managerom, inak sa bijú priority a chýba spätná väzba
    • Čím skôr robiť kroky, aby sa aktivity vykonávané support teamom dostali späť do feature teamu