Spotkałem się ostatnio bardzo ciekawym stwierdzeniem, jakoby zwinne metodyki dbały wyłącznie o funkcjonalności, pomijając kwestie związane przykładowo z bezpieczeństwem. Czy na pewno? Czy nie jest to jedna z nadinterpretacji zwinnego podejścia, z którą powinniśmy walczyć?
Niebezpieczna zwinność
Tomek pisał wczoraj o zjawisku dziesięciu backlogów. Tworzenie wielu list wymagań często ma miejsce w sytuacji, gdy mamy problem z procesem tworzenia naszego Produktu. Każdy z Interesariuszy posiada swój własny Backlog i uważa go za ten jedyny. Zapisuje w nim najważniejsze wymagania ze swojego punktu widzenia. Ale czy są one później odpowiednio priorytetyzowane i agregowane do listy znanej nam jako jeden Backlog Produktu? A może każdy forsuje swoje wymagania, jako te najważniejsze?
Praktyka pokazuje, że częściej możemy zaobserwować tę drugą sytuację. Działa w tym przypadku prawo silniejszego, ten, kto ma większe przełożenie na Produkt, ten rządzi. Doskonale rozumiem podłoże takiego zachowania. Wielu z nas na pewno widziało taką sytuację w swojej Organizacji.
Większa część wysiłków związanych z budową Produktu, w skrajnym przypadku 100%, skierowana jest na tak zwaną część widzialną. Mam tutaj na myśli wszystkie te rzeczy, z których będzie mógł korzystać użytkownik naszego Produktu. Patrząc na sprawę przez ten pryzmat faktycznie wymagania niefunkcjonalne, a do takich przecież zaliczyć możemy wymagania związane z bezpieczeństwem ujmowane będą w pozycji wymagań drugiej kategorii.
Również źle pojęty Agile Mindset doprowadzić może do sytuacji, w której skupimy się tylko i wyłącznie na wartości biznesowej, która jest „klikalna”. Pytanie tylko czy zgodnie z standardami organizacji i najlepszymi praktykami.
Odraczanie elementów niefunkcjonalnych
Na pytanie, dlaczego tak się dzieje, odpowiedź jest jasna. Dokonując priorytetyzacji elementów Backlogu Product Owner skupiony wyłącznie na wartości dla Klienta końcowego będzie brał pod uwagę wyłącznie rzeczy, które ten drugi zobaczy. Ale zadanie Product Ownera nie ogranicza się wyłącznie do dbania o tę znaczącą część naszego Backlogu.
To w gestii Właściciela Produktu jest przekonanie klienta, że wymagania niefunkcjonalne są tak samo ważne jak te, które widać i z których można skorzystać. I jedne, i drugie przyniosą nam korzyści (np. finansowe) lub pozwolą ograniczyć negatywne skutki braku ich zaimplementowania (np. ograniczenie strat).
Brak przyłożenia właściwej atencji do kwestii priorytetyzacji wcześniej czy później zakończy się katastrofą. Mowa oczywiście o priorytetyzacji wymagań związanych z częścią „techniczną” rozwiązania. Czy jest to jednak część, którą postrzegać powinniśmy jako techniczną? Jest to integralna część naszego Produktu której potrzebujemy tak samo bardzo, jak części biznesowej. Brak realizacji tych wymagań spowoduje, że będziemy mieli produkt, który wygląda i działa ale nie jest np. bezpieczny. Czy jest więc kompletny?
Wymagania niefunkcjonalne
Zagadnienia takie jak bezpieczeństwo, wydajność czy użyteczność mogą stanowić element długu technologicznego. Pisaliśmy i mówiliśmy już o tym wielokrotnie. Dług technologiczny to świadome odroczenie realizacji ważnych elementów naszego Produktu w czasie.
Nie oznacza to, że nie będziemy ich realizować. Po prostu w chwili obecnej priorytety naszego Backlogu wyznaczają inną kolejność realizowania wymagań. Do tych odroczonych w czasie wrócimy w momencie, w którym nastanie właściwa pora na ich realizację, a więc gdy zakończymy prace nad wszystkimi elementami Backlogu znajdującymi się na liście przed nimi.
Ustalenie możliwości opóźnienia realizacji wymagań niefunkcjonalnych powinno być każdorazowo potwierdzone z Interesariuszami. Zapewniamy ich w ten sposób, że pamiętamy o ważnych dla nich aspektach Produktu oraz że zostaną one zaadresowane na równi z innymi wymaganiami funkcjonalnymi. To właśnie brak współpracy ze wszystkimi Klientami naszego Produktu jest jednym z częstych problemów komunikacyjnych prowadzących do wzajemnego niezrozumienia. Problemy te przekładają się później na wrażenie braku adresowania przez zwinne podejście kwestii nie związanych z częścią bazową funkcjonalności. A to duży błąd!
Bezpieczne czy niebezpieczne?
Czy zwinne podejście jest niebezpieczne? Jeśli do tworzenia Produktu podejdziemy wyłącznie z punktu widzenia biznesowego, skupiając się wyłącznie na dostarczeniu widzialnej części systemu, tak. Jeśli w naszej organizacji Interesariusze reprezentujący część biznesową posiadają ponadnormatywną siłę przebicia i nie dopuszczają do realizacji elementów związanych na przykład z bezpieczeństwem, tak. Każda sytuacja, w której elementy ważne, ale nie związane z częścią biznesową spychane są na drugi plan jest niebezpieczna. Zagraża to kompletności Produktu.
Jest to jeden z powodów, dla którego potrzebujemy posiadać umocowanego i świadomego Product Ownera. To właśnie odpowiedzialnością tej roli jest dopuszczenie do głosu wszystkich zainteresowanych posiadających wymagania w zakresie naszego Produktu. To właśnie Product Owner powinien traktować na równi wymagania funkcjonalne i niefunkcjonalne. Dzięki tym pierwszym będziemy w przyszłości na przykład zarabiać na Produkcie, dzięki drugim zapewnimy możliwość np. obsłużenia dużej ilości użytkowników w tym samym czasie.
Jakiekolwiek zachwianie powyższego ładu jest niedopuszczenie. Brak uwzględnienia głosu wszystkich Interesariuszy, na przykład tych reprezentujących głos „niebiznesowy” spowoduje brak kompletności czy spójności rozwiązania. W dłuższej perspektywie sytuacja ta spowodować może poważne problemy. Tych ostatnich na pewno nie chcemy bo ich obsługa jak pokazuje życie jest znacznie bardziej kosztowna.
