fbpx
 

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 zgodne z metodyką Scrum rozpoczynają się po zamknięciu etapu konsultingu, doboru systemu CRM oraz ustaleń handlowych. Przybierają formę działań analitycznych opisanych szerzej tutaj. Dla klienta zainteresowanego wdrożeniem przeprowadzamy warsztaty System Overview (zapoznanie z systemem) lub Product Discovery (rozpoznanie potrzeb i wymagań wobec systemu). Są to wysoce kreatywne spotkania, które pozwalają spojrzeć na zarządzanie procedurą biznesową zarówno z wąskiej, jak i szerokiej perspektywy. Warto podkreślić, że uczestnictwo w warsztatach wiąże się z koniecznością Twojego pełnego zaangażowania. Aby lepiej zwizualizować omawiane zagadnienia, proponujemy Ci pobudzające wyobraźnię techniki myślenia kreatywnego; wszystko z wykorzystaniem kolorowych karteczek samoprzylepnych, pisaków, tablic suchościeralnych oraz folii antystatycznych.

Wynikiem przeprowadzonych warsztatów jest Product Backlog, głównie w formie User Stories, czyli historyjek z życia użytkownika. Jest on przygotowany przez przedstawiciela eVolpe, który 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 Backlog przygotowujemy oszacowanie poszczególnych elementów systemu, tak by uzyskać rząd wielkości projektu przed jego rozpoczęciem. Podejście to stosujemy 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 kilkutygodniowych iteracjach. Oznacza to, że po każdym takim okresie następuje przyrost nowych funkcji, zmiana lub udoskonalenie istniejących elementów systemu. Każda iteracja rozpoczyna się od spotkania zwanego Sprint Planningiem. W jego trakcie ustalany jest cel nadchodzącego sprintu, czyli nadrzędna wartość, która zostanie uzyskana. Na tej podstawie dobierane są również User Stories (historyjki z życia użytkownika), których rozwiązanie pozwala na osiągnięcie przyjętego celu. Tworzą one Sprint Backlog. Druga część spotkania polega na dokładnym zaplanowaniu prac przez Zespół Deweloperski, tak by gotowe zagadnienia spełniały ustalone wcześniej kryteria ukończenia (Definition of Done).

Jest to niezwykle istotne, gdyż codziennie przez kolejne dni odbywa się krótkie (maksymalnie 15-minutowe) spotkanie zwane Daily Stand-upem. W eVolpe przeprowadzamy je przy 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 również, co udało się wykonać przez ostatnią dobę, jaki jest plan działania i czy napotkaliśmy jakieś trudności.

W trakcie sprintów odbywają się również spotkania zwane Refinement. Są one dedykowane nowym wymaganiom, które zgłasza klient, 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 uzyskany przyrost, pokrótce prezentując to, co zostało wykonane. Jest to również odpowiedni moment na dyskusję odnośnie do nowych wymagań (które mogły zostać zainspirowane obecnym kształtem produktu), innych przekształceń, a także oczekiwań dotyczących kolejnego sprintu. Następuje więc inspekcja wykonanych prac, a także adaptacja wymagań do sytuacji, w której 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. Pamiętaj! Masz możliwość zapoznania się z nowymi funkcjami w przygotowanym dla Ciebie środowisku testowym. Na tej podstawie następuje ostateczna akceptacja 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. Warto przyjrzeć się także relacjom międzyludzkim panującym w zespole oraz omówić, co się udało i z czego jesteśmy dumni, a nad czym należy jeszcze pracować. W ten sposób stajemy się jeszcze bardziej efektywni  jako zespół. Następuje 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 uznasz, że produkt jest już 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