Wewnętrzna jakość

Słyszałeś o tym, że istnieje coś takiego jak wewnętrzna i zewnętrzna jakość?

Jakość zewnętrzna to wszystko to, co widzi użytkownik. To funkcje jakie spełnia aplikacja. Nie chodzi jedynie o usability i kwestie związane z wyglądem zewnętrznym. Też o jakość zaimplementowanych możliwości. Czy po kliknięciu drukuj pojawia się dialog drukowania, czy pdf do ściągnięcia, którego można wydrukować po otwarciu? Czy cały proces biznesowy jest obsługiwany, czy może o część elementów dbają użytkownicy? Czy elementy z zewnętrznych systemów importują się perfekcyjnie, czy w 10% potrzebna jest interwencja użytkownika lub nawet programisty?

Niższa jakość zewnętrzna nie zawsze oznacza, że jest źle. To jest decyzja, którą podejmuje właściciel produktu (product owner) pod warunkiem, że dysponuje pełną informacją o sytuacji. Jeśli wie, że perfekcyjny import opóźni wdrożenie o cały miesiąc, a “prawie dobry” oznacza wykorzystanie okazji biznesowej już teraz (relatywnie niewielkim nakładem pracy ludzi) – może wybrać opcję “prawie dobrą”. Oczywiście może poprosić o wersję idealną przy kolejnej iteracji.

Jakość wewnętrzna zkolei to coś, czego zrozumienie przychodzi ciężko czasem nawet programistom. To brak długu technicznego (przykład), podatność kodu na zmiany wymagań, niewrażliwość na regresję (wprowadzanie błędów wraz z nowym kodem, powracanie tych już naprawionych).

Jakość wewnętrzna aplikacji jest nienegocjowalna w zespołach Agile.

Gdy jest ona niska, nowe błędy są odkrywane przy każdym wdrożeniu, Twoja aplikacja choruje, a zespół traci czas na jej łatanie – wolniej implementuje nowe elementy. Sponsor/właściciel produktu nie wykorzystuje w pełni nadarzających się okazji na rynku. To wszystko trwa aż do dramatycznego momentu, kiedy okazuje się że nie da się już produktu rozwijać. Pomyśl tylko… zespół programistów dwa lata rozwijał aplikację i teraz musi zacząć od nowa. Aplikację, na którą wydałeś setki tysięcy złotych. I jedyne co masz, to doświadczenie Twoich programistów (o ile cały zespół nie wymienił się w tym czasie przynajmniej raz). Dla nich to świetne szkolenie, ale z Twojego punktu widzenia niezbyt opłacalne.

Znam trzy narzędzia, które dbają o wysoką jakość wewnętrzną.

Pierwszy (nietechniczny) już podałem: jakość wewnętrzna nie podlega negocjacji. Gdy product owner chce importu, ale nie ma czasu zaimplementować go perfekcyjnie – nie jest opcją zaimplementowanie go na szybko w technologii spagehetti code. Możesz negocjować zakres funkcji do zaimplementowania, nigdy jakość wewnętrzną. Klient nawet nie powinien znać opcji “super szybkiej”, z dwóch powodów:

  1. na pewno by ją wybrał, ponieważ…
  2. nie wie, że to zabije jego projekt

Posługując się analogią budowlaną: Klient chciałby mieć tańszy dom. Wykonawca proponuje zamiast wylania fundamentów (co trwa i kosztuje) wsypanie do wykopu śmieci, które ma z poprzedniej budowy. Klient oczywiście się nie zgadza, bo to śmiertelne zagrożenie dla jego rodziny. Oczywiście w naszym kraju to jest niemożliwe – kierownik budowy poszedłby do więzienia. IT nie ma nadzoru budowlanego – nieszczęście w szczęściu ;)

Pozostałe (techniczne): refaktoring kodu i testy. Refaktoring (czy refaktoryzacja) usuwa dług techniczny, który zawsze zaciągasz rozwijając aplikację. Aktywnie z nim walczy, stale przebudowując kod usuwając powtórzenia i poprawiając architekturę systemu.

Jednak refaktoring jest strasznie trudny. Nowe funkcje mogą wprowadzić nowe i przywrócić stare błędy. Zmiana kodu, która nie wprowadza nowych funkcji, ale wprowadza błędy w ogóle nie jest sexy. Dlatego potrzebujesz automatycznych testów.

Testy jednostowe, testy integracyjne i wszystkie inne jakie jesteś w stanie zautomatyzować mogą ochronić Cię przed regresją kodu. Dzięki nim programista nie boi się refaktoringu – zmienia, klika – widzi wielki zielony napis “OK” i jest szczęśliwy.

Takie podejście zwraca się w długim terminie. Życzę wszystkim, aby mieli okazję pracować którzy potrafią tak daleko patrzeć.

Share Button

5 thoughts on “Wewnętrzna jakość

  1. Pingback: Czym jest Agile? | webbricks

  2. Nie mam z nimi doświadczenia, ale jeśli tylko wspierają konwencje i dobre praktyki (jak na przykład używanie var i unikanie eval w Javascript) na które zgadza się cały zespół to czemu nie. Te praktyki najczęściej pomagają uniknąć trudnych do wytropienia bugów. Ale nie powinny zastąpić testów napisanych dla konkretnej aplikacji, testujących np. jej logikę biznesową.

    A jakie Ty masz, Krzyśku, doświadczenie z takimi narzędziami?

  3. Żadnych, dlatego pytałem :)

    W tym co piszesz jest jeden haczyk, cały zespół musi mówić jednym głosem. Inaczej może się skończyć zwolnieniem. W końcu manager uzna, że ten gość mało umie, wszyscy inni to napiszą ;)
    Zgodzę się, że “dobrze” napisany kod jest lepszy w utrzymaniu, ale to jest inwestycja na przyszłość, nie każdy manager będzie jej świadomy.
    Przesadzam?

  4. Oczywiście, że zespół musi mówić jednym głosem (nawet jeśli ten głos jest wypracowanym w trudach kompromisem). W ogóle trudno zbudować zwinny zespół, jeśli menedżer jest moim wrogiem i uważa, że programiści chcą go oszukać ;)
    W zwinnym zespole menedżer jest jego członkiem tak jak właściciel produktu – wszyscy zgodnie twierdzą, że projekt jest najważniejszym celem. Wydaje mi się, że rozsądny menedżer to zrozumie. A nierozsądny może niestety tracić dobrych specjalistów.

    No i nie przesadzasz. Żeby była jasność – nie twierdzę, że tym postem wyczerpałem temat. To temat na całe rozdziały książek (które chciałbym zacytować, ale te co przeczytałem rozdałem lub pożyczyłem :P)

Leave a Reply

Your email address will not be published. Required fields are marked *