Inżynieria wymagań dla zespołów zwinnych
TWORZENIE OPROGRAMOWANIA
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!
