8

Praca w wielu początkujących zespołach scrumowych wygląda podobnie. Programiści prawie przez cały sprint kodują, a później testerzy nie mają czasu, żeby dobrze przetestować wyniki ich pracy.

Dzisiaj pokażę Wam 3 proste sposoby, jak możecie poradzić sobie z tą sytuacją.

1. Skróć czas przekazywania zadań.

Pierwszy sposób polega na skróceniu czasu przekazywania zadań przez programistów testerom. Dobry zespół scrumowy każdego dnia sprintu powinien robić po kawałku wszystkiego. Trochę analizy, trochę projektowania, trochę programowania i trochę testów. Tylko wtedy praca takiego zespołu jest naprawdę wydajna.

Na początku oczywiście, nie jest to łatwe. Bo trzeba oderwać się od „starego” myślenia. W tradycyjnym, kaskadowym podejściu do tworzenia oprogramowania, byliśmy przyzwyczajeni do pracy sekwencyjnej. Najpierw była analiza, potem powstawał projekt, później ruszała implementacja, dalej testy, a na końcu był czas na wdrożenie i utrzymanie. W Scrumie jest inaczej.

Im bardziej „zrównoleglamy” pracę, tym lepiej. Krótki czas przekazywania zadań pomiędzy poszczególnymi członkami zespołu zwiększa efektywność wykonywania zadań w sprincie.

Weźmy na przykład programistę i testera, którzy nigdy wcześniej nie pracowali w Scrumie. To jest oczywiście tylko przykład. Równie dobrze moglibyśmy się tutaj skupić na każdej innej roli w zespole – analitykach, projektantach interfejsu użytkownika, inżynierach baz danych itp.

I jeżeli nasz przykładowy programista i tester są nowicjuszami, którzy dopiero zaczynają swoją przygodę w Scrumie – to jest bardzo możliwe, że programista przypisze się do jakiejś historyjki użytkownika, będzie nad nią pracował przez tydzień lub dwa, i dopiero pod koniec sprintu przekaże ją do testów.

To nie jest dobre podejście. Na tym przykładzie jak na dłoni widać, że czas oczekiwania testera na zadania gotowe do testów jest niemożliwie długi. Programista nie powinien czekać aż skończy wszystkie swoje zadania, związane z daną historyjką i dopiero wtedy przekazywać je do testów. Zamiast tego, powinien wysyłać zadania testerowi małymi porcjami. Jak tylko coś jest gotowe, od razu powinno trafić do testera. W ten sposób, jego czas oczekiwania na zadania bardzo się skraca.

I na tym właśnie polega ZEN pracy w Scrumie. Musicie umożliwić jej swobodny przepływ pomiędzy poszczególnymi rolami w zespole.

Weźmy na przykład taką historyjkę:

Jako użytkownik muszę mieć możliwość zalogowania się do konta, żeby mieć dostęp do swoich danych.

Dla tak zapisanej historyjki, możemy zdefiniować następujące kryteria akceptacyjne:

• Jeżeli poprawnie wpiszemy dane logowania, to mamy dostęp do naszego konta
• Możemy zalogować się za pomocą konta facebookowego
• Jeżeli błędnie wpiszemy dane logowania, to wyświetli nam się komunikat o błędzie
• Jeżeli zapomnieliśmy hasła, to korzystając z adresu email możemy go zresetować

Teraz pokażę Wam jak praca nad taką historyjką może wyglądać w dojrzałym zespole scrumowym.

Na początku, programista i tester siadają wspólnie i zastanawiają się jak najlepiej zorganizować swoją pracę. Ustalają, że w pierwszej kolejności skupią się na pierwszym kryterium akceptacyjnym:

• Udzielanie dostępu do konta, po uprzednim poprawnym zalogowaniu się użytkownika

Prace ruszają. Programista koduje swoje pierwsze zadania. W tym czasie, tester przygotowuje plan testów, dopieszcza scenariusze i przypadki testowe, również pisze skrypty do automatyzacji testów.

Jak widzicie, nikt tutaj nie próżnuje. Jak tylko pierwsza porcja zadań jest gotowa, programiści od razu przekazują je do testów. Tester, ponieważ ma już przygotowany grunt do działania, bez chwili zwłoki może testować.

Kiedy programista i tester wykonają swoją pracę, integrują jej wyniki i odpalają automatyczny proces budowania i testowania.

Kolejny krok jest bardzo podobny. Programista i tester, znowu wspólnie zastanawiają się nad czym będą dalej pracować i jak zorganizują swoją pracę. Idąc za ciosem, wybierają następne kryterium akceptacyjne:

• Logowanie za pomocą Facebooka

Dalej, schemat postępowania jest bardzo podobny. Kiedy programista koduje, tester przygotowuje plany testów, opracowuje scenariusze i przypadki testowe, pisze skrypty do testów automatycznych.

I nikt tutaj nie ma „wolnych przebiegów”. Pomiędzy jedną a drugą porcją zadań, które programista oddaje do testów, każdy ma co robić. Programista i tester cały czas pracują nad swoimi zadaniami, które dotyczą tej samej funkcjonalności.

2. Wizualizuj problemy.

Drugi sposób, to wprowadzenie dodatkowego wykresu, który w prosty i przejrzysty sposób pokaże Wam, czy prace w sprincie idą w dobrym kierunku.

W wielu wypadkach, dyskusja z zespołem na temat podejścia nr 1 może wystarczyć. Ale nie zawsze tak jest. Niektóre zespoły potrzebują bardziej namacalnych dowodów 😉

Wtedy, dobrze jest zastosować drugą praktykę, która polega na wizualizacji problemów. Chodzi o problemy, które wynikają z niewłaściwego przepływu pracy w zespole.

Żeby to zrobić, wystarczy wprowadzić jeden dodatkowy wykres.

Ten wykres pokazuje liczbę skończonych elementów Backlogu Produktu w ciągu jednego dnia sprintu. To, co widzicie na wykresie, to bardzo typowy scenariusz, z którym boryka się większość zespołów scrumowych na etapie startu.

Przez pierwszy tydzień sprintu i połowę drugiego, żadna funkcjonalność nie jest jeszcze gotowa. Sytuacja zmienia się dopiero w ciągu dwóch ostatnich dni sprintu. Kiedy wszystkie funkcjonalności są już zrobione.

Jak zwykle robię tak, że tego typu wykres wieszam tuż obok tablicy scrumowej zespołu lub wykresu spalania sprintu. I znikam 😊

Nigdy nie robię za dużo szumu wokół wieszania tego wykresu, bo nie ma takiej potrzeby. Ludzie, wcześniej czy później sami zaczną dyskutować o tym, co dzieje się na wykresie. Wystarczy tylko, że regularnie, dzień po dniu, będziecie ten wykres aktualizować. A magia zadzieje się sama.

Ludzie zaczną przechodzić obok tego wykresu, zaczną o nim dyskutować. I, w pewnym momencie, sami zobaczą, że z ich sprintem dzieje się coś złego.

A jeżeli zespół ignoruje sytuację na wykresie (chociaż zdarza się to naprawdę rzadko), dobrze jest zadać ludziom z zespołu proste pytanie:

Co możemy wspólnie wymyśleć, żeby przynajmniej kilka historyjek dało się skończyć w sprincie?

3. Wypróbuj nowe techniki pracy zespołowej.

I wreszcie trzeci sposób, polega na zastosowaniu praktyki „swarmingu”, dzięki której Wasz zespół nauczy się lepiej ze sobą współpracować.

„Swarm”, to angielskie słowo, które oznacza roić się lub tłoczyć się. Można więc powiedzieć, że technika „swarmingu”, to taka technika rojenia się zespołu.

„Swarming” polega na tym, że w danym momencie, CAŁY zespół pracuje tylko nad jedną historyjką użytkownika. Zamyka ją i dopiero wtedy przechodzi do następnej.

Ta technika ma naprawdę bardzo dużą moc. Dzięki niej zespół może lepiej poczuć, na czym polega praca zespołowa w Scrumie. Ludzie lepiej poznają swoje kompetencje. Uczą się samoorganizacji. Chętniej się komunikują i wymieniają doświadczeniem. Ale, UWAGA! „Swarmingu” nie można stosować zbyt długo. Ja zwykle robię to przez jeden lub co najwyżej dwa sprinty. Zwykle na początku, kiedy zespół uczy się Scruma.

Stosowanie techniki „swarmingu” przypomina trochę lekcje pływania. Nie wiem jak Wy, ale ja bardzo późno nauczyłem się pływać – dopiero na studiach. Miałem bardzo profesjonalnego instruktora z krakowskiej AWF. Chłopak był naprawdę świetnym pływakiem, z sukcesami (miał 2 rekordy Polski na swoim koncie).

I pamiętam, że jedno z ćwiczeń, które wykonywałem, polegało na tym, że przez określony dystans płynąłem z dłońmi zaciśniętymi w pięści. Później je rozluźniałem i płynąłem normalnie kraulem.

Wielu z Was pewnie teraz puka się w czoło. Jak to? Przecież tak się nie pływa? No właśnie. Tak się nie pływa, ale dzięki temu ćwiczeniu nauczyłem się lepiej wyczuwać wodę. To ćwiczenie pomogło mi lepiej zrozumieć ruch, jaki wykonywała moja ręka, kiedy pociągała i odpychała się od wody.

I bardzo podobnie jest z praktyką „swarmingu” w Scrumie. Dzięki niej zespół może poczuć, na czym polega praca zespołowa. Jeżeli wszyscy ludzie w zespole będą pracować tylko nad jednym elementem Backlogu Produktu w danym momencie, to chcąc nie chcąc, będą musieli nauczyć się lepiej ze sobą współpracować. Lepiej planować swoją pracę i dekomponować ją na mniejsze części. Poznają kto, w czym jest dobry. Uczą się samoorganizacji.

Mam nadzieję, że te 3 praktyki pomogą Wam lepiej organizować swoją pracę w sprintach. Pamiętajcie, że Scrum jest drogą ciągłego doskonalenia, której fundamentem jest empiryzm. Dzięki temu, każdy kolejny sprint jest lepszy od poprzedniego 😉

***

Na koniec mam jeszcze krótkie ogłoszenie. Kilka dni temu wystartowała sprzedaż mojego autorskiego szkolenia dla osób, które nie pracują w branży IT – „Scrum dla Zielonych”. Jest to szkolenie otwarte, które w takiej formie udostępniam (w zależności od swojego czasu) tylko 2-3 razy w roku. Jeżeli uważacie, że ktoś z Waszych znajomych byłby zainteresowany, poślijcie proszę tę wiadomość dalej w świat. Sprzedaż potrwa jeszcze tylko kilka dni.

Scrum dla Zielonych

Nie wiesz, czym jest Scrum? Jakie zasady nim rządzą? Do czego możesz go wykorzystać w swojej firmie? W jaki sposób wpłynie na sukces Twojego zespołu i prowadzonych projektów? O czym mówią działy IT w Twojej firmie?

Jeżeli zadajesz sobie podobne pytania, to dobrze trafiłeś. Bo właśnie dla takich osób stworzyłem ten kurs. Osób, które nigdy wcześniej nie pracowały w Scrumie i chcą poznać jak wykorzystać tę metodę w praktyce.

„Scrum dla Zielonych” to 1-dniowe otwarte szkolenie, które przygotowałem z myślą głównie o OSOBACH NIETECHNICZNYCH, takich które chcą poznać Scruma – pracowników działów HR, sprzedaży, marketingu, administracji, organizacji pozarządowych oraz wszystkich, którzy chcą zgłębić tajniki pracy w tej metodzie.

Sprzedaż szkolenia „Scrum dla Zielonych” kończy się 16 września. Jeżeli jesteś zainteresowany nie zwlekaj, bo zostało już tylko kilka wolnych miejsc.

Wszystkie niezbędne szczegóły, program, znajdziecie na stronie scrumdlazielonych.pl

Start szkolenia: 15 października, 2018, Kraków