Prawdopodobnie każdy inżynier systemu ma doświadczenie z pracy nad długiem technologicznym. Czasem jest on “zaciągany” z powodu braku czasu, innym razem ze względu na nieodpowiednie oszacowanie kosztów projektu. Niemniej, jak każdy dług, również ten technologiczny trzeba spłacić. Zadanie to nie należy do najłatwiejszych – zarówno pod kątem gromadzenia, jak i udoskonalania wymagań.
Walka z długiem technologicznym uczy jednocześnie, w jaki sposób najlepiej realizować zadania techniczne. Pokazuje też, na co zwrócić uwagę, pokrywając dług technologiczny. O tym w poniższym artykule.
Zbieranie wymagań do zadań technicznych
Pokrywanie długu technologicznego utrudniają elementy przeznaczone do poprawy, które programiści zwykle dodają do folderu z zaległościami, bez odpowiednich notatek i opisu. Wychodzą wówczas z założenia, iż nie są potrzebne, bo przecież rozumieją zakres zadań i wiedzą, co należy robić. Ludzka pamięć nie jest jednak idealnym miejscem do przechowywania danych. Niemal pewne jest więc, iż ich wiedza prawdopodobnie będzie utracona w momencie, gdy zadanie techniczne zostanie podjęte do udoskonalenia i wdrożenia.
Uniknięcie długu i napisanie dobrego rozwiązania technologicznego wymaga poświęcenia temu zadaniu dużej uwagi ze strony zespołu deweloperskiego. Dlatego też w jednym z zespołów EPAM Polska zadania związane z zaległościami technologicznymi (technical backlog items) przechodzą przez następujące bramki jakości:
- Wstępne tworzenie: lider zespołu i kluczowi programiści omawiają możliwe ulepszenia technologiczne – szczególnie w sytuacji, w której mają wątpliwości, czy są one potrzebne lub w jaki sposób zostaną wdrożone.
- Tworzenie: kiedy przygotowywane jest ulepszenie techniczne, inżynier systemu powinien upewnić się, iż zawiera ono wszystkie wymagane szczegóły.
- Wstępne udoskonalenie: weryfikacja przez innych programistów i kierownika zespołu.
- Dopracowanie: cały zespół programistów omawia przedmiot i zadaje pytania.
- Końcowe-dopracowanie: odpowiedzi na wszystkie pytania zadane na etapie udoskonalania powinny zostać udzielone przez twórcę zadania.
Etap tworzenia może być najtrudniejszy, ponieważ programiści zwykle wiedzą, co należy zrobić w ramach zadania technicznego, ale stworzenie odpowiedniego opisu, który będzie zarówno informacyjny, jak i przejrzysty, może być dla nich prawdziwym koszmarem.
Prezentacja pomysłów technicznych
Artykuł na temat korzystania z funkcji FDD umożliwia pewne zrozumienie dobrego opisu zadania technicznego. Krótko mówiąc, idea jest taka, iż większość technicznych elementów backlogu powinna być napisana bez jakiegokolwiek ustrukturyzowanego języka. Oczywiście możliwe jest użycie notacji „As […] I would like to […] So that […]” i kryteriów akceptacji napisanych w języku Gherkin, ale spowoduje to nadmierny wysiłek dla zespołu programistów, bez przełączania domeny podczas pracy nad zadaniem. Dla zobrazowania różnicy w podejściu, wystarczy porównać dwa przykłady:
1. „Jako programista chcę mieć możliwość uruchomienia potoku wydania (eng. release pipeline), aby aplikacja mogła zostać wdrożona w środowisku programistycznym, testowym, UAT i produkcyjnym”.
lub
2.„Powinieneś skonfigurować potok wydań dla środowiska programistycznego, testowego, UAT i produkcyjnego”.
Oczywiście druga opcja jest o wiele łatwiejsza do odczytania i zrozumienia.
Wiele zespołów zdaje sobie sprawę, iż najlepsze praktyki odpowiednie dla historyjek użytkownika nie sprawdzają się w zadaniach technicznych. Z tego powodu prawie wszystkie zespoły programistyczne nie mają ścisłej formy opisywania usprawnień technicznych. Taka sytuacja prowadzi do kolejnego problemu: historie są źle napisane, trudno je dopracować, oszacować, a co za tym idzie – dostarczyć.
Składniki dobrego zadania technicznego
W oparciu o pytania, które zwykle zadają zespoły deweloperskie podczas sesji udoskonalania, opracowałem następującą listę kontrolną, która przyda się podczas przygotowywania opisu zadania doskonalenia technicznego na etapie wstępnego udoskonalania:
1. Jaki jest cel poprawy?
Każde zadanie powinno mieć cel, który jest warunkiem wstępnym dobrze zdefiniowanego kontekstu i zakresu. Przykład: refaktoryzacja niektórych usług lub aktualizacja bibliotek. Poza tym wyznaczanie celów to solidna podstawa do motywowania zespołu.
2. Czy zadanie może być dostarczone jako osobny element?
Każde zadanie powinno być zbiorem znaczących i stosunkowo niewielkich zmian. Możesz myśleć w kategoriach wysokiej spójności i niskiego sprzężenia, które są bliższe inżynierii oprogramowania. Pomoże to zdefiniować zakres zadania i łatwiej spełnić definicję ukończenia.
3. Jakie jest tło zadania?
Kontekst może być przydatny do lepszego zrozumienia zadania, jednak nie powinien być dłuższy niż kilka zdań. Może to być na przykład komentarz, problem znaleziony podczas pracy nad innym zadaniem lub po prostu ogólny opis.
4. Czy podejście jest zdefiniowane?
Sesja udoskonalania nie jest najlepszym miejscem do planowania i wytwarzania rozwiązań, ale zrozumienie wdrożenia na wysokim poziomie sprawia, iż szacunki są bardziej precyzyjne.
5. Czy zdefiniowano relacje i zależności?
Jeśli zależności nie zostaną zidentyfikowane lub są niejasne, prace rozwojowe mogą zostać zablokowane lub wykonane w niewłaściwy sposób, co zwykle wiąże się z dodatkowymi, pracochłonnymi zadaniami. Można je prześledzić dzięki powiązań zadań (funkcja, następca, poprzednik) lub jako część opisu.
6. Czy jest jakieś źródło wiedzy, które może pomóc (specyfikacja API, wytyczne, eksperci merytoryczni)?
Chociaż niektóre zespoły traktują te informacje jako dodatkowe, mogą być one dość istotne, ponieważ przyczyniają się do dzielenia się wiedzą i ustalania adekwatnych oczekiwań dla różnych stron (zespołu deweloperskiego, architektów, interesariuszy).
7. Pytanie kontrolne: Czy jest to czytelne dla człowieka?
Najlepiej użyć prostego języka, punktorów i odpowiedniej struktury w opisach zadań – to zawsze zmniejsza wysiłek włożony w zrozumienie zadania.
Przykład z życia wzięty
Biorąc pod uwagę listę kontrolną, spróbujmy sobie wyobrazić, iż musimy dopracować i oszacować następujące zadanie:
„Powinieneś zrefaktoryzować logikę obsługi wyjątków w Orders API.”
Czy możesz to oszacować? Jaki jest zakres? (Zakładam, iż nigdy nie widziałeś wspomnianego w opisie interfejsu Orders API.) Czy ta zmiana zablokuje inne zespoły? Jakie zasady wprowadzić? Spróbujmy poprawić opis, aby odpowiedzieć na te pytania, zanim nasz zespół zapyta o to podczas sesji udoskonalania.
Oprogramowanie pośredniczące – o tym warto pamiętać
Obecnie wiele wyjątków jest obsługiwanych w kontrolerach, co skutkuje powielaniem kodu. Rozwiązaniem może być wprowadzenie systemu pośredniczącego. W związku z tym:
- Należy wprowadzić oprogramowanie pośredniczące do obsługi wyjątków, które przechwytuje wszystkie typy wyjątków, a także usunąć logikę obsługi wyjątków ze wszystkich kontrolerów Orders API.
- Obsługa wyjątków powinna obejmować rejestrowanie szczegółów wyjątku (komunikat, śledzenie stosu, pola niestandardowe) w usłudze Azure Application Insights zgodnie z przewodnikiem rejestrowania strukturalnego.
- W przypadku zgłoszenia wyjątku klienci API powinni otrzymać obiekt ErrorResponse z wypełnionymi wszystkimi danymi.
Kryteria przyjęcia:
- Wszelkie wyjątki są obsługiwane w oprogramowaniu pośrednim.
- W przypadku wyjątku konsumenci API powinni otrzymać odpowiedni obiekt ErrorResponse, śledzenie stosu nie jest dostępne z zewnątrz.
- Szczegóły wyjątku można znaleźć w dziennikach.
Dobre praktyki
Na marginesie warto dodać, iż usuwanie nadmiernych bloków try-catch w logice biznesowej jest poza zakresem i należy zająć się nimi osobno, ponieważ wymagają poważnego zbadania wymagań biznesowych.
Dodatkowo, należy dodać linki do innych pozycji backlogu, aby zidentyfikować adekwatne relacje. Na przykład tych zmian nie należy wprowadzać w czasie, gdy edytowane są inne punkty końcowe.
Powinniśmy pamiętać, iż pytania są nieuniknione, a choćby niezbędne podczas procesu udoskonalania. Odpowiednio napisane elementy backlogu pozwalają zaoszczędzić mnóstwo czasu i przyczynić się do wysokiej produktywności zespołu.
Zdjęcie główne artykułu pochodzi z envato.com. Artykuł został pierwotnie opublikowany na wearecommunity.io.
