Aby przybliżyć Ci najlepszy sposób prowadzenia projektów programistycznych, podzielimy się z Tobą naszym procesem dostarczania oprogramowania.
Chociaż chwalimy Agile we wszystkich formach, potrzebujemy pewnej podstawowej struktury, jeśli chcemy wielokrotnie dostarczać najwyższej jakości wyniki. Utrzymujemy ją prostą i spójną, dzięki czemu możliwe jest zastosowanie jej u większości naszych klientów.
Proces dostarczania oprogramowania
Poniżej widać, że tworzenie oprogramowania nie jest nawet drugim etapem naszego 4-etapowego procesu. Deweloperzy w Inspeerity są chętni do rozpoczęcia kodowania od razu, ale wiemy, że im więcej potu na treningu, tym mniej krwawienia w bitwie. W projektach rozwoju oprogramowania oznacza to, że im więcej czasu poświęcasz na eksplorację, tym mniej czasu spędzasz na naprawianiu błędów.
Zazwyczaj Inspeerity dzieli projekty na 4 fazy:
- EKSPLORACJA - kiedy zagłębiamy się w potrzeby klienta i uzasadnienie projektu.
- ROZPOCZĘCIE PROJEKTU - kiedy spotykamy się, aby wszyscy byli na tej samej stronie i nadali projektowi rozpędu.
- DEVELOPMENT - faktyczne tworzenie oprogramowania.
- CIĄGŁE WSPARCIE ROZWOJU - kiedy upewniamy się, że nasze oprogramowanie reaguje na zmieniające się potrzeby i wymagania burzliwego środowiska.
Przejdźmy przez każdą fazę i odkryjmy, jak to robimy.
Eksploracja
Pierwszą rzeczą, którą my (lub jakikolwiek zespół programistów) musimy zrobić, jest zbadanie potrzeb naszych klientów (Twoich) i wymagań projektu. Następnie chcemy odkryć najlepsze sposoby na zaspokojenie tych potrzeb i sprawienie, by wszystko działało. Tak, później w fazie rozwoju będziemy odkrywać lepsze sposoby dostarczania wartości poprzez każdą iterację, ale na razie potrzebujemy czegoś na początek. Co więcej, ważne jest, czego nie tworzyć i nad czym nie pracować.
Faza eksploracji wygląda więc następująco:
- Zbierz wszystkie wymagania i przeprowadź badania użytkowników.
- Zbuduj listę funkcji za pomocą techniki Event Storming.
- Utwórz dokument przeglądu projektu, zwany dokumentem projektu niskiego poziomu (LLD).
- Przygotowanie planu technicznego i projektu podejścia wdrożeniowego.
- Tworzenie szkieletów i/lub projektów wizualnych.
Podczas tej fazy organizujemy spotkania twarzą w twarz lub rozmowy telefoniczne, ponieważ są one znacznie bardziej efektywne niż wysyłanie do siebie maili przez wiele dni. Pracując z klientem, staramy się zrozumieć cele i założenia, tło biznesowe i wymagania techniczne projektu. Każda funkcja powinna być uzasadniona wartością, jaką zapewnia. Tylko wtedy stworzymy właściwą rzecz.
Ten etap jest kluczowy, ponieważ każdy klient jest inny, a każdy projekt jest wyjątkowy. Podobnie jak opracowywane przez nas rozwiązania szyte na miarę. Bez dogłębnego zrozumienia wizji i potrzeb klienta niemożliwe jest dostarczenie najbardziej odpowiedniego rozwiązania, dostosowanego do obecnych i przyszłych wyzwań biznesowych, w ramach docelowego budżetu.
Eksploracja jest związana z tworzeniem Deklaracji pracy - krótkiego opisu zakresu projektu, rezultatów i harmonogramu. Upewniamy się, że wszyscy są na tej samej stronie i zgadzają się co do głównych założeń projektu.
Głównym celem jest zebranie wszystkich wymagań i zrozumienie wszystkich przypadków biznesowych, a następnie stworzenie odpowiedniej architektury projektu i projektu UI/UX. Poniższy rysunek przedstawia wszystkie kroki w fazie eksploracji.

Przyjrzymy się teraz podstawom każdego kroku.
Badania użytkowników i wymagania + lista funkcji i sesja Event Storming
Zwykle zbieramy wymagania od klienta wraz ze wszystkimi możliwymi informacjami o środowisku i innych ważnych czynnikach (cała dokumentacja, przypadki użycia, opis projektu, dokumentacja API innych firm itp.)
Następnie organizujemy spotkanie, aby przedstawić nasz zespół i spotkać się z klientem i właścicielem produktu. Co więcej, jest to okazja dla wszystkich członków naszego zespołu, aby dowiedzieć się więcej:
- Główny cel aplikacji.
- Wszyscy aktorzy (role), na przykład Administrator, Konstruktor itp.
- Główne przepływy (przypadki biznesowe).
- Główny model domeny.
- Wymagane i przyszłe interfejsy zasilania danymi
Z całą tą wiedzą zespół spotyka się na sesji Event Storming. Ich celem jest zebranie wszystkich wymagań. Następnie mogą rozwinąć wszystkie potrzeby interesariuszy i odkryć potencjalne luki. Zagłębiając się w przepływ biznesowy, odkrywają niespójności między różnymi perspektywami i konkurującymi celami.
Używamy oprogramowania Miro do wizualizacji wyników Big Picture Event Storming. Poniżej znajduje się analogowy przykład z naszych poprzednich warsztatów:

Przegląd projektu i dokument projektu niskiego poziomu
Zgodnie z RFQ (Request For Quotation) dla projektu, przygotujemy przegląd projektu. Poniżej znajduje się dokument Low Level Design (LLD). Opisuje on szczegółowo logikę systemu i zawiera:
- Architektura systemu
- Opis komponentów (schemat C4)
- Projekt architektury wdrożenia
Plan techniczny
Plan techniczny będzie oparty na dokumentacji LLD. Tym razem celem jest uchwycenie ważnych decyzji architektonicznych oraz ich kontekstu i konsekwencji, a także stworzenie całej dokumentacji LLD. Każdy zapis będzie zawierał następujące informacje:
- Status - proponowany, zaakceptowany, odrzucony, przestarzały itp.
- Kontekst - jaki jest powód tej decyzji lub zmiany?
- Decyzja - Jaką zmianę proponujemy i/lub wprowadzamy?
- Konsekwencje - co staje się łatwiejsze lub trudniejsze do wykonania z powodu tej zmiany?
Plan techniczny wprowadza również frameworki, biblioteki, usługi SaaS planowane w obecnym rozwiązaniu.
Szkielety i projekty wizualne
Szkielety są jak szkice, które pokazują ogólny układ aplikacji lub strony internetowej. Jest to niezbędny krok przejściowy między zebraniem wszystkich informacji i stworzeniem architektury a zaprojektowaniem kompletnej wizualnej części oprogramowania - interfejsu użytkownika (UI).
Projekt wizualny obejmuje nie tylko rozmieszczenie elementów, ale także kolory, ilustracje, kontrasty, kształty, tekstury, a czasem także mikrokopię.
Wszystkie wyniki, wszystko, co do tej pory zebraliśmy, prowadzi nas do rozpoczęcia projektu.
Rozpoczęcie projektu
Rozpoczęcie to moment, w którym spotykamy się wszyscy (Ty i my), aby podsumować wszystkie ustalenia i wyniki fazy eksploracji. Wierzymy, że dobra komunikacja jest kluczem do stworzenia wyjątkowego oprogramowania. Dlatego dzielimy się wiedzą tak często, jak to tylko możliwe.
Nasz Kick-off rozpoczyna się od warsztatów Agile. Wspólnie z zespołem tworzymy szczegółowy plan rozwoju, backlog dla pierwszego wydania i wybieramy funkcje dla pierwszego przyrostu projektu (Sprintu).
Następnie dopasowujemy członków zespołu do konkretnych zadań. Bierzemy pod uwagę doświadczenie, umiejętności i talenty naszych specjalistów i dopasowujemy je do Twoich celów i potrzeb. Dopiero wtedy możemy przejść do fazy rozwoju.
Rozwój
Faza rozwoju to czas, w którym dzieje się magia. Stosujemy metodologię Agile, aby efektywnie tworzyć oprogramowanie i dostarczać wartość.
Zgodnie z Agile, pracujemy przyrostowo i planujemy naszą pracę w odstępach czasu, zwanych Sprintami. Zazwyczaj trwają one od 2 do 4 tygodni. Sprinty rozpoczynają się sesjami planowania, a następnie przechodzą do fazy kodowania. Wreszcie, każdy Sprint kończy się sesją demonstracyjną i retrospektywami, podczas których zbieramy informacje zwrotne, aby dostosować i ulepszyć sposób, w jaki pracujemy razem. Możesz dowiedzieć się więcej o zwinnym tworzeniu oprogramowania z naszego artykułu o różnicach między SCRUM i Kanban.
Korzystając z tego podejścia, dostarczamy działające oprogramowanie na wczesnym etapie, dzięki czemu możemy szybko reagować na zmiany i pojawiające się potrzeby. Wczesne i regularne testowanie oprogramowania pomaga nam w pełni zaspokoić potrzeby biznesowe klientów
Ciągłe wsparcie rozwoju
Koniec fazy rozwoju nie oznacza końca cyklu życia oprogramowania. W miarę ewolucji projektu nadal optymalizujemy wielkość i strukturę zespołu, aby dostosować go do zmieniających się wymagań. Nasi najlepsi programiści będą nieustannie pracować nad ulepszaniem oprogramowania i odpowiadaniem na wyzwania turbulentnego środowiska. Zbierzemy informacje zwrotne od użytkowników i przekształcimy je w nowe, lepsze rozwiązania. Dążymy do tego, aby Twój produkt odniósł sukces!
Podczas całkowicie niezobowiązującej 30-minutowej rozmowy nasz zespół przeanalizuje obecną konfigurację techniczną i przedstawi sugestie dotyczące najlepszych ulepszeń dla Twojej firmy.
P: Na czym polega technika Event Storming?
Event Storming to technika wykorzystywana do zbierania i organizowania wymagań projektowych. Polega ona na zorganizowaniu spotkania z klientem i właścicielem produktu w celu przedstawienia zespołu i poznania głównego celu aplikacji, aktorów, głównych przepływów, głównego modelu domeny i wymaganych interfejsów zasilania danymi.
P: Jak wygląda proces dostarczania oprogramowania w Inspeerity?
Proces dostarczania oprogramowania Inspeerity składa się z 4 faz, które obejmują eksplorację, rozpoczęcie projektu, rozwój i ciągłe wsparcie rozwoju. Podczas fazy eksploracji zespół gromadzi wymagania klienta i przeprowadza badania użytkowników. Faza Project Kick-Off to moment, w którym zespół zbiera wszystkich na tej samej stronie i nadaje projektowi rozpędu.