Pomysł na Planowanie Sprintu – praca w grupach

Pomysł na Planowanie Sprintu w grupach

Pomysł na Planowanie Sprintu w grupach

Najczęstszym zaobserwowanym przeze mnie sposobem na przeprowadzenie drugiej części Planowania Sprintu jest następujący scenariusz: Scrum Master wspomaga Zespół Deweloperski, który pracując jako jedna całość, przygotowuje plan wykonania Sprintu.

Po kilkudziesięciu planningach przeprowadzonych w ten sposób, można zaproponować alternatywne podejście planowania, aby spotkanie to nadal było przyjemnym sposobem na przygotowanie się do Sprintu, a nie nudnym i powtarzalnym obowiązkiem.

Jaki jest pomysł na drugą część Planowania Sprintu?

Planowanie Sprintu w grupach.

Co potrzebujemy?

  • wydrukowane lub rozpisane na kartkach Historie Użytkownika
  • bloczek kartek samoprzylepnych
  • kilka kartek A4
  • kilka pisaków/długopisów
  • pomieszczenie ze stołami

Jak przebiega Planowanie?

  1. Dzielimy Zespół na dwie grupy
  2. Zadania wstępnie przyjęte na Sprint dzielimy równo pomiędzy nowo powstałe grupy
  3. Każda grupa opracowuje plan wykonania Sprintu dla otrzymanych Historii Użytkownika, wynikiem czego powinien być ogólny zarys najbliższej pracy do wykonania oraz oszacowane zadania techniczne
  4. Po upłynięciu określonego wcześniej czasu, grupy kończą pracę i pierwsza z grup przedstawia efekty swojej pracy
  5. Druga grupa zadaje pytania oraz dyskutuje zaproponowane rozwiązanie
  6. Następuje zmiana grup – ta, która dotychczas słuchała, przedstawia swoje rozwiązanie, natomiast ta, która prezentowała efekty swojej pracy, zadaje pytania oraz dyskutuje
  7. Grupy łączą efekty swojej pracy w jedną całość i upewniają się – już jako połączony ponownie Zespół – czy na skutek rozbicia na dwie grupy, nie zostało utracone globalne spojrzenie na problem

Na co zwrócić uwagę?

  • grupy powinny być w miarę porównywalne pod względem umiejętności
  • czas przeznaczony na poszczególne etapy trzeba sumiennie mierzyć, aby płynnie przejść wszystkie fazy

Zdjęcie: Grant Cochrane / FreeDigitalPhotos.net

Wspaniały zespół czy grupa świetnych ludzi?

Wspaniały zespół czy grupa świetnych ludzi?

Wspaniały zespół czy grupa świetnych ludzi?

Znam zespół (A), który składa się z świetnych specjalistów. Są wszechstronnie rozwinięci technologicznie, bardzo inteligentni, a suma ich umiejętności pozwala rozwiązać każdy przedstawiony im problem. Każdy z nich to indywidualista, często tak silny, że potrafi zdominować całą grupę.

W innym zespole (B), funkcjonuje grupa solidnych, rzetelnych deweloperów. Potrafią rozwiązywać problemy w jednej, głównej technologii, posiadając ogólną wiedzę na temat innych rozwiązań. Rozwiązują problemy na nieco niższym poziomie abstrakcji, aniżeli zespół A.

Zespół A ma problemy, żeby dostarczyć działający software na koniec Sprintu.

Zespół B dostarcza gotowe oprogramowanie w każdej iteracji.

Jaka jest różnica?

A to tylko grupa ludzi. B to prawdziwy zespół.

Subtelna różnica, która decyduje o efektach. Zespół przeciętnych, solidnych deweloperów jest w stanie zrobić o wiele więcej, niż grupa gwiazd. Przykład celowo przedstawiłem jaskrawo.

Kiedy efekty pracy nie osiągają poziomu, do którego dążymy, warto zastanowić się, czy jednym z powodów nie jest fakt, iż pracujemy tak naprawdę (jeszcze) z grupą, a nie z prawdziwym zespołem.

Zdjęcie: hinnamsaisuy / FreeDigitalPhotos.net

„Marsz ku klęsce” – Eward Yourton

Marsz ku klęsce - Eward Yourton - okładka

„Marsz ku klęsce”, Eward Yourton

Na tytułowy „Marsz ku klęsce” trafiłem zupełnie przypadkiem, przeglądając rekomendacje, które podsunął mi Amazon.

Po kilku kliknięciach wiedziałem już, że książka została wydana również w Polsce. Nie zrażając się okładką – która jasno komunikuje, że została zaprojektowana w czasach, kiedy zamiast kanałów RSS czytało się Bajtka – kliknąłem „Kup Teraz”, ciesząc się, że już za kilka dni, książka wyląduje na mojej półce.

Autor – uznany autorytet w dziedzinie inżynierii oprogramowania – skupia się w tej pozycji na analizie projektów, które z racji niekorzystnego kontekstu oraz kontrowersyjnego przydziału zasobów określa „marszami ku klęsce”.

Zdaniem autora, często nie mamy wpływu na to, że projekt, który otrzymaliśmy do zrealizowania, musi zatonąć. Dzieje się tak z wielu powodów – politycznych, organizacyjnych czy personalnych. Przez całą książkę stara się wskazać, co możemy zrobić, aby pomimo niesprzyjających warunków, doprowadzić takie projekty z sukcesem do końca.

Jeżeli liczysz, że znajdziesz w tej książce liczne wskazówki techniczne, zapewne poczujesz się rozczarowany. Przede wszystkim, książka została napisana ponad dekadę temu, stąd magia związana z pewnymi pojęciami (Windows 95, COBOL, CASE, itp.) dawno przestała czarować. Tak naprawdę, w książce bardziej chodzi o ludzi oraz relacje aniżeli narzędzia oraz techniki. Pomimo tego, znalazłem naprawdę doskonały, ponadczasowy cytat techniczny, który świetnie oddaje idee ciągłej integracji:

„Codzienne budowanie jest jak bicie serca projektu. Dzięki niemu wiemy, że żyjemy” – Jim McCarthy, Microsoft

Jeśli natomiast poszukujesz typowo miękkich aspektów, związanych z ludzkim podejściem do realizacji projektów, będziesz zadowolony. Okazuje się, że mentalność ludzka nie zmienia się tak szybko jak technologia, stąd pewne obserwacje dotyczące ludzi są ponadczasowe.

To co mi się podoba, to fakt, iż autor celnie wskazuje pewne typy zachowań, które możesz spotkać w zespołach, z którymi realizujesz projekty.

Przykładowo – z jednej strony ukazuje nam młodych, niedoświadczonych programistów, z przesadnym, szczeniackim wręcz optymizmem, którzy propagują wiarę, że prawdziwi programiści nie śpią (mentalność komandosa), a weekendy uznają za świetny czas, aby usiąść do kodu.

Z drugiej strony, przedstawia doświadczonych developerów, którzy przeszli już w życiu kilka marszy ku śmieci, mają rodzinę na utrzymaniu oraz kredyty do spłacenia. Łatwo się domyślić, że weekend planują spędzić z rodziną i ciężko będzie ich przekonać, aby przyjechali w niedzielę do pracy naprawiać bugi.

Tego typu obserwacji, wychodzących poza horyzont umiejętności technicznych zespołu projektowego, można znaleźć więcej – i to w mojej ocenie jest najsilniejszą stroną tej pozycji.

Przy okazji, warto zdać sobie sprawę z faktu, że w czasach, gdy w USA realizowano setki innowacyjnych projektów informatycznych rocznie, w Polsce na zwykły telefon stacjonarny czekało się średnio kilka lat. Gdy w naszych sklepach wymieniano kartki na kiełbasę, zza wielką wodą ludzie zjadali zęby na projektach programistycznych. Doświadczenie, jakie w tamtym czasie zbierano w USA, jest bezcenne. Dlatego pomimo, iż narzędzia programistyczne zdążyły się kompletnie zmienić, lekcje nabyte w tamtych projektach – szczególnie te dotyczące aspektów miękkich – pozostają nadal aktualne. I możemy do nich sięgnąć dzięki takim książka jak ta.

Dużym plusem jest bogata bibliografia, która przewija się przez całą książkę. Lista zalecanych pozycji jest naprawdę imponująca i choć trudno łudzić się, że są to pozycje dostępne w Polsce, warto poświęcić chwilę i wyszukać je w zagranicznych sklepach lub portalach aukcyjnych. Daleko nie szukając – parę dni temu zamówiłem „Slack” Toma De Marco za 7 euro i co więcej, przesyłka do Polski była darmowa.

Jeśli miałbym szukać minusów, to byłyby to głównie kwestie kosmetyczne. Skład książki pozostawia wiele do życzenia – czuć po prostu, że czytamy pozycję, która ma już swoje lata. Zwrot „projekt na drodze ku klęsce” pojawia się co drugie zdanie, co po przeczytaniu połowy książki zaczyna irytować. Odnośniki do listów od czytelników, na które powołuje się autor, sprawiają wrażenie oderwanych od kontekstu i są przedstawione chaotycznie.

Nie zmienia to jednak faktu, że jest obowiązkowa pozycja książkowa, szczególnie dla tych, których każdy kolejny projekt to marsz ku zagładzie – wyczerpujący, wypalający, wyniszczający. W tej kwestii auto nie pozostawia złudzeń – może to po prostu sygnał, że czas zmienić pracę?

Moja ocena: 4/5

Drugie dno szacowania

Większość osób nie lubi szacować pracy. Uzyskane wyniki bardzo często bywają błędne, stąd wielu z nich nie widzi większego sensu w szacowaniu, skoro finalnie i tak okazuje się to wyłącznie spekulacją. Idąc dalej, obawa przed możliwością niewywiązania się z obietnicy powoduje, że mało kto lubi odpowiadać na pytania o czas potrzebny na wykonanie pracy.

Warto dostrzec jednak drugie dno szacowania, a mianowicie okazję do wymiany oraz pogłębienia wiedzy dotyczącej konkretnego zagadnienia. Korzyść ta jest szczególnie wyraźnie widoczna w samowystarczalnych, interdyscyplinarnych zespołach.

Jak to wygląda w praktyce?

Dowolne wymaganie poddawane jest szacowaniu na dwóch poziomach:

  1. Historii Użytkownika (wysokopoziomowe), oraz
  2. zadań technicznych (niskopoziomowe).

Szacowanie Historii Użytkownika

Wyobraźmy sobie przykładową Historię Użytkownika:

Jako Użytkownik chcę mieć możliwość dodania przedmiotu do koszyka, tak abym mógł go kupić.

Zespół, po zapoznaniu się w wystarczającym stopniu z wymaganiami, korzystając np. z Planning Pokera, określa złożoność zadania. Padają następujące wartości:

3, 3, 1, 8

Wygląda na to, że członkowie Zespołu różnie określają złożoności zadania. Rozpoczyna się dyskusja. Osoba, która szacowała złożoność na 1, omawia dlaczego jej zdaniem jest to jedynka. Następnie osoba odpowiedzialna za oszacowanie złożoności na 8, przedstawia swój punkt widzenia. Po zakończonej dyskusji, Zespół ponownie szacuje skomplikowanie zadania:

3, 5, 3, 5

Ze względu na dalszą rozbieżność wyników, następuje kolejna runda szacowania. Uczestnicy znów podają swoje wartości. Cykl ten trwa to tak długo, aż Zespół, na skutek wymiany wiedzy, dojdzie do porozumienia w kwestii złożoności konkretnego zadania.

Ze względu na zgrubny charakter tych oszacowań, nie ma konieczności, aby poświęcać na tego typu szacowanie zbyt dużej ilości czasu.

Szacowanie zadań technicznych

Kiedy mogło by się wydawać, że mamy już gotowe oszacowanie, a poziom ogólnej wiedzy w Zespole jest zadowalający, przechodzimy do drugiej fazy szacowania. Zespół dekomponuje Historię Użytkownika na zadania techniczne, i tak dla wspomnianego wyżej przykładu otrzymujemy przykładowe zadania:

  • przygotowanie warstwy prezentacji
  • stworzenie logiki biznesowej
  • zrealizowanie testów
  • refaktoryzacja istniejącego kodu

Dla tych konkretnych zadań technicznych, Zespół podaje szacowany czas pracy w godzinach. I znów, kiedy widać duże rozbieżności w proponowanych wartościach, Zespół dyskutuje o konkretnym zadaniu technicznym tak długo, aż zostanie osiągnięte porozumienie.

Ze względu na fakt, iż zejście na poziom zadań technicznych oznacza, że zadaniem będziemy zajmować się w najbliższej perspektywie (iteracja, Sprint), wskazane jest aby dokonać tych oszacować z większą precyzją, aniżeli w przypadku zgrubnego szacowania Historii Użytkownika.

Podsumowanie

Warto traktować szacowanie pracy nie tylko jako narzędzie dostarczające konkretne wartości liczbowe przydatne do planowania, ale także jako okazję do pogłębienia wiedzy o wymaganiach w Zespole. Dodatkowo, członkowie Zespołu mogą się wiele od siebie nauczyć – szczególnie, jeśli dysponują różnym doświadczeniem, a platforma na której pracują jest skomplikowana.