Dot voting, czyli nadawanie priorytetów głosując kropkami

Przykładowe głosowanie kropkami

Przykładowe głosowanie kropkami

Podczas Retrospektyw, często dochodzimy do momentu, kiedy konieczne jest wybranie obszarów, nad których poprawą zespół będzie pracował w kolejnych Sprintach. Skutecznie przeprowadzone spotkanie powinno zaowocować dużą liczbą pomysłów, spośród których trzeba wybrać kilka najważniejszych.

Możemy podejść do tego problemu w różny sposób, na przykład nadając priorytety pomysłom. Istnieje jednak inny, bardzo prosty sposób, który dodatkowo silnie angażuje zespół, a mianowicie – głosowanie kropkami (ang. dot voting).

Co potrzebujemy?

  • duże arkusz papieru, najlepiej z możliwością przyklejenia na ścianę (ew. tablica suchościeralna)
  • pisaki / długopisy

Jak przebiega dot voting?

  1. Przedstawiamy zespołowi listę pomysłów (usprawnień, obszarów, scenariuszy, itp.) które zostały wypracowane podczas Retrospektywy i zapisane na dużym arkuszu papieru
  2. Każdy uczestnik otrzymuje pisak i możliwość postawienia określonej liczby kropek przy wybranych pomysłach
  3. Moderator (najczęściej Scrum Master) zlicza głosy – „wygrywają” pomysły, które otrzymały największą liczbę głosów

Na co zwrócić uwagę?

  • liczba kropek do dyspozycji każdego uczestnika wynika z ustalenia przed rozpoczęciem głosowania – nie ma tutaj szczególnych reguł,
  • można głosować raz na określony pomysł, albo wzmacniać ważność jednego konkretnego, oddając na niego więcej niż jeden głos,
  • technikę można wykorzystać na każdym innym spotkaniu, podczas którego konieczne jest np.: wyłonienie zwycięskich pomysłów, nadanie priorytetów zdarzeniom, wybranie najważniejszych obszarów do poprawy, itd.

Fotografia użyta na licencji Creative Commons od użytkownika mikecogh.

Scrumowa checklista każdego Scrum Mastera

Scrum pod mikroskopem

Scrum pod mikroskopem

Trzy główne filary Scruma to przejrzystość, inspekcja oraz adaptacja. W dużym uproszczeniu oznacza to konieczność systematycznej oceny prowadzonych działań oraz wprowadzania usprawnień.

Pomocnym narzędziem w tym przypadku będą wszelkiego rodzaju listy kontrolne, których przeanalizowanie pozwala zastanowić się nad kondycją Scruma w naszym środowisku. Mogą być też przydatnym narzędziem w rozwoju świadomego Scrum Mastera.

W internecie bardzo łatwo można znaleźć kilka tego rodzaju list. Poniżej parę najbardziej popularnych:

 

  • The unofficial Scrum Checklist by Henrik Kniberg– chyba najbardziej znana i najczęściej używana lista, sensownie podzielona na obszary, pozwala przyglądnąć się Scrumowi na rożnych poziomach, uwzględniając również rekomendowane, choć niewymagane praktyki
  • Joe’s Unofficial Scrum Checklist – checklista bazująca na liście Henrika Kniberga, rozbudowana i przedstawiona w formie opisowej. Można stosować jako interesujący zamiennik.
  • Nokia Test aka „the ScrumButt Test” – krótki, treściwy test od Jeff’a Sutherland’a. Wyniki można zsumować oraz próbować interpretować. Czasem tych kilka prostych pytań wystarczy, aby zainspirować do działań.
  • An Example ScrumMaster’s Checklist – Michael James proponuje swój zestaw pytań, który pomaga w ocenie kondycji naszego procesu. Pokrywa pewne obszary, których nie znajdziemy na poprzednich listach.

Oczywiście listy te należy traktować zdroworozsądkowo. Mogą być one wartościowe dla Scrum Mastera, który – jako osoba odpowiedzialna za proces – może zidentyfikować słabe punkty i dokonać niezbędnych modyfikacji.

Listy te mogą okazać się również ciekawym wkładem na Retrospektywę Zespołu.

Teoretyzowanie oraz spekulacja w tworzeniu oprogramowania

Obiektyw (real foto)

Obiektyw (real foto)

Odkąd pamiętam, na biurku znajomego w pracy stał obiektyw.

Fotografia była jedną z jego pasji, więc bardzo często można było go zobaczyć z aparatem w ręku. Czasem fotografował osoby z zespołu, innym razem uwieczniał przedmioty dostępne w biurze. Raz używał lustrzanki z „rybim okiem”, kiedy indziej aparatu w telefonie.

Wielokrotnie zwracałem uwagę na wspomniany obiektyw, jednak nigdy tak naprawdę się mu nie przyglądnąłem. Wyglądał profesjonalnie, posiadał najróżniejsze przełączniki oraz pokrętła, które wprawdzie niewiele mi mówiły, ale upewniały mnie w przekonaniu, że to poważny sprzęt.

Zastanawiałem się czasem, po co tak właściwie trzyma ten obiektyw w pracy? Do głowy wpadały mimowolnie różne scenariusze.

Przecież sprzątaczka może o niego zahaczyć podczas sprzątania przestrzeni biurowej, spadnie i uszkodzi się. Nie martwi się o to?

Sądziłem, że tego typu sprzęt trzyma się w etui, tak aby nie osadzał się na nim kurz. Po co więc stoi i kurzy się na biurku?

Znajomy podczas luźnych rozmów bezmyślnie brali obiektyw do rąk, oglądali go z różnych stron i odkładali na miejsce. Przecież mógł im wypaść z rąk, nie pomyślał o tym?

Wielokrotnie w ciągu ostatnich kilkudziesięciu miesięcy zaprzątałem sobie głowie podobnymi analizami.

Wczoraj sam wziąłem wspomniany obiektyw do rąk. Okazało się, że nie był prawdziwy obiektyw, tylko plastikowy kubek, który wyglądał jak obiektyw.

Dlaczego o tym piszę?

Podobną analogię obserwuję w wytwarzaniu oprogramowania.

Dokładnie zgłębiamy wymagania biznesowe, które za chwilę mogą ulec zmianie. Wybiegamy daleko w przód, zastanawiając się, jakie problemy mogą nas spotkać za pół roku. Przygotowujemy szczegółowe makiety interfejsu graficznego na podstawie naszych wyobrażeń i wizji. Spekulujemy, czego potrzebują nasi użytkownicy. Spędzamy czas optymalizując kod, aby już dziś być gotowym na obciążenie, którego być może nigdy nie doświadczymy. Poświęcamy czas na teoretyczne rozważania, zamiast szybko oddawać mniejsze, gotowe funkcjonalności i przekazywać je do użytkowników w celu otrzymania informacji zwrotnej.

Często okazuje się, że rzeczywistość jest zupełnie inna, niż sobie wyobrażaliśmy. Nasze założenia okazują się błędne. Niepotrzebnie brnęliśmy w ślepe uliczki.

Czy naprawdę nie chcemy dowiedzieć się o tym wcześniej?