Kiss your Backlog! Jak czule dbać o Backlog produktu?

Refaktoryzujemy kod, zmieniamy architekturę, usprawniamy strategie testowe, a backlog raczej zostawiamy Product Ownerom i analitykom biznesowym – w końcu to są specjaliści od wymagań. A gdyby tak wymienić się doświadczeniami i zaadoptować praktyki, które znamy z clean code do pracy z wymaganiami?

Zobaczmy zatem, jakie reguły ze świata programistycznego możemy wykorzystać, przy pielęgnacji backloga, o której wspominaliśmy w poprzednim wpisie.

KISS

Keep It Simple, Stupid w dosłownym tłumaczeniu Jak Najprościej, Głupcze. Reguła, która powstała w środowisku amerykańskich wojskowych i konstruktorów z branży lotnictwa. Tworzone samoloty miałby być zbudowane w tak prosty sposób, żeby każdy mógł je naprawić bez posiadania zaawansowanych narzędzi. Wymagania tak jak samoloty oparte o KISS, powinny być zrozumiałe dla wszystkich, napisane w prosty sposób. 

Jakie korzyści zyskujemy przez zaadoptowanie KISS w dziedzinie inżynierii wymagań?

1. Szybsze wdrożenie nowych pracowników.
2. Łatwość i wspólne zrozumienie.
3. Prostotą łatwiej się zarządza, modyfikuje oraz utrzymuje.

KISS doczekało się polskiego odpowiednika, którym jest BUZI – Bez Udziwnień Zapisu, Idioto.

DRY

Don’t Repeat Yourself – Nie Powtarzaj Się. Reguła pochodzi z książki The Pragmatic Programmer (autorstwa Andy’ego Hunta i Dave’a Thomasa) i mówi jasno, że w większości przypadków powtórzenia, biorą się z bezmyślnego kopiowania i nie są one korzystne w pracy programisty. Należy unikać powtórzeń w kodzie, np. w postaci powtarzanych w kółko elementów, które mocno wpływają na czytelność kodu źródłowego, zrozumienie oraz w konsekwencji na efektywność zespołu.

Dla przykładu: powtórzenia w wymaganiach wymagają od nas więcej wysiłku, żeby zrozumieć sens zadania. Wracając do INVEST, które pojawiło się na blogu jakiś czas temu, pod literką S kryje się small, jeżeli robimy powtórzenia w opisie wymagania, to jasne jest, że dana historyjka będzie większa i złamiemy ten punkt.

Jakie benefity mamy przy korzystaniu z DRY?

1. Oszczędność czasu przy analizie wymagań.
2. Łatwość w zrozumieniu, utrzymaniu, oraz zarządzaniu zmianą.

YAGNI

You Aren’t Gonna Need It) Tak naprawdę, tego nie potrzebujesz. Reguła wywodząca się ze środowisk extreme programming (XP), która moim zdaniem mocno wspiera Lean’a i kładzie nacisk na eliminację straty pt. nadprodukcja.

Ron Jeffries, jeden z pionierów i współtwórców idei XP napisał

Always implement things when you actually need them, never when you just foresee that you need them.

Ron Jeffries

Przekładając na pracę z backlogiem: YAGNI pomoże w uzyskaniu zwięzłej listy wymagań, na które naprawdę czekają użytkownicy. Jeżeli coś jest odległą przyszłością, życzeniem zgłoszonym przez użytkowników i nie wiesz, czy dojdzie do jego implementacji, nie umieszczaj tego w backlogu. Co więcej, jeżeli w ramach wiosennych porządków znajdziesz takie wymaganie – usuń je, niepotrzebnie wydłuża listę. 

Co zyskujemy stosując YAGNI?

1. Przejrzystość, ponieważ backlog zawiera tylko wymagania, które są ważne.
2. Mniejsze obciążenie mentalne przy analizie listy priorytetów.

Gorąco polecam Ci następująca rzecz: zrób eksperyment i przy następnym przeglądzie backlogu wykorzystaj wspomniane dobre praktyki, które na pewno stosuje każdy programista pracujący w zespole. Nic nie stracisz, a wiele możesz zyskać!