Zanim internet zawitał na stałe do naszych domów, zamiast grania online spotykaliśmy się we własnych domach i używając techniki gorącego krzesła spędzaliśmy czas grając w proste, ale strasznie miodne gry.
Jedną z takich gier, przy których spędziliśmy setki godzin, była gra Scorched Earth. Zasada była prosta – każdy gracz ma swój czołg, którym wystrzeliwał pocisk w pozostałych graczy. Wygrywał ostatni pozostały na placu boju. Celowanie odbywało się poprzez ustawienie kąta strzału oraz jego mocy. Charakterystyczna była smuga, która powstawała po wystrzale. Pozwalała ona precyzyjniej wycelować w kolejnej turze. Jej brak znacząco utrudniał grę i zmniejszał celność graczy.
Pociski smugowe w programowaniu
Pociski smugowe bywają wykorzystywane przez programistów – pomagają im one dosięgnąć celu w trudnych warunkach, które wynikają z niełatwego zadania kompletowania wymagań użytkowników.
Zasada ich działania jest bardzo prosta. Możemy podejść do rozwoju oprogramowania na dwa sposoby:
- określając na starcie bardzo precyzyjnie wymagania systemu, ograniczenia, niewiadome oraz ograniczenia środowiska, tak by za jakiś czas – po zakodowaniu oraz integracji wszystkich funkcji – przekazać gotowe rozwiązanie użytkownikom,
- szukając rozwiązań, które w szybki i tani sposób przeniosą nas od koncepcji do działającego systemu, który – pomimo surowości oraz braku wszystkich funkcji – będziemy mogli wkrótce czasie pokazać użytkownikom, aby uzyskać od nich informację zwrotną i zadecydować, czy chcą rozwijać system dalej, czy to co zobaczyli jest dla nich wystarczające.
Drugie podejście jest nieco trudniejsze – wymaga od zespołu tworzenia kompletnych rozwiązań end-to-end w trakcie pojedynczej iteracji, jednak efekt wart jest wysiłku.
Co to oznacza w praktyce?
Załóżmy, że mamy stworzyć prosty proces zakupowy składający się z 3 kroków:
- KROK 1: dodanie produktu do koszyka
- KROK 2: wybór adresu dostawy, rodzaju płatności oraz sposobu dostawy
- KROK 3: wysłanie zamówienia
Podejście pierwsze
Po określeniu precyzyjnych wymagań na starcie, efektem pierwszego tygodnia prac może być dobrze zaimplementowany pierwszy krok procesu – możemy dodać produkt do koszyka. Możemy podać liczbę przedmiotów, zwiększać oraz zmieszać ich liczbę, a także zobaczyć zdjęcia obrazujące produkt wraz z ich opisem.
Efekt: Nie możemy de facto zrealizować zamówienia – dysponujemy wyłącznie jednym krokiem z trzech.
Podejście drugie
Wystrzeliwujemy pocisk smugowy. W trakcie tygodnia pracy implementujemy kompletny proces, składający z trzech kroków, który pozwala nam faktycznie zrealizować zamówienie. Oczywiście, możemy dodać tylko jeden przedmiot do koszyka, nie wyświetlamy zdjęć produktu, musimy ręcznie wpisać adres dostawy (nie napisaliśmy jeszcze modułu logowania), a zapłacić można tylko przy odbiorze przesyłki.
Efekt: Pomimo surowości rozwiązania, możemy zrealizować zamówienie. Możemy również pokazać rozwiązanie użytkownikom i zapytać, czy zmierzamy w dobrym kierunku.
Na koniec…
Ważna sprawa – stosowanie pocisków smugowych nie oznacza rezygnacji z jakości. Pamiętamy o obsłudze błędów, dokumentacji czy ogólnej walidacji danych. Obszar, którym możemy sterować, to liczba funkcji, którą decydujemy się zaimplementować.
Życzę udanych strzałów :)
2 odpowiedzi