Metodologia Agile w dostarczeniu systemu zakupowego, czyli w jaki sposób pracujemy. cz. I

Zespół NextBuy z certyfikatami Scrum

Wstęp

Agile to metodologia, która coraz częściej pojawia się w kontekście metod prowadzenia projektów – szczególnie w branży IT. Dlaczego powstała i skąd się wzięła? To przede wszystkim odpowiedź na wymagania rynku, który wymusza elastyczność. Określone role w zespole, szczegółowo rozpisane zadania i czas na ich wykonanie sprawiają, że proces wdrożenia systemu zakupowego przy współpracy z naszymi klientami przebiega coraz sprawniej i efektywniej.

Szybko zmieniający się świat spowodował, że dotychczasowo stosowane podejście waterfall przestało się sprawdzać. Dlaczego? Doprowadzało często do tworzenia produktu, który w momencie wyjścia na rynek był już przestarzały.

Odpowiedzią na dynamiczne zmiany i wymagania jest Agile, który powoduje, że elastyczność pracy staje się dużo większa. Co więcej, Manifest Agile spowodował, że powstało wiele sposobów prowadzenia i realizowania projektów – wśród najważniejszych warto wymienić na przykład metodykę Scrum. Jednak praca w metodykach zwinnych często ma wiele cech wspólnych.

Warto zwrócić uwagę na najważniejsze zasady pracy w Agile, które zaowocowały sukcesem na rynku oraz na słabości tego podejścia, bo ich nigdy nie brakuje. Poniżej przybliżymy założenia metodyki Scrum, ponieważ to właśnie ją wykorzystujemy przy wdrożeniu NextBuy.

Od czego zacząć? Praca w cyklu Sprint

Analizując metodologię Agile trzeba zacząć przede wszystkim od podziału i organizacji pracy całego zespołu. Sprint to określenie okresu czasu przeznaczonego na dokładnie przewidziane prace deweloperskie. Trwa zazwyczaj od 2 do 4 tygodni. W czasie Sprintu i po jego zakończeniu dokonuje się przeglądów działań, a następnie zazwyczaj od razu po zakończeniu bieżącego sprintu rozpoczyna się kolejny.

W porównaniu z projektami prowadzonymi w metodologii waterfall, rozłożenie zadań w Sprincie na krótki okres znacznie ogranicza ryzyko. Efekty przyrostów są prezentowane klientowi po zakończeniu każdego Sprintu, dzięki czemu na bieżąco otrzymywany jest regularny feedback a także reakcja na potencjalne błędy. Ryzyko projektowe ograniczone jest w wielu przypadkach do jednego Sprintu, gdzie coś rozwijało się w sposób nieprawidłowy przez błędną interpretację wymagań. W przypadku metody waterfall często błędne zrozumienie wymagań jest diagnozowane dopiero po kilku miesiącach pracy.

Planowanie Sprintu i backlog refinement

Każdy Sprint wymaga odpowiedniego planowania. Metodyka, taka jak Scrum, przewiduje specjalne spotkanie – Sprint Planning, które odbywa się na początku każdego Sprintu, aby zdecydować, co ma zostać zrealizowane. Zespół developerski wycenia wymagania o najwyższym priorytecie do wykonania w najbliższym Sprincie. Istotny jest także backlog refinement, czyli regularne przeglądanie backlogu (aktualnych zadań) by mieć pewność, że są tam tylko istotne zadania a także, że nadaje są im odpowiednie priorytety. Odpowiada za to Produkt Owner(PO).

Definiowanie wymagań w postaci historyjek – czym są Stories?

Ciekawym i jednym z najbardziej rozpoznawalnych elementów metodologii Scrum jest definiowanie wymagań w postaci historyjek. Stories – potocznie nazywane jako historyjki – to krótki opis wymagań, zawierających informacje o tym, komu potrzebna jest dana funkcjonalność i w jakim celu. Stories powinny zawierać także Acceptance criteria, czyli elementy, które są niezbędne by wymagania były uznane za zrealizowane.

Retrospektywy – wgląd w działania

Istotnym elementem metodologii Scrum jest także retrospektywa – Sprint Retrospective. Metody Agile zakładają ciągłe doskonalenie. Retrospektywa to spotkanie, którego celem jest przegląd działań zespołu prowadzonych w danym Sprincie. Co więcej potwierdzenie, co w Sprincie udało się i zadziałało, a co jest do poprawy. Wyciągnięte wnioski są realizowane w przyszłym Sprincie.

Specyficzne role w Scrum

Metodyka Scrum określa specyficzne role w zespole. Scrum Team tworzy:

• Scurm Master, który jest strażnikiem przestrzegania zasad Scrum i liderem, który pomaga zespołowi w pokonywaniu wszystkich napotkanych trudności adresując je do odpowiednich osób,
• Product Owner, który odpowiada za finalny wygląd produktu oraz za priorytetyzację zadań
• Development Team, który składa się z profesjonalistów dostarczających rzeczywisty przyrost.

Jaki powinien być Scrum Team? Przede wszystkim cross-functional, to znaczy, że zespół ma składać się z osób posiadających kompetencje niezbędne do wykonania zadań oraz self-organizing­, czyli zespół doskonale wie, jak zarządzać swoją pracą.

Praca naszego zespołu

Jako firma, która ma liczne doświadczenia we wdrażaniu systemu zakupowego (zajrzyj do zakładki case study) postawiliśmy na zmianę. W zeszłym roku zmieniliśmy sposób naszej pracy – przeszliśmy na metodologię Agile i jesteśmy z siebie bardzo zadowoleni! Obecnie możemy pochwalić się certyfikatami, które otrzymaliśmy po zdaniu egzaminów Scrum na oficjalnej stronie twórców: Kena Schwabera i Jeffa Sutherlanda – nasz zespół stanął na wysokości zadania i wśród zdających mamy: 8 certyfikatów uprawniających do pracy w roli Scrum Mastera oraz 1 – Product Ownera. To nie koniec! Nadal będziemy się rozwijać!