Scrum Droid

Mar
11

Jaki艣 czas temu mia艂am okazj臋 uczestniczy膰 w beta warsztatch Droid-Scrum organizowanych przez firm臋 Octigo przy wsp贸艂pracy GeekGirlsCarrots.

Warsztaty by艂y reklamowane jako dopiero wchodz膮ce na wroc艂awski rynek praktyczne poznanie scrum’a za pomoc膮 klock贸w lego i by艂y przeznaczone na 3 godziny (wersja standardowa zak艂ada dwa dni szkolenia).
Ca艂e szkolenie mo偶na by艂o podzieli膰 na trzy cz臋艣ci:

  1. Teoria
  2. Poznanie klock贸w (jak si臋 ju偶 po warsztatach okaza艂o by艂 to “Sprint 0”
  3. Scrum w praktyce

Wprowadzenie do Scrum’a i Agile trwa艂o a偶 godzin臋. Bardzo d艂ugo. Wydaje mi si臋, 偶e podczas praktycznego poznania Scrum’a potrzebne jest minimum teorii, kt贸r膮 b臋dzie mo偶na pozna膰 w艂a艣nie praktycznie, a nie teoretycznie.
Tutaj moj膮 uwag臋 przyku艂y slajdy, kt贸re by艂y pomieszane j臋zykowo – cz臋艣膰 po polsku, cz臋艣膰 po angielsku. Dodatkowo prowadz膮cy nie byli do ko艅ca przygotowani od strony technicznej. Wielko艣膰 zdj臋膰 na slajdach nie by艂a przystosowana dla uczestnik贸w z ko艅ca sali oraz nie potrafili zrobi膰 pe艂nego ekranu z Adobe Reader’a. Ale mo偶e na Mac’u to nie dzia艂a (nie mam Mac’a, wi臋c si臋 nie znam). Na uwagi ze strony publiczno艣ci (tak, tak, w艂a艣nie dziewczyn) aby wcisn膮膰 Ctrl+L stwierdzili, 偶e to i tak nie zadzia艂a i szkoda czasu..

Po teorii Scrum’a przysz艂a cz臋艣膰 na wyja艣nienie zasad.
Problem:W kopalni nast膮pi艂 zawa艂 chodnika. Na szcz臋艣cie nikt nie zgin膮艂, ani nie zosta艂 ranny, jednak nie mo偶liwo艣ci szybkiego uwolnienia g贸rnik贸w. Okaza艂o si臋 jednak, 偶e chodnikiem mo偶e przecisn膮膰 si臋 co艣 ma艂ego i sprawnego. Na przyk艂ad robot krocz膮cy, kt贸ry m贸g艂by dostarczy膰 odizolowanym ludziom wod臋, jedzenie, latarki oraz 艣rodki komunikacji. Zarz膮d kopalni szybko powo艂a艂 zesp贸艂, kt贸rego celem jest skonstruowanie robota. Ze wzgl臋du na presj臋 na czas oraz du偶膮 innowacyjno艣膰 projektu postanowiono wybra膰 podej艣cie Scrum do tego celu. Problemem jest nie tylko nieznana technologia, ale i nieprzewidywalne warunki pod ziemi膮. Celem zespo艂u jest zbudowa膰 robota, kt贸ry dotrze do ko艅ca chodnika i zaniesie uwi臋zionym g贸rnikom potrzebne artyku艂y.

Zasady:
20 min zapoznania si臋 z zadaniami + scrum poker
10 min budowanie robota
30 min rozmowa o zadaniu, zespole i co nale偶y poprawi膰.

Podczas praktycznej cz臋艣ci zosta艂y utworzone dwa zespo艂y. Do ka偶dego zosta艂 przydzielony mentor, kt贸ry mia艂 przeprowadzi膰 nas przez 艣wiat scrum’a. Jednak podczas t艂umaczenia zasad ka偶dy zesp贸艂 by艂 nie 聽r贸wno traktowany. Nasz sta艂 i s艂ucha艂 (poniewa偶 nasz mentor chcia艂 tylko na sobie skupi膰 nasz膮 uwag臋), za艣 zesp贸艂 przeciwny m贸g艂 si臋 zapoznawa膰 jakie klocki zosta艂y przekazane do tej zabawy.

WP_20140221_008

W ko艅cu przyszed艂 czas na “Sprint 0”, gdzie krok po kroku nasz mentor mia艂 nas przeprowadzi膰 przez ten sprint. Dostali艣my wytyczne, czyli robot powinien mie膰:

  1. gumowe podeszwy,
  2. antenk臋 d艂ugo艣ci dw贸ch centymetr贸w,
  3. mie膰 szczelin臋 (mi臋dzy spodem a ziemi膮) jeden centymetr,
  4. sta膰 stabilnie na czterech nogach,
  5. mie膰 niebieski kolor

Poniewa偶 by艂o ma艂o klock贸w koloru niebieskiego, przekonali艣my “klienta” (czyli naszego mentora), aby sama antenka by艂a koloru niebieskiego. Reszta zada艅 by艂a prosta, wi臋c 聽robota stworzyli艣my w 聽7 聽minut, kt贸ry by艂 zgodny ze specyfikacj膮.

WP_20140221_011

Podczas introspekcji wysz艂y takie rzeczy jak:

  1. Brak komunikatywno艣ci – wi臋kszo艣膰 rzuci艂a si臋 na klocki aby jak najszybciej wykona膰 zadanie
  2. Brak rozm贸w – w jaki spos贸b w og贸le powinni艣my podej艣膰 do zadania?
  3. Brak scrum master – a raczej brak osoby, kt贸ra pilnowa艂aby, aby konkretne zadania nie powiela艂y si臋 i aby ca艂y zesp贸艂 by艂 wykorzystany jak najefektywniej

Zosta艂a wi臋c podj臋ta decyzja, 偶e zostanie wy艂oniony scrum master, kt贸ry rozdzieli te zadania i b臋dzie dba艂 o to, aby ka偶da cz臋艣膰 zosta艂a wykonana.
I przyszed艂 czas na “Sprint 1”.
Tym razem robot powinien:

  1. posiada膰 sze艣膰 n贸g
  2. posiada膰 gumowe ko艂a
  3. posiada膰 g膮sienice
  4. potrafi膰 przej艣膰 przez przeszkody
  5. posiada膰 cztery nogi
  6. … (i kilka innych, kt贸rych ju偶 nie pami臋tam)

Og贸lnie du偶o wymaga艅 na raz wrzuconych i ma艂o czasu na zapoznanie si臋 i dyskusje, co i jak powinno zosta膰 wykonane oraz kt贸re elementy w kt贸rej kolejno艣ci nale偶a艂o wykona膰, tak aby ich nie wyklucza膰 nawzajem.
Wi臋c zosta艂o postanowione, 偶e oceniamy i bierzemy pod uwag臋 modu艂y wg priorytetu, kt贸ry biznes okre艣li艂. Nie by艂o to najlepsze, poniewa偶 cz臋艣膰 rzeczy si臋 wyklucza艂o zgodnie ze specyfikacj膮. Po za tym wyszed艂 czynnik ludzki, czyli nasz nowy scrum master nie mia艂 si艂y przebicia, gdy偶 zawsze znajdzie si臋 osoba kt贸ra wszystko wie najlepiej, chce innymi rz膮dzi膰 i rozstawia膰 ich po k膮tach, ale za nic nie chc臋 ponie艣膰 odpowiedzialno艣ci swoich decyzji.
W ka偶dy razie, wszystko to co zosta艂o zbudowane w “Sprint 0” zosta艂o zburzone, aby od pocz膮tku stworzy膰 co艣 zupe艂nie nowego w “Sprint 1”.
Nam nie uda艂o si臋 spe艂ni膰 wymaga艅 za艂o偶onych dla tego sprinta.

I na tym zako艅czy艂y si臋 warsztaty z praktycznego poznania scrum’a. Punkt 20.00 trzeba by艂o wszystko od艂o偶y膰, bo mia艂y by膰 dok艂adnie 3 godziny (nie mniej i nie wi臋cej).

Og贸lnie warsztaty reklamowane s膮 jako warsztaty nie tyko dla informatyk贸w. Ze swojej perspektywy nie widz臋 innej mo偶liwo艣ci ni偶 wyj艣cie scrum’a od programist贸w.. Ale biznes te偶 mo偶e tworzy膰 swoje rzeczy zgodnie ze scrum’em i naciska膰 na programist贸w, ale czy to b臋dzie efektywne?

Mia艂am nadzieje, 偶e podczas warsztat贸w b臋d臋 mia艂a okazj臋 zobaczy膰 jak wygl膮da od strony praktycznej “idealny” scrum. Jedynie co pozna艂am podczas warsztat贸w, to:
  • w ka偶dym spo艂ecze艅stwie istniej膮 osoby, kt贸re dominuj膮, nie bior膮c za swoje decyzje odpowiedzialno艣ci
  • wa偶ne jest dok艂adne zbadanie tematu, a nie rzucanie si臋 na to co biznes zechcia艂
  • komunikacja i aktywne s艂uchanie to jedyna opcja, aby projekt dzia艂a艂 dobrze
 

Leave a Reply