Agile Surfing

Podoba mi się jak zorganizowana jest przestrzeń w biurze mojego zespołu.

W tym wpisie zamieszczę kilka zdjęć wraz z opisem.

Jeśli odwiedziłbyś mnie w moim biurowcu i udalibyśmy się do mojego pokoju, to pierwsze co byś zobaczył to drzwi wejściowe. Na drzwiach wisi tzw. elevator pitch (co i po co robimy?) naszego projektu oraz tzw. burn-up chart (jak nam idzie?).

Świetnie, a więc wchodzisz i kierujesz uwagę na ścianę po lewej stronie. Widzisz nasz „story wall„:

Nasze user story wędrują przez fazy „W analizie”, „Gotowy do implementacji”, „W implementacji”, „Gotowy do testowania”, „Testowany”, „Gotowy do zaakceptowania”, „Zaakceptowany”. Każdy członek zespołu ma swojego Avatara, który znajduje się przy historyjce nad którą aktualnie dana osoba pracuje.

Kolory mają znaczenie.. Mógłbyś zapytać jakie, więc spoglądasz trochę bardziej w lewo. Widzisz legendę:

W legendzie widać: „historyjki”, „błędy”, „historyjki czysto techniczne”, oraz symbol „zablokowania”.  Oprócz tego widzisz kto aktualnie jest poza biurem (nikt, wszyscy obecni). Kolejnym elementem są tak zwane „akcje”, czyli zadania, które trzeba wykonać, a nie związane bezpośrednio z user stories. Może to być na przykład zadanie polegające na rezerwacji stolika na wieczorną imprezę integracyjną zespołu. Na każdym zadaniu przyklejona jest karteczka z informacją kto jest za nie odpowiedzialny. Codziennie po porannym stand-upie akcje są przeglądane.

Obracasz się w przeciwną stronę i widzisz drzwi, które pokryte są masą karteczek:

Na białej planszy na środku drzwi znajduje się tzw. team charter(jakie ogólne zasady panują w naszym zespole, czego od siebie oczekujemy, co jest celem naszego zespołu). Na niebieskich karteczkach znajdują się różne informacje zebrane w początkowej fazie projektu (zidentyfikowane zagrożenia dla projektu, założenia poczynione podczas planowania, nasze zewnętrzne zależności – jak na przykład inny zespół pracujący nad czymś co jest nam potrzebne).

Ostatnim elementem na który zwracasz uwagę jest kalendarz:

Z kalendarza możesz dowiedzieć się kto i kiedy ma zaplanowane wakacje oraz zobaczyć uciekający czas (i zbliżający się deadline).

By śledzić nasz postęp używany też Jiry, czyli narzędzia do chowania informacji w „lodówce na dane” (komputerze). Ktoś kiedyś napisał, że trzymanie user-story w komputerze jest trochę jak trzymanie karteczek samoprzylepnych w środku lodówki zamiast na jej drzwiach. Trochę się z tym zgadzam, dużo bliższe mojemu sercu są koncepcje opisane na tym blogu. (Oczywiście Jira ma swoje zastosowania: dane historyczne, rozproszone zespoły..)

To już wszystko.. O tym dlaczego prawie przy każdym biurku są dwa krzesła i dwie klawiatury opowiem Ci innym razem.

Update

Po komentarzu Herbiego postanowiłem opisać trochę dokładniej nasz burn-up chart. Oto on:

Kilka faktów na jego temat:

• Burn-up chart dotyczy naszego realeasu, nie iteracji
• Uaktualniamy go co sprint, czyli co tydzień
• Czerwona pionowa linia pokazuje gdzie aktualnie jesteśmy (w czasie)
• Pomarańczowa krzywa pokazuje „optymalne” spalanie, takie, które pozwoli nam zdążyć na deadline
• Mamy różne definicje „gotowego” przy czym najważniejsze oczywiście jest „gotowe do wdrożenia” (fioletowy kolor, na samym dole). „Przetestowane” to zielony, „zaimplementowane” to pomarańczowy, „gotowe do implementacji” to niebieski.

Jeśli chodzi o podział historyjki na taski (techniczne) to dokonuje go para przy przenoszeniu z „gotowy do implementacji” do „implementowany”. Same taski pełnią raczej rolę pomocniczą.

Jeśli chodzi o różne fazy gotowe, to tworzy to ciekawy setup, gdzie powiedzmy na demo pokazujemy 1-3 historyjki „gotowe do wdrożenia”, ale w tym samym czasie mogą już być zaimplementowane 2 kolejne, które zostaną przetestowane w następnym sprincie. Wstępnie wydaje mi się, że jest to lepszy setup niż sprinty 2 tygodniowe (gdzie zdążylibyśmy napisać i przetestować), bo deweloperzy mogą mieć lepszy „flow”. W konfiguracji 2 tygodniowej pod koniec sprintu jest coraz mniej do roboty (albo łatamy błędy), a tutaj deweloperzy pracują w swoim stałym tempie „marszowym”. Burn-up pozwala nam kontrolować czy nasze tempo marszowe jest takie, że zdążymy, a story board pozwala wykryć problemy z drożnością systemu (gdyby na przykład dużo historyjek kumulowało się w stanie „gotowy do przetestowania”, świadczyłoby to o za małej ilości testerów).

Brak podobnych wpisów.

Tagi: agile, visual management

Ten wpis został opublikowany piątek, 18 Luty 2011 o 21:39 i jest zaszufladkowany do kategorii Agile. Możesz śledzić wszystkie odpowiedzi do tego wpisu poprzezkanał RSS 2.0. Możesz dodać odpowiedź lub trackback ze swojej strony.