Projektowanie Tworzenie Utrzymanie
i rozwój
Projektowanie
systemu informatycznego
Tworzenie
oprogramowania
Utrzymanie i rozwój
aplikacji biznesowych
Tomasz

O tym jak powstają systemy biznesowe opowiada
Tomasz Gdula – inżynier oprogramowania w FINGO

Jak powstaje oprogramowanie „szyte na miarę”?

Na temat powstawania dedykowanego oprogramowania krążą legendy. Wiele osób myśli na przykład, że programiści otrzymują specyfikację, zamykają się w swoich pokojach i przez kilka tygodni tworzą oprogramowanie, a gdy jest gotowe, otwierają drzwi i pokazują je zachwyconemu Klientowi.

I Klient jest zachwycony czy nie jest?

W trosce o wysoką jakość i satysfakcję Klienta, zgodnie z nowoczesnymi metodologiami oprogramowanie zawsze powstaje w bliskiej współpracy z Klientem. Dla mnie tworzenie oprogramowania to nie jest sytuacja, w której dostajemy napisaną specyfikację i zabieramy się za kodowanie. Moją rolą w firmie jest ustalanie z Klientem, jak powinno funkcjonować oprogramowanie i pilnowanie, by wynik prac odpowiadał Zleceniodawcy.

Czy aplikacji nie tworzy się właśnie w ten sposób, że wspólnie z Klientem przygotowuje się szczegółowy opis funkcjonalności, a następnie na podstawie tego dokumentu programiści tworzą aplikację?

Obecnie praca zespołu projektowego jest zorganizowana inaczej. To tradycyjne podejście, o którym mówisz, jest coraz częściej wypierane przez tak zwane zwinne metodyki, nazywane z angielskiego „agile”. My również pracujemy w ten sposób. W tradycyjnym podejściu najpierw powstaje dokładna specyfikacja programu, później projekt całego systemu, następnie do pracy ruszają programiści, którzy przygotowują kod źródłowy. W dalszej kolejności jest faza testowania, po czym gotowe rozwiązanie trafia do Klienta.

W podejściu, które wykorzystujemy, te fazy też są realizowane, jednak w krótszych interwałach czasowych i dotyczą pewnych części systemu. Fazy takie nazywamy Sprintami. W trakcie jednego Sprintu, który trwa najczęściej dwa tygodnie, nie jesteśmy w stanie zaprogramować całej złożonej aplikacji, lecz tylko część funkcjonalności. Po każdym Sprincie wytworzony fragment można przetestować i przekazać uwagi twórcom. Obecnie powstaje tak większość złożonych systemów informatycznych.

Jakie są korzyści tej metody?

Klienci mają możliwość szybkiego ewaluowania aplikacji i wyrażenia swojego zdania na jej temat. W tradycyjnym podejściu na wczesną wersję systemu trzeba czekać nawet kilka miesięcy. Tutaj pierwsze funkcjonalności możemy przetestować w ciągu pierwszego miesiąca. Jeśli Odbiorca jest zadowolony, idziemy dalej, jeśli ma uwagi uwzględniamy je w kolejnym Sprincie.

Mogę prosić o przykład?

Jako przykładem posłużę się systemem dla handlowców pracujących zdalnie. W pierwszym etapie przygotowujemy bazę klientów, którą handlowcy mogą swobodnie przeglądać i przeszukiwać. Nawet bez żadnych dodatkowych funkcjonalności można ją wykorzystać np. do prowadzenia korespondencji biznesowej. W kolejnych Sprintach udostępniamy możliwość tworzenia zamówień, podglądu stanów magazynowych, wyliczenia kosztów transportu dla złożonych zamówień, podglądu płatności i rankingu kredytowego itp. Każda z tych funkcji stanowi wartość dla użytkowników.

Czy są jeszcze jakieś korzyści tworzenia aplikacji w „krótkich odcinkach”?

W wielu projektach na początku pozornie dobrze wiadomo, jak ma działać aplikacja. Gdy jednak dochodzi do przygotowania rozwiązania, okazuje się, że wizja ta wcale nie jest tak przejrzysta. Posłużę się wcześniejszym przykładem systemu dla handlowców.

Wraz z rosnącą liczbą klientów aplikacja powinna zapewnić możliwość łatwego ich wyszukiwania w bazie danych. To wyszukiwanie może być zrealizowane na wiele sposobów, od prostego znajdowania po nazwie, poprzez sortowanie po różnych parametrach, takich jak czas ostatniego kontaktu, wielkość zamówień lub ich brak w ostatnim czasie, lokalizacja klienta itp. Często dopiero, gdy użytkownicy zaczną korzystać z tej aplikacji wiadomo, jakiego rodzaju wyszukiwanie preferują. Można to próbować przewidzieć na etapie projektowania, ale życie potrafi zaskakiwać nawet najbardziej doświadczone osoby.

Jak wyglądają wskazówki od użytkowników?

Użytkownicy zgłaszają prośby takie, jak: „Częściej korzystam z tego. Tę funkcję przydałoby się umieścić na głównym ekranie. To powinno działać inaczej” itp. Stąd ogromną zaletą pracy w Sprintach jest możliwość wczesnego oddawania aplikacji użytkownikom i słuchania ich propozycji rozwoju.

W takim razie, jak zacząć pierwszy Sprint?

Pracę zaczynamy od zdefiniowania produktu o minimalnej koniecznej funkcjonalności. Jest to podstawowy zakres funkcji, który musi zostać zaimplementowany, żeby Klient mógł zweryfikować w praktyce przydatność biznesową produktu. Czasami, by to osiągnąć potrzeba nie jednego, ale kilku Sprintów.

Ile czasu zajmuje stworzenie pierwszej wersji oprogramowania?

Zdarzało nam się, że pierwsza wersja oprogramowania była gotowa w miesiąc. Jeśli ten czas miałby być znacznie dłuższy, to warto przygotować prototyp, który pozwala użytkownikom ocenić proponowane rozwiązania. W takim prototypie część funkcjonalności nie będzie działała, ale użytkownicy będą mogli sformułować pierwsze oceny.

Co jest ważne w dobrej współpracy przy tworzeniu oprogramowania?

Bardzo istotna jest informacja zwrotna. Bez niej metodyka zwinna przestaje działać. Nie otrzymując informacji musimy tworzyć oprogramowanie, zgadując, czy to, co robimy, spodoba się Klientowi. To się nie może udać. Na szczęście Klientom zależy na sprawnej komunikacji i to pomaga.

Myślę, że największa obawa Klientów przed metodykami zwinnymi to brak informacji o kosztach i terminie realizacji projektu na początku.

Trudno jest powiedzieć, ile będzie kosztował cały projekt, aby to zrobić trzeba przygotować wcześniej bardzo szczegółową specyfikację. Jednak koszt tworzenia takiej specyfikacji jest często większy niż błąd oszacowania kosztów w projekcie prowadzonym według metodyki zwinnej.

Klienci mogą mieć już przecież przykre doświadczenia z projektami, których koszt wzrósł na etapie realizacji znacznie ponad szacunki z etapu sprzedaży…

Jak w każdej współpracy, nie tylko biznesowej potrzebne jest zbudowanie zaufania. Dostawca powinien na nie zapracować. Trudno jest zakładać, że otrzyma je za darmo, szczególnie, jeśli Klient ma złe doświadczenia z pracą z innymi firmami. Mieliśmy sytuacje, w których rozpoczynaliśmy współpracę przy bardzo ograniczonym zaufaniu, ale w miarę realizacji złożonych obietnic ono rosło.

Istotne jest też, że w metodyce zwinnej Klient zamiast płacić za nieprzydatną, z jego punktu widzenia, szczegółową dokumentację – która później i tak będzie podlegała zmianom – może zobaczyć jak pracuje się z nami i otrzymać pierwszą wersję produktu. Nie musi nic zakładać – może przekonać się, że jesteśmy w stanie przygotować dla niego dokładnie to, czego potrzebuje.

Jeśli Wasze produkty powstają w takim tempie, to czy macie też czas, żeby je przetestować?

Na to zawsze jest czas. Inaczej poprawianie błędów kosztuje zbyt dużo, a ponadto może się negatywnie odbić na naszej reputacji.

Nasze oprogramowanie testujemy na różne sposoby. Bardzo lubimy testy automatyczne: testujemy w ten sposób zarówno pojedyncze funkcje w kodzie, jak również całą funkcjonalność. Można to sobie wyobrazić tak, jakby automat testował naszą aplikację: klikał i poruszał się po jej ekranach. W przypadku niektórych naszych projektów, te automatyczne testy są tak złożone, że potrzeba całej nocy, aby je wszystkie wykonać. Dzięki nim, gdy przyjdziemy rano do pracy, możemy od razu zorientować się, czy nie trzeba czegoś poprawić.

Oczywiście nawet najlepsze testy automatyczne nie zastąpią naszych nieocenionych testerów. Ich niezwykła inwencja jest często w stanie wykryć sytuacje, których nie przewidzi programista ani nie wychwyci automat.

To brzmi jakbyś chciał powiedzieć: „Metodyka oparta na Sprintach, czyli SCRUM, jest tak efektywna, że nie wyobrażam sobie pracy w inny sposób”.

Tradycyjna metodyka ma uzasadnienie tam, gdzie Klient dokładnie wie, jak ma wyglądać produkt i nie może pozwolić sobie na ciągłą dostępność i obecność na spotkaniach. Zamiast tego woli przyjechać i odebrać gotowy system dokładnie według specyfikacji. Jeśli jednak na etapie tworzenia założeń pojawiało się wiele wątpliwości w zespole projektowym, to warto rozważyć zastosowanie metodyki zwinnej. Wtedy większość wątpliwości uda nam się rozstrzygnąć w czasie projektu, przy udziale użytkowników końcowych.

Wiele mówiliśmy o metodyce. Jak na co dzień wygląda praca programistów FINGO?

Każdy z nas pracuje trochę inaczej. Jedni pracują przy ogromnych 30-to calowych monitorach. Mnie do pracy wystarcza laptop. Często mówi się, że informatycy wolą, gdy pisze się do nich e-maile niż proponuje rozmowę – rozumiem to, gdy ktoś jest zajęty i nie chce, by go rozpraszać, ale ja uwielbiam rozmawiać i zdecydowanie wolę krótką pogawędkę niż e-maile.
Zresztą rozmowa to część metodyki, którą stosujemy – spotykamy się rano, by omówić zadania na dany dzień – co zostało zrobione, co sprawia trudności, na czym powinniśmy się skupić i czym zajmiemy się dzisiaj.

Kontakt

FINGO sp. z o.o.
  • Plac Powstańców Śląskich 7
    53-329 Wrocław, Polska
  • godz. 8:00 – 16:00
  • NIP 8942683871
FINGO sp. z o.o. z siedzibą we Wrocławiu, Plac Powstańców Śląskich 7, 53-329 Wrocław, zarejestrowana w Sądzie Rejonowym Wrocław-Fabryczna we Wrocławiu, VI Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 0000020323. NIP 8942683871, REGON 932670710. Kapitał zakładowy 50.000,00 zł w pełni opłacony.
Używamy plików cookies, aby zwiększyć wygodę użytkownika strony. Brak zmiany ustawień przeglądarki oznacza na to zgodę.
Więcej