bugi marnotrawstwo waste lean

O marnowaniu #6 – Błędy i wady jakościowe

Agile

Bugi to integralna część życia zespołów IT. Każdy z nich to marnotrawstwo – trzeba poświęcić dodatkową pracę na ich naprawę, przerwać często coś innego nad czym pracowaliśmy. W ten sposób tracimy czas, który mógł tworzyć nową wartość.


Ten post to szósty (i ostatni) post z serii, w której poruszam problem manortrawstwa. Jeśli chcesz się dowiedzieć, czym ono jest lub przeczytać poprzednie artykuły przejdź do tej strony.


Nie każdy bug jest taki sam

Dla każdego z nas będzie jasne, że wady w działaniu naszych serwisów czy usług to nic korzystnego. Jednak, jak do tego problemu podchodzić? Na co zwrócić uwagę?

Zacząłbym od dwóch rzeczy:

#1 należy pogodzić się z faktem, że oprogramowanie bez jakichkolwiek wad, to rzecz bardzo trudna do osiągnięcia, o ile w ogóle możliwa – częściej po prostu nie wiemy o istnieniu jakiegoś błędu

#2 należy w ogóle przyjąć jakieś zasady i zwalczać wpływ bugów na nasz produkt – często widzę po prostu nieuregulowany sposób zgłaszania i naprawiania błędów, bez większej refleksji.

Tak jak punkt #1 jest zapewne dość jasny, szczególnie dla tych, którzy doświadczyli już złego dotyku bugów ;-) to punkt #2 wymaga trochę rozwinięcia. Co warto uwzględniać? Będą to:

– wpływ błędu na nasz produkt (np. czy blokuje całkiem możliwość zakupu wszystkim użytkownikom czy tylko „wygląda brzydko”),
– zasięg błędu (dotyczy tylko 1% użytkowników, w zupełnie brzegowych sytuacjach czy „wszystkich”?),
– ile czasu błąd mógł występować,
– co nowego poświęcamy w miejsce pracy nad naprawieniem buga,
– jaki wpływ ma decyzja o naprawianiu (lub nienaprawianiu) danego błędu na dług technologiczny (czasem świadomie można coś odkładać „na potem”, ale w ten sposób zwiększamy dług, którego spłata może dużo kosztować).

Zatem, gdy znajdziemy błąd, warto podejść do niego obiektywnie i rozważym powyższe aspekty, a następnie zdecydować co dalej.

Zapobieganie jest lepsze

Rozsądek zapewne podpowiada, że lepiej zapobiegać niż leczyć. A jak zapobiegać bugom? Kilka wskazówek:

– dobre inspekcje kodu
– dobry proces QA
– odpowiednie testy kodu
– lintery, standardy, style-guide itd.
– możliwie częste integracje kodu
– możliwie częste wdrożenia produkcyjne

Stosowanie takich praktyk może pomóc nam ograniczyć marnotrawstwo (waste) związane z defektami. Nigdy ich całkiem nie wyeliminujemy, ale to nie oznacza, że nie możemy dążyć do najwyższych możliwych standardów, prawda? :)

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *