Dzisiaj na blogu poruszymy  temat metodyki Scrum. Czym jest? Jakie inne metodyki zarządzania projektami możemy spotkać? Jakie rolę występują  w Scrumie? Czym są metodyki zwinne? Odejdziemy w tym wpisie od tematów ściśle testerskich, technicznych. Myślę, że ten wpis pozwoli wam zrozumieć jak wygląda zarządzanie projektem w Scrumie oraz jakie są jego korzyści.

Poniższy rysunek przedstawia kilka metod zwinnych opartych i zgodnych z manifestem Agile:

Czy wiesz, dlaczego metodyki zwinne zyskują tak dużą popularność? Nie dzieje się to bez powodu. Manifest Agile ma kilka istotnych założeń, należą do nich między innymi:

  • zadowolenie klienta to najważniejszy priorytet
  • szybkość działania, programowania
  • gotowość na zmiany, na każdym etapie projektu
  • dobra współpraca między biznesem i developmentem
  • dostarczanie wykonanych funkcjonalności w stałych i krótkich odstępach czasu
  • osiąganie technicznej doskonałości oraz prostota i dobra jakość kodu
  • praca zespołowa
  • częste, najlepiej codzienne sprawdzanie postępów i podziału zadań
  • ludzie ponad procesami i narzędziami
  • dokumentacja ma drugorzędne znaczenie, prawidłowe działanie programu jest nadrzędne
  • stała, jasna a przede wszystkim zadowalająca współpraca z klientem
  • doskonalenie wydajności

Na samym początku ważne jest ustalenie celów, omówienie zakresu projektu oraz ostatecznego efektu, jaki oczekuje klient i do którego dąży zespół. W Scrumie to właśnie Zespół jest najważniejszy w czasie trwania całego projektu. W skład zespołu wchodzą programiści, testerzy, ale również analitycy oraz architekci. Zespół charakteryzuje to, że rządzi samym sobą. Po otrzymaniu wymagań dzieli zadania pomiędzy wszystkimi wchodzącymi w jego skład, jak również jest odpowiedzialny za wykonanie tych zadań w odpowiednim czasie. Każda funkcjonalność jest oszacowana przez programistów. Programiści analizują, a następnie podają potencjalny czas wykonywania poszczególnych zadań. Wszystkie wymagania na dany Sprint są umieszczane w tzw. Product Backlog. Termin wykonania założeń jest wyznaczany przez czas trwania Sprintu. Sprint to nic innego, jak zdefiniowany okres, w którego trakcie wykonywane są przydzielone dla niego zadania. Na projekt może przypadać od kilku do kilkudziesięciu Sprintów. Czas trwania Sprintu mieści się w przedziale od kilku dni do maksymalnie 4 tygodni. Taki podział prac pozwala na tworzenie dobrej jakości produktów oraz zadawalającej, stałej współpracy z klientem. Na koniec każdego sprintu przedstawione są wykonane funkcjonalności w trakcie trwania tzw. demo aplikacji. Oprócz Sprintów zespół uczestniczy każdego dnia, w krótkich statusowych spotkaniach. Pozwala to na bieżące reagowanie na występujące problemy. Zespół doskonale się rozumie i ma jasno wyznaczone zadania na każdy dzień.

Przed chwilą opisaliśmy, kto wchodzi w skład zespołu oraz czym on się zajmuje. Teraz skupmy się nad charakterystyką roli Właściciela Produktu.

Właściciel produktu to osoba, która przedstawia interesy klienta. Odpowiada za zarządzanie wymaganiami. Na zakończenie każdego Sprintu odbiera lub odrzuca wykonaną przez zespół funkcjonalność. Jego zaangażowanie, dociekliwość i pracowitość może ochronić klienta przed otrzymaniem błędnie działającej aplikacji. To od niego zależy czy dana funkcjonalność zostanie zatwierdzona, czy zwrócona do ponownego wykonaniu lub jej naprawienia.

ScrumMaster jak sama nazwa może nas nakierować, czuwa oraz nadzoruje proces Scrum-a na projekcie. Jest wsparciem dla zespołu, pomaga w przypadku pojawiających się problemów, zapobiega ich występowaniu poprzez analizę działań wykonywanych przez zespół. Czuwa, aby proces Scrum-a był realizowany oraz skupia się nad tym, aby wszystkie zadania były wykonywane w okresie trwania Sprintu. ScrumMaster stara się, aby proces Scrum-a przyniósł, jak najwięcej korzyści dla danego projektu.

Z dzisiejszego wpisu mogliście przeczytać, czym jest manifest Agile, metodyka Scrum oraz jakie rolę w niej występują. Mam nadzieję, że dowiedzieliście się czegoś nowego oraz w oparciu o własną wiedzę poszerzycie się nią w komentarzach. Życzę wam udanego weekendu i dużo odpoczynku:D

 

Skomentuj Ewelina Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany.

  • Ewelina
    4 lipca, 2017 o 7:06 pm

    Trafiłam tu z grupy. Przeczytałam do momentu „W skład zespołu wchodzą programiści, testerzy, ale również analitycy oraz architekci. ” i nie byłabym sobą gdybym nie zareagowała, gdyż jest to mijanie się z prawdą. Częścią zespołu scrumowego odpowiedzialną w sposób bezpośredni za realizacje jest zespół developerski. Kropka. W zespole developerskim nie ma testerów, nie ma analityków są developerzy (wszyscy członkowie zespołu posiadają zakres kompetencji możliwy do realizacji wszystkich zadań w sprincie). Zadania nie są dzielone pomiędzy osoby z konkretnymi kompetencjami. Zadania wpadają na tablice i są pobierane do realizacji przez każdą z osób samodzielnie.
    Nie odbierz mnie źle- rozumiem że opisujesz swoje doświadczenia z obecnej pracy, ale z pewnością nie jest to scrum i wpis nie powinien być w takiej formie publikowany. O wiele lepiej bym go odebrała gdybyś przedstawiła to jako: „Agile u nas”.
    Mój feedback dla Ciebie- więcej literatury przed opublikowaniem wpisu
    Pozdrawiam 🙂

    • Testerka
      4 lipca, 2017 o 7:22 pm

      Zdecydowanie nie odebrałam Cię źle, wiem, że wiele mi jeszcze brakuje i cały czas staram się poszerzać swoją wiedzę. Słuszna uwaga, tytuł zmieniony, mam nadzieję, że następne wpisy będą dla Ciebie bardziej interesujące.

      Pozdrawiam 🙂

      • Ewelina
        4 lipca, 2017 o 7:29 pm

        Gratuluję postawy! Jedna z cech dobrych relacji w projekcie to umiejętność przyjmowania feedbacku (zarówno pozytywnego jak i tego negatywnego który przekłada się na konstruktywny). Na pewno zajrzę w inne wpisy i wtrącę swoje 3 grosze 🙂 Powodzenia!

  • Marta
    19 września, 2017 o 5:17 pm

    Droga Testerko, koleżanka powyżej zwróciła uwagę na fakt że rola testera w agilu jest/była pomijana. Może warto wdać się w polemikę i napisać coś czemu to jest słuszne/lub nie. Moim zdaniem jesteśmy niedocenieni a zespół deweloperski oznacza nie tylko programistów a grupę która ma dostarczyć wartość… a jak są potrzebni testerzy to też w zespole deweloperskim są i są jego częścią 🙂

    • Testerka
      20 września, 2017 o 6:22 am

      Droga Marto, niewątpliwie to o czym piszesz, ma miejsce na wielu projektach i w ogromnej ilości firm. Inspirując się Twoim komentarzem, rozpoczęłam pracę nad wpisem na temat roli testera i dlaczego jest ona niedoceniana oraz czy jest to słuszne 🙂 Myślę, że pojawi się najpóźniej pod koniec tygodnia 🙂 Mam nadzieję, że uświadomi on wielu osobom, że ich postawa wobec testerów może nie do końca jest odpowiednia i pora ją zmienić!

  • Ewelina
    7 października, 2017 o 3:44 pm

    Cześć, zostałam wywołana do odpowiedzi, więc pozwolę sobie na kilka słów wyjaśnienia. Reguły gry opsiują SCRUMa jako framework który idealnie sprawdzi się do zespołów developerskich. Nie da się dostosować „klasycznego” scruma do zespołów (nazwijmy to) mieszanych- gdzie testerzy, analitycy i programiści wspólnie pracują nad dostarczeniem produktu. SCRUM po prostu nie jest kierowany do tych zespołów, ponieważ jednym z jego fundamentalnych założeń jest brak specjalizacji członków zespołu polegającej na tym, że zadania są z góry przydzielane do grupy osób. SCRUM zakłada, że zespoły samoorganizują się i każdy z członków zespołu ma kompetencje i wiedzę do zrealizowania dowolnego zadania z tablicy i sam pobiera je do realizacji.
    W takim ujęciu zespół testerski powinien mieć własną tablicę, analitycy własną i devowie własną.
    Tyle w teorii. W praktyce, moje doświadczenia pokazują, że lepsze efekty osiągamy, kiedy pracujemy wszyscy razem i wspólnie widzimy efekty naszej pracy. Uważam podobniej jak Wy, że takie podejście jest lepsze. Jest to jakaś forma podejścia zwinnego, ale nie można nazywać tego wykorzystaniem SCRUMa jako frameworka do pracy zwinnej.
    Rola testera w agile nie jest pomijana. Akurat w tym jednym frameworku nie ma miejsca na dzielenie kompetencji zgodnie ze specjalizacją, ale AGILE pozwala na szeroki zakres działań. Agile SCRUM 🙂
    W mojej karierze nigdy nie czułam się niedoceniona (czy to jako tester, czy realizując inne zadania „niedeveloperskie”) więc nie zgodzę się że to, iż SCRUM nie zakłada miejsca dla testera jest jakąś.. dykskryminacją?
    Zespół może sam wypracować sobie framework do pracy- grunt żeby wszystkim dobrze i efektywnie się pracowało.
    I tego Wam dziewczyny życzę 🙂

    • Paweł
      29 stycznia, 2019 o 8:40 pm

      Niestety, ale nie mogę się z tym zgodzić. Scrum Guide opisuje zespół jako posiadający kompetencje do realizacji każdego zadania z tablicy. Nie opisuje on w taki sposób każdego członka zespołu. Pozwolę sobie załączyć definicję zespołu deweloperskiego ze strony https://www.scrumguides.org/scrum-guide.html
      Development Teams have the following characteristics:

      1. They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
      2. Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment; W tym punkcie zespół jest opisany jako posiadający wszystkie niezbędne umiejętności do stworzenia inkrementu.
      3. Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person; W tym punkcie mowa jest tylko o nienadawaniu tytułów pośród członków zespołu, ale nie wyklucz on wykonywania określonych zadań przez poszczególnych jego członków.
      4. Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; Ten punkt wyklucza dzielenie zespołu na mniejsze, podzielone na poszczególne kompetencje.
      5. Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole. Ostatni punkt wspomina wręcz o tym, że różni członkowie zespołu posiadają różny poziom wiedzy i różne kompetencje, ale odpowiedzialność w scrumie od nich nie zależy. Zawsze cały zespół odpowiada za dostarczony produkt.

      Nie wiem dlaczego nikt nie zadał sobie trudu zajrzenia do scrum guide. Takie przeświadczenie, że każdy członek zespołu może wykonać każde zadanie mocno ogranicza możliwość tworzenia dobrych zespołów, bo jeżeli ktoś potrafi robić wszystko to w niczym nie jest ekspertem.

  • Ewelina
    7 października, 2017 o 3:47 pm

    Po wysłaniu komentarza ucięło znaki więc: Agile (różne od) SCRUM podobnie jak Prostokąt (różne od) kwadrat 🙂

  • Krzysztof
    28 grudnia, 2021 o 11:29 am

    Witaj 😉
    Ja też wdam się w polemikę. Zarzewiem powyższej dyskusji być może jest fakt, że nie powiedziałaś jasno o Zespole Scrumowym i Zespole Deweloperskim i że ten drugi jest częścią pierwszego. Fakt, że Scrum wkłada poszczególne kompetencje do worka, podpisanego „deweloperzy”, ale te kompetencje nadal istnieją a Dev team, jako całość, ma posiadać je wszystkie, aby z powodzeniem dowieźć produkt. Sugerowanie, że każdy ma umieć wszystko, jest złe – Scrum nie zakazuje specjalizacji, bo na tych kilkunastu stronach prawie w ogóle nie ma zakazów. Są ramy postępowania, szkielet i wewnątrz tego mamy sobie poradzić i wypracować własne, działające praktyki/techniki/działania.
    Nie zgadzam się bardzo z tym, że Scrum jest tylko dla w pełni kros-kompetencyjnych zespołów a sugerowanie oddzielnych tablic pachnie mi sekwencyjną pracą nad produktem.
    Zapisy, do których celnie odwołał się Paweł, mają wskazywać na to, że każdy wewnątrz Dev Teamu jest traktowany tak samo, jest tak samo ważny a na koniec każdy jednakowo odpowiada za sukces lub porażkę produktu. To ostatnie należy rozszerzyć o SMa i PO.

    No to teraz moje uwagi 😉 Rzeczy Sprintowe umieszcza się w Sprint Backlogu. PB (product backlog) to ten ogólny worek, z którego wybieramy elementy do Sprintu i umieszczamy w SB (sprint backlog). Unikałbym też porównywania Przeglądu Sprintu do Demo – Review ma więcej założeń, niż tylko przeklikanie nowych funkcjonalności przed zaproszonymi 😉 Odrzucanie funkcjonalności na Review przez PO – czy to nie za późno? Według mnie byłoby to dopuszczalne tylko wtedy, gdy wymagania zmienią się bardzo nagle. Jeśli PO widzi dostarczone elementy dopiero na Review, to gdzie się podziewa przez cały Sprint? A może zabrakło procesu pielęgnacji elementów PB i wizje PO i Dev Teamu się rozminęły?

    Czytam wpisy chronologicznie, dobra robota! 🙂

Ten serwis wykorzystuje pliki cookies. Korzystanie z witryny oznacza zgodę na ich zapis lub odczyt wg ustawień przeglądarki. Więcej
Zgoda