Wymagania architektów spoza zespołu Scrum

Jakiś czas temu zapytano mnie, co sądzę o powierzaniu „Mądrym Architektom" firmy technicznego nadzoru nad różnymi zespołami projektowymi. Często bowiem słyszę argument, że architekci nie są częścią zespołu i dlatego nie powinni decydować o tym, w jaki sposób zespół coś rozwija…

…to jednak nie jest szczególnie dobry argument, bo jest wystarczająco dużo innych zewnętrznych osób, które również stawiają wymagania zespołowi. Wymagania te są jednak zawsze filtrowane przez Product Ownera – to on decyduje, czy są ważne, czy nie.

„Mądrzy Architekci" nie proponują rozwiązań

„Mądry Architekt" często daje zespołowi wymagania niefunkcjonalne, które traktuje raczej jako warunki lub ograniczenia. Nie może więc nakazywać zespołowi, jak ma rozwiązać problem. Może jednak stawiać pewne wymagania, np. „System ma skalować się do określonej liczby jednoczesnych użytkowników (Concurrent Users)", „musi przetwarzać X transakcji na minutę", „musi działać na Linuksie", „musi integrować się z tym i tamtym" itp.

Wymagania niefunkcjonalne stają się elementami Product Backlogu i mogą być priorytetyzowane przez Product Ownera – w zależności od tego, jak ważne je uważa. Jeśli na przykład nie uważa za kluczowe, żeby system działał na Linuksie i mógłby równie dobrze działać na innym systemie operacyjnym, Product Owner może usunąć to wymaganie lub przesunąć je w dół Product Backlogu (tak, żeby zespół nadal mógł zobaczyć, że architekt o to prosił).

Tekst pochodzi z bloga Mike'a Cohna i został przetłumaczony przez nas na język polski.