• Lis : 09 : 2013 - Wstępniak
  • Lis : 09 : 2013 - Dziel i zwyciężaj ...bądź scalaj i zwyciężaj
  • Gru : 15 : 2013 - Doomsday is coming
  • Sty : 15 : 2014 - Ramzes umarł, Kryzys żyje
  • Sty : 24 : 2014 - "Dupa" na tablicy
  • Lut : 20 : 2014 - Zarządzanie czasoprzestrzenią
  • Maj : 15 : 2014 - Stosunek przerywany, czyli strzelając z biodra w architekturę

Featured articles

"Zarządzanie czasoprzestrzenią" - czyli kilka porad dotyczących harmonogramu zdarzeń SCRUM'owych Czytaj ...

Doomsday clock - czyli o tym jak mój zespół monitoruje dług techniczny i pokochał zagładę Czytaj...

"Stosunek przerywany, czyli strzelając z biodra w architekturę" - czyli słów kilka o groomingach Czytaj ...

Olewajki przeszkadzajki

Posted by pOtrek - 0 komentarze


W dzisiejszym odcinku przybliżę dwie „techniki”, które używamy w celu monitorowania.

Przeszkadzajki

W projektach dev-ops (deweloperka nowych funkcjonalności przy jednoczesnym utrzymaniu działającego produkcyjnie systemu) niezwykle istotna jest kontrola tzw. „focus factor”, czyli w jakim stopniu zespół koncentruje się na realizacji celu sprintu. Oczywiście w idealnym przypadku nie powinniśmy wykonywać żadnej pracy, która nie zliża nas do wspomnianego celu, ale takiej utopii nie udało nam się jeszcze osiągnąć J. W naszym przypadku główne źródła „dekoncentracji” zespołu to:

  • Wsparcie procesu deploymentu (pomoc działowi IT w konfiguracji środowisk, konsultacje z testerami)
  • Wparcie dla biznesu (odpowiedzi na pytania klienta związane z planowanymi funkcjonalnościami)
  • Wsparcie użytkowników końcowych w procesie onboardingu (integracji ich systemu z naszym systemem)
  • Analiza problemów i błędów, które pojawiły się na systemach produkcyjnych
Aby zaadresować ten problem wprowadziliśmy tak zwane kartki- wrzutki przeszkadzajki. O co chodzi? Otóż za każdym razem, gdy członek zespołu musi wykonać jakąkolwiek pracę, która zajmuje więcej niż 15 minut i nie jest związana z celem sprintu tworzy karteczkę, na której wpisuje swoje imię, datę, krótki opis tego, co musiał zrobić oraz ile godzin mu to zajęło.



 Zawiesza ją na tablicy z Sprint Backlogiem a po skończeniu pracy wrzuca ją do specjalnego pudełka na kartki - wrzutki przeszkadzajki. Dzięki temu jesteśmy w stanie łatwo stwierdzić, jaki jest poziom „dekoncentracji” w danym sprincie, jakie były ich przyczyny, kto był najczęściej „odrywany” od pracy… i tak dalej. Ja do tego celu używam prostego arkusza excel, do którego codziennie przepisuje dane z karteczek (zajmuje mi to dosłownie 2 minutki). Oczywiście same karteczki nie rozwiązują problemu „wrzutek”. Realizują jedynie pierwszy etap empirycznej kontroli, czyli Visibility. Co dalej z nimi zrobić? Masz już potrzebne dane teraz dobrze je wykorzystaj J Jak? Zachęcam do przeczytania tego artykułu (http://www.agileadvice.com/2012/01/08/scrumxplean/seven-options-for-handling-interruptions-in-scrum-and-other-agile-methods/).

Na koniec dwie przestrogi:

  • Ustalcie jasno i klarownie, czym jest wrzutka przeszkadzajka (naszą definicję znajdziecie wytłuszczoną w tekście powyżej)
  • Starajcie się unikać jednostek czasu liczonej w godzinach (my niestety wpadliśmy w tą pułapkę) – szczególnie, jeśli dane prezentujecie Product Ownerowi. Niestety 1 godzina pracy nad wrzutką przeszkadzajką nie uwzględnia kosztu „zmiany kontekstu” (porzucenia zadania, które było poprzednio wykonywane oraz ponownego powrotu do niego). Jeśli możecie wprowadźcie swoją miarę w postaci: Distraction Points, litrów, kilogramów, kubików, łokci, marchewek … czegokolwiek byle nie czasu. Unikniecie przez to żmudnych tłumaczeń, dlaczego zespół narzeka na wrzutki skoro zajmują one jedynie -  powiedzmy  5% ich czasu.


Olewajki

Wasz zespół pracuje niczym małe pszczółki w ulu (Zimoch moim idolem ;)). Wszyscy skoncentrowani są na celu sprintu i nagle <bam> test z jakiegoś starego projektu przestaje przechodzić, znaleźliście „kwiatek” w legacy kodzie, który spowodował, że wszystkim obecnym zjeżył się włos na głowie, padł serwer, który wprawdzie udało się podnieść, ale wszystko powiązane jest sznurkami. Jeśli zajmiecie się rozwiązaniem problemu nie zrealizujecie celu sprintu, jeśli „olejecie” problem może za jakiś czas uderzyć ze zdwojoną siłą. Co teraz? Naszym pomysłem było stworzenie kartek-olewajek. Na takiej karteczce wpisujemy, z czym jest problem i umieszczamy ją w osobnym backlogu. Na Sprint Planningu zespół wybiera niezrealizowane „olewajki”, które powiązane są z obszarem aplikacji, nad którym będą pracować i wrzuca je, jako techniczne zadania do wykonania w ramach User Story.


Czemu osobny backlog ?
Ponieważ te problemy dotyczą stricte technicznych zagadnień, które ciężko zrozumieć Product Ownerowi (a ponieważ tego nie rozumie, nadaje tym problemom niski priorytet). Dodatkowo w większości nie są to „pełnoprawne” User Stories, ale raczej zadania techniczne do wykonania.
Jak zorganizować taki backlog?
Jak chcecie. My mamy macierz, której rzędy reprezentują obszary systemu a wiersze priorytet/krytyczność problemu
Priorytet/obszar
Obszar 1
Obszar 2
Najwyższy priorytet
Fix XYZ




Najniższy priorytet

Refaktor kodu w XXX

Jaką strategię obrać przy realizacji olewajek?
Ponieważ nie są to zadania niezbędne do ukończenia User Story (a raczej doczepione do niego) zespół miał tendencję do odwlekania realizacji na „ostatnią chwilę”. Jak można się domyśleć w związku z tym były rzadko robione. Dlatego odwróciliśmy sytuację przez dodanie nowej reguły działania zespołów: „Kartka olewajka musi być zrealizowana w przeciągu 2 pierwszych dni sprintu (a najlepiej zanim zaczniemy pracę nad danym User Story)”
Co zmieniło się przez wprowadzenie kartek olewajek?
Zaczęliśmy PLANOWAĆ poprawki, a nie realizować je ad-hock (zawalając przy okazji inne rzeczy, które były w celu sprintu) lub totalnie ignorować (może nie wybuchnie)

Stosunek przerywany, czyli strzelając z biodra w architekturę

Posted by pOtrek - 0 komentarze

Dzisiejszy odcinek poświęcimy kwestii planowania, analizy i tworzenia architektury.

Workshops vs grooming
Zadania naszego zespołu można zasadniczo podzielić na dwie kategorie:
  • Poprawki błędów, drobne usprawnienia i modyfikacje, tworzenie niewielkich komponentów,
  • Tworzenie dużych komponentów, grup funkcjonalności (czyt. coś w rodzaju projektu)


Jak pewnie część z was wywnioskowała z mojego poprzedniego postu, poza Sprint Planningiem, w ramach planowania prac, stosujemy również grooming (lub w nomenklaturze najnowszego SCRUM guide: Product Backlog refinement). Poświęcamy na niego przeważnie 4 godziny per 2 tygodniowy sprint. I w tym miejscu pojawił się pewien problem…  a właściwie kilka problemów związanych z groomingiem dużych komponentów:
  • 4 godziny to zdecydowanie za mało, aby dobrze „opracować” duży komponent. W związku z tym nastąpiło coś, co zespół nazwał „stosunkiem przerywanym”. Grooming jednego komponentu przeciągał się na wiele sprintów, co oczywiście miało fatalny efekt na jego skuteczność,
  • Podczas analizy zespół często przeoczał pewne obszary funkcjonalne (jak i niefunkcjonalne). Powodowało to, że wielkość (czyt. pracochłonność) komponentu „puchła” wraz z postępem prac nad nim,
  • Wielkość groomingów była „zdalna”, (czyli telekonferencja między zespołem a Product Ownerem) w związku, z czym zespół developerski miał spore trudności z zebraniem wszystkich istotnych informacji,
  • Często pojawiały się problemy koncepcyjne wynikające z niezrozumienia przez developerów założeń biznesowych (modelu biznesowego).


W celu rozwiązania tych problemów wprowadziliśmy tak zwany Workshop. Jest to tak naprawdę ustrukturowana forma groomingu, która odbywa się zawsze face2face (Product Owner z zespołem współpracują razem w jednej lokalizacji). Wprowadzenie tej nowej nazwy jest bardzo istotne, ponieważ sygnalizuje zarówno stronie biznesowej jak i developerskiej, że grooming:
  • Dotyczy większej funkcjonalność/komponentu,
  • Nie może odbywać się „zdalnie”,
  • Ma określoną strukturę,
  • Będzie trwał dłużej niż zwykle.


Struktura Workshopu
Nasze Workshopy trwają przeważnie cały dzień (8h) i podzielone są na 3 części.

Część pierwsza

Uczestniczy w niej cały zespół (razem). Max. 1,5 h.
Agenda
  1. Wprowadzenie – ScrumMaster przypomina/informuje o tym jak zorganizowany jest Workshop, (czyli prezentuje niniejszą agendę)
  2. Zidentyfikowanie obszaru prac - Określenie, nad którymi funkcjonalnościami/komponentami będziemy pracować podczas wokshopu. Przeważnie robi to Product Owner
  3. Przedstawienie wizji funkcjonalności/komponentu
    a. Cel biznesowy funkcjonalności/komponentu,
    b. Długoterminowy plan biznesowy związany z funkcjonalnością/komponentem,
    c. Jakiej grupy klientów dotyczy funkcjonalność/komponent,
    d. Do jakiego rynku jest skierowany,
    e. Potencjalne problem/wyzwania.
    Podczas tego punktu agendy Product Owner nakreśla zespołowi wizję związaną ze stroną biznesową przedsięwzięcia.
  4. Ustalenie celu/ów workshop’u – cele najlepiej wypisać na tablicy. Przykładowymi celami mogą być: ustalenie wysokopoziomowej estymaty dla komponentu XYZ, ustalenie architektury, rozbicie pracy na epic’i
  5. Podział na zespoły wokrshopowe – z powodu wielkości zespołu dzielimy się nam mniejsze 4-5 osobowe pod-zespoły.


Część druga

Odbywa się w podzespołach
  1. Identyfikacja aktorów – burza mózgów, której celem jest stworzenie listy wszystkich potencjalnych aktorów (użytkowników, innych systemów itd.)
  2. Identyfikacja obszarów funkcjonalnych I niefunkcjonalnych – burza mózgów w celu stworzenia listy wszystkich potencjalnych obszarów funkcjonalnych
  3. Stworzenie macierzy epiców
    Zespół tworzy macierz, w której w rzędzie są zidentyfikowani aktorzy a w kolumnie obszary.

          Obszar/Aktor
             Aktor 1
            Aktor 2
         Obszar 1
    Epic 1

         Obszar 2

    Epic 2
  4. Identyfikacja epiców/user story - dla każdej komórki macierzy (pary aktor/obszar) identyfikowany jest epic lub user story. Nie tworzymy ich na siłę. Jeśli dany epic nie ma sensu zostawiamy pole puste. Dzięki temu podejściu „patrzymy” na system z różnych perspektyw i minimalizujemy ryzyko, że jakiś obszar/element przegapimy.
  5. Określenie priorytetów dla epic’ów/user stories (essential, important, nice to have) – priorytetyzujemy epicki. Mamy trzy kategorie: essential – totalnie niezbędne do startu produkcyjnego, important – musimy to zrobić, ale od biedy można zrobić start produkcyjny bez tego, nice to have – fajnie było by mieć tą funkcjonalność, ale przeżyjemy bez niej
  6. Wprowadzić epici/user story do product backlogu
  7. Opracowanie bazowej architektury – o tym w dalszej części posta
  8. Estymacja epiców/user stories – bardzo zgrubnie (T-shirt size), ale o tym w dalszej części posta
  9. Rozbić epic’ów na User Story – jak starczy czasu J




Część trzecia

Wszyscy razem. Max 30 minut.
  1. Czy cel(e) workshopu osiągnięty?
  2. Następne akcje? – Jakie powinny być następne akcje związane z groomowanymi elementami (wstępny plan działania lub dalszego groomingu),
  3. Podsumowanie – kilka zdań komentarza od Product Ownera.
Tak mniej więcej wygląda nasz plan workshopu. Czasem ulega on drobnym modyfikacją, aby dostosować go do określonych celów workshopu. Na koniec wspomnę jeszcze o dodatkowym atucie. Nawet, gdy nie wszystkie punkty planu udało się zrealizować wiemy dokładnie, na czym skończyliśmy i możemy w łatwy sposób kontynuować pracę na kolejnym workshopie lub groomingu.

Estymacja


Aby sprostać wymaganiom naszego Product Ownera oraz by poprawić klarowność informacji przekazywanych do „biznesu” wprowadziliśmy 3 stopniową skalę estymacji.
  • Shoot from the hip – mierzona w T-Shirt size’ach. Każdemu rozmiarowi przypisany jest jakiś przedział Story Pointów, a im większy rozmiar tym szerszy przedział (np. XL to 50 - 90 SP).Tego typu estymata z jednej strony pozwala Product Ownerowi określić czy jest sens zajmować się tą funkcjonalnością, z drugiej w pewien sposób daje komfort psychiczny zespołowi (pewne oderwanie od Story Pointów) dzięki czemu nie tracą czasu starając się wszystko dokładnie wyestymować.
  • RAW – estymata w Story Pointach, wartość musi być z ciągu Fibonacciego (1,2,3,5,8,13,21,34,55)
  • Rough but ready – w Story Pointach. Dokładność do 1 SP, maksymalna wielkość to 13 SP. Tylko User Stories z tym poziomem estymaty mogą być włączone do Sprint Backlogu. Zapobiega to „wciągania” do sprintu zbyt dużych (a przez to niejasnych) historyjek.


Architektura


Na koniec trudna w agile’u sprawa architektury systemu. Nasłuchałem i naczytałem się sporo komentarzy typu: „W agile NIGDY nie tworzymy architektury up-front. Refaktorujemy.” BZDURA!!! Widać, że osoby szerzące tego typu teorie nie miały styczności z dużymi projektami już działającymi produkcyjnie. Życzę im powodzenia przy każdym wdrożeniu w modyfikacji kilkudziesięciu komponentów rozproszonych na kilku klastrach serwerowych. W agile jak to w agile… robisz tak, aby było optymalnie dla twojego projektu. Nie musicie robić architektury up-front… to super. My niestety musimy. Staramy się natomiast utrzymać ją na pewnym poziomie abstrakcji, nie zagłębiając się za bardzo w szczegóły. Robimy to podczas workshopu lub groomingu, ponieważ bez ustalonej wysokopoziomowej architektury ciężko wyestymować dany komponent.   

Zarządzanie czasoprzestrzenią

Posted by pOtrek - 1 komentarze


SCRUM: ostatnia granica. Oto wędrówki zespołu AnythingButEnterprise kontynuującego misję odkrywania nowych, nieznanych światów, poszukiwania form efektywnej i przyjemnej pracy, śmiałego podążania tam, gdzie nikt z firmy jeszcze nie dotarł.

Tematem tego posta będzie planowanie zdarzeń (eventów) SCRUMowych. Dzisiejszy odcinek sponsorują hasła: timeboxing, zrozumienie ponad ortodoksję oraz chwila oddechu.

Timeboxing


Timeboxing, obok teorii empirycznej kontroli procesu oraz „empowerment’u”, jest wg. mnie jednym z filarów, na których stoi SCRUM. Potrzeba ścisłego trzymania się ram czasowych wręcz emanuje z kart SCRUM Guide, opisujących zdarzenia SCRUM’owe. Zauważyłem jednak, że większość zespołów rozpoczynających przygodę ze SCRUMem najczęściej ignoruje zasady związane z trzymaniem ustalonych ram czasowych. Muszę szczerze przyznać, że było tak też w przypadku mojego pierwszego „zwinnego” zespołu. Początkujące team’y najczęściej starają się utrzymać stałą długość sprintu, lecz zapominają, że rygor czasowy obowiązuje również w innych zdarzeniach, takich jak Sprint Planning, Daily Scrum czy Retrospekcja.

Okazuje się często, że utrzymanie ram czasowych spotkań jest znacznie trudniejsze niż w przypadku Sprintów. Poniżej znajdziecie kilka porad, które mam nadzieję, pomogą wam opanować trudną sztukę timeboxingu:
  • Rób agendę na dłuższe spotkania, uwzględniając maksymalny czas trwania każdego z punktów agendy – tutaj korzystasz z dobrodziejstw strategii dziel i zwyciężaj, (jeśli utrzymasz ramy czasowe każdego punktu agendy - utrzymasz ramy czasowe całego spotkania bez pomijania żadnego z jego punktów). Jest to szczególnie przydatne podczas przeprowadzania retrospekcji;
  • Zwróć uwagę na punktualność, zaczynaj spotkania zawsze o czasie, jeśli kogoś jeszcze nie ma to trudno. Nie czekajcie na niego, lecz wyjaśnijcie sprawę z „delikwentem” po spotkaniu. Szkoda waszego czasu;
  • Na każdym spotkaniu ustaw jakiś „czasomierz” w widocznym miejscu. Może to być zegar, lecz znacznie lepszy jest minutnik albo stoper. Ja, jako wielbiciel urządzeń z jabłuszkiem, używam aplikacji 30/30. Pozwala ona na odmierzanie ile czasu pozostało na dany punkt agendy. Wydaje mi się, że jak chwilkę poszukacie znajdziecie analogiczną aplikację na inne platformy (android, windows, linux);
  • Co w przypadku, gdy nie udało wam się „wyrobić” ze spotkaniem w wyznaczonym czasie? Wówczas proponuję poświęcić ostatnie 15 minut spotkania na:
    • Podsumowanie, co wam się udało osiągnąć na spotkaniu,
    • Dokładne ustalenie (najlepiej w postaci listy), czego nie udało się ustalić na spotkaniu,
    • Podjęcie decyzji czy warto kontynuować dyskusję o nierozstrzygniętych zagadnieniach. Jeśli tak, to:
      • Wybrać dokładnie co należy jeszcze ustalić (określić cel dodatkowego spotkania),
      • Ustalić ramy czasowe dodatkowego spotkania,
      • Ustalić, kiedy ma się ono odbyć (oczywiście może zacząć się ono zaraz po zakończeniu bieżącego spotkania – w praktyce będzie pewnego rodzaju jego przedłużeniem).
    Pamiętajcie jednak, że każde dodatkowe spotkanie odbywa się kosztem czegoś innego.
    Jeśli na przykład potrzebujecie dodatkowych 2 godzin na Sprint Planning oznacza to, że
    będziecie mieli 2 godziny mniej na właściwe prace w Sprincie. Upewnijcie się, że wzięliście
    to pod uwagę przy planowaniu ilości pracy, którą chcecie wykonać podczas sprintu.


  • ScrumMaster powinien w kwestii timeboxingu świecić przykładem. Nie dopuszczalne jest, aby spóźniał się na spotkania lub sam je wydłużał.


    • Zwinny SCRUM


    Teraz chciałem zwrócić uwagę na nadgorliwość, którą wykazują się co poniektórzy SCRUM puryści. SCRUM guide nie definiuje ścisłych ram czasowych zdarzeń. Przykładowo przyjrzyjmy się kwestii Sprint Planningu. Zacytujmy tutaj fragment SCRUM guide w tłumaczeniu Tomka Włodarka: „Planowanie Sprintu jest zdarzeniem ograniczonym do ośmiu godzin dla miesięcznego Sprintu. Dla krótszych Sprintów jest ono zwykle krótsze”. Co z tego wynika? SCRUM guide określa maksymalny czas trwania spotkania. Nie narzuca, lecz sugeruje, że w przypadku sprintów krótszych niż miesiąc sprint planning powinien trwać mniej niż maksymalne 8 godzin. Często słyszałem lub czytałem, że np. zespół, który ma dwutygodniowe sprinty i poświęca na sprint planning 3 godziny z tego powodu uprawia „SCRUM-but’a” (bo powinien poświęcać 4 godziny). Jest to oczywiście bzdura. Bądźcie „zwinni”. Dostosujcie długość zdarzeń SCRUM’owych do waszych potrzeb. 


    Dla „świeżych” i niedoświadczonych (w SCRUM’ie) zespołów proponuję zastosować zasadę przeliczania, 1: 1, czyli:
    • dla sprintu miesięcznego 8 godzinny sprint planning, 
    • dla sprintu 2 tygodniowego 4 godzinny sprint planning, 
    • dla sprintu tygodniowego 2 godzinny sprint planning. 
    Co sprint na retrospekcji omawiajcie efektywność sprint planningu. Jeśli nie wyrabiacie się w określonych ramach czasowych szukajcie rozwiązań, które zwiększą efektywność spotkania. Decyzję o wydłużeniu sprint planningu (jeśli będzie taka potrzeba) podejmijcie dopiero po kilku sprintach, gdy okaże się, że mimo wprowadzonych po retrospekcji zmian, ciągle jest problem z zakończeniem spring planningu na czas. Chodzi o to, że zespoły często „idą na łatwiznę” zwiększając limit czasowy, podczas gdy prawdziwy problem leży w niskiej efektywności spotkań.

    Daj ludziom odpocząć


    Środowisko w jakim najlepiej czują się developerzy to oczywiście środowisko programistyczne :P Spotkania przez większość z nich uznawane są za zło konieczne. Planując zdarzenia SCRUM’owe zwróćcie szczególną uwagę na to, czy stężenie spotkań na dzień roboczy nie przekracza dawki śmiertelnej. W naszym zespole był taki czas, gdy Sprint Review, Sprint Planning I, Sprint Planning II oraz Retrospekcja odbywały się tego samego dnia. Efekt był taki, że ludzie już na Sprint Palnningu II mieli serdecznie wszystkiego dość, a w retrospekcji (która była na samym końcu) uczestniczyły może 3 osoby.

    Dlatego: 
    • Zaplanuj pół godzinną przerwę na każde 1,5 – 2 godziny spotkań, 
    • Ustal konkretną godzinę przerwy na obiad, szczególnie, jeśli ludzi zamawiają katering. W przeciwnym razie spotkania notorycznie będą przerywane w trakcie, „bo jedzienie dotarło”, 
    • Dobrą praktyką jest rozłożenie zdarzeń kończących i zaczynających sprint (Sprint Review, Sprint Planning, Retrospekcja) na dwa dni, 
    • Dni planningu powinny trwać maksymalnie 8 godzin, choć osobiście zalecam, aby były krótsze. W naszej pracy są znacznie istotniejsze rzeczy niż „wyrobienie dniówki”. 
    Próba „oszczędzania” czasu na zdarzeniach SCRUMowych poprzez maksymalne ich „upychanie” w harmonogramie prawdopodobnie przyniesie efekt odwrotny od spodziewanego. Zmęczenie członków zespołu z pewnością negatywnie odbije się na efektywności spotkań, kreatywności, wykazanej inicjatywie oraz jakości planów.

     

    Nasz (typowy) harmonogram


    W naszym zespole typowy harmonogram wygląda następująco:

    Wtorek
    9:00 – 10:30 Sprint Review
    11:00 – 13:00 Grooming I
    13:00 – 13:40 Lunch break
    13:40 – 13:50 Kudos meeting
    13:50 – 14:00 Doomsday clock meeting
    14:00 – 15:30 Retrospective

    Środa
    09:00 – 11:00 Grooming II
    11:30 – 12:00 Sprint Planning I
    12:00 – 12:40 Lunch break
    12:40 – 15:45 Sprint planning II
    15:45 – 16:00 Sprint Planning - Summary

    Kilka komentarzy na jego temat:
    • Z uwagi na rozmiar zespołu tak zwane (u nas) planningi trwają dwa dni, 
    • Zespół zdecydował, że chce włączyć grooming w ramy dni planingów, aby w trakcie „właściwego” sprintu móc skoncentrować się na właściwych pracach wykonawczych (development, testy, deployment), 
    • Między spotkaniami (które trwają do 2 godzin) zespół ma pół godzinne przerwy, 
    • Przerwa na obiad trwa 40 minut. Jest z góry ustalona, aby było wiadomo, na którą godzinę zamówić obiadki. Bez tego spotkania często były nagle przerywane, bo dostarczono (o losowej godzinie) obiad i trzeba go zjeść póki jest ciepły, 
    • Podczas sprint planningu II zespół dzieli się na podzespoły i każdy podzespół sam określa, kiedy chce zrobić przerwę, 
    • Sprint Planning I jest bardzo krótki (pół godziny) – na nim zespół z Product Owner’em ogólnie omawia, które User Story powinny być wykonane w trakcie Sprintu. Zespół developerski również wykorzystuje ten czas do dopytania o interesujące ich rzeczy, 
    • Sprint Planning – Summary jest tak naprawdę fragmentem części drugiej Sprint Planningu. Został wydzielony, ponieważ Product Owner często uczestniczy w zdarzeniach scrumowych zdalnie (realizujemy produkt dla klienta zagranicznego). Podczas podsumowania zespół developerski zdzwania się z Product Ownerem w celu ustalenia ostatecznego kształtu sprintu, 
    • Harmonogram rozpisany jest na 7 (a nie standardowe 8) godzin. Spowodowane jest tym, że: 
      • We wtorek członkowie zespołu przychodzą wcześniej, aby przygotować środowiska (serwery, aplikacje) do Sprint Review, 
      • W środę jest duże natężenie spotkań planistycznych i pod koniec ludziom „mózgi przez uszy wypływają”.

    P.S. Tytuł zainspirowany jest pewnym wymaganiem, które widziałem (dzięki Darku J) w jednym z dokumentów SiWS do przetargu publicznego. Brzmiało ono następująco:
    „System powinien zarządzać czasoprzestrzenią”.
    Umocniło mnie to w przekonaniu, że jedynie „metodyki” zwinne są w stanie uratować obszar informatycznych przetargów publicznych. Przeraża mnie ile naszych ciężko zarobionych pieniędzy idzie w błoto. 

    "Dupa" na tablicy

    Posted by pOtrek - 0 komentarze



    Fizyczne tablice rządzą


    Większość z nas, praktyków arkan SCRUMowych, używa SCRUM board’ów jako reprezentacji Sprint Backlogu. Część korzysta z tablicy „analogowej”, powieszonej gdzieś w pokoju, część cyfrowej w postaci jakiegoś toola (np. JIRY). Ja osobiście jestem wielkim zwolennikiem tych pierwszych, ponieważ:
      • Stanowią naturalny punkt „zbiórki” dla zespołu, gdy trzeba przedyskutować plan działania,
      • Są niezastąpione podczas Daily Scrum’a i stanowią idealne tło dyskusji (wszyscy wiedzą, o czym mowa, mogą pokazać na karteczkę z konkretnym zadaniem, mogą wreszcie przejrzeć swoje karteczki, aby przypomnieć sobie nad czym ostatnio pracowali),
      • Wystarczy oderwać oczy od klawiatury, aby zorientować się w postępie prac (zamiast szukać odpowiedniego tab’a w przeglądarce),
      • Są zdecydowanie bardziej „elastyczne” niż jakikolwiek inny system elektroniczny,
      • Jest coś przyjemnego w „ręcznym” przesuwaniu karteczek… poważnie J

    Powiem szczerze, że ciężko mi sobie wyobrazić porządny Daily Scrum bez tablicy. No chyba, że z gigantycznym ekranem dotykowym J W sytuacji, gdy macie w zespole kilka osób „zdalnych” możecie utrzymywać jednocześnie tablicę analogową i cyfrową. Te kilka minut dziennie potrzebne na zsynchronizowanie tablic wydaje mi się śmiesznie małą ceną za wszystkie zalety fizycznych tablic, które wymieniłem powyżej (możecie również spróbować takiego toola: http://jimflow.jimdo.com).

    Elastyczna tablica, czyli nie bój się kolorów


    W dalszej części tego prosta chciałbym poruszyć temat „elastyczności” fizycznych tablic. SCRUM board nie musi wyglądać jak tabelka z kolumnami TODO, In Progress, Done, na której przyczepione są żółte karteczki. Macie cały zestaw wspaniałych narzędzi, które uczynią wasz product backlog bardziej czytelnym i przyjemniejszym w użyciu. Pamiętajcie, że karteczki typu post-it są dostępne w różnych kolorach, kształtach i rozmiarach. Wykorzystajcie to!! Pamiętajcie także, że możecie również skorzystać z wszelkiego rodzaju magnesów z obrazkami, naklejek, wydruków, żetonów z gry, odznak, awatarów, zdjęć, korowych taśm klejących, zakładek do książek, markerów… słowem jakichkolwiek przyborów papierniczych jakie wpadną wam w ręce. Ciekawy przykład: mój zespół potrzebował czegoś by oznaczać zadania  przy realizacji których pojawił się problem/blocker. Mieli do dyspozycji tylko „zwykłe” karteczki typu post-it oraz karteczki przylepne w kształcie serduszka, gwiazdki i księżyca. Żadna z nich nie specjalnie kojarzy się z problemem. Co zrobili? Wzięli serduszka przywiesili je do góry nogami i stwierdzili że od teraz symbolizują one „dupę” J. Na każdej takiej „dupie” pisali w kilku słowach na czym polega problem. Poniżej znajdziecie listę różnych sposobów modyfikacji zwykłej, szarej i nieatrakcyjnej tablicy SCRUMowej w użyteczną, czytelną i „fajną” jej wersję. Pomysły zaczerpnąłem z koncepcji, które stosujemy lub stosowaliśmy w naszym zespole jak i z podpatrzonych wśród innych zespołów.
    ·         Oznaczanie User Story kolorami – wszystkie zadania związane z jednym User Story zapisujcie na karteczkach w tym samym kolorze. Każde User Story (US) w ramach jednego Sprintu powinno mieć inny kolor. Dzięki temu dużo łatwiej ocenić ile zadań zostało do wykonania w ramach różnych US oraz widać nad jakimi US zespół aktualnie pracuje,
    ·         Wysokość US na tablicy określa jego priorytet w sprincie – US umieszczone najwyżej na tablicy mają najwyższy priorytet. Zespół (w ramach rozsądku) powinien zacząć pracę „od góry” tablicy i kontynuować „w dół”. Dzięki temu zmniejszy się ryzyko niedostarczenia kluczowych US,
    ·         Dodatkowe znaczniki na kartkach z zadaniami – stosuj znaczniki aby sygnalizować „specyficzne” statusy związane z zadaniami. Poza wspomnianą wcześniej „dupą” w naszym zespole stosowaliśmy również magnesiki z nadrukami, które używaliśmy do oznaczania następujących statusów: zadanie zblokowane, zadanie nie idzie zgodnie z planem, zadanie idzie bardzo źle, FUBAR. Magnesiki z własnymi „nadrukami” możecie zamówić za parę złotych na allegro,
    ·         Awatary reprezentujące członków zespołów – zamiast pisać kto wykonuje dane zadanie można przy tym zadaniu umieszczać wydruk awatara reprezentującego konkretnego developera. Awatary możecie zrobić tu, tu, tu lub skorzystać z tej listy,
    ·         Zasygnalizować maksymalną ilość zadań nad którymi zespół może równolegle pracować – czyli po ludzku WiP limit dla kolumny In progress. Można zrobić to na wiele sposobów: napisać w nagłówku kolumny jaki jest WiP limit, narysować miejsca na karteczki (tylko tam można umieszczać zadania), fizycznie ograniczyć ilość miejsca w kolumnie In progress.
    ·         Wielkość karteczki z zadaniem odpowiada wielkości zadania – tego jeszcze nie spróbowaliśmy w praktyce ale wydaje się być ciekawą koncepcją J

    Zachęcam do eksperymentowania z waszymi Sprint Backlogami. Pamiętajcie tylko, że nadrzędnym celem jest zwiększenie jego czytelności, a nie zrobienie go bardziej zbajerowanym.

    Nasz Sprint Backlog





    W naszym zespole do realizacji Sprint Backloga używamy białych tablic. Na tablicy z lewej strony wieszamy kartki (formatu A5) reprezentujące User Stories, w kolejności od góry do dołu (na górze są najbardziej priorytetowe US). Obok US umieszczamy zadania. Wszystkie zadania dotyczące jednej US są napisane na kartkach tego samego koloru. Zadania uporządkowane są od prawej do lewej strony, czyli najbliżej kolumny In progres znajdują się te, które najwcześniej będziemy robić. Kartka z zadaniem wygląda następująco:





    Dodatkowo, gdy zadanie jest gotowe do review, wpisujemy na niej literkę R, a obok niej osobę która zgłosiła się, aby wykonać Review. Nasz Spritnt Backlog ma tylko 3 kolumny: TODO, In progres i Done. Nie mamy kolumny Review oraz Test (często spotykanej w innych zespołach). Zamiast stanu Test mamy zadania typu Test. Powód jest prosty: testujemy funkcjonalności, a nie poszczególne zadania (typu dodaj kolumnę do bazy danych).


    Ramzes umarł, Kryzys żyje

    Posted by pOtrek - 0 komentarze


    Nasz proces deploymentu


    Apokaliptycznych wizji ciąg dalszy. Jak wspomniałem we wstępniaku, proces deploymentu nowych funkcjonalności jest dość skomplikowany. SCRUM’em objeliśmy jedynie fazę developmentu i testów na środowiskach developerskich. Reszta procesu wygląda (w pewnym uproszczeniu) mniej więcej tak:


    Dla tych którym nie chce się zagłębiać w powyższy diagram lista co ciekawszych właściwości procesu:
    1. Proces skomplikowany i przejście go trwa bardzo długo (średnio około miesiąca),
    2. Przez proces przepływają nowe wersje komponentów, a nie funkcjonalności (jedna funkcjonalność może wymagać zmiany w kilku komponentach),
    3. Spora część procesu znajduje się poza bezpośrednią kontrolą zespołu,
    4. Po stronie organizacji klienta istnieje trylion różnych zespołów IT, nad którymi nasz klient (sponsor, PO, zespół biznesowy) nie ma bezpośredniej kontroli (znajdują się w innym pionie organizacji).

    Problem


    Teraz najwyższa pora opisać jak to wyglądało w praktyce. Otóż przez proces przepływała olbrzymia ilość zgłoszeń o deploy komponentów. Część z nich utykała w różnych miejscach procesu, część  w ogóle ginęła w niewyjaśnionych okolicznościach, części nie udało się zainstalować z powodu braku innych komponentów, od których były zależne, wreszcie część jakimś cudem udawało się „przepchnąć” na środowisko produkcyjne. W tym ogólnym galimatiasie co jakiś czas zespół biznesowy ni stąd, ni zowąd rzucał jakąś datą: np. funkcjonalność XYZ ma być gotowa za tydzień bo umówiliśmy się z klientem na testy. Oczywiście funkcjonalność, mimo że gotowa od strony developerskiej, znajdowała się w bliżej nieokreślonym stanie w procesie deploymentu. Jednym słowem KRYZYS. W takich przypadkach zbieraliśmy sztab kryzysowy, zakasaliśmy rękawy i do roboty!! A robota polegała na szaleńczym „przepychaniu” zgłoszeń wszelkimi możliwymi sposobami… co oczywiście przynosiło skutek odwrotny od oczekiwanego i funkcjonalność „przechodziła” przez proces deploymentu jeszcze dłużej. Ramzes umarł, kryzys żyje!!!

    Rozwiązanie


    Ktoś mógłby powiedzieć, że fundamentalnym problemem jest tutaj „zasięg” SCRUM’a, który nie obejmuje procesu deploymentu. Niestety, mimo że takie podejście pozwoliło by nam rozwiązać większość wymienionych powyżej problemów, w naszym przypadku nie jest możliwe do zastosowania. Przeszkodami są tutaj:
    1. Zespół developerski nie ma kontroli nad sporą częścią procesu, 
    2. Proces trwa bardzo długo, a z powodu opisanego w punkcie 1. zespół developerski nie ma możliwości skrócenia go,
    3. Wydłużenie sprintów tak, aby mogły objąć development + deployment nie wchodzi w grę z powodu dużej dynamiki biznesu klienta (cały czas coś się zmienia, a długie, miesięczne sprinty spowodowałyby nieakceptowalną dla zespołu biznesowego „bezwładność” funkcjonalności).

    Debatując nad problemem doszliśmy do wniosku, że w naszej sytuacji najistotniejszą rzeczą, jaką musimy zrobić, jest opanowanie chaosu. Wszyscy muszą mieć wyraźny wgląd w aktualną sytuację, jaka panuje w procesie deploymentu. W świecie Lean Managementu istnieje oczywiście rozwiązanie naszego problemu i nazywa się Visual Management. Dodatkowo aby ułatwić wdrożenie nowego rozwiązania oraz uczynić go atrakcyjniejszym dla zespołu postanowiłem „ubrać go w szaty” zabawy. I tak powstała gra planszowa „Kryzys”. 


    Czym jest gra planszowa „Kryzys” ?


    Jest to pewna wariacja tablicy Kanbanowej (nie mylić z tablicami często wykorzystywanymi w SCRUM’ie do realizacji Sprint Backlogu), która reprezentuje nasz proces deploymentu. Przez pola przedstawiające poszczególne kroki procesu, wędrują żetony funkcjonalności (a nie tak jak do tej pory komponenty). Jednak w porównaniu do typowej tablicy Kanbanowej posiada ona kilka innych elementów. Są to:

    • Żetony „Kryzysu” (reprezentowane przez bombę atomową) – jeśli widzimy zagrożenie, że dana funkcjonalność może nie „przejść” procesu deploymentu na czas przypinamy do niej żeton „Kryzysu”,
    • Pole z Datami – które reprezentują daty dostarczone przez klienta,
    • Punktację dla graczy biorących udział w grze.

    Nasza tablica wygląda mniej więcej tak:


    Tura gry „Kryzys” odbywa się codziennie o stałej porze (za wyjątkiem dni planningów) i bierze w niej udział delegacja z zespołów: developerskiego, testerów i IT.

    Gorąco zachęcam też do zapoznania się z instrukcją do gry, którą znajdziecie w pliku poniżej:

    Instrukcja do gry "Kryzys"

    Problemy Wyzwania


    Visual Management pomógł nam opanować chaos, a przedstawienie pomysłu jako gry planszowej uczyniło to rozwiązanie atrakcyjnym dla zespołu. Należy jednak pamiętać, że dla developerów zarządzanie procesem deploymentu to zło konieczne, którym najchętniej w ogóle by się nie zajmowali. Dlatego z czasem entuzjazm w zespole osłabł, jako ScrumMaster musiałem (!?) pilnować, aby spotkania kryzysowe odbywały się regularnie, frekwencja również bardzo zmalała. Problemem również okazało się  wyciąganie (a właściwie to wydzieranie) dat i terminów od zespołu biznesowego. Niemniej jednak przedsięwzięcie uważam za bardzo udane… wprowadziliśmy je półtora roku temu i wciąż działa. Pomogło nam też zapobiec wielu poważnym  kryzysom.

    Przyszłość

    Dlaczego nie zastosowaliśmy Kanbana? Odpowiedź jest prosta: tak jak SCRUM, Kanban jest koncepcją prostą do zrozumienia, lecz trudną do stosowania, szczególnie dla zespołu biznesowego osadzonego w rzeczywistości korpo(racji). Gra „Kryzys” pozwoli na łagodne „wejście” w świat Kanbana… świat w stronę którego zmierzamy (przynajmniej w kwestii deploymentów, ponieważ oczywiście ze SCRUMa nie rezygnujemy). W tym momencie, gdy zaczniemy wprowadzać np. WiP limity, każdy zrozumie dlaczego to robimy. W końcu wielokrotnie podczas gdy w „Kryzys” widział jak ten czy tamten krok procesu korkuje się powodując znaczne utrudnienia dla wszystkich deploymentów.

    Wyciągnięte lekcje


    1.  W firmie/projekcie zmiany wprowadza się trudno i mozolnie. Dotyczy to szczególnie projektów, które mają styczność z rzeczywistością korpo(racyjną)
    2. Nie oznacza to, że nie warto próbować. Jeśli nie możesz przeskoczyć problemu to spróbuj go obejść
    3. Zmiany wprowadzaj małymi kroczkami (nie wszystko naraz)
    4.  Zespół zaadaptuje zmiany szybciej, jeśli spróbujesz ją uczynić dla nich … po prostu fajną (fun factor !!!)
    5. „Krzywa nauki” będzie mniej stroma, jeśli upewnisz się, że:
      1. Wszyscy wiedzą, dlaczego wprowadzamy zmianę / nowy element procesu
      2. Zasady są jasne i przejrzyste
    6. Przygotuj się na to, że w wypadku zmian typu „zło konieczne” zapał z czasem osłabnie.
    7. W świecie Agile poza SCRUM’em istnieją też inne frameworki. Większość z nich ma tą ciekawą właściwość, że nie wykluczają się nawzajem, lecz raczej uzupełniają (najczęściej stosowany mix to SCRUM + XP, ale nie jest to jedyna możliwość)



    Doomsday is coming

    Posted by pOtrek - 0 komentarze

    Geneza problemu


    Jednym z problemów, z którym boryka się mój zespół, jest dług technologiczny. System tworzony jest od kilku lat, w między czasie znacząco zmienił się jego zakres (łącznie z docelowym przeznaczeniem), oryginalny skład zespołu … czyli innymi słowy sporo „legacy code’u” i „ciekawej” (czytaj pokręconej) architektury. Gdy poruszyliśmy temat długu technicznego na retrospekcji okazało się, że pierwszym krokiem w celu poprawy sytuacji powinno być w jakiś sposób monitorowanie sytuacji. Tylko jak ? Narzędzia do statycznej analizy kodu (Sonar, checkstyle, fxcop) dają jakiś taki pogląd na jakość kodu ale to nie wystarczy. Nie są w stanie zobrazować sytuacji na poziomie architektury, nie wyłapią „quickfixów” i co bardziej kreatywnych „obejść problemów”.


    Rozwiązanie


    Wtedy wpadliśmy na pomysł Doomsday clock’u. Jest to koncepcja wymyślona w 1947 roku na Uniwersytecie Chicagowskim. Pomysł jest bardzo prosty: przy pomocy zegara przedstawić jak daleko jesteśmy od totalnej zagłady ludzkości w wyniku wojny nuklearnej. Gdy wybije północ rozpocznie się judgement day. Każde istotne wydarzenie (np. pakt rozbrojeniowy) zapisywane jest w rejestrze zegara, a jego wskazówki przesuwane są do przodu lub do tylu w zależności od tego czy skutki zdarzenia były pozytywne czy negatywne. Więcej o Doomsday clock tutaj: http://pl.wikipedia.org/wiki/Zegar_Zagłady
    Pomysł więc był prosty: monitorować dług technologiczny przy pomocy naszej wersji Doomsday clock’a.

       

    Jak zrobić Doomsday clock


    1. Kup najprostszy, najtańszy zegar ścienny (analogowy, nie cyfrowy ;) )
    2. Jeśli zegar ma szybkę to ją zdemontuj
    3. Dla zwiększenia efektu, podmień tarczę zegara na taką która w tle ma jakiś apokaliptyczny zegarek (my wydrukowaliśmy ją na kartce A4, wycięliśmy i wstawiliśmy do zegara)
    4. Zadbaj o to aby wskazówki były jak najbardziej widoczne (my obkleiliśmy końcówki wskazówek jaskrawym papierem kolorowym)
    5. Powieś zegar w pokoju w którym pracujecie
    6. Pod zegarem powieś dużą kartkę papieru na rejestr zegara (świetnie do tego nadaje się folia/tablica samoprzylepna http://styl-sklep.pl/biala_tablica_samoprzylepna,257,5177.html#.Uod-uFyoF0o)
    7. Gotowe !
    U nas wygląda to tak:






    Pytania i odpowiedzi


    Dlaczego wybraliście akurat taką formę monitorowania długu technologicznego ?
    Bo jest fajna :) Poważnie ! To jest bardzo istotny czynnik. Zespół dużo chętniej robi coś co sprawia mu przyjemność (nawet w odniesieniu do tak nieprzyjemnej rzeczy jak dług technologiczny)
    Czy zegar przedstawia „twarde, statystyczne dane” ?
    Oczywiście że nie. Zegar bazuje na intuicji zespołu. A intuicja przeważnie ma dużo więcej wspólnego z rzeczywistością niż twarde dane statystyczne :)
    Czy pokazujecie zegar swojemu klientowi ?
    Tak. Wytłumaczyliśmy koncepcję klientowi i zegar stanowi integralną część raportów prezentowanych Product Owner’owi. Oczywiście nie obyło się bez pytań typu ”a nie dało by się zaprezentować tego  „bardziej konkretnie” np. w postaci Story Pointów ?”
    Na którą godzinę ustawić początkową wartość zegara ?
    Koncepcja Doomsday clock opiera się na subiektywnej ocenie sytuacji. Nie ma tutaj jednoznacznej odpowiedzi. Im bliżej północy zaczniecie tym bardziej podkreślicie powagę sytuacji.
    O ile zmieniać wskazania zegara ?
    Tak jak przy odpowiedzi na poprzednie pytanie -  nie ma tutaj konkretnej zasady. Jeśli korzystacie przy estymacjach ze Story Point’ów dość łatwo do tego dojdziecie. Story Point’y określają relatywną wielkość funkcjonalności, zmiany wskazań zegara określają relatywny wpływ zdarzeń podczas sprintu na gromadzenie lub likwidowanie długu technicznego. Dla ułatwienia możecie zrobić sobie przykładowy „cennik” który posłuży wam jako punkt odniesienia.
    Co to jest sprint drift ?
    Podczas jednej z retrospekcji doszliśmy do wniosku, że w sytuacji, gdy podczas sprintu nie zrobiliśmy nic co wpływa na dług technologiczny (ani nic nie zepsuliśmy, ani też nie naprawiliśmy), tak naprawdę sytuacja się pogarsza. Powód: doszły nowe funkcjonalności, które trzeba utrzymać, a stary zakumulowany dług technologiczny tak jak bomba zegarową… wciąż tyka. Dlatego po zakończeniu tworzenia rejestru zegara na dany sprint dodatkowo przesuwamy wskazówkę zegara o stały interwał do przodu (w stronę północy)
    Kiedy aktualizować Doomsday clock ?
    Kiedy chcecie, ważne aby uczestniczył w tym wydarzeniu cały zespół. Możecie zrobić to podczas retrospekcji lub na osobnym, krótkim spotkaniu (najwygodniej umieścić je gdzieś między spotkaniami typu retrospekcja, sprint planning)


    Inne zegary


    Oczywiście koncepcję zegara możecie wykorzystać również na inne sposoby. Zespoły które uczestniczą w yourdon’owskim „Marszu ku klęsce” mogą rozszerzyć zegar do wszystkich zdarzeń mających kluczowe znaczenie dla projektu. Wówczas północ oznacza FUBAR (Fucked Up Beyond All Recognition/Repair). Zegar może również posłużyć jako wskaźnik nastroju zespołu lub nawet status prac nad całym projektem (godzina 12 – projekt został ukończony).  

    Dziel i zwyciężaj… bądź scalaj i zwyciężaj

    Posted by pOtrek - 0 komentarze


    Gdy dołączyłem do zespołu półtora roku temu jedną z pierwszych rzeczy, która zwróciła moją uwagę, były Daily Scrum’y. Wszystkie osoby uczestniczące w projekcie (a było ich 17) ustawiały się w kółku, które z powodu wielkości zespołu, zajmowało cały pokój. Następnie każdy recytował odpowiedzi na trzy pytania: „Co robił wczoraj ?” , „Co będzie robił dzisiaj” i „Czy ma problemy?”. A te odpowiedzi wyglądały mniej więcej tak: „Wczoraj pracowałem na ticketem XYZ, dzisiaj nadal będę pracował nad ticketem XYZ, problemów nie mam”. Gdy pojawił się problem cały zespół nad nim dyskutował. Po kilku takich spotkaniach uświadomiłem sobie że:
    • Daily SCRUM’y strasznie się przedłużają. Zajmowały często ponad 30 minut
    • Po zakończeniu spotkania tak naprawdę nie mam pojęcia co się dzieje w Sprincie
    • Członkowie zespołu byli zmęczeni i znudzeni („no nieeee… znowu Standup. Muszę na niego iść ?”)
    • Poszczególni developerzy koncentrowali się na wąskich obszarach (swoich ticketach)

    Aby potwierdzić moje obserwacje na końcu Daily SCRUM’a zacząłem zadawać niezręczne pytania typu: „Jasiu co dzisiaj będzie robił Krzysiu ?”, „Małgosiu jak idzie Jasiowi ?”, „Ludziska czy dowieziemy cały commitment ?”. Większość odpowiedzi potwierdzały moje przypuszczenia… coś było nie tak.
    Zacząłem kombinować jak można byłoby zwiększyć efektywność Daily SCRUM’ów, lecz za chiny ludowe nie mogłem wymyślić jak tego dokonać przy tak dużej ilości osób w zespole. I nagle uświadomiłem sobie, że kluczowym elementem jest właśnie ta „duża ilość osób”. Rzecz wydawałoby się oczywista, lecz jak to często bywa, ciężka do zauważenia wśród nawarstwienia innych problemów. Zacząłem więc zastanawiać się nad podziałem zespołu. Pojawiły się dwa problemy. Pierwszym z nich było wymyślenie jak to zrobić. Najpopularniejszą techniką jest oczywiście „Scrum of Scrums”. Słyszałem jednak wiele negatywnych opinii na jej temat i nie byłem przekonany, czy sprawdzi się w naszym przypadku. Drugim problemem był strach. Zespół współpracował z sobą przez długi czas i był ze sobą zżyty. Nie pomagała też spora liczba publikacji które przeczytałem i opisywały zjawiska typu „synergia zespołu” i „team glue”. Właśnie wtedy w moje ręce wpadła książka Craiga Larmana „Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum”. Opisywał on  w niej ciekawe podejście do tego problem, które prezentuje obrazek poniżej. 

    Na retrospekcji przedyskutowałem problem z zespołem i razem ustaliliśmy nasz wariant implementacji tego modelu. Wygląda on następująco:
    1. Mamy jednego Product Ownera i jeden Product Backlog. Sprint Planning I przeprowadzamy razem jako jeden zespół
    2. Po Sprint Planningu I dzielimy się na 2-3 zespoły. Dostosowujemy wielość i skład zespołów do User Stories, które potencjalnie chcemy zrobić w tym sprincie (te informacje mamy z SP I)
    3. Rozdzielamy User Stories na zespoły
    4. Każdy zespół przeprowadza swój własny Sprint Planning II i posiada swój własny Sprint Backlog 
    5. Jest jeden Scrum Master  dla wszystkich zespołów
    6. Każdy zespół ma swoje własne Daily Scrumy. Członkowie innych zespołów mogą „wpaść z wizytą” na Dialy Scrumy innych zespołów (jako kurczaki)
    7. Demo i Retrospekcje przeprowadzamy wspólnie
    8. Przy groomingu dzielimy się na zespoły, lecz nie muszą to być te same zespoły które realizują aktualny Sprint
    9. Wprowadzamy rolę Feature Owner’a (FO). Jest to stricte techniczna rola odpowiednik technical team leadera ograniczona do jednego obszaru systemu.

    Jak widać nie wykorzystaliśmy bezpośrednio modelu przedstawionego przez Larmana, lecz wprowadziliśmy
    nasze własne zmiany, aby lepiej dostosować go do naszych realiów. Najważniejsze z nich to:  
    • Zostawiliśmy tylko jednego Scrum Mastera, aby zwiększyć efektywność prac. Łączenie roli SM z rolą Developera w naszym przypadku to kiepski pomysł, ponieważ kontakty z zespołem biznesowym miały tendencję do zabierania 100% czasu osoby zaangażowanej. SM zaczął stanowić filtr pozwalający zespołowi wykonywać swoją pracę bez ciągłych „przeszkadzajek” ze strony zespołu biznesowego.
    • Dynamicznie zespoły zmieniające się co sprint pozwoliły nam zachować integralność zespołu (prędzej czy później każdy będzie pracował z każdym) oraz lepiej dostosować się do planów Product Ownera przedstawionych na Sprint Planningu I
    Oczywiście nie ma róży bez kolców. Przy podziale na zespoły narzuciłem pewne ograniczenia:
    •  Zespół musi liczyć minimum 3 osoby
    • Zespół musi siedzieć razem w jednym pokoju (nasz projekt ma do dyspozycji dwa pokoje)
    Kontrowersje budził szczególnie ten drugi punkt. Na początku trudno było „odkleić” niektóre osoby od miejsc na których siedziały przez ostatni rok.  Nie pomagały również procedury firmowe, które wymagały formalnego przekazywania kluczy do pokoi z podpisaniem oficjalnego „świstka” (a.k.a. protokołu zdania i odbioru). Prowadziło to na początku do kłótni, które trwały czasem ponad godzinę zanim zespół się podzielił. Poruszyliśmy ten temat na retrospekcji i cały zespół ustalił następujące rozwiązanie: gdy po 15 minutach nie udaje się stworzyć zespołów (i co ważniejsze miejsc siedzenia :P ) jedna osoba arbitralnie ustala podział (ten „zaszczyt” przypadł mnie).   I powiem szczerze, że od tamtej retrospekcji bardzo rzadko musiałem interweniować.
    Na koniec inna sytuacja związana z podziałem zespołów. Jakiś czas temu na korytarzu zaczepił mnie kolega z pracy, który prowadzi dwa małe projekty. Zapytał mnie w jaki sposób powinien zorganizować product baclogi tych projektów, aby mieć większą kontrolę nad nimi. Zaproponowałem, aby połączył oba backlogi w jeden. On jednak poszedł o krok dalej i połączył zarówno backlogi jak i zespoły (liczące 2-3 osoby). Po jakimś czasie stwierdził, iż było to tak naturalne rozwiązanie, że aż dziw bierze że nie wpadł na to wcześniej. Teraz ma większą kontrolę nad projektem, lepszy przepływ wiedzy między ludźmi oraz potencjalnie mniejsze problemy w okresie wakacyjnym.

    Z opisanych sytuacji ja wyciągnąłem następujące lekcje:
    • Warto zastanowić się nad strukturą zespołu. Czy odpowiada aktualnej sytuacji w twoim projekcie?
    • „Najciemniej pod latarnią” . Czasem potencjalnie najbardziej oczywiste rozwiązania są najtrudniejsze do zauważenia
    • Strach przed zmianą jest jednym z największych wrogów zwinności
    • Techniki i metody opisywane w różnych źródłach (książkach, artykułach, blogach ;)) niech będą dla Ciebie inspiracją a nie procedurą postępowania. Nie bój się eksperymentować.