Inżynieria wymagań dla zespołów zwinnych

INŻYNIERIA WYMAGAŃ

Co dzieje się z inżynierią wymagań (Requirements Engineering lub RE) w trakcie zwinnej transformacji? Czy rola inżyniera wymagań jest nadal potrzebna i jak odnosi się ona do roli Product Ownera? Czy zwinna inżynieria wymagań sprowadza się do zarządzania wymaganiami tylko w postaci User Stories? W jaki sposób można zapewnić adekwatną dokumentację? Jak znaleźć dobre kryteria akceptacji? Jak do tego schematu pasują artefakty, metody i dokumenty „klasycznej” inżynierii wymagań? U nas znajdziesz odpowiedzi!

Wystarczająco dużo, ale możliwie najmniej wymagań – w każdej iteracji

Nasze doświadczenie w inżynierii wymagań pozwoli pomóc Twojemu Product Ownerowi lub Ownerce (PO), Twoim inżynierom wymagań i Twojemu zespołowi w zrozumieniu potrzeb i metod pracy przyszłych użytkowników. Ważne jest, aby zrozumieć i opracować pytania „co” i „dlaczego” z tzw. zakresu problemu – lekko, „just in time“, czyli innymi słowy możliwie najmniej, ale w wystarczającym stopniu. Tak na marginesie, z naszego doświadczenia projektowego wynika, że ​​nie ma znaczenia, skąd pochodzą środki pomocnicze – liczy się to, że pomagają one PO i zespołowi.
Od samego początku zwracamy uwagę na – zbyt często zaniedbywaną – testowalność przedstawionych User Stories i wymagań. Ta metodyka jest unikalną zaletą QualityMinds.

Jeśli chcesz dowiedzieć się, czy, w jakim stopniu i jakie wymagania optymalnie wesprą Cię w zwinnym sposobie pracy, to jesteś we właściwym miejscu.

Jak przebiega rentowne współdziałanie inżynierii wymagań i procedur zwinnych

W zwinnym zespole celem inżynierii wymagań jest wypracowanie wspólnego zrozumienia przyszłego produktu i jego użytkowników. W pierwszej kolejności zespół musi zrozumieć wizję produktu. W tym celu pomocne może być zaprojektowanie konspektu produktu z najważniejszymi funkcjami, użytkownikami, systemami partnerskimi, celami i zakresem ryzyka lub skorzystać z metody Product Canvas. Następnie zespół musi zrozumieć, co konkretnie przekazują User Stories następnej w kolejności iteracji. Przy tym pojedyncza User Story nie opisuje wszystkich szczegółów niezbędnych do programowania lub testowania i musi zostać uzupełniona testowalnymi kryteriami akceptacji. Przed podjęciem decyzji, czy udokumentować więcej szczegółów, zespół powinien zadać sobie dwa następujące pytania odnośnie każdej User Story:

  • czy na jej potrzeby należy koniecznie utworzyć dokumentację, na przykład ze względów prawnych? Dokumenty te powinny stać się częścią „definicji ukończenia” (Definition of Done lub DoD). W fazie planowania należy stworzyć odpowiednie zadania;
  • czy istnieją artefakty – na przykład tabela decyzyjna lub diagram procesu – które pomogłyby zespołowi je wdrożyć? Jeśli tak, artefakty te powinny być utworzone podczas fazy udoskonalania (Refinement’u). Pomocny w znalezieniu odpowiednich artefaktów może być konspekt artefaktu, pokazujący możliwe formaty, scenariusze aplikacji i powiązane metody testowe.

Jeśli dodatkowe artefakty lub dokumenty nie są ani pomocne, ani konieczne, wystarczająca jest bezpośrednia komunikacja między zespołem a Product Ownerem. W ten sposób uzyskujemy dokumentację, która oferuje wartość dodaną; jednocześnie wszystko, czego potrzebuje zespół, jest dostępne w sprincie.

Doradztwo

Jako konsultanci wspieramy na miejscu Ciebie i Twój projekt w następujących rolach:

  • Product owner
  • Requirements Engineer
  • Business analyst

Podejmujemy się tej roli odpowiedzialnie, optymalnie integrujemy się z Twoim zespołem i dostarczamy wymagane przez Ciebie rezultaty „in time & in budget & in quality”.

 

Coaching

Alternatywnie, oferujemy wsparcie dla Twoich pracowników, którzy już pełnią jedną z tych ról, i zapewniamy

  • trenerów dla Product Ownerów/inżynierów wymagań/analityków biznesowych

którzy działają jako partnerzy sparingowi oraz nośniki doświadczenia i wiedzy. Możemy zapewnić Twojemu zespołowi skuteczne wsparcie we wszystkich kwestiach związanych w szczególności z wartościami i procedurami zwinnymi.

Warsztat “Doskonalenie User Stories” (1 dzień)

Czy trudno jest odpowiednio skroić User Stories? Czy Twoje User Stories zbyt często znajdują się w przestrzeni rozwiązań? Czy jesteś niezadowolony ze swoich kryteriów akceptacji? Zastanawiasz się, jak User Stories i formalna dokumentacja mogą ze sobą sensownie współdziałać? Same User Stories nie gwarantują wystarczającej kontroli nad przetwarzaniem wymagań w projektach zwinnych. Pokaż nam swoje, a wspólnie opracujemy rozwiązania dla Twojej wyjątkowej sytuacji.

Warsztat “Optymalizacja RE” (1-2 dni)

Czy uważasz, że możesz zoptymalizować poziom Twojej, zwinnej lub klasycznej, inżynierii wymagań (RE), ale nie masz pewności, jak się do tego zabrać? Wspólnie przyjrzymy się Twojej obecnej metodyce (a dokładniej: Twojemu procesowi tworzenia wymagań i Twoim przykładowym wymaganiom) i wspólnie zidentyfikujemy Twoje mocne strony jak i potencjał ulepszeń oraz pola działania i punkty zapalne. W rezultacie otrzymasz konkretne zalecenia dotyczące działań i wstępną road map produktu. Zespoły zwinne dowiedzą się w szczególności, ile i jakiego rodzaju RE jest konieczna lub pomocna w ich projektach.

Czekamy na Twoje pytania!

Oprócz naszego “Quality-Mindset”, wyróżniamy się bogatym doświadczeniem projektowym i doskonałością metodyczną.

Wysoce zadowoleni klienci to nasz kapitał i jednocześnie cel. Potrzebujesz wsparcia w zwinnym RE? Dowiedz się, w jaki sposób możemy Ci pomóc podczas pierwszej rozmowy!

Szukasz czegoś konkretnego?
Skontaktuj się z nami!

Szukasz naszych usług w Twoim kraju?