Słów kilka na temat pracy w Scrumie…
Zastanawiałem się jakiego rodzaju tematu do tej pory z Wami nie poruszyłem. Robiąc sobie kawę doszedłem do wniosku, że może warto by zainspirować się czymś co miałem na uczelni. Poszedłem do komputera i spojrzałem na listę przedmiotów z 5 semestru studiów (bo ten wspominam najprzyjemniej), padło na skrótowiec IP czyli Inżynierię Programowania. Lubiłem ten przedmiot, lecz odczuwam do tej pory wielki niedosyt. Liczyłem, że dostaniemy jakieś fajne świeże informacje, rzeczywistość wyglądała tak, że uczyliśmy się o rzeczach na dziś dzień raczej historycznych. Stwierdziłem, że przedstawię Wam najprawdopodobniej najpopularniejszych framework pracy - Scrum. Na zakończenie tego lekko przydługiego wstępu dodam, że pracowałem w firmie gdzie byłem obecny od braku Scrum do uformowania się go w około 80% zgodnego z definicją. Zaczynajmy!
Zacznijmy od wyjaśnienia czym tak właściwie jest Scrum. W dużym uproszczeniu jest to plan naszej pracy oraz podział obowiązków w teamie. Spróbuję to opisać w kilku punktach:
Scrum wyróżnia 3 role:
Product Owner - osoba znająca potrzeby klienta i priorytety.
Scrum Master - jak wskazuje nazwa mistrz Scruma, dba o przestrzeganie zasad i o to, żeby wszystkim dobrze się pracowało.
Zespół Scrumowy - to rola zbiorowa, reprezentuje ona wszystkie osoby należące do temu.
Zespół powinien liczyć 6 (+/- 3 osoby), czyli minimum 3, a maksimum 9.
Działa na odpowiedzialności grupowej. Zadania są przypisane do zespołu, nie do konkretnych osób.
W Scrumie wszyscy są równi, nie ma roli ważniejszej. Są one po prostu inne i skupiają się na różnych zadaniach.
Głównym założeniem, które uznano za rewolucyjne była/jest praca iteracyjna. Celem jest oddawanie “potencjalnie sprzedawalnych elementów” klientowi w jak najkrótszych odstępach czasu.
Działa na “sprintach” czyli powtarzalnym cyklu pracy. Jeden sprint może trwać maksymalnie miesiąc.
Sprinty powinny mieć stałą długość - takie są zalecenia.
W Scrumie wyróżniamy następujące spotkania:
Daily - odbywa się codziennie, biorą w nim udział wszyscy członkowie zespołu (czas: 15 min)
Sprint Planning - odbywa się przed każdym sprintem, wtedy zespół deklaruje ile pracy wykona.
Sprint Review - jest to spotkanie z klientem, odbywa się po zakończonym sprincie. Zespół pokazuje ile pracy wykonał w sprincie.
Sprint Retrospective - odbywa po zakończeniu sprintu w zamkniętym gronie. Zespół podsumowuje tam swoją pracę, rozmawia o sukcesach i przyczynach porażki.
DoD - czyli Definition of Done, jest to podstawa dobrze działającego Scruma. Jeśli dobrze określisz warunki jakie musi spełniać zadanie by uznać je za zakończone, to otrzymasz realny obraz pracy jaką możesz wykonać.
Scrum zakłada, że zespół działa jak mała firma. W skład zespołu wchodzą ludzie o różnych specjalnościach.
Dobrze działający Scrum przynosi przyrost wartości produktu co sprint - nie powinna zaistnieć sytuacja, że sprint to tylko poprawianie bugów, o których połowa użytkowników nie wie.
Scrum wyróżnia Product oraz Sprint Backlog, są to miejsca gdzie lądują zadania jakie będą wykonywane. Odpowiedzialność za Product Backlog spoczywa na Product Ownerze, zaś za Sprint Backlog na całym zespole.
Mam nadzieję, że udało mi się choć trochę przybliżyć Ci to czym jest Scrum. Teraz powiem Ci jak z perspektywy programisty zmieniła się moja praca i atmosfera w biurze po procesie wdrożenie Scruma w mojej firmie.
Gdy przyszedłem do firmy byłem mocno zielony, pod opieką starszego programisty zacząłem pisać kod. Firma była wtedy nieduża (około 30 osób), co jakiś czas prezes do nas zaglądał żeby upewnić się czy aby na pewno pracujemy i przy okazji dorzucić jakieś nowe, wyjątkowo pilne wymaganie. Pewnego dnia do prezesa przyszedł “szef programistów” i powiedział, że chciałby spróbować wdrożyć Scrum i zobaczymy jak to będzie działało. Prezes o mało nie spadł z krzesła, gdy usłyszał że ma nas puścić “samopas” na 2 tygodnie (tyle miały wynosić sprinty), ale po długich rozmowach ostatecznie się zgodził - “Dwa miesiące i zobaczymy co z tego wyjdzie, chcę raport co miesiąc.”
Początki nie były łatwe (nigdy nie są), prezes z przyzwyczajenia zaglądał i dorzucał pomysły, które w jego opinii były super pilne. Nasz PO (product owner) próbował brać go na klatę, ale nie zawsze był na posterunku i w pierwszym sprincie wpadły 2 wrzutki. Sprint był oczywiście źle zaplanowany (zawsze tak jest na początku, bo nie znamy swoich możliwości) i byłby totalną klapą, gdyby nie fakt że udało się nam wykonać jedną rzecz potencjalnie sprzedawaną. Przyszedł czas review (Sprint Review), prezes był lekko zaskoczony - oczekiwał raportu na koniec miesiąca, a tu w połowie już go zapraszamy na spotkanie. Mimo porażki jaką ponieśliśmy prezes był zadowolony, że dostał coś co może sprzedawać - pewnie byłoby mniej fajnie gdyby nie była to jedna z jego wrzutek. W kolejnych sprintach było trochę lepiej, wpadła tylko jedna wrzutka i robiliśmy coraz więcej (to nie jest do końca prawdą, po prostu lepiej planowaliśmy). Prezes zaczął zyskiwać zaufanie do nas, a my z powodu nieco większego luzu zaczęliśmy pracować efektywniej - w końcu można było się skupić na jednej robocie do wykonania. Podniosła się także jakość naszego oprogramowania, zaczęliśmy znajdować czas na testy i poprawianie bugów - a także zmniejszyła się liczba “wykonywanych”.
Specjalnie dla Android.com.pl
Łukasz Bednarczyk