Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

O Scrumie słów kilka...

Jak kiedyś tworzyło się oprogramowanie? Firma dostała dokument z wymaganiami klienta, wyceniała, po akceptacji zabierała się do pracy, po np. roku dostarczała gotowe rozwiązanie które rzadko było tym czego oczekiwał klient. Można temu jakoś zapobiec? Tak, można wytwarzać oprogramowanie przy pomocy technik zwinnych, np Scruma.

Na czym to wszystko polega?

Praca w Scrumie polega na powtarzających się sprintach (iteracjach) podczas których zespół skupia się na zadaniach, które zostały zaplanowany na dany okres. Sprint kończy demo podczas którego klientowi przedstawiamy nowe funkcjonalności. Na spotkaniu ustala się priorytety na następny sprint i wszystko się powtarza.

Manifest Zwinnego Tworzenia Oprogramowania

Wytwarzając oprogramowanie i pomagając innym w tym zakresie,
odkrywamy lepsze sposoby wykonywania tej pracy.
W wyniku tych doświadczeń przedkładamy:

  • Ludzi i interakcje ponad procesy i narzędzia.
  • Działające oprogramowanie ponad obszerną dokumentację.
  • Współpracę z klientem ponad formalne ustalenia.
  • Reagowanie na zmiany ponad podążanie za planem.

Doceniamy to, co wymieniono po prawej stronie,
jednak bardziej cenimy to, co po lewej.

Występujące role

Podczas wytwarzania oprogramowania najliczniejszą grupą stanowią programiści, testerzy i inni członkowie zespołu pracujący nad projektem. W Scrumie można znaleźć osoby z dodatkowymi obowiązkami.

Właściciel Produktu (Product Owner) - przedstawiciel klienta, który odpowiada za kontakt z całym zespołem, ustala priorytety zadań, odpowiada na pytania, tłumaczy niejasności, podejmuje decyzje wpływające na projekty lub kieruje do osób (ze strony klienta) które pomogą w danym problemie.

Pracą całego zespołu kieruje Scrum Master, który odpowiada za organizację całego procesu, umawianie spotkań, dba o “rytuały Scruma” oraz rozwiązuje problemy zespołu.

Rytułały w Scrumie

Planowanie

To spotkanie z product ownerem i wybranie funkcjonalności systemu, które chcemy dostarczyć klientowi w najbliższej iteracji. Historyjki (jak często nazywa się kolejne elementy systemu) spisane są w backlogu i stamtąd według priorytetów wybierane są elementy na najbliższy sprint. Zespół skupia się tylko na tych wyborach lecz jest świadomy odległego celu jaki chce osiągnąć klient, np zbudowanie nowego Facebooka.

Daily standup / daily meeting

Codzienne spotkania o ustalonej przez zespół zawsze tej samej godzinie. Podczas nich każdy członek odpowiada na trzy pytania:
-co robił od poprzedniego standupu?
-co zamierza robić w najbliższych godzinach?
-czy coś blokuje jego pracę?
Spotkania te pozwalają codziennie każdemu członkowi być na bieżąco z informacjami co dzieje się w projekcie. Umożliwia to bardzo dobry przepływ informacji, unikanie powtarzania czynności oraz znalezienie szybko pomocy w rozwiązaniu danego problemu.

Demo wewnętrzne

Często przed demem z klientem zespół podsumowuje swoją pracę w danym sprincie i sprawdza czy wszystkie funkcjonalności działają poprawnie. Umożliwia to wychwycenie elementów, które wymagają jeszcze poprawy i ostatnie poprawki.

Demo

Spotkanie z klientem, podczas którego demonstrujemy pracę wykonaną w danym sprincie.

Retrospekcja

Podsumowanie pracy zespołu i jej analiza. Na spotkaniu próbuje się znaleźć przyczynę niepowodzeń, elementy, które sprawdziły się podczas sprintu lub wskazanie zachowań, których brakowało. Podsumowaniem retrospekcji powinny być cele na następny sprint. Cele mogą być bardzo różne, np:
-zwiększenie pokrycie kodu testami,
-częstsza rozmowa z klientem umożliwiająca doprecyzowanie funkcjonalności.
-aktualizacja komponentów projektu,
-pilnowanie elementów Scruma.

Warto aby cele zostały spisane i omówione na następnej retrospekcji, czy zostały osiągnięte jeśli nie dlaczego itp.

Długość sprintu

Długość interacji ustalana jest przez zespół wraz z klientem. Moim zdaniem dwa tygodnie to optymalny wybór na organizację wszystkich rytuałów oraz dostarczenie nowych funkcjonalności.

W przypadku tygodnia, gdy planujemy pracę np. w poniedziałek pozostają nam trzy pełne dni pracy i demo w ostatnim dniu. Jest to krótki okres i często bardzo nerwowy.

Natomiast 3 i 4 tygodnie zbyt rozwleka cały proces. “Mamy przecież jeszcze 3 tygodnie…”. Informację zwrotną od klienta dostajemy o wiele rzadziej co uniemożliwia tak szybkie reagowanie na zmianę priorytetów. Tak samo jeśli w czasie sprintu klient będzie chciał prowadzić nową rzecz, trzymając się reguł Scruma gdzie nie dorzucamy nowych elementów podczas trwania sprintu możemy ją zaplanować dopiero na najbliższym planowaniu i pokazać gotową za np miesiąc.

Task Board

Całym sprintem zarządza się na tak zwanym Task Boardzie. Widać na nim wszystkie historyjki wraz z podziałem na zadania. Na poniższym screenie widać przykład. Każda historyjka (w dolnym rogu) posiada Story Pointy, jest to abstrakcyjna liczba świadcząca o trudności zadania. Jeśli zadanie jest podobne do wcześniej już wykonywanych lub zespół ma doświadczenie w tej dziedzinie zadanie będzie raczej proste czyli np 1, 2 lub 3. Jeśli zadanie wymaga użycia nowej biblioteki do integracji z portem kosmicznym może wymagać to więcej pracy i być dużym wyzwaniem.

Przy każdym zadaniu widać wartość liczbową. Jest to oszacowany przez zespół czas, który zajmie wykonanie danego zadania. Na planowaniu po rozpisaniu historyjek na zadanie następuje głosowanie nad wyceną zadań. Każdy z zespołu podaje swoją liczbę i następuje krótka dyskusja na ten temat. Może stać się tak że ktoś zaproponuje gotową bibliotekę które skróci czas pracy do 2 godzin gdy reszta zespołu szacowała cały dzień. W innym przypadku bardziej doświadczony programista może wskazać problemy na które można się natknąć w danym zadaniu i przekonać zespół aby zarezerwować więcej czasu na dany problem.

Inne zastosowania Scruma

Scruma można stosować nie tylko podczas budowania nowego systemu. Sprawdza się on bardzo dobrze przy już wdrożonym i działającym projekcie gdzie podczas sprintów dodajemy nowe funkcjonalności lub rozbudowujemy już gotowe.

Można go także stosować w takich obszarach jak sprzedaż gdzie są ustalane cele i codziennie zespół sprzedawców omawia co robił w celu np pozyskania nowego klienta.

Podsumowanie

Pracuję w Scrumie od prawie roku i bardzo go sobie chwalę. Problem stanowią czasem osoby nieprzestrzegające reguł gry i próbujące przepchać swoje wymagania podczas rozpoczętego trwającego już sprintu.

Moje doświadczenie może nie jest olbrzymie ale jeśli coś Was zaintersowało lub macie pytania piszcie. Powyższy tekst to tylko zajawka całego Scruma, można o nim na pewno napisać o wiele więcej

Linki, które warto odwiedzić:

 

programowanie inne

Komentarze

0 nowych
Songokuu   14 #1 28.04.2015 23:22

Ciekawy temat. Chociaż nie jestem programistą ale dłubie ostatnio sporo w Arkuszach kalkulacyjnych i też z tego wychodzą "prawie" aplikacje. Może się przydać także u nas w firmie przy przyszłych projektach IT.

kaisuj   11 #2 28.04.2015 23:39

Od teoretycznie strony scruma znam. Bardziej mnie interesuje jak to funkcjonuje w praktyce. Jak ludzie na standupie opowiadają o swoich problemach? Czy mówią otwarcie "wczoraj przez 3 godziny walczyłem z hierarchią styli..." choć trochę kicha jest się przyznać, czy raczej wymyślają jakąś ściemę? A co jeśli kończy się termin sprintu, a zaplanowane zadanie nie zostało skończone? Teoretycznie scrum master nie powinien do tego dopuścić, ale stało się. Pokazujecie klientowi tyle, ile udało się zrobić, czy przedłużacie sprint, żeby pochwalić się kompletną funkcjonalnością? Fajnie by było, jakbyś opisał scruma od kuchni, a nie w ujęciu teoretycznym.

Autor edytował komentarz.
ziggurad   12 #3 29.04.2015 08:43

@kaisuj
Ludzie nie ściemniają, o to też chodzi w Scrumie żeby wszyscy wiedzieli na czym stoimy. Jeśli ktoś ma problem z jakimś zadaniem od razu staramy się znaleźć rozwiązanie, najczęściej ktoś inny próbuje pomóc lub dana osoba bierze inne zadanie żeby bez sensu nie tracić czasu.

Nie przedłużamy sprintu, wyjątki stanowił np okres świąteczny gdzie wszystko się trochę rozsypało ze względu na wolne dni i dodatkowe urlopy członków zespołu.

Na Demie pokazujemy to co zrobiliśmy, nie ściemniamy. Na retrospekcji szukamy powodów problemów. Czy wzięliśmy za dużo na dany sprint. Czy osobom wskoczyły jakieś zadania spoza danego projektu, czy mieliśmy jakąś katastrofę na produkcji. Najważniejsze wyciągnąć jakieś wnioski i postawić sobie nowe cele ;)

Od razu napiszę że Scrum nie nadaje się do wszystkich firm i wszystkich projektów. Były przykłady firm które chciały być fajne i na czasie, wprowadzały Scruma a po kilku tygodniach z niego rezygnowano.

Autor edytował komentarz.
wojtekadams   18 #4 29.04.2015 08:54

Mi jakoś Scrum nie przypadł do gustu... te Stand-upy od tego zawsze bolą nogi :)

ziggurad   12 #5 29.04.2015 09:11

@wojtekadams
Może mieliście je za długie i rozwlekłe ;) Powinny trwać z 10-15 minut. Trzeba pilnować ludzi żeby mówili o projekcie a nie o tym co wczoraj na obiad zjedli :)

  #6 29.04.2015 09:56

@kaisuj: Jeśli ktoś jest ściemniaczem to będzie ściemę walił niezależnie czy pracuje się w scrumie czy nie. Daily są po to aby sobie pomagać. Tak aby ktoś kto miał wczoraj problem i stracił na niego pół dnia, nie tracił na jego rozwiązanie kolejnego dnia. Ktoś z zespołu może mu pomóc dzieląc się doświadczeniem albo pomysłem na jakiś workaround.

Klucz do wyrobienia się z funkcjonalnościami na demo to dobre planowanie. Wiadomo że jak się zaczyna pracować zwinnie to ciężko określić swoje możliwości, więc na początku prawe zawsze są obsuwy. Dopiero jak się zespół dotrze i zaczyna się dobrze znać wtedy planingi stają się bardziej precyzyjne i łatwiej jest się wyrobić do końca iteracji.

  #7 29.04.2015 10:11

@kaisuj: wiesz w praktyce to jest inaczej. Ktoś mówi "Wczoraj walczyłem przez 3 godziny z hierarchią styli" a druga osoba wtedy mówi. "Ok, wiesz ja szybciej ogarnąłem swój temat to siądę zerknę z Tobą co tam się dzieje". Nie muszę mówić, że wydajność wtedy rośnie jak szalona.

SebaZ   16 #8 29.04.2015 11:31

Dotknąłeś fajnego zagadnienia inżynierii oprogramowania. Scrum jest świetny przy zachowaniu 2 warunków koniecznych: stosowany od samego początku projektu oraz stosowany przez cały zespół wdrożeniowy oraz role w projekcie. Bez tych dwóch czynników ciężko użyć motodyki scrum w trwającym już projekcie oraz bez zaangażowania zespołu.

ziggurad   12 #9 29.04.2015 11:35

@SebaZ
Zgadzam się co do tego że musi być stosowany przez cały zespół, inaczej nie ma sensu.

Co do pierwszego, zdarza się że projekt rozpoczyna się w innej firmie, my go przejmujemy i dopiero wdrażamy Scruma ;)

Samurai   16 #10 29.04.2015 15:02

"...Powyższy tekst to tylko zajawka całego Scruma,..." - i to jest właśnie dla mnie podsumowanie całego wpisu ze szczególnym naciskiem na słowo "zajawka". O Scrumie słyszałem, ale nigdy nie miałem okazji z niego korzystać i nie mam w swoim otoczeniu osoby, która z niego korzysta. Jak byś coś jeszcze skrobnął w tym temacie ale trochę bardziej szczegółowo chętnie poczytam :)

ziggurad   12 #11 29.04.2015 15:13

@Samurai: Jeśli będzie zainteresowanie mogę coś skrobnąć. Tak są to mega ogólniki. Każdy z elementów scruma można rozwinąć i omówić.

Druedain   14 #12 29.04.2015 15:50

@wojtekadams: Ale bolą, bo mają boleć, żeby nie rozgadywali się ludzie i o pierdołach nie gadali :P

Autor edytował komentarz.
mikolaj_s   14 #13 29.04.2015 17:08

Zastanawiam się, czy zleceniodawcy tak bardzo chętnie współpracują przy tej metodzie?

SebaZ   16 #14 29.04.2015 18:28

@ziggurad: Ale dla Was od początku jedziecie ze SCRUMem od stanu zastanego.

SebaZ   16 #15 29.04.2015 18:29

@mikolaj_s: Muszą, bo inaczej nie dostaną produktu jakiego oczekują. Dobrym argumentem jest, że maja cały czas kontrolę nad postępami :)

#r2d2#   11 #16 29.04.2015 18:49

Ciekawy artykuł, chętnie poczytam jak ten system wygląda w praktyce.

jarodebombel   7 #17 29.04.2015 21:19

Problem ze SCRUM-em jest taki, że... mało kto go używa. Albo inaczej: używają go zespoły w poważnych firmach, głównie korporacjach. A i to nie wszystkich. Swoją działkę, z tego co wiem, ma kanban i waterfall. Ja osobiście interesuje się środowiskiem wnioskowania Cynefine. Poza tym nie spotka się SCRUM-a w małych przedsiębiorstwach, gdzie po prostu nie da się stworzyć zespołu. Bo nie ma z kogo.

Ale wracając do tematu posta. Drugi raz czytam książeczkę "Scrum. Praktyczny przewodnik po najpopularniejszej metodyce Agile" Helionu. Książeczka jest dość gruba, ale dobrze "uczy", na ile dobrze może uczyć książka. SCRUM jest niby prosty w założeniach. Ale pod tą prostotą kryje się złożony ekosystem. Którego należy nie tyle się nauczyć, ile zrozumieć.

W twoim wpisie brakuje mi wzmianki o pojęciu długu, szczególnie technicznego, który według mnie jest najbardziej wredny. Inna sprawa, że nie wspominasz o wadze elementów w rejestrze. I parę innych rzeczy ale to temat na kolejny wpis,

Co do samej certyfikacji... tak, ze scruma można się certyfikować... to mamy Scrum Alliance albo Scrum.org. Tu macie linki (wiedza z serwisu "Pod drzewem"):
http://www.poddrzewem.pl/do-poczytania/certyfikacja-scrum-wedlug-scrum-alliance
http://www.poddrzewem.pl/do-poczytania/certyfikacja-scrum-wedlug-scrum-org

Ja osobiście skłaniam się do Scrum.org. Z kilku powodów, między innymi:
- pierwszy poziom certyfikacji, Scrum Open Assesment, jest darmowy i jest dobrym wstępem do Scrum Mastera;
- nie ma "wymogu" uczestniczenia w spotkaniach związanych ze Scrumem;
- certyfikat jest bezterminowy;
- nie trzeba płacić składki członkowskiej;

Sam szykuję się właśnie do Scrum Open Assesment i problem mam taki, że... orientuję się w podstawach Scruma, ale nie mam jak przećwiczyć w realu. Z powodu wyżej opisanego w pierwszym akapicie mego komentarza.

Boję się też jeszcze jednej kwestii: słownictwo polskie a angielskie odnośnie SCRUMA troszkę się różni... a egzaminy po angielsku się zdaje (niesławna wtopa Mikom-u z tłumaczeniem książek Cisco...)

Jak masz wenę to pisz o Scrumie bo warto. Ale nie da rady prosto, łatwo i przyjemnie. Pozdrawiam!

SebaZ   16 #18 30.04.2015 00:23

Tak mi jeszcze przyszło do głowy, że SCRUM ma zastosowanie do projektu i zespołu projektowego, który zajmuje się tylko nim. W przypadku kiedy zespół robi projekt, a przy okazji tzw. normalne i codzienne obowiązki to już się nie da. Ilość rzeczy odrywających od pracy i tworzących backlog jest więcej niż samych zadań na sprinty :P

ziggurad   12 #19 30.04.2015 10:00

@mikolaj_s: niektórych trzeba trochę przekonywać ale jeśli się nie mylę aktualnie wszystkie projekty w mojej pracy są prowadzone w ten sposób. Dodatkowo sprzedaż też działa w scrumie.

Jak napisał @SebaZ dzięki temu klient ma cały czas podgląd projektu i na bieżąco można dokonywać zmian aby produkt był taki jak klient tego oczekuje.

ziggurad   12 #20 30.04.2015 10:04

@SebaZ: Tak, masz rację, ale piszesz o świcie idealnym :) Ogólnie na podstawie mojej firmy osoby są w jednym projekcie i nim się tylko zajmują, czasem zdarza się że wypłynie coś ze starego projektu ale są to raczej pojedyncze przypadki.

ziggurad   12 #21 30.04.2015 10:09

@jarodebombel

Nie zgodzę się z tym że mało kto go używa, znam kilka firm które z niego korzystają.

"Ale pod tą prostotą kryje się złożony ekosystem. Którego należy nie tyle się nauczyć, ile zrozumieć."
W pełni się z tobą zgodzę, scruma trzeba poznać i zrozumieć, trzeba go poczuć ;)

Nie przeczę, wiele rzeczy pominąłem lub potraktowałem po macoszemu. Istnieje pojęcie długu technicznego i także pod jego kontem oceniamy swoje projekty.

Ja aktualnie nie myślę o żadnych certyfikatach, nieraz życie pokazało że ważniejsza jest praktyka i zrozumienie tematu niż świstek papieru to potwierdzający.

Na rozmowach nikt nie pytał o papier tylko o to na ile znam Scruma, jak go stosowałem w poprzedniej firmie itp.

SebaZ   16 #22 30.04.2015 14:52

@ziggurad: To ciesz się z tego faktu :)

jarodebombel   7 #23 30.04.2015 21:40

@ziggurad #21: pisząc, że "mało kto go używa" miałem na myśli to, że nie jest popularny w niewielkich firmach. A i zwykli Kowalscy nazwy nawet nie kojarzą. Scrum kojarzą tylko ci, co się interesują tematem bądź pracują tam, gdzie go się używa.

A co do papieru, cóż, ja też uważam, że wiedza jest od papierka ważniejsza. Ale większość firm w naszym pięknym kraju przy rozmowie rekrutacyjnej uważa inaczej... choć są pozytywne wyjątki.

ziggurad   12 #24 01.05.2015 00:29

@jarodebombel dużo zależy od tego czym zajmuje się firma. Jeśli robi taśmowo strony i stawia sklepy to nie jest dla nich. Ale wydaje mi się że coraz więcej osób zna Scruma i wie kiedy można go wykorzystać.

Moim zdaniem papierki już dawno przestały mieć tak ważną pozycję. Oczywiście mówię tu o świecie programistów i podobnych :)