Jak eVolpe pracuje w SCRUM

SCRUM w eVolpe

Na stronie o SCRUM opisaliśmy czym jest zwinne podejście we wdrażaniu systemów informatycznych. Poniżej przybliżamy jak od strony praktycznej wygląda nasza współpraca z Klientem podczas realizacji projektów scrumowych.

Stworzenie Product Backlog

Działania zgodnie z metodyką Scrum rozpoczynają się po zamknięciu etapu konsultingu, doboru systemu CRM oraz ustaleń handlowych. Przybierają one formę działań analitycznych opisanych szerzej tutaj. Przeprowadzamy dla Klienta System Overview (zapoznanie z systemem) oraz warsztaty Product Discovery. Są to wysoce kreatywne aktywności pozwalające spojrzeć na zarządzanie relacjami z klientami z firmie zarówno z wąskiej, jak i szerokiej perspektywy. Co warte podkreślenia, wymagają one wysokiego poziomu zaangażowania ze strony Klienta. W trakcie takich warsztatów, aby lepiej wizualizować omawiane zagadnienia, a także wspomóc wykorzystanie kreatywnych technik, korzystamy z wielu kolorowych karteczek samoprzylepnych, pisaków, tablic suchościeralnych czy folii antystatycznych.

Wynikiem przeprowadzonych warsztatów jest Product Backlog, głównie w formie User Stories, czyli historyjek użytkownika. Jest on przygotowany przez przedstawiciela eVolpe, który będzie pełnił w projekcie rolę proxy Product Ownera (biznesowego łącznika pomiędzy Klientem oraz zespołem deweloperskim). Następnie Product Backlog jest priorytetyzowany. Działania te realizowane są wspólnie przez proxy Product Ownera oraz Product Ownera, czyli przedstawiciela Klienta – osoby odpowiedzialnej za produkt, decyzyjnej w kwestii kształtowania jego wizji i rozwoju.

W niektórych przypadkach, na podstawie powstałego Product Backlogu przygotowywane jest oszacowanie jego elementów, tak by uzyskać rząd wielkości projektu przed jego rozpoczęciem. Podejście to stosowane jest najczęściej gdy Klientowi zależy na ustaleniu wysokości budżetu projektu. Należy jednak pamiętać, że podejście scrumowe dopuszcza, a wręcz wspiera, dokonywanie zmian i zwrotów kierunku, w którym podąża projekt, więc oszacowanie to ma głównie charakter poglądowy.

W trakcie Sprintów

Implementacja projektu scrumowego przebiega w 2-tygodniowych iteracjach. Oznacza to, że po każdym takim okresie następuje pewien przyrost nowych funkcjonalności, bądź zmiana lub udoskonalenie dotychczas istniejących. Każda iteracja, zwana sprintem, rozpoczyna się od spotkania zwanego Sprint Planningiem. W jej trakcie ustalany jest cel nadchodzącego sprintu, czyli nadrzędna wartość, która zostanie uzyskana. Na tej podstawie dobierane są również historyjki, których ukończenie pozwoli na osiągnięcie tego celu. Tworzą one Sprint Backlog. Druga część spotkania polega na dokładnym zaplanowaniu prac przez zespół deweloperski, tak by ukończone zagadnienia spełniały ustalone wcześniej Definition of Done (kryteria ukończenia).

Jest to niezwykle istotne, gdyż codziennie przez kolejne dni odbywa się krótkie – maksymalnie 15-minutowe – spotkanie zwane Daily Stand-upem, które w eVolpe odbywa się przy wykorzystywanych przez nas tablicach scrumowych (równolegle korzystamy z dostosowanego do naszych potrzeb systemu do zarządzania projektami Redmine). Każdorazowo następuje wtedy inspekcja postępu prac i ewentualna adaptacja wcześniejszego planu do zaistniałych w rzeczywistości warunków. Ustalamy wtedy również co udało się wykonać przez ostatnią dobę, jaki jest plan na kolejną i czy zostały napotkane jakieś trudności.

W trakcie Sprintów odbywają się również spotkania zwane Refinement. Są one dedykowane nowym wymaganiom, które pojawiają się od Klienta, tak by móc je odpowiednio doprecyzować, ewentualnie podzielić na mniejsze, a następnie oszacować. Tak przygotowane zagadnienia są dostępne w Product Backlogu i mogą zostać dobrane do wykonania w trakcie nadchodzących Sprintów.

Czym się kończy każdy Sprint?

Na koniec Sprintu spotkamy się z Klientem (najczęściej zdalnie) podczas Sprint Review. Zespół oddaje wtedy Klientowi uzyskany przyrost, pokrótce również prezentując to, co zostało wykonane. Jest to również odpowiedni moment na dyskusję odnośnie nowych wymagań, które mogły zostać zainspirowane obecnym kształtem produktu, zmian tych już istniejących, a także oczekiwań dotyczących kolejnego Sprintu. Następuje więc inspekcja wykonanych prac, a także adaptacja wymagań do punktu odniesienia, w którym się obecnie znajdujemy.

Po każdym ze Sprintów możliwa jest instalacja paczek, tworzących przyrost, w środowisku produkcyjnym Klienta. Oczywiście nie każdy Sprint musi kończyć się takim wydaniem. Jest to w pełni zależne od decyzji Klienta. Wcześniej jednak Klient ma możliwość zapoznania się z nowymi funkcjonalnościami w przygotowanym dla niego środowisku testowym. Na tej podstawie następuje ostateczne zaakceptowanie przez Klienta wykonania zagadnień z wcześniejszego Sprintu.

Ostatnim spotkaniem, w którym uczestniczy Zespół Scrumowy, czyli proxy Product Owner, Zespół Deweloperski oraz Scrum Master (odpowiedzialny za proces), jest Sprint Retrospective. Retrospektywa to doskonała okazja do inspekcji sposobu, w jakim pracujemy jako zespół, a także relacji międzyludzkich pomiędzy nami. Omawiamy co nam się udało i z czego jesteśmy dumni, a nad czym musimy pracować, aby jako zespół stać się bardziej efektywnym i dojrzałym. Następuje więc, tak ważna w Scrumie adaptacja.

Każdy projekt może składać się z wielu następujących po sobie Sprintów. Zazwyczaj jest to od kilku do nawet kilkudziesięciu takich iteracji. Gdy Klient uzna, że produkt jest już gotowy i skończony, przechodzimy w tryb jego utrzymania ustalony w umowie serwisowej.

Porozmawiaj z nami o usługach konsultingu i wdrożenia systemów CRM w Twojej firmie!

Skontaktujemy się z Tobą w ciągu 24 godzin.

mautic is open source marketing automation

Ta strona korzysta z plików cookie. Więcej informacji

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close