Zasada INVEST przy tworzeniu historii użytkowników
Oprócz ustandaryzowanego formatu i kompletnych elementów, dobra historia użytkownikapowinna również przestrzegać zasad INVEST : 1. Niezależna; 2. Negocjowalna; 3. Wartościowa; 4. Sszacowalna; 5. Mała; 6. Ustabilna.
1. Niezależna – Ważne jest, aby jedna historia użytkownika była jak najbardziej niezależna od innych historii użytkowników. Utrzymanie niezależności między historiami użytkowników nie tylko ułatwia priorytetyzację i dostosowanie, ale także ułatwia planowanie wydania i iteracji, sprzyja niezależnemu zrozumieniu, śledzeniu, wdrażaniu, testowaniu i częstemu dostarczaniu, ale także sprawia, że zakres oszacowania wielkości historii użytkownika jest jaśniejszy, a tym samym mniejsze jest odchylenie w oszacowaniach.
2. Negocjowalna – Treść historii użytkownika jest negocjowalna; historia użytkownika nie jest umową. Historia użytkownika to tylko krótki opis historii użytkownika bez wielu szczegółów; szczegółowe informacje są opracowywane w fazie komunikacji. Historia użytkownika zbyt dużą ilością szczegółów w rzeczywistości ogranicza użytkownika, pomysły zespołu i komunikację.
3. Wartościowa – Każda historia musi być wartościowa dla klienta (czy to użytkownika, kupującego, czy wewnętrznej roli w firmie). Historie użytkowników są wartościowe dla końcowego użytkownika, dlatego powinny być pisane z perspektywy użytkownika, opisując CECHĘ, a nie ZADANIE.
Ta cecha ułatwia przejście z tradycyjnego stylu pracy opartego na dyrektywach do samodzielnego, zorientowanego na wartość stylu pracy dla członków zespołu zajmujących się rozwojem i testowaniem, aby każdy w zespole znał wartość pracy, którą wykonuje każdego dnia.
4. Szacowalna (może być oceniana) – Bardzo ważną częścią spotkania planistycznego jest oszacowanie punktów historii. Jest to w rzeczywistości ogólne oszacowanie historii użytkownika, która ma być rozwijana, aby zespół mógł poznać złożoność (obciążenie) tej historii użytkownika.
Skupiamy się na tym, czy historia użytkownika może być ukończona w bieżącej iteracji zgodnie z warunkami przyjęcia tej historii użytkownika oraz DoD (kryteria ukończenia) zdefiniowanymi przez zespół, a jeśli nie może być ukończona, podawany jest powód, a PO decyduje, czy podzielić lub przeprojektować historię użytkownika.
Problemy, które utrudniają programistom oszacowanie historii, pochodzą z: braku wiedzy o dziedzinie (w takim przypadku potrzebna jest większa komunikacja) lub historia jest zbyt duża (w takim przypadku musi być podzielona na mniejsze części).
5.Mała – Dobra historia powinna być jak najkrótsza pod względem obciążenia, najlepiej nie więcej niż 10 idealnych osób/dzień, przynajmniej aby zapewnić, że zostanie ukończona w jednej iteracji. Im większa historia użytkownika, tym większe ryzyko w harmonogramie, oszacowaniu obciążenia itp.
6. Testowalna (testowalna) – Historia użytkownika powinna być testowalna, aby potwierdzić, że może być ukończona. Jeśli historia użytkownika nie jest testowalna, nie można wiedzieć, kiedy zostanie ukończona. Przykład nie-testowalnej historii użytkownika: oprogramowanie powinno być łatwe w użyciu.
Trzy wytyczne
Historia użytkownika jest zasadniczo dobrą historią użytkownika, gdy przestrzegane są zasady INVEST. Następnie skupiamy się na trzech wytycznych, aby lepiej przestrzegać zasad przy tworzeniu historii użytkowników.
Trzy wytyczne to: jeden użytkownik, pełna wartość i brak zależności.
Jeden typ użytkowników – Uwzględnij tylko jeden typ użytkowników, ponieważ wielu użytkowników często ma niuanse. Zwykle jest to typowy użytkownik, często z jakąś wspólną potrzebą.
Pełna wartość – Dostarcz pełną wartość dla klienta. Pełna historia użytkownika oznacza, że gdy ta historia jest ukończona, użytkownik może osiągnąć jasny i znaczący cel.
Brak zależności – Trzy powszechne typy zależności to: nakładanie się, sekwencja i zawartość.
Ogólnie rzecz biorąc, należy unikać nakładających się punktów funkcjonalnych między historiami; relacje sekwencyjne są rzeczywistością i w większości przypadków można je rozwiązać w jakiś sposób; a relacje inkluzyjne są pomocne w złożonych systemach, mając wpływ na planowanie wydań i plany iteracji, które wymagają uwagi.
Nakładające się zależności
Nakładające się zależności to forma zależności, która powoduje najwięcej problemów, szczególnie gdy wiele historii użytkowników zawiera wiele różnych nakładających się części. Trudno jest znaleźć zestaw historii użytkowników, który może reprezentować zestaw funkcji dla minimalnego produktu użytecznego, który powinien zawierać i tylko zawierać funkcje potrzebne raz.
Rozwiązanie
Wyodrębnij nakładające się części jako oddzielne historie użytkowników.
Racjonalne dzielenie historii użytkowników i utrzymywanie nakładek tylko w jednej z najbardziej spójnych historii użytkowników.
Użyj modelu rozwoju Scrum.
Zależności sekwencyjne
Zależność sekwencyjna oznacza, że aby historia użytkownika mogła zostać ukończona, jedna lub więcej innych historii użytkowników musi zostać ukończona przed nią. Zależności sekwencyjne są zazwyczaj nieszkodliwe, a istnieją sposoby na złagodzenie takich zależności.
Z perspektywy zwinnego rozwoju cały system ewoluuje stopniowo od początkowego minimalnego produktu użytecznego do solidnego produktu, przy czym każdy kolejny krok opiera się na poprzednich.
Jednak z innej perspektywy, niepotrzebne zależności sekwencyjne utrudniają klasyfikację i priorytetyzację, co z kolei wpływa na rozwój planów wydań i iteracji oraz utrudnia oszacowanie rozmiaru historii użytkowników.
Rozwiązanie
Uczyń historie użytkowników w ramach iteracji jak najbardziej wolnymi od wewnętrznych zależności.
Utrzymywanie tylko jednostronnych zależności między iteracjami, z jednostronnymi zależnościami w czasie od historii w późniejszych iteracjach do historii w wcześniejszych iteracjach (zależności w przód).
Wyodrębnienie podstawowych zależności jako oddzielnych historii i nie mieszanie wymagań zależnych i niezależnych w jednej historii.
Inkluzja zależności
Zawarte zależności odnoszą się do użycia zarządzania hierarchicznego w organizowaniu historii użytkowników, na przykład powszechne zarządzanie funkcjami i historiami na dwóch poziomach, gdzie funkcja zawiera wiele historii użytkowników, stanowiąc tym samym zawartą zależność funkcji od jej podrzędnych historii.
Rozwiązanie
Poziom historii użytkowników jest używany do planowania iteracji, unikając gruboziarnistego planowania iteracji na poziomie funkcji, które może być używane do planowania wydań.
Poziom funkcji może być również dzielony, aż osiągnie poziom minimalnej funkcji rynkowej, a historie użytkowników, które zawiera, mogą być oddzielnie grupowane w nowo podzielone funkcje.
Zgodnie z koncepcją minimalnego produktu użytecznego, funkcja jest wdrażana w wielu iteracjach wielu historii użytkowników, z których każda może skutkować potencjalnym dostarczonym produktem lub dostarczyć wewnętrzną lub zewnętrzną informację zwrotną.
Odniesienia
- Skuteczne historie użytkowników – przewodnik 3C i INVEST
- Temat vs Epika vs Historia użytkownika vs Zadanie
- Mapa historii użytkownika
- Czym jest mapowanie historii użytkownika?
- Pisanie celów SMART i INVEST dla historii użytkowników
Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文