Jak wygląda proces tworzenia oprogramowania w Futuriti

Czego potrzeba, aby tworzyć dobre oprogramowanie? Na pewno odpowiedniego zespołu przekuwającego swoją wiedzę i doświadczenie w prawidłowo napisany kod. Oprócz tego niezbędna jest również świetna organizacja pracy, dzięki której możliwe będzie terminowe kończenie wszystkich projektów. Dlatego w Futuriti już jakiś czas temu wdrożyliśmy metodykę pracy Agile (czyli zwinną) Scrum, a teraz chcemy pochwalić się opartym o nią procesem tworzenia oprogramowania w naszej firmie.

Co tworzymy w Futuriti?

Kiedy zaczynaliśmy naszą przygodę z biznesem, działając jeszcze pod nazwą ALPOL, zajmowaliśmy się przede wszystkim wdrażaniem systemów ERP firmy Comarch. Następnie do naszej oferty trafiły pierwsze integratory pozwalające połączyć ERP Optima i ERP XL z najpopularniejszymi platformami sprzedażowymi (m.in. z Allegro, Amazon i eBay), esklepami i firmami kurierskimi.

Dziś, działając niemal siedmiu miesięcy pod zupełnie nową marką – Futuriti – za cel postawiliśmy sobie tworzenie oprogramowania dedykowanego firmom ecommerce. Tak powstał xSale – system do zarządzania sprzedażą wielokanałową. Tak pojawił się w naszej ofercie również autorski WMS usprawniający działanie magazynu.

Oprócz powyższych aplikacji – dostępnych dla każdego, kto chce zwiększać wydajność w swojej firmie – prowadzimy również projekty dedykowane, „szyte na miarę” pod konkretne zastosowania. To wszystko sprawiło, że potrzebowaliśmy zupełnie nowej metodyki pracy pozwalającej stale ulepszać wszystkie nasze produkty.

Dlatego podjęliśmy decyzję, aby skorzystać z zalet, jakie daje Agile Scrum.

Jak tworzymy oprogramowanie w Futuriti?

Chcąc osiągnąć zamierzone cele, musimy wytyczyć ku nim odpowiednią drogę. W tym właśnie pomaga nam Agile Scrum. Działając zgodnie z zasadami tej metodyki jesteśmy w stanie skuteczniej wyznaczać kamienie milowe dla naszych produktów, uwzględniając wszystkie potrzeby klientów i plany tworzone dla kolejnych wersji produkcyjnych.

Proces tworzenia oprogramowania w Futuriti przedstawić można w kilku punktach:

  • Nad całością prac produktowych dla każdego produktu czuwa Product Owner, którego zadaniem jest utrzymywanie tzw. backloga, czyli listy funkcji jakie zamierzamy wdrożyć do naszych systemów.
  • Dla każdej funkcji z backloga przygotowywana jest historia, czyli opis zawierający schemat jej działania z punktu widzenia użytkownika (albo administratora jeżeli to np. funkcja administracyjna). Tak opisane zadanie, wraz z innymi zadaniami zaplanowanymi na cały tydzień, tworzy tzw. sprint.
  • Wybór zadań z pośród wszystkich w Backlogu do realizacji w kolejnym sprincie to też odpowiedzialność Product Ownera. Muszą to być funkcje najbardziej potrzebne naszym klientom a jednocześnie realizujące długoterminowe cele rozwoju produktu.
  • W trakcie sprintu nie można dodawać nowych zadań. Jeżeli są one bardzo pilne to trafią już do następnego sprintu.
  • Zadania są szacowane na podstawie potencjalnego czasu pracy i trudności i przypisywane poszczególnym developerom.
  • Każdego dnia z rana (o stałej godzinie, na którą wszyscy z zespołu musza się pojawić) robimy stand-up – spotkanie odbywane na stojąco przy tablicy z listą zadań. Tam też każdy z developerów omawia wykonaną już przez siebie część projektu, dzieli się spostrzeżeniami i uwagami. Cały stand-up trwa maksymalnie kwadrans, w czasie którego staramy się zidentyfikować wszystkie ewentualne problemy pojawiające się w czasie tworzenia kolejnych funkcji i w miarę możliwości zaproponować rozwiązanie, albo ustalić jak dany temat będziemy rozwiązywać dalej.
  • Zadanie, które zostanie przez developera wykonane trafia następnie do weryfikacji. Ta dzieli się na kilka etapów, z których pierwszy to PeerReview, sytuacja, w której rezultat pracy oceniany jest przez innego developera. Pozwala to wyłapać ewentualne nieścisłości, znaleźć wypadające z szafy trupy, lecz przede wszystkim zapewnia swobodną wymianę wiedzy w DevTeamie.
  • Kolejny etap weryfikacji to specjalnie przygotowane testy automatyczne. Ich zadaniem jest przejście przez wszystkie kroki nowych funkcji oraz wykrycie pominiętych na poprzednim etapie nieprawidłowości. Testy projektowane są tak, aby oceniały również oddziaływanie nowych fragmentów kodu na całość działania systemu i szybko wychwytywały ewentualne błędy. Pozwala to wprowadzić niezbędne poprawki zanim aktualizacja pojawi się w wersji dostępnej dla klientów.
  • Jeśli testy automatyczne dają wynik pozytywny, zespół testów tworzy nowe wersje scenariuszy uwzględniające kolejne dodawane funkcje, umożliwiając dalsze testowanie coraz bardziej rozbudowanego systemu w przyszłości.
  • Ostatnim etapem weryfikacji są testy eksploracyjne przeprowadzane ręcznie przez Product Ownera oraz automatycznie w środowisku testowym. Jeśli wszystko jest w porządku, aktualizacja trafia do produkcyjnej wersji systemu.
  • W każdym tygodniu w piątek po południu podsumowujemy sprint na specjalnym spotkaniu. Dzielimy się wrażeniami, sprawdzamy co poszło dobrze a co warto usprawnić w kolejnym tygodniu.
  • O nowościach (Demo) informujemy klientów, m.in na forum, a partnerów i pozostałe zespoły w dedykowanych newsletterach.

Wprowadzenie elementów metodyki Agile Scrum pozwoliło nam dokładniej planować działania i skutecznie egzekwować realizację wszystkich zadań przekazywanych do developerów. Dzięki wdrożeniu testów automatycznych jesteśmy również w stanie szybciej i dokładniej sprawdzać kolejne wersje naszych produktów upewniając się, że będą bezproblemowo służyć klientom w spełnianiu ich celów biznesowych.

Zobacz również

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *