Scrum i Webtown

Polegamy na Scrumie.

Jakość

Wierzymy, że jakość w tworzeniu oprogramowania oznacza najwyższy poziom.

Wierzymy, że podczas tworzenia oprogramowania, podstawowym wyznacznikiem jakości jest perfekcyjna zgodność z celami biznesowymi, która z natury rzeczy obejmuje pełne zrozumienie wymagań, a także wysoki poziom umiejętności programistycznych z tym związanych, aby tworzyć oprogramowanie i produkty powiązane.

Wierzymy również, że dokładne dopasowanie wymagań i rozwiązań tworzy wartość, jeśli odbywa się w tym samym czasie, dlatego jedynym prawdziwym rozwiązaniem jest oprogramowanie, które jest dostarczane szybko, cechuje się dobrą jakością i nie zawiera błędów.

Fakt, że nasze rozwiązania spełniają wszystkie trzy warunki oznacza, że stosujemy się do wytycznych dotyczących zwinności zgodnie z ramami postępowania Scrum. Nasze zespoły Scrumowe są samoorganizujące się, wielofunkcyjne, a jednocześnie dostarczają i udoskonalają własne techniki w ciągu 1-tygodniowego sprintu, zapewniając tym samym ciągłe doskonalenie.

Zgodnie z naszymi wytycznymi, nasze zwinne podejście jest stosowane nie tylko w tworzeniu oprogramowania, ale cała nasza firma posiada płaską strukturę organizacyjną, zapewniając w ten sposób samoorganizację i przestrzeń potrzebną do pracy intelektualnej i dalszego rozwoju.

W Webtown stosujemy poniższe metody Scrumowe.

Zasady i reguły

Wydarzenia, role i materiały robocze połączone są ze sobą regułami Scrum, które określają relacje i interakcje między nimi. Zespoły Scrumowe opracowują własne reguły, materiały robocze i narzędzia wykorzystywane zgodnie z zasadami i wartościami Scrum.

Zasady Scrum:

  • Ustalanie priorytetów w oparciu o wartości (Backlog Produktu)
  • Współpraca (w ramach zespołu Scrumowego i z interesariuszami)
  • Zasada samoorganizacji
  • Empiryczne monitorowanie procesu (retrospektywny przegląd zdarzeń, ciągłe monitorowanie postępów w dążeniu do celów – wizja, cel sprintu)
  • Rozwój w podejściu iteracyjnym (przyrostowy rozwój produktu potencjalnie gotowego podczas każdego sprintu)
  • Ramy czasowe (zdarzenia ograniczone czasowo)

Zalety pracy w Scrumie

Events, roles and work materials are connected to each other by the rules of Scrum, which determine the relationships and interactions between them. Scrum Teams develop their own rules, the work materials and tools used in accordance with the principles and values of Scrum.

Scrum principles:

- Value-based prioritization (Product Backlog)

- Co-operation (within the Scrum Team and with stakeholders)

- Self-organization

- Empirical process monitoring (review on retrospective events, continuous monitoring of the progress towards goals (vision, sprint goal))

- Iterative development (potentially releasable product increment in every sprint)

- Time frame (time-boxed events)

Zalety pracy w Scrumie

Poniżej zebraliśmy nasze doświadczenia i powody, dla których uważamy, że stosowanie Scruma jest korzystne zarówno dla naszych partnerów, jak i dla nas samych.

Tworzenie wartości

Za pomocą ram postępowania Scrum, zamiast realizować czysto funkcjonalne wymagania, zajmujemy się wymaganiami, które niosą ze sobą wartość biznesową określoną przez Właściciela Produktu i których wdrożenie jest planowane i realizowane przez Zespół Deweloperski.

Sprawna i bezpośrednia komunikacja pomiędzy Właścicielem Produktu a Zespołem Deweloperskim w dużym stopniu przyczynia się do tworzenia rozwiązań o wysokim standardzie technologicznym i wyróżniającej się jakości.

Planowanie produktu w oparciu o wersję roboczą oprogramowania

Realizując nasze projekty, staramy się w miarę możliwości wykonywać wszystkie czynności niezbędne do przygotowania oprogramowania do pracy zgodnie z procesem dostawy zaprojektowanym specjalnie w odniesieniu do danego projektu w trakcie sprintu. W związku z tym zalecamy, aby zadania wgrywania treści realizowane były w sposób ciągły, dostosowany również do planu sprintu, aby uniknąć akumulacji tych zadań i związanego z tym opóźnienia aktywacji produktu.

W wyniku zastosowanych rozwiązań osiągalnym, realnym celem jest, aby po jednym sprincie  zamysł gotowego produktu był jasny dla Właściciela Produktu i aby mógł on podjąć decyzje nie na podstawie planu zawartego w dokumentacji, lecz na podstawie działającego oprogramowania.

Firma klienta może natychmiast otrzymać należące do niej interfejsy portalu w celu przeprowadzenia walidacji biznesowej, dzięki czemu możliwa jest weryfikacja i dostarczenie idealnego rozwiązania w końcowym produkcie – nawet w oparciu o wielokrotne cykle przekazywania informacji zwrotnej.

Jedną z największych zalet projektów zwinnych jest fakt, że dzięki stale dostarczanym przyrostom produktu z końcem każdego sprintu można osiągnąć stan potencjalnej gotowości do działania.

Szybkie dostosowywanie się do zmian

Regularne przetwarzanie informacji zwrotnej i planowanie na drodze sprintu dają Właścicielowi Produktu możliwość dostosowania swoich wymagań do aktualnych celów i oczekiwań użytkownika.

Pomaga to zapewnić, że produkt dostarczony na koniec projektu będzie posiadać funkcjonalność, która będzie wykorzystywana przez użytkowników końcowych i reprezentować rzeczywistą wartość biznesową.

Zastosowanie Scruma sprawia, że koszty zmian są znacznie niższe niż w przypadku korzystania z metod tradycyjnych, w których wszelkie modyfikacje dodawane są do pierwotnie zaplanowanych kosztów w postaci dodatkowych wydatków.

Wysoka jakość

W Scrumie jakość można zdefiniować na zasadzie zdolności zapewnienia, że produkt lub wynikające produkty będą spełniać kryteria „Ukończonych” i posiadać wartość biznesową wymaganą przez klienta.

  • Kryteria „Ukończone”, a w razie potrzeby schemat współpracy, są opracowywane wspólnie przez członków Zespołu Scrumowego i polegają ciągłej weryfikacji.
  • W celu zapewnienia wysokiej jakości konieczne jest zmniejszenie, nawet wyeliminowanie tzw. długu technicznego. W tym celu badamy jakość kodu źródłowego za pomocą przeznaczonego do tego celu oprogramowania – SonarQube – oraz uzupełniamy testy przeprowadzone manualnie testami automatycznymi.
  • W celu weryfikacji oczekiwanej wartości biznesowej najbardziej efektywnym rozwiązaniem są testy przeprowadzone na rzeczywistych użytkownikach.

Testowanie jest działaniem ciągłym, dlatego na końcu projektu nie pojawią się błędy.

Testy manualne wykonywane w ramach sprintu uzupełniane są o testy automatyczne, dając możliwość przeprowadzania kompleksowych testów cyklicznych, również dla rozwiązań dostarczonych w ramach poprzednich sprintów. Dzięki aktywnemu udziałowi interesariuszy i częstym testom użytkowników, nawet po każdym sprincie, błędy wynikające z niewłaściwej analizy wymagań i nieprawidłowego planowania mogą być wykryte wcześnie, obniżając koszty związane z usuwaniem błędów.

Dokumentacja zawierająca aktualne wymagania i rozwiązania

Utrzymanie zbioru historyjek na optymalnym poziomie sprawia, że zawsze zawierają one aktualne wymagania, a dodatkowo Zespół Deweloperski posiada odpowiednią liczbę takich historyjek, aby utrzymać tempo pracy.

Poprzez aktualizację w każdym sprincie powstającej w ten sposób dokumentacji można zapewnić zgodność produktów systemu  z opisami systemu.

Role

W ramach Scrum wyróżnia się 3 kluczowe role: Zespół Deweloperski, Właściciel Produktu i Scrum Master.

Właściciel Produktu

Osoba odpowiedzialna za maksymalizację wartości produktu oraz pracy Zespołu Deweloperskiego, stanowiąca łącznik pomiędzy interesariuszami a Zespołem Deweloperskim.

Główne zadania:

  • Identyfikacja i zaangażowanie interesariuszy, kluczowych uczestników.
  • Pomiar i dokumentacja potrzeb i wymagań biznesowych.
    • Przygotowanie i ciągła kontrola Wizji Produktu.
    • Przygotowanie i utrzymanie Roadmapy Produktu.
    • Prowadzenie Backlogu Produktu – przygotowanie historyjek.
    • Pomiar wymagań niefunkcjonalnych, określanie kryteriów „Ukończony” (Definicja Ukończenia).
  • Przygotowanie Planu Wdawania, nadanie priorytetu zaległościom i określenie celu sprintu z uwzględnieniem zaplanowanych terminów wypuszczenia.
  • Aktywne zaangażowanie w planowanie interfejsu/doświadczenia użytkownika (UI/UX). Zapewnienie zgodności pomiędzy historyjkami a planami ze szkicami.
  • Komunikacja z interesariuszami.
  • Współpraca z Zespołem Deweloperskim.

Zespół Deweloperski

Zespół Deweloperski jest samoorganizującym się zespołem, którego członkowie są współodpowiedzialni za planowanie procesu wdrażania punktów zawartych w Backlogu właściwą realizację kryteriów „Ukończenia”.

Główne zadania:

  • Odpowiada za zrozumienie potrzeb biznesowych, planowanie i szacunkowe przygotowanie rozwiązania najlepiej odpowiadającego potrzebom, a także za ukończenie produktu.
  • Pozycje w Backlogu są uzupełniane i prezentowane przez zespół zgodnie z zasadami metodologicznymi.

Scrum Master

Scrum Master jest odpowiedzialny za zgodność z zasadami ram postępowania i zapewnienie warunków niezbędnych do sprawnej pracy Zespołu Deweloperskiego.

  • Zapewnia, że w ramach projektu (jako część planu współpracy) zostanie opracowana kolejność przyjmowania/zatwierdzania elementów dostawy oraz że wymagane do tego dokumenty, jak również kryteria „Ukończenia”, zostaną wyjaśnione.
  • Wspiera Właściciela Produktu w opracowywaniu skutecznej metody zarządzania Backlogiem. Organizuje i przeprowadza zdarzenie w ramach sprintu.
  • Wspiera uczestników projektu i uczestników biznesowych w zakresie teorii i praktyki Scrum.
  • Wspiera zespołu w tworzeniu samoorganizacji. Nie wydaje bezpośrednich poleceń dotyczących wykonywania zadań.

Interesariusze

Interesariusze mają wpływ na przebieg projektu i stawiają wymagania dotyczące produktu, który ma być dostarczony. Zadaniem Właściciela Produktu na początku projektu jest wskazanie interesariuszy i ich zaangażowanie w projekt w zależności od obaw jako kluczowego użytkownika, a nawet jako osoby zatwierdzającej.

Struktura projektu

Z naszego doświadczenia wynika, że dostosowanie środowiska korporacyjnego do metodologii Scrum można zrealizować w następujący sposób.

 

Faza poprzedzająca sprint (faza przygotowawcza)

  • Na początku projektu cel projektu/produktu oraz kluczowe informacje niezbędne do pomyślnego opracowania produktu są zapisywane przez Właściciela Produktu w Wizji Produktu.
  • Następnie w Roadmapie Produktu prezentowana jest droga rozwoju produktu w toku planowanych wydań aż do osiągnięcia zamierzonej wizji. Rozbiciu ulegają cele biznesowe i określana jest funkcjonalność oraz wymagania, które należy spełnić, aby osiągnąć cele.
  • Wynikiem fazy poprzedzającej sprint jest wstępny Backlog Produktu.
    • Wymagania użytkowników są zapisywane w Backlogu Produktu w formie opisu lub historyjki.
    • Wszelkie zmiany pojawiające się w postaci cech, funkcji, wymagań, ulepszeń i poprawek, które powinny zostać wprowadzone w przyszłych wersjach produktu, są umieszczane w Backlogu Produktu.
    • Pozycje zaległe są porządkowane i klasyfikowane przez Właściciela Produktu w ramach planowanych wydań.
    • Backlog Produktu ulega ciągłym zmianom do momentu zakończenia projektu.
  • W celu przygotowania produktu o odpowiedniej jakości konieczne jest określenie wymagań, które wyraźnie uwzględniają oczekiwania nieodłącznie związane z produktem oraz dające się zweryfikować oczekiwania dotyczące przyrostu produktu. Służą temu tzw. kryteria „Ukończenia” (Definicja Ukończenia).
    • Kryteria „Gotowości” (Definicja Gotowości) zazwyczaj zawierają formalne i merytoryczne wymogi dotyczące elementów zaległych. Dzięki ich przestrzeganiu można mieć pewność, że zespół wdrożeniowy będzie planować i dostarczać rozwiązanie w oparciu o wysokiej jakości wymagania, dzięki czemu oprogramowanie będzie dokładnie służyć swoim celom.
    • Omawianie „kryteriów Ukończenia” zapewnia, że wszystkie ukończone przyrosty produktu będą zgodne z wymogami dotyczącymi całego produktu, a zatem można uniknąć sytuacji, w której wymóg dotyczący całego produktu, który został zidentyfikowany zbyt późno, musi zostać zastosowany do całego projektu, generując wysokie koszty.

W fazie przygotowawczej powstaje Zespół Scrumowy i rozpoczynają się negocjacje pomiędzy Zespołem Deweloperskim a Właścicielem Produktu. Celem jest udostępnienie – do końca fazy przygotowawczej – następujących warunków wymaganych do rozpoczęcia sprintu:

  • Przygotowanie Wizji Produktu
  • Przygotowanie Roadmapy Produktu
  • Określenie interesariuszy (wewnętrznych i zewnętrznych)
  • Przygotowanie wstępnego Backlogu Produktu (identyfikacja uczestników, rejestrowanie opisów), rozmieszczenie ramy punktu historyjki na poziomie opisu lub funkcjonalności.
  • Przygotowanie historyjek na poczet 3 sprintów
  • Określanie kryteriów GOTOWOŚCI i UKOŃCZENIA
  • Utworzenie Zespołu Scrumowego
  • Infrastruktura sprzętowa i programowa

Pierwszy sprint można rozpocząć po zakończeniu zadań w fazie przygotowawczej.

Cykl Scrumowy

  • Cykl Scrumowy rozpoczyna się od planowania pierwszego sprintu.
    • Podczas planowania sprintu Właściciel Produktu i Zespół Deweloperski ustalają wspólnie cel sprintu. Materiałem wyjściowym w ramach prac Zespołu Deweloperskiego są gotowe do sprintu pozycje z Backlogu Produktu. Każda historyjka, która ma być uwzględniona w sprincie, otrzymuje od Zespołu Deweloperskiego punkt historyjki, a Zespół określa zobowiązanie dotyczące zakresu sprintu (Backlog Sprintu).
    • W drugiej części planowania sprintu Zespół Deweloperski opracowuje plan realizacji celu sprintu i efektywnego wykonywania pracy wewnętrznej. W celu przygotowania przyrostu produktu, który może potencjalnie zacząć działać pod koniec każdego sprintu, wszystkie zadania związane z produktem są wykonywane przez zespół w ramach sprintu.
    • W wyniku planowania historyjki są rozdzielane przez Zespół Deweloperski na mniejsze pozycje (mniejsze zadania).
  • W czasie trwania sprintu działania wymagane do wdrożenia i osiągnięcia celu sprintu są synchronizowane i ustalane przez Zespół Scrumowy w ramach Codziennego Scrumu.
  • Równolegle z wdrożeniem Właściciel Produktu pracuje nad historyjkami do kolejnych sprintów. Podczas zdarzeń związanych z Doskonaleniem Backlogu (Pielęgnacją Backlogu) Właściciel Produktu i Zespół Deweloperski prowadzą negocjacje dotyczące historyjek przygotowanych przez Właściciela Produktu. Na podstawie informacji zwrotnych Właściciel Produktu aktualizuje informacje o zaległych elementach i ich porządku.
  • Na koniec sprintu, podczas Przeglądu Scrumu (lub Demo Sprintu) gotowy produkt jest prezentowany Właścicielowi Produktu przez Zespół Deweloperski.
    • Jeśli przyrost produktu spełnia kryteria akceptacji i kryteria „Ukończenia”, Właściciel Produktu akceptuje wykonane historyjki.
    • Historyjki, które nie spełniają tych kryteriów, są ponownie umieszczane w Backlogu Produktu.
  • Na koniec każdego sprintu Zespół Scrumowy analizuje czynności w ramach zdarzenia zwanego Retrospektywą Scrumu. Badanie to obejmuje stosowane metody, współpracę między członkami zespołu, a także jakość przygotowywanego produktu. Dla każdego wykrytego odchylenia zespoły przygotowują plan rozwiązania problemu, który jest stale monitorowany.
  • Zalecany czas trwania sprintu to jeden tydzień, którego początek i koniec przypada na ten sam dzień tygodnia w czasie trwania projektu.

Wydanie i aktywacja produktu

  • Wydanie/aktywacja produktu odbywa się w czasie określonym w Roadmapie Produktu.
  • Wydanie est poprzedzone szczegółowym planowaniem, w wyniku którego sporządzany jest Plan Wydania. Planowanie wydania produktu pomaga klientom w przygotowaniu się do zmian oraz organizacji działań niezbędnych do dostosowania organizacji (modyfikacja przepływu pracy, szkolenia).