Planowane i nieplanowane prace w Scrum
Wiekszosc zespolow, ktore zaczynaja pracowac z Scrumem, rozumie swoj Backlog i tzw. „zaplanowane prace". Sa to prace, ktore wszyscy wspolnie zebrali i ktore w pelni rozumieja. A potem jest caly ten pozostaly brak... Na te rzeczy nowe zespoly Scrum musza zwracac uwage w swoim pierwszym Sprincie. Wszystkie rzeczy, ktore wykonuja niezaleznie od zaplanowanych prac w tym Sprincie, sa wymienione z liczba godzin potrzebnych do ich wykonania w kolumnie „niezaplanowane prace".
Po pierwszym Sprincie zespoly sa czesto calkowicie zaskoczone, ile tego sie zbiera. Zazwyczaj sa to rozne zadania, ktore wykonuje sie od zawsze kazdego dnia lub tygodnia – czesto nazywamy je zadaniami „Business-as-Usual" (BAU), ale w innych firmach moga nosic inne nazwy. Sa tez spotkania ad-hoc i inne rzeczy, ktore robimy bez wiekszego zastanowienia. Moga to byc zadania BAU lub po prostu przeszkody i prze rwania.
Sa tez naglosci, ktore musza zostac natychmiast zalatwione. Czesto wchodzi to pod „wsparcie" – ale mogloby tez nosic kazda inna nazwe.
Niektore z tych rzeczy sa nam juz znane podczas Sprint Planningu. Wtedy dodaje sie je do Sprint Backlogu jako czesc zobowiazan. Jesli pojawiaja sie one stale, mozna sie zastanowic nad utworzeniem dla nich osobnej kolumny i rezerwowaniem pewnych mocy na te rzeczy.
Co robic z niezaplanowanymi pracami w Scrum?
Zaplanuj spotkanie, aby dokladniej przyjrzec sie nawracajacym zadaniom i dowiedziec sie, jak mozna poprawic z nimi prace. Celem jest ich zautomatyzowanie lub przynajmniej jak najwieksze zmniejszenie.
Elementy, ktorych nie mozna uwzglednic w Sprint Planningu, to te, ktore pojawiaja sie dopiero w Sprincie i nie mozna ich przewidziec. Nazywamy je „unplanned" (niezaplanowane). Kazdy zespol ma czesc takich niezaplanowanych prac i musi dowiedziec sie, jak sobie z nimi radzic. Tutaj rowniez nalezy regularnie zastanawiac sie, co mozna zrobic, aby jak najbardziej zmniejszyc te niezaplanowane prace. Im wiecej niezaplanowanej pracy ma zespol, tym mniej pracy mozna jeszcze dodatkowo przejac. Idealnie wiekszosc pracy zespolu Scrum powinna byc planowana. Kazdy zespol musi zbadac swoje mozliwosci i dowiedziec sie, jak najlepiej z nimi pracowac.
Oto kilka metod, ktore widzialem juz w zespolach:
Limity i zasady
Kazda niezaplanowana praca jest odnotowywana na tablicy i priorytetyzowana. Jednak kolumna Work-in-Progress ma limit, ile prac mozna jednoczesnie podejmowac, np. dwa. Mozna wiec jednoczesnie pracowac tylko nad dwoma roznymi rzeczami. Reszta zespolu moze sie wtedy skupic na zaplanowanych pracach dla Sprintu. Mozna rowniez okreslac zasady, ktore niezaplanowane elementy mozna wpisac na tablice i kiedy itd.
Jedna osoba dziennie/tygodniowo/na Sprint
Mozna tez stworzyc plan okreslajacy, kto jest kiedy wyznaczony do pracy nad niezaplanowanymi rzeczami. W ten sposob rowniez reszta zespolu moze skupic sie na zaplanowanych pracach. Jesli ta osoba czegos nie rozumie lub ma problem, moze prosic innych czlonkow zespolu o pomoc. Mozna sie przy tym zmieniac codziennie, co tydzien lub przy kazdym Sprincie.
Okreslone okno czasowe
Mozna rowniez wyznaczyc okno czasowe na niezaplanowane prace. Moze to byc np. miedzy 9:00 a 11:00, reszta dnia roboczego jest zarezerwowana dla elementow Sprintu.
Stale dni
Mozna tez zaplanowac okreslone dni tygodnia na prace nad niezaplanowanymi rzeczami – np. wtorek i czwartek. Wszystkie inne dni robocze sa przeznaczone tylko na zaplanowane prace.
Zespoly Scrum moga sie zmieniac
Jesli kilka zespolow Scrum pracuje nad tym samym Backlogiem, zespoly moga zmieniac sie nawzajem w pracy nad niezaplanowanymi rzeczami. Zespol A pracuje wiec w tym Sprincie tylko nad niezaplanowanymi elementami, a zespol B nad elementami Backlogu.
Z pewnosciadostrzegles, ze we wszystkich przykladach zespolom jest dany konkretny czas na prace nad elementami Backlogu. Nie ma stalego wzorca i z pewnosciaistnieja jeszcze wiecej mozliwosci niz wymienione powyzej. Jesli masz rowniez ten problem, po prostu wyprobuj kilka z tych propozycji i dowiedz sie, co najlepiej dziala dla Ciebie.
Niniejszy tekst pochodzi z bloga Growing Agile i zostal nam udostepniony.
