Empiryzm w życiu codziennym

Prawie jak Ironman

Prawie jak Ironman

Empiryzm reprezentuje pogląd, iż wiedza wynika z doświadczania i podejmowania decyzji w oparciu o to co poznane.” – taką definicję empiryzmu znajdujemy w polskim tłumaczeniu Scrum Guide’a.

Ta naukowo brzmiąca formuła ilustruje postawę, z którą spotykamy się – mniej lub bardziej świadomie – w życiu codziennym.

Postawmy się na chwilę w roli osoby, który zamawia kilka przykładowych produktów, spełniających jej wyimaginowane potrzeby.

Przykład A

Zamówiłeś garnitur u krawca. Czy chciałbyś go przymierzyć, zanim pojedziesz w nim na ślub przyjaciela? Czy słowa krawca „na pewno będzie ładnie leżał” są dla Ciebie wystarczająco przekonujące, aby zapłacić za niego 2 tys. PLN?

Chciałbym jednak przymierzyć. Krawiec mnie nie przekonał.

Przykład B

Zleciłeś stworzenie projektu wnętrza domu, którego rozpocząłeś właśnie budowę. Czy chciałbyś zobaczyć wizualizację pomieszczeń – choćby naszkicowaną na papierze – zanim ekipy wykonają adaptację? Czy stwierdzenie projektanta „doskonale czuję Pańskie potrzeby” jest dla Ciebie wystarczającym zapewnieniem, aby zapłacić 6 tys. PLN i przekonać się, czy faktycznie się zrozumieliście odbierając klucze od domu?

Chciałbym jednak zobaczyć wizualizację. Nie wiem, czy projektant dobrze mnie zrozumiał.

Przykład C

Zamówiłeś aplikację webową w firmie deweloperskiej. Czy chciałbyś zobaczyć swoją aplikację, zanim Twoi klienci zaczną jej używać? Czy zapewnienie szefa programistów „robiliśmy już coś takiego, będzie Pan zadowolony” pozwala Ci w spokoju zapłacić 30 tys. PLN, czekając na efekt finalny?

Chciałbym jednak zobaczyć mały, ale działający wycinek aplikacji już za tydzień. Nie jestem pewien, czy dobrze się zrozumieliśmy.

Konkluzja

Zanim idea, którą przekazujemy drugiej osobie, zostanie przez nią odebrana, ulega zniekształceniu. Na drodze pomiędzy naszymi myślami, słowami, tym co usłyszała druga strona oraz jak to zrozumiała i odniosła do swojej rzeczywistości, pojawiają się uproszczenia, zakłócenia oraz modyfikacje.

Przedstawienie uproszczonego produktu, przygotowanego w krótkim odcinku czasu może być parafrazą tego, jak zostaliśmy zrozumiani – empirycznie doświadczymy tego, jak nasze idee zostały uchwycone.

Przymierzymy garnitur i przekonamy się, czy „elegancki krój” znaczy dla nas to samo.

Obejrzymy szkice projektu wnętrza i dowiemy się, czy „minimalistyczne wnętrze” odbieramy w ten sam sposób.

Uruchomimy pierwszą wersję aplikacji i sprawdzimy, czy „prosty formularz” zrozumieliśmy w identyczny sposób.

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

Swarming – technika dla zespołu pomagająca kończyć zadania

Swarming w praktyce

Swarming w praktyce

Pomagałem ostatnio nowo powstałemu zespołowi podczas ich drugiego Sprintu. Kiedy się u nich pojawiłem – dzień przed Sprint Review – na tablicy korkowej wisiało 10 zadań, z czego tylko 1 było zakończone. Co więcej, było to zadanie znajdujące się na ostatniej pozycji ich Sprint Backlogu.

Podczas rozmowy ze Scrum Masterem tego zespołu dowiedziałem się, że mają problem z finalizowaniem zadań oraz, że to kolejny sprint, kiedy dużo pracy jest w trakcie realizacji, a pomimo tego niewiele jest faktycznie skończone.

Co to jest swarming?

Zaproponowałem użycie techniki zwanej swarming (ang. rój). Polega ona na tym, że w danym momencie cały zespół pracuje nad jedną, wybraną historyjką i nie przechodzi do kolejnej, zanim poprzednia nie zostanie zakończona.

Jak podzielić się pracą?

Oczywiście od razu pojawiło się pytanie – „no dobrze, ale jak zorganizować pracę, żeby wszyscy mieli co robić?”. Poniżej kilka przykładów pracy, która może zostać wykonana równocześnie w ramach pracy nad jednym zadaniem:

  • przygotowanie scenariuszy testowych
  • zdobycie brakującej wiedzy biznesowej potrzebnej do realizacji zadania
  • napisanie unit testów
  • konfiguracja środowiska testowego (zapewnienie danych, połączeń do zewnętrznych systemów, konfiguracja)
  • nagranie testów automatycznych (początkową będą świecić na czerwono)
  • opracowanie planu prezentacji przyrostu na Sprint Review
  • przyglądnięcie się zadaniu z perspektywy Definition of Done
  • programowanie w parach
  • konsultacja rozwiązania z innymi deweloperami (spoza zespołu)

Na co zwrócić uwagę?

  • rozmiar zadania – zbyt małe zadanie może powodować, że trudno będzie sensownie podzielić się pracą; z drugiej strony zbyt duże może spowodować, że w rzeczywistości każdy zajmie się swoim, niezależnym fragmentem większej historyjki
  • liczba jednocześnie realizowanych zadań – spotkałem się z wariantem „dwie historyjki na raz” oraz „tyle historyjek na raz, ilu testerów w zespole”

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