O wymaganiach Kilka słów o wymaganiach w projektach informatycznych

16maj/130

Relacje dostawca – klient w codziennym życiu

Zastanawialiście się kiedyś jak wyglądałyby relacje między klientem a sprzedawcą w codziennym życiu, gdy wyglądały tak samo jak relacje dostawca - klient w branży IT? Oto przykład:

 

25kwi/130

Małe Opowieści Użytkownika

Czas na literę S z zasady INVEST. S czyli Small. User Stories, które tworzysz powinny być małe. Nie krótkie, tylko małe, czyli powinny prezentować stosunkowo niewielką funkcjonalność, najlepiej taką, która możliwa jest do zaimplementowania w ciągu kilku osobodni. Większe User Stories sprawiają problemy przy nadawaniu priorytetów, szacowaniu oraz planowaniu prac. Duże User Stories mogą spowodować, że pojawi się Potwór Zmiany Zakresu. Takie US są zwykle mało precyzyjne i dają duże pole manewru do różnych interpretacji i zmiany wymagań oraz zakresu w trakcie ich realizacji.

Jeśli widzisz, że Twoja Opowieść Użytkownika jest zbyt duża lub gdy Zespół nie potrafi jej oszacować lub zaplanować, wówczas zastanów się, czy nie możesz podzielić danej User Story na kilka mniejszych.

18kwi/132

Klient to nie użytkownik

Często prowadząc szkolenia spotykam się u uczestników z myśleniem, że klient jest nam w stanie przekazać wszystkie wymagania dotyczące tworzonego systemu. Niestety pod pojęciem "klient" różne osoby mogą rozumieć kogoś innego, dlatego warto rozróżnić dwie oddzielne role: Sponsora od Użytkownika systemu. Sponsor to osoba, która zamawia u nas wykonanie systemu. Często jest to prezes firmy, szef lub dyrektor działu po stronie klienta. Użytkownik to osoba, która będzie korzystała z systemu po jego wdrożeniu. Oczywiście może się zdarzyć, że Sponsor i Użytkownik to będą te same osoby, częściej jednak Sponsor płaci za system, z którego mają korzystać inne osoby. W takiej sytuacji warto jest pamiętać, aby wymagania zbierać nie tylko od Sponsora, ale również od Użytkowników. A czasami warto wręcz skonfrontować wizję systemu Sponsora i Użytkowników, gdyż niestety często Sponsor nie do końca zna i czuje potrzeby Użytkowników. Takiej konfrontacji lub raczej wspólnej pracy można dokonać podczas warsztatów zbierania wymagań. Więcej o warsztatach przeczytasz tutaj.

Przy okazji warto sobie przypomnieć, kto może być potencjalnym czytelnikiem naszych specyfikacji wymagań.

10kwi/130

Możliwe do oszacowania User Stories

Czas na literę E z zasady INVEST dla pisania Opowieści Użytkownika. E, czyli Estimable, po polsku oznacza to, że User Stories powinny być łatwe do oszacowania. Pamiętaj, że Twoje User Stories będą musiały w pewnym momencie być oszacowane pod względem trudności i pracochłonności przez programistów. Jeśli trudno będzie oszacować Opowieść Użytkownika to wzrasta prawdopodobieństwo, że nikt nie będzie chciał ruszać tego US, że zostanie źle oszacowane (przez co nie będzie wykonane w terminie), że będziesz musiał włożyć dodatkowy wysiłek w wyjaśnienie niejasności. Zwykle przyczyną problemów z oszacowaniem User Story jest jej wielkość, US jest po prostu za duża (opisuje sobą zbyt duża funkcjonalność). Za każdym razem zastanów się, czy Ty byłbyś w stanie ocenić pracochłonność danej Opowieści oraz czy będą w stanie zrobić to programiści.

6kwi/130

Wartościowe User Stories

Kontynuujemy wpisy o atrybutach jakie powinny mieć nasze User Stories zgodnie z regułą INVEST. V czyli Valuable for users and customers. Często pisząc Opowieści Użytkownika piszemy je z punktu widzenia wytwórcy oprogramowania zapominając, że każde wymaganie powinno nieść konkretną wartość dla użytkownika i/lub klienta.

User Story w postaci: "Obsługa błędów i ich logowanie powinno się odbywać poprzez wspólny mechanizm" jest kiepskim pomysłem. Co prawda widzimy dość jasno, że to wymaganie jest wartościowe, ale czy użytkownik/klient będzie potrafił ocenić jego wartość? Dodatkowo taki zapis zawiera w sobie sugestię na temat implementacji sposobu obsługi błędów - czy z punktu widzenia klienta ma to znaczenie? Pamiętajmy też, że jako analitycy (lub jako product owner w Scrumie) nie chcemy sugerować rozwiązania programistom, którzy często lepiej od nas znają się na technologii, której będą używać. My powinniśmy napisać, co chce osiągnąć użytkownik i pozwolić programistom wybrać najlepszy sposób implementacji rozwiązania.

Zatem lepiej jest zapisać to wymaganie jako dwa oddzielne User Stories:
"Jako użytkownik będę widział wszystkie błędy w jednolity sposób"
oraz
"Jako administrator systemu będę miał dostęp do logów systemu zapisanych w jednolity sposób".

Zastanów się, czy pisane przez Ciebie User Stories mają zawsze wartość dla użytkownika i/lub klienta?

2kwi/130

O Wymaganiach wraca do życia!

Nie było mnie tutaj już prawie dwa lata. Nie będę się tłumaczył co było tego powodem, bo nie ma to chyba w tej chwili sensu. Przez te kilkanaście miesięcy milczenia zdobyłem sporo nowych doświadczeń i nauczyłem się wielu nowych rzeczy na temat zbierania, dokumentowania i zarządzania wymaganiami. Wszystkim tym będę się z Wami dzielił w najbliższych wpisach.

23cze/110

Negocjuj swoje User Stories!

Zasada INVEST przypomina nam, że każda Twoja User Story jest tylko wstępem do dalszych negocjacji i dyskusji z klientem. Samo pojedyncze zdanie z User Story najczęściej zawiera zbyt mało informacji, żeby ją poprawnie i kompletnie zaimplementować. Każde wymagania powinno być dodatkowo przedyskutowane z klientem i wszystkie ustalenie powinny być zapisane jako dodatek do User Story. Każda taka informacja może być później przydatna dla programisty, który będzie implementował dane wymaganie.

7cze/110

Niezależne User Stories

Zgodnie z zasadą INVEST każda User Story powinna być niezależna (ang. independent). Co to oznacza? To, że powinniśmy się starać, aby nasze User Stories były od siebie jak najmniej zależne. Wymagania, które zależą od siebie trudno jest szacować oraz planować. Wyobraź sobie sytuacje, w której klient nadał wysoki priorytet User Story, która jest zależna od User Story o niskim priorytecie. Jak dobrze zaplanować realizację takich wymagań? Jeśłi User Stories są małe, to trzeba się zastanowić, czy nie można połączyć ich w jedno większe wymagania. Dla większych wymagań można zastanowić się, czy nie można podzielić go na mniejsze User Stories, które będzie łatwiej szacować i planować. Oczywiście nie zawsze da się uniknąć zależności między User Stories, za każdym razem należy się jednak zastanowić, czy nie można tej zależności wyeliminować.

17maj/110

Jakie umiejętności powinieneś mieć jako moderator warsztatów wymagań?

Przygotowujesz się do roli moderatora warsztatów wymagań? A może już prowadziłeś takie warsztaty? Spójrz poniżej, znajdziesz tam listę umiejętności oraz zadań, które pomogą Ci w Twojej pracy:

  • Zbieranie informacji od członków zespołu oraz uczestników projektu. Musisz również pomagań im artykułować ich potrzeby i wymagania.
  • Tworzenie planu warsztatów oraz jasne określanie produktów końcowych każdego spotkania.
  • Obserwacja grupy podczas spotkań oraz odpowiednie interweniowanie na zagrożenia, gdy jest taka potrzeba.
  • Zadawanie odpowiednich pytań w odpowiednich momentach.
  • Podsumowywanie, wyjaśnianie oraz aktywne słuchanie.
  • Motywowanie uczestników spotkania do pracy.
  • Znajomość różnych sposobów modelowania wymagań oraz umiejętny dobór odpowiednich modeli w zależności od potrzeb.
  • Rozstrzyganie konfliktów podczas spotkań.
  • Rozsądne kierowanie pracą grupy.
  • Proszenie o opinie na temat warsztatu.

Jak widać rola moderatora warsztatów nie jest prosta, wymaga wielu umiejętności, zarówno interpersonalnych jak i związanych z zarządzaniem oraz zbieraniem wymagań.

A Ty kiedyś prowadziłeś warsztat wymagań lub spotkanie, na którym dyskutowano wymagania wraz z klientem i członkami zespołu?

10maj/110

INVESTuj w swoje User Stories

Jeśli zapisujesz swoje wymagania za pomocą User Stories, to pamiętaj, że każda dobra User Story powinna być:

  • Niezależna (Independent)
  • Negocjowalna (Negotiable)
  • Nieść pewną wartość dla użytkowników i/lub klienta (Valuable for users and customers)
  • Możliwa do wyestymowania (Estimatable)
  • Mała (Small)
  • Testowalne (Testable)

W kolejnych postach przyjrzymy się poszczególnym atrybutom dobrze napisanych User Stories. A Wy bierzecie pod uwagę zasady INVEST, gdy piszecie swoje US?

Related Posts with Thumbnails
Zagłosuj na ten blog w konkursie na Blog Roku 2010!
Get Adobe Flash player