Jak wygląda proces tworzenia oprogramowania w HighSolutions?
Tworzenie oprogramowania w HighSolutions to długi i złożony proces. Każdy uczestnik tego przedsięwzięcia musi być tak elastyczny, jak tylko to możliwe.
Możemy podzielić ten cykl na kilka części, które dadzą nam dobry przegląd tego, jak wygląda. Oczywiście nie każdy krok jest potrzebny we wszystkich projektach, na przykład jeśli klienci potrzebują chatbota na ich fanpage'u na Facebooku, możemy pominąć zbędne elementy projektowania lub gdy potrzeby klienta są naprawdę dobrze wyrażone w dokumentacji - nie ma potrzeby warsztatów.
- Oszacowanie
- Warsztaty
- Projekt
- Programowanie
- Testowanie / kontrola jakości
Oszacowanie
Pierwsza część, której się przyjrzymy, to część szacunkowa. Ta część ma miejsce nawet przed podpisaniem jakiejkolwiek umowy z klientem. Podczas tego etapu dział biznesowy spotyka się z zespołem technicznym. Lider technologiczny odpowiedzialny za projekt musi wycisnąć każdą kroplę wiedzy, jaką firma ma na temat potrzeb klienta. Tutaj decydujemy, jakiej technologii będziemy używać.
Warsztaty
Czasami zespół musi spotkać się z klientem w celu omówienia jego szczegółowych potrzeb. Dzięki temu możemy uniknąć problemów w przyszłości. Często klient nie ma pełnego obrazu swojego produktu i nie myślał o niektórych problemach technicznych, które programiści natychmiast zobaczą.
Również osobiste spotkanie z klientem pozwala nam zbudować silniejszą relację, która pomaga w przyszłości, gdy pojawią się jakiekolwiek nieporozumienia.
Planowanie
Podczas planowania całego procesu, lider zespołu zapisuje każdą część projektu na mniejsze, prostsze zadania. W idealnym projekcie powinny być proste na tyle, aby mogły zostać wyjęte z kontekstu i wykonane przez dowolnego programistę bez wiedzy na temat całego przedsięwzięcia.
Po pierwsze, projekt został podzielony na większe części zwane milestones (kamienie milowe), które są w zasadzie zestawami funkcji aplikacji. Następnie zaczynamy myśleć o tym, jak użytkownik będzie wchodził w interakcje z tymi funkcjami i tworzymy mniejsze porcje, które nazywamy „User story”. Następnie zapisujemy w nich rzeczywiste zadania dla programistów, podając jak najwięcej szczegółów.
Projekt
Nadszedł czas, aby wkroczył nasz zespół projektowy. Najczęściej lider techniczny przygotowuje listę widoków, które nasza aplikacja powinna posiadać i na podstawie tych informacji, przygotowywane są wireflam’y.
Wireflame’y to „szkice” aplikacji, które można wykonać bardzo szybko, ale wiele mówią o tym, jak będzie wyglądał produkt końcowy, jakie funkcje będzie miał i jak różne części systemu będą ze sobą współdziałać. Są one konsultowane z programistami w celu sprawdzenia, czy wszystkie zaprojektowane funkcje są możliwe do wdrożenia.
Jeśli wireflam’y są akceptowane zarówno przez klienta, jak i zespół programistów, projektanci rozpoczynają pracę nad rzeczywistymi projektami. Zawierają każdy szczegół produktu, dodatkowe informacje, takie jak paleta kolorów zastosowana w projekcie, rzeczywista treść, obrazy, które będą wyświetlane na stronie internetowej. Są one używane jako model dla programistów na temat tego, jak dokładnie aplikacja powinna wyglądać piksel po pikselu.
Na samym końcu tworzymy prototypy. Dzięki nim klient może „korzystać” z aplikacji bez żadnego kodu. Są one w zasadzie zaprojektowane z klikalnymi częściami, które przenoszą cię z jednego widoku do drugiego. Pozwala klientowi przyzwyczaić się do tego, jak aplikacja będzie używana jako produkt końcowy.
Programowanie
Tutaj dzieje się rzeczywista magia. Programiści wykonują swoje małe zadania i powoli tworzą całość. W międzyczasie tworzone są testy automatyczne. Zapewniają nas, że kod robi to, co powinien, nawet po wprowadzeniu dużych zmian. Aby umożliwić programistom jednoczesną pracę na tym samym kodzie, używamy zapisów kontrolnych postępów, w których wszystkie zmiany są zapisywane, a następnie możemy połączyć je w produkt końcowy.
Programiści tworzą także różne środowiska, w których aplikacja jest dostępna. Aby nadążyć z aktualizowaniem zmian, możemy potrzebować osobnych instancji dla programistów, testerów i klientów, a gdy całość jest już w porządku, wszystkie zatwierdzone funkcje są dostępne na serwerze produkcyjnym, gdzie użytkownicy mogą z nich korzystać.
Testowanie / kontrola jakości
Programiści wciąż są ludźmi (chociaż czasami wcale się tak nie zachowują 🤖), więc nie tworzą doskonałego oprogramowania. Automatyczne testy pomagają w trakcie procesu, ale mogą tworzyć fałszywe przekonania o naszej doskonałości. W tym miejscu wkraczają inni ludzie. Testerzy najpierw zapewniają uczciwe działanie naszej aplikacji - używają jej tak, jak powinni użytkownicy. Nie robią nic specjalnego, po prostu sprawdzają, czy wszystko działa tak, jak powinno. Jeśli nic nie znajdą, podejmowane są specjalne kroki. Każda część projektu jest testowana do granic możliwości. Testerzy używają tak brutalnych technik, jak pisanie bzdur w każdym polu, klikanie spamu, a nawet zaglądanie do konsoli programisty w poszukiwaniu błędów.
Cykl
Najczęściej to właśnie tester znajduje błąd i zgłasza go programistom, ale istnieje wiele innych przypadków. Na przykład, jeśli programiści zdają sobie sprawę, że kodowanie niektórych funkcji potrwa zbyt długo, następuje powrót do fazy projektowania, w której można to zrobić inaczej. Dlatego właśnie tworzenie software’u nigdy nie jest prostą drogą do celu. To raczej cykl, w którym podczas każdej części zadanie może zostać cofnięte do poprzedniego kroku.
