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.
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ć.
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?
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?
Czym jest modelowanie procesów biznesowych?
Czasem nasze projekty dotyczą małych klientów, często są to zupełnie nowe projekty, które dają nam całkowitą swobodę budowy rozwiązania dla klienta. Niejednokrotnie jednak nasze projekty tworzone są dla dużych klientów, muszą wpasować się w istniejące procesy, którymi kieruje się cały biznes po stronie klienta, a także muszą się integrować z istniejącym i działającym oprogramowaniem. Zdarzają się również sytuacje, gdy klient sam nie do końca rozumie problem, z którym tworzony system powinien sobie poradzić. Oczekuje wtedy od nas identyfikacji źródła problemów oraz zaproponowania najlepszego rozwiązania. Co robić w takiej sytuacji? Jak zacząć pracę? Jednym z podejść proponowanych w takim przypadku jest zamodelowanie procesów biznesowych, którymi kieruje się klient. Wizualizacja tych procesów pozwoli nam lepiej zrozumieć klienta, sposób jego działania oraz poznać inne systemy, z których nasz klient korzysta. Lepiej również będziemy się orientowali w sposobie komunikacji pomiędzy poszczególnymi uczestnikami procesów oraz lepiej zrozumiemy w jaki sposób przepływają informacje w organizacji klienta. To wszystko będzie stanowiło świetny start zarówno dla zbierania wymagań oraz dla zaproponowania rozwiązania dla klienta.
W kolejnych postach spojrzymy na kilka popularnych notacji do modelowania procesów biznesowych.
A Ty w swoich projektach modelujesz procesy biznesowe? Jakiej notacji najczęściej używasz do tego celu?
Jak możesz przekonać swojego szefa o istotności wymagań?
Jeśli przez cały czas musisz walczyć ze swoim szefem i zespołem o dodatkowy czas lub pieniądze na zbieranie wymagań, to poniżej znajdziesz dane, które mogą pomóc Ci w Twojej walce.
- Problemy z wymaganiami -w szczególności częste zmiany wymagań, brakujące wymagania, niewystarczająca komunikacja z klientem, słaba jakość dokumentu wymagań - to jeden z pięciu głównych powodów słabych estymacji kosztów projektów. [1]
- Wymagania są poważnym źródłem problemów, które mogą prowadzić do wielu kosztownych zmian w projekcie. [2]
- Błędy wymaganiach to jedna trzecia wszystkich defektów w projektach. [3]
- Procesy związane ze zbieraniem wymagań są źródłem większości poważnych problemów z jakością. [4]
- Naprawa błędów związanych z wymaganiami pochłania 70 - 80% kosztów ponownej pracy w projektach IT. A całkowite koszty ponownej pracy zjadają nawet do 50% kosztów projektu. [5]
- Szukanie i naprawianie błędów wymagań po wdrożeniu systemu jest 100 razy kosztowniejsze niż szukanie i naprawianie tych samych błędów podczas zbierania wymagań. [6]
- Zmiany zakresu są jednym z najczęstszych źródeł dodatkowych kosztów w projektach i często prowadzą do porzucenia projektu. [7]
[1] Alan M. Davis - "200 Principles of Software Development" (1995)
[2] Capers Jones - "Software Assessments, Benchmarks and Best Practices" (2000)
[3] Dean Leffingwell, Don Widrig - "Managing Software Requirements" (1999)
[4] Gerald Weinberg - "Quality Software Management" (1997)
[5] Dean Leffingwell - "Calculating and Return on Investment from More Effective Requirements Management" (1997)
[6] Barry Boehm, Victor R. Basili - "Software Defect Reduction Top 10 List" (2001)
[7] Capers Jones - "Assessment and Control of Software Risks" (1994)
Zasięgając rad polonisty
Nie ma co ukrywać, że bardzo często nasze wymagania zapisujemy w języku naturalnym. Czy zastanawiamy się wtedy nad zasadami, którymi powinniśmy się kierować zapisując takie wymagania? Musimy na pewno pamiętać o podstawowych atrybutach, jakie powinny spełniać wymagania. Jeśli poprosilibyśmy polonistę o kilka rad, jak zapisywać wymagania tak aby były m.in. jednoznaczne, spójne, poprawne to moglibyśmy usłyszeć:
- Podawaj zawsze wykonawcę (aktora) danej akcji lub funkcji.
- Zapisuj wymagania pełnymi zdaniami, unikaj równoważników zdań i zdań urwanych w połowie.
- Pisz krótkie zdania, unikaj zdań wielokrotnie złożonych.
- Bądź tak precyzyjny jak to tylko możliwe.
- Unikaj subiektywnych sformułowań, takich jak: najszybszy, lepiej, bezpieczniej, łatwo.
- Pamiętaj, aby wszystkie skróty wyjaśnić w słowniczku.
- Bądź konsekwentny w używaniu terminów i skrótów.
- Pamiętaj o spójności rysunków z opisem słownym.
- Pisz z zachowaniem zasad ortografii oraz interpunkcji.
- Używaj różnych czcionek, aby wyróżnić bardziej istotne elementy.
Charakterystyka ISO 9126: Łatwość utrzymania
Zastanawialiście się kiedyś jakie są koszty utrzymywania systemów (czyli naprawy błędów, dodawania brakujących wymagań, itp.)? Ta strona bardzo ładnie zbiera i prezentuje różne wyniki badań w tym zakresie. Jak widzicie niektóre badania pokazuję, że koszty utrzymania systemów potrafią przewyższać nawet 90% kosztów całego systemu. Może warto więc już w czasie zbierania wymagań zastanowić się nad wymaganiami dotyczącymi łatwości utrzymania systemu, tak aby koszty później były jak najmniejsze. Z pomocą przychodzi nam kolejna charakterystyka ISO 9126, która definiuje następujące podcharakterystyki:
- Łatwość analizy - budowa systemu, która umożliwia proste analizowanie i diagnozowanie błędów oraz sytuacji problemowych.
- Łatwość zmiany -budowa systemu, która umożliwia łatwe wprowadzanie koniecznych zmian.
- Stabilność - taka budowa systemu, która pozwala na uniknięcie nieprzewidzianych efektów ubocznych po wprowadzeniu zmian.
- Łatwość testowania - budowa systemu, która umożliwia efektywne testowanie po wprowadzonych zmianach.
Warto jest zastanowić się, czy mamy jakieś wymagania obejmujące powyższe podcharakterystyki. Może nam to pomóc ustrzec się przed późniejszymi problemami z utrzymaniem tworzonego systemu.
User Story vs Use Case
Czasami osoby pracujące w branży IT, gdy dowiadują się, że zajmuję się wymaganiami pytają mnie, czym różnią się User Story i Use Case (ang. przypadek użycia), przecież ich nazwy brzmią podobnie. Prawda jest taka, że oprócz identycznych pierwszych trzech liter User Story oraz Use Case różnią się diametralnie. Wyjaśnijmy więc po krótce w czym tkwią główne różnice.
User Story: są to bardzo prosto zapisane wymagania, tworzone bezpośrednio przez klienta. Są one niekompletne, nie opisują w jaki sposób obsługiwać sytuacje wyjątkowe, przekazują wyłącznie główne cele użytkowników systemu, Podczas rozwoju systemu User Story często stanowią podstawę dalszych dyskusji z klientem służących doprecyzowaniu wymagań. Więcej o User Story pisałem tutaj.
Use Case: jest bardziej skomplikowanym i sformalizowanym zapisem wymagań, tworzonym przez wytwórcę oprogramowania. Przypadki użycia z założenia przedstawiają kompletne oraz dokładne wymagania. W czasie rozwoju systemu przypadki użycia powinny być w stanie odpowiedzieć na wszystkie pytania programistów bez potrzeby kontaktowania się z klientem. Więcej o przypadkach użycia przeczytasz tutaj.
Co jest lepsze? Wszystko zależy od projektu i klienta, dla którego tworzysz oprogramowanie.
Ivar Jacobson o sukcesie i powodzeniu przypadków użycia
Ivar Jacobson, ten pan, który wymyślił przypadki użycia, na swoim blogu opisuje swoje przemyślenia na temat powodów, dlaczego przypadki użycia zyskały tak dużą popularność. Oto źródła sukcesu:
- Diagramy przypadków użycia pozwalają w dość prosty sposób opisać nawet skomplikowane systemy w prosty i przystępny sposób.
- Przypadki użycia mówią o wartościach dla konkretnego użytkownika systemu, a nie dla niezidentyfikowanej społeczności użytkowników.
- Przypadki użycia są przy okazji przypadkami testowymi. Jeśli do przypadków użycia dodasz dane testowe dostaniesz gotowe scenariusze testowe.
- Przypadki użycia są punktem wyjścia do projektowanie wysokiej jakości interfejsu użytkownika.
- Przypadki użycia prowadzą tworzenie systemu od projektowania aż po kod. Każdy przypadek użycia to zestaw scenariuszy, które mogą być zaimplementowane i przetestowane osobno.
Jacobson pisze też przy okazji o typowych nieporozumieniach związanych z przypadkami użycia. Zachęcam do przeczytania oryginalnego postu na blogu Jacobsona.
