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? :)