Zwinny zespół, czyli role i organizacja pracy przy tworzeniu aplikacji

Zwinny zespół, czyli role i organizacja pracy przy tworzeniu aplikacji

Gdy rozpoczynasz nowe przedsięwzięcie, ekscytacja miesza się z poczuciem niepokoju. Co zrobić, żeby poczuć się pewniej? Przezorny zawsze ubezpieczony, dlatego ważne jest odpowiednie przygotowanie do procesu tworzenia aplikacji.

Aby Ci to ułatwić, przedstawiam, jak przebiega rozwój oprogramowania w Holdapp. Dowiedz się, jacy specjaliści tworzą zwinny zespół (z ang. agile team), czym się zajmują i z jakich korzystają narzędzi. Dzięki temu poczujesz się pewniej i lepiej przygotujesz się do zadań, które na Ciebie czekają.

Poznaj członków zespołu agile

Do stworzenia funkcjonalnego produktu potrzeba wielu umiejętności. Dlatego podejście agile zakłada, że każdy zespół składa się z osób, które razem mają wszystkie kompetencje niezbędne do osiągnięcia celu, czyli wydania aplikacji.

Ci specjaliści wspólnie tworzą zespół deweloperski i są odpowiedzialni za rozwój produktu. Chociaż nazwa kojarzy się głównie z deweloperami (programistami), w rzeczywistości w takim zespole są osoby, które pełnią różne funkcje. Mogą to być m. in. analitycy biznesowi, testerzy, designerzy i inni eksperci. Znajdziesz w tej grupie wszystkich zaangażowanych w tworzenie produktu. Poznasz ich podczas spotkania kickoffowego.

Kto może wchodzić w skład zespołu agile?

Każda firma ma własny tryb pracy. Przedstawiony tutaj skład zespołu nie musi być identyczny w przypadku Twojego projektu. Daje Ci jednak dobre rozeznanie, jacy specjaliści zazwyczaj się w nim znajdują.

  • Project manager – nazywany też kierownikiem projektu lub scrum masterem, jest bezpośrednio odpowiedzialny za projekt. Dba o to, żeby komunikacja pomiędzy zespołem a klientem przebiegała bezproblemowo, pilnuje budżetu oraz harmonogramu.
  • iOS developer – pracuje nad aplikacją na urządzenia firmy Apple.
  • Android developer – tworzy aplikację na urządzenia z systemem Android.
  • Flutter developer – zajmuje się programowaniem aplikacji tworzonych w technologii cross-platformowej.
  • QA specialist – tester aplikacji, który dba o to, aby wszystkie funkcjonalności działały zgodnie z określonymi wymaganiami na różnych rodzajach urządzeń.
  • UX/UI designer – projektuje widoki ekranów aplikacji, grafiki i makiety; czasem zadania związane z UX i UI są podzielone na dwie osoby.
  • Business analyst – inaczej analityk biznesowy, czyli osoba odpowiedzialna za identyfikację wymagań oraz specyfikacje funkcjonalności.
  • Backend developer – zazwyczaj jest to zewnętrzny dostawca API lub członek zespołu klienta; pracuje on nad rozwiązaniami backendowymi, z których korzysta aplikacja mobilna.

Product owner i jego rola w zespole

Członkiem zespołu agile jest również właściciel produktu (czyli product owner albo PO). To najważniejsza rola po stronie klienta, ponieważ PO reprezentuje zleceniodawcę projektu. Product owner ma pełną decyzyjność jeśli chodzi o ustalanie priorytetów, zakresu prac i wysokość budżetu.

Podejmuje również decyzje dotyczące tego, w jaki sposób ma działać każda funkcjonalność. On też ostatecznie zatwierdza, że rezultat pracy zespołu jest zgodny z postawionymi wymaganiami. Najściślej PO współpracuje z kierownikiem projektu, czyli project managerem (PM).

Agile team members

Jak wygląda organizacja pracy zespołu?

Zwinne zespoły pracują w trybie iteracyjnym, co charakteryzuje podejście agile. To znaczy, że okres trwania projektu jest podzielony na małe odcinki zwane iteracjami albo inaczej sprintami. Zazwyczaj trwają one ok. 2 tygodnie. Przez ten czas zespół rozwija produkt.

Taki system sprawia, że możemy na bieżąco monitorować i korygować harmonogram prac. Kontrolujemy też, czy ich postęp zmierza we właściwym kierunku.

Spotkania organizowane w ramach iteracji

Sprint in app development process

Rytm iteracji wyznaczają spotkania ustalone podczas kick-offu.

Planning to spotkanie całego zespołu, które ma miejsce przed rozpoczęciem każdej iteracji. Służy do ustalenia celu oraz zakresu działań, jakie należy zrealizować w nadchodzącym sprincie. Wtedy decydujemy, nad czym będzie pracował każdy członek zespołu deweloperskiego. Zadania te trafią do backlogu sprintu. Podczas tego spotkania często staramy się też doprecyzować wymagania dotyczące funkcjonalności, które będziemy brać na warsztat. Dlatego product owner musi być obecny na planningu. Po spotkaniu każdy dokładnie wie, co musi wykonać i w jaki sposób.

Daily, czyli krótkie codzienne spotkanie wewnątrz zespołu deweloperskiego (zazwyczaj bez udziału klienta). Ma ono na celu ustalenie, jak postępuje praca, nad czym pracuje każdy członek zespołu w danym momencie oraz co udało już się zrealizować. Jest to też moment, kiedy rozmawiamy o ewentualnych problemach, jakie napotkaliśmy. Dzięki temu każdy wie, co dzieje się w projekcie, a project manager może szybko reagować na pojawiające się ryzyka.

Demo – pierwsze z dwóch spotkań, które odbywają się na zakończenie sprintu. Organizujemy je, żeby zebrać informacje zwrotne na temat produktu. Pozwala nam to wyznaczyć dalszy kierunek rozwoju aplikacji. Podczas demo każdy deweloper prezentuje, co udało mu się zrealizować w czasie ostatniej iteracji. Jest to też dobry moment na zgłaszanie przez PO (lub innych osób po stronie klienta) uwag związanych z zaimplementowanymi funkcjonalnościami. Udział w tym spotkaniu bierze zespół deweloperski i PO. Obecni mogą też być sponsorzy projektu lub inni interesariusze.

Retrospektywa stanowi drugie spotkanie kończące sprint. Wtedy zespół rozmawia o możliwych usprawnieniach i napotkanych problemach. Omawia też pomysły na zapobieganie im w przyszłości. Jest to spotkanie wewnętrzne, podczas którego zespoły zwinne skupiają się na procesie dostarczania funkcjonalności. Po takich rozmowach decydujemy się na wprowadzenie poprawek, które są zapisywane jako tzw. action pointy. Mają one poprawić wydajność procesu tworzenia i rozwoju oprogramowania.

Refinement (weekly) zazwyczaj ma miejsce pomiędzy planningiem a demo. Podczas tego spotkania product owner wraz z zespołem ustalają, jakie powinny być dalsze działania. Dodają te zadania do backlogu produktu. Następnie w czasie planningu ustalamy terminy ich wykonania. Refinement to też czas, kiedy przeglądamy zadania, które już wcześniej wpisano do backlogu produktu i aktualizujemy ich status. W ten sposób porządkujemy backlog.

Z jakich narzędzi korzystamy?

Nie wystarczy wiedzieć, kto i co robi w ramach procesu rozwoju aplikacji. Żeby mieć pełen obraz sytuacji, musisz też pamiętać o narzędziach, które umożliwiają sprawne zarządzanie projektami. Oto najważniejsze z nich.

Jira

Skąd masz wiedzieć, na jakim etapie właśnie jesteśmy? Jak sprawdzić, ile udało nam się zrobić i co jest jeszcze w planach? W planowaniu i rozliczaniu pracy pomaga nam Jira.

To specjalistyczne oprogramowanie, które służy do zarządzania projektami. Każdy projekt ma własne miejsce zwane tablicą, która odzwierciedla jego aktualny stan. Dostęp do takiej tablicy ma cały zespół projektowy. Zarządza nią project manager (lub scrum master) wraz z product ownerem.

Domyślny widok pokazuje aktualny sprint. Możesz na nim sprawdzić numer i cel sprintu, skład zespołu, daty rozpoczęcia i zakończenia sprintu, a nawet ile dni zostało do jego końca.

Tablice

Tablica to nic innego jak zestaw odpowiednio nazwanych kolumn. Nazewnictwo może się różnić w zależności od projektu i organizacji, ale podstawowe kolumny to:

  • TO DO – kolumna, w której na początku sprintu znajdują się wszystkie zaplanowane zadania. Z biegiem czasu jest ich coraz mniej.
  • IN PROGRESS – są w niej wszystkie zadania, nad którymi obecnie pracuje zespół deweloperski.
  • CODE REVIEW – kod napisany przez dewelopera zawsze sprawdza inny specjalista. To pozwala nam dbać o jakość naszych rozwiązań. Dlatego w tej sekcji są zadania, nad którymi prace zasadniczo się zakończyły, ale aktualnie ich kod czyta inny deweloper. Może on np. sugerować poprawki czy inne rozwiązania optymalizacyjne.
  • TEST – w tej kolumnie znajdziesz zadania, które zespół QA poddaje testom funkcjonalnym.
  • DONE – zawiera zadania, które przeszły z sukcesem całą opisaną ścieżkę.

Dodatkowo mogą się pojawić inne kolumny np. :

  • BLOCKED – tutaj znajdą się wszystkie zgłoszenia związane z zadaniami, nad którymi prace zostały przerwane z pewnych (zazwyczaj niespodziewanych) powodów np. niedziałającego API.
  • CLIENT TEST – korzystamy z tej kolumny jeśli po stronie klienta pracuje dodatkowy zespół testerów.

Wygląd tabeli zależy od zakresu prac oraz składu zespołu. Warto zastanowić się nad swoimi potrzebami, żeby znaleźć najlepszy układ kolumn dla swojego projektu.

Jira board

Widok tablicy w Jirze.

Zgłoszenia

Każde zadanie czy zgłoszenie jest przyporządkowane do danej osoby. Możesz ją zobaczyć na karcie zgłoszenia. W szczegółach zadania sprawdzisz też:

  • rodzaj zgłoszenia (user story, task, bug),
  • dokładnie zdefiniowany zakres prac,
  • kryteria akceptacji,
  • epic, do którego przyporządkowane jest zgłoszenie,
  • numer wersji aplikacji, w której rozwiązanie zostanie wdrożone,
  • estymacje czasochłonności,
  • faktyczny czas spędzony nad zadaniem,
  • komentarze,
  • historię edycji.

Jira - Issue

Widok zgłoszenia w Jirze.

Oprócz widoku bieżącego sprintu, w Jirze jest też podgląd roadmapy projektu oraz backlogu projektu i sprintu.

Jira - backlog

Widok backlogu w Jirze.

Warto również wspomnieć o możliwości sprawdzenia zakresu poszczególnych wersji aplikacji, które znajdziesz w zakładce Releases. Ten widok przydaje się, gdy chcesz się upewnić, co zostało zrobione i na jakim etapie.

Jira - Releases

Widok Releases w Jirze

Slack

W Jirze sprawdzisz, czym każda osoba zajmuje się w danym momencie. Ale co jeśli musisz jednak zadać pytanie komuś z zespołu? Pisanie maili nie jest wygodne, szczególnie jeśli chcesz dyskutować z kilkoma osobami jednocześnie.

Dlatego w codziennej komunikacji używamy Slacka. To komunikator, który pozwala prowadzić zarówno rozmowy grupowe, jak i prywatne.

Każdy projekt otrzymuje swój własny workspace w Slacku, czyli miejsce, do którego mają dostęp wszyscy zaangażowani w jego rozwój. Jeśli agencja współpracuje z jakimś dostawcą, np. backendowym, lub zleceniodawca ma większy zespół po swojej stronie, ważne jest, aby każdy miał swoje miejsce do prowadzenia rozmów.

W ramach projektu tworzymy tzw. kanały. Każdy projekt ma ich kilka, a ich dobór jest uzależniony od rodzaju prowadzonych działań. Kanał to miejsce, które skupia wybrane osoby (np. specjalistów z jednej dziedziny i project managera) i pozwala im szybko wymieniać się informacjami. Dzięki temu nikt nie dostaje zapytań, które go nie dotyczą.

Przykładowe kanały:

  • #api – do zadawania pytań / zgłaszania błędów / wprowadzania zmian w warstwie służącej do komunikacji pomiędzy aplikacją mobilną a backendem;
  • #design – do informowania o zmianach, które zostały wprowadzone na designach, omawiania widoków czy grafik;
  • #builds – kanał zsynchronizowany z narzędziem do dystrybucji buildów, dzięki któremu cały zespół jest informowany o wypuszczeniu nowej wersji aplikacji do testów;
  • #general – kanał, na którym pojawiają się wszystkie najważniejsze ustalenia, podsumowania spotkań, uzgodnione terminy wydań itd.

W zależności od projektu oraz fazy rozwoju aplikacji są dodawane kolejne kanały, jak np. #bug – do zgłaszania błędów, które wykrył klient lub użytkownicy końcowi aplikacji.

Pod kanałami znajduje się sekcja do wysyłania wiadomości prywatnych.

Pamiętaj jednak, że większość informacji wymieniamy jawnie na kanałach, aby zachować transparencję i umożliwić szybki przepływ informacji.

Znasz organizację pracy w zespole agile. Co dalej?

Znajomość zwinnych metodyk pozwoli Ci lepiej zrozumieć, jakie zadania czekają na Ciebie na etapie planowania działań oraz w fazie rozwoju produktu. Dzięki temu możesz z wyprzedzeniem ustalić, jakich informacji będzie potrzebował zespół deweloperski. Określisz też, które kompetencje warto rozwijać, jeśli pełnisz rolę product ownera.

Przyda Ci się to w codziennej pracy nad rozwojem produktu. Ponadto łatwiej będzie Ci się porozumieć z innymi osobami, które zajmują się budową oprogramowania.

PM portrait - Anka

Anna Szymanek

Project Manager

Dowiedz się więcej

Wycena projektu

Opowiedz nam o swoim projekcie i napisz, jak możemy Ci pomóc.

Dlaczego warto rozwijać z nami projekty?

Logo Mobile Trends Awards

Mobile Trends Awards 2021

Wygrana w kategorii
ŻYCIE CODZIENNE

Nagroda Legalnych Bukmacherów

Nagroda Legalnych Bukmacherów 2019

Najlepsza aplikacja mobilna

Mobile Trends Awards logo

Mobile Trends Awards 2020

Nominacja w kategorii
SPORT I REKREACJA

20

opinii klientów

Clutch logo