Cześć! Dzisiaj zajmę się tematem wymagań klienta co do aplikacji. Tym, co może się stać, gdy są one zmieniane bez zastanowienia. Jak zmiana wymagań wpływa na naszą pracę? Wreszcie czy błahe z pozoru zmiany w aplikacji, mogą spowodować błąd krytyczny?
Jak zawsze zaczniemy od podstaw.
Czym są wymagania aplikacji?
Zgodnie z definicją podaną przez SJSI „Wymaganie” to
Postanowienie zawierające kryteria, które należy spełnić.
Definicja wydaje się wyjaśniać dobrze, wymaganie to wszystko to, co mówi, jak aplikacja ma działać. W przypadku formularza dla osób pełnoletnich wymaganiem będzie to, że formularz musi wypełniać osoba mająca 18 lub więcej lat.
Wymagania zmieniają się.
Wymagania określa klient. Klient może również zmienić te wymagania w dowolnym momencie wytwarzania aplikacji. Nie znaczy to jednak, że zmienia je stale, ponieważ zmiany kosztują, każdej zmianie towarzyszy kosztorys jej wykonania. Jak się pewnie domyślasz, w związku z tym nie wszystkie proponowane zmiany wymagań są wdrażane. I dobrze, bo mielibyśmy chaos.
Zmiana wymagań a metodyka wytwarzania aplikacji.
Zacznę od odwołania się do metodologii wytwarzania oprogramowania, w drugiej kolejności do pracy zespołu nad wytwarzanym oprogramowaniem.
Zacznijmy od metodologii – i tu podejmę dwie główne model kaskadowy oraz metodyki zwinne.
Model kaskadowy jest moim zdaniem bardziej odporny na sytuację, w której klient nagle stwierdza, że chciałby, żeby jakaś funkcjonalność wyglądała inaczej. Dzieje się tak dlatego, że każda zmiana w tym modelu jest osobno estymowana i podejmowana jako coś poza procesem – często wydłużając wydanie aplikacji. W modelu kaskadowym mamy jako zespół trochę więcej czasu, żeby zareagować prawidłowo na zachcianki klienta.
Gorzej ma się kwestia, jeżeli chodzi o metodyki zwinne – tu powodów jest kilka. Głównym grzechem jest podejście Scrum Masterów/PMów do samej kwestii zmian wymagań – przeczytaj manifest Agile.
Czasami dochodzi do tego, że jest stosowane podejście „Nasz klient nasz pan”. Skutkiem takiego podejścia jest na przykład wprowadzanie zmian tuż przed wdrożeniem/nieoczekiwanie. Co w tym złego?
Tego typu zmianom przeważnie towarzyszy duża presja czasu. Na programistach wymusza ona czasami bardzo nieeleganckie podejście do kodu. Kolejnym problemem może być to, że jeżeli nasz klient jest zmienny, to programiści, zamiast czyścić kod, częściej go komentują „na wszelki wypadek”, bo a nuż widelec za dwa tygodnie się odwidzi naszemu klientowi.
No dobra, ale co w takim razie jest w tym złego?
Czy błahe zmiany wymagań w aplikacji mogą być powodem dużych problemów?
Inspiracją do tego wpisu jest krótki film na YouTube, w którym autor omawia największe błędy w grach komputerowych. I tak na podstawie jednego przykładu dowiedzieć się możesz, że w jednej z gier możliwe było ubranie gracza w skarpety nie do pary. Po jakimś czasie twórcy gry zdecydowali, że jest to niepotrzebna funkcjonalność. Skarpety powinny do siebie pasować. I tak tą jedną zmianą spowodowali, że wszyscy ci, którzy przed zmianą ubrali swoją postać w grze w różne skarpety, byli wywalani z gry (nastąpiło rozłączenie z serwerem gry).
Zmiana wymagań w grze na pozór prosta spowodowała, że część graczy nie mogła jej włączyć. Jeśli chcesz zobaczyć ten i inne przykłady, zachęcam do obejrzenia filmu na YouTube. Przykład, który omówiłem powyżej, pokazany jest w 3 minucie filmu.
Wracając do pytania „Co w tym złego, że zmiany wymagań w aplikacji są spontaniczne?”. Jeżeli mamy jakieś nieoczekiwane zmiany, zwłaszcza w aplikacjach rozległych, gdzie zaimplementowana funkcja może odwoływać się do kilu lub kilkunastu innych, to zwyczajnie możemy mieć aplikację nie do użytku, bo nam się będzie przez skarpetki wywalać – tu nawiązanie do udostępnionego filmu.
No dobra, ale jak sobie w takim razie radzić pracując w takim projekcie, w którym zmiany są częste?
Przede wszystkim jako majster od jakości musisz przewidzieć, co może nie pyknąć. Jednym słowem warto przygotować dużo danych testowych powiązanych z usuwaną czy zmienianą funkcjonalnością. Czy jest to realne? No tutaj pojawia się srogie, TO ZALEŻY. Przede wszystkim od rozległości zmian. Jeśli musisz przygotować masę danych testowych, to też tego od ręki nie zrobisz. Po drugie, zwłaszcza jeżeli pracujesz np. w Scrumie, to terminy bardzo obowiązują no i musisz się wyrobić – co z tego, że masz właśnie dodatkową robotę „be agile”.
Ten meme zrozumiecie, jak już trochę popracujecie w branży i okaże się, że fajne są owocowe czwartki. Kawusia też spoko, ale jak mamy wdrożenie to nasze standardy pracy muszą na chwilę zamknąć oczy, bo klient nasz pan.
Skutki oczywiście bywają różne i też zależą od tego, jaką aplikację robimy. Jak widać po załączonym filmiku jedną ze składowych porażki może być brak możliwości używania aplikacji – a wydawałoby się, że bug pierdołowaty 😀
Przy trochę bardziej wymagających aplikacjach np. bankowe mamy swojego rodzaju bufor i mimo wszystko staramy się nie dopuszczać do aż takich sytuacji – chociaż wiadomo, bywa różnie.
Na koniec pochwała dla mnie 🙂
Mam trochę więcej czasu. To znaczy tyle, że mogę pisać w miarę regularnie (trzeci tydzień z rzędu, znaczy dobrze chyba?). Chwalę się tym, ponieważ od dłuższego już czasu nie miałem chwili, by regularnie napisać na blogu. Tak więc dzisiaj mogę poklepać się po ramieniu, zasłużyłem! 🙂
