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ń?
- Szybsze wdrożenie nowych pracowników.
- Łatwość i wspólne zrozumienie.
- 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?
- Oszczędność czasu przy analizie wymagań.
- Ł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?
- Przejrzystość, ponieważ backlog zawiera tylko wymagania, które są ważne.
- 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ć!