Czy w Scrumie są dozwolone „techniczne historie użytkowników”?

11

Czy techniczne historie użytkowników są dozwolone w Scrum? Jeśli tak, jaki jest standardowy szablon do pisania technicznych historii użytkowników w Scrumie? Czy to to samo As a <user> I want to do <task> so that I can <goal>?

Czytałem na niektórych blogach, że jako twórca-programista nie jest użytkownikiem , ale przeczytałem również, że Scrum tego nie nakazuje. Istnieje niewiele blogów, na których dzielą się historiami użytkowników z systemem jako użytkownik , to jest podobne as a <user who is not end user> i want to <system functionality> so that <some techinical thing>. Który z nich jest standardem?

Na przykład istnieją historie użytkowników, takie jak:

Jako recenzent chcę przesłać zdjęcia dowolnego hotelu / jedzenia, aby inni użytkownicy mogli je zobaczyć i polubić

Jako użytkownik chcę dodawać komentarze do zdjęć, aby móc lepiej wyjaśnić mój widok

W przypadku obu tych historii użytkowników istnieje duży element techniczny - zapisywanie i pobieranie obrazu

Czy mogę zatem dodać historię techniczną zatytułowaną „Mechanizm przechowywania i wyszukiwania obrazów” z następującym opisem?

Jako programista chcę opracować mechanizm przechowywania i pobierania obrazów, aby użytkownicy mogli dodawać / wyświetlać obrazy w dowolnym miejscu

Vignesh Subramanian
źródło
6
„Mechanizm przechowywania i wyszukiwania obrazów” nie powinien być historią techniczną, ale zadaniem programisty dołączonym do pierwszej historii użytkownika.
guillaume31,

Odpowiedzi:

14

Historie techniczne są dozwolone, ale radzę starać się unikać ich w jak największym stopniu.

Na przykład historię zapisywania i pobierania obrazów można łatwo napisać jako dwie zwykłe historie użytkowników

  1. Jako recenzent chcę, aby moje przesłane zdjęcia były przechowywane w sposób trwały, aby inni użytkownicy mogli je wyświetlać w dowolnym momencie.
    (Należy pamiętać, że zakłada to, że w oryginalnej historii przesyłania obraz nie zostanie trwale zapisany po przesłaniu. Chociaż może to wyglądać dziwnie, jest to prawidłowy sposób dzielenia historii, aby umożliwić zarządzanie nimi).
  2. Jako użytkownik chcę oglądać przesłane zdjęcia w dogodnym dla mnie momencie.
    (Oznacza to, że zapisane obrazy można odzyskać później).

Historie techniczne powinny być zastrzeżone dla pracy, która jest ważna dla organizacji, ale nie powinna być bezpośrednio widoczna dla użytkowników jako funkcja / funkcjonalność. Na przykład dodanie równoważenia obciążenia w celu obsługi większej liczby lub żądań.

Bart van Ingen Schenau
źródło
5
Nawet coś takiego jak równoważenie obciążenia jest wynikiem tego, że użytkownik chce, aby system działał lepiej, więc nie różni się niczym od żadnej innej implementacji. Chcą zapisywać dane, ale nie dbają o bazę danych.
JeffO,
1
@JeffO ma dokładnie rację. Nawet te historie powinny być sformułowane w kontekście wartości dla użytkownika, aby były traktowane priorytetowo i odpowiednio oceniane. Bez tego możesz łatwo stracić z oczu fakt, że nie masz jeszcze wystarczającego obciążenia, aby uzasadnić równoważenie obciążenia, więc historię można odłożyć na kilka miesięcy, aż zespół sprzedaży będzie pracował trochę ciężej;) Mike Cohn mówi o tym w książce Suceeding with Agile.
pbarranis,
Czy byłby taki przypadek, w którym historia użytkownika nie ma zastosowania? Na przykład, jakie są przykłady historii użytkowników, które zobaczymy, jeśli powiedzą ci, aby zbudować Sztuczny Inteligentny: alphaGO, a ostatecznym celem jest pokonanie człowieka w GO? Kim byłby użytkownik, z którym mogę przeprowadzić wywiad, aby zdefiniować kryteria oczekiwań / akceptacji?
Roy Lee
11

Pytanie, biorąc pod uwagę konkretny przykład, brzmiałoby: dlaczego programista chce opracować mechanizm przechowywania i pobierania obrazów, aby użytkownicy mogli dodawać / wyświetlać obrazy w dowolnym miejscu, chyba że użytkownik chce dodawać lub wyświetlać obrazy?

Oznacza to, że chociaż twoje pytanie jest dobre, przykład nie jest. Jest to funkcja użytkownika i powinna mieć historię użytkownika. A jeśli użytkownik tak naprawdę nie potrzebuje tej funkcji, programista nie powinien tego robić.

Techniczna historia to więcej: „Jako programista chcę ograniczyć duplikację modułów do archiwizacji danych, aby nie musiałem dokonywać każdej zmiany w 6 miejscach”.

Pytanie, czy należy je uwzględnić w sprincie, jest trudne i zależy w pewnym stopniu od tego, kogo uważasz za swojego klienta. Czy to użytkownik końcowy, firma, która Cię zatrudnia, czy firma, która zatrudnia firmę, która Cię zatrudnia?

Wiele opinii branżowych jest kierowanych przez osoby pracujące dla firm doradczych. Z tej perspektywy widzę argument, że historie deweloperów są złe. Powinny one być po prostu częścią tego, co robisz, z dnia na dzień, niewidoczne dla firmy, która za to płaci. Firmy te instynktownie wiedzą, że zbyt wysokie naliczanie rachunków gwarantuje, że praca wyschnie, więc każdy programista działa zgodnie z zasadą robienia jedynie rozwoju technicznego, który skraca czas programowania lub poprawia możliwość wydania oprogramowania wolnego od błędów.

Mam większe doświadczenie w pracy w zespołach wewnętrznych, dostarczając oprogramowanie bezpośrednio firmie, która wypłaca moje wynagrodzenie. W wielu z tych firm istnieje bariera zaufania między biznesem a technicznym skrzydłem biznesu. We wszystkich jest inna mentalność, w której malejące koszty są tak samo jak rosnące przychody.

W tych środowiskach dobrze jest zdefiniować ważne historie programistów. Zwiększa widoczność, budzi zaufanie i zachęca zarówno programistów, jak i kierownictwo do zastanowienia się nad wartością takich zadań dla firmy i do ustalenia priorytetów.

Ostatecznie proponuję spróbować. A jeśli nie oferuje wartości, przestań to robić.

Ale mój instynkt mówi, że biorąc pod uwagę wartość tego rozwoju dla firmy, nawet nie próbowałbyś zrobić z tego historii rozwoju. Jest albo dobry dla użytkownika końcowego, albo nie jest. Jeśli tak nie jest, to nie ma żadnej wartości dla firmy.

pdr
źródło
1
Czy byłby taki przypadek, w którym historia użytkownika nie ma zastosowania? Na przykład, jeśli powiedziano ci, aby zbudować Sztuczny Inteligentny: alphaGO, a ostatecznym celem jest pokonanie człowieka w GO? Jak powinienem tworzyć historie użytkowników, kim byliby aktorzy tych historii i kim (czy byłby to właściciel produktu?
Roy Lee
2

To dobre pytanie. Nie mam oficjalnej odpowiedzi, ale tam, gdzie pracuję, dodajemy techniczne historie użytkowników i nazywamy je technicznymi długami. Gdyby nie były dozwolone, znalazłbym inny sposób na dodanie ich tylko w celu zarejestrowania mojej pracy i przekazania jej firmie. Podobnie, posiadanie tej dokumentacji przypomina nam o tym, co jest potrzebne do przyszłych projektów.

Na przykład brak połączenia w nowej aplikacji, jeśli nie wolno nam dodawać historii technicznych, polega na tym, że będę nucić przez tydzień po rozpoczęciu sprintu, tworząc modele baz danych i czekając na zatwierdzenie przez mojego projektanta danych je, iteruj z modelarzem, a po zakończeniu wyślij skrypty do dba i poczekaj, aż utworzą obiekty db. W międzyczasie utworzę nowy projekt kodu, podstawową funkcjonalność ORM i mój układ kontroli źródła, a kiedy wszystko zostanie powiedziane i zrobione, będę miał czas na utworzenie jednej pustej strony docelowej i wdrożenie.

Dzień po dniu, gdy to się dzieje, jeśli nie zarejestruję informacji, firma się wścieka, że ​​nasz zespół nie pracuje nad projektem, gdy w rzeczywistości jesteśmy. Umieszczenie tych artykułów w opowiadaniach oznacza, że ​​możemy sprawdzić naszą pracę, udokumentować pracę i poinformować firmę, że robimy postępy.

Jeśli jest jakaś lepsza praktyka, aby to zrobić, jestem cała w uszach.

Brian
źródło
Chociaż problem ten występuje w wielu organizacjach, błąd 100% wykorzystania jest powszechną dysfunkcją. POZA: Dług techniczny jest znanym problemem wymagającym pracy, która jest celowo opóźniana.
Alan Larimer
2

Osobiście uważam, że zespoły nie powinny zbytnio rozłączać się z tym, na co pozwala scrum, i bardziej martwić się tym, co działa dla zespołu. Jednym z powodów, dla których Scrum zyskał nieco złą reputację, jest to, że praktykujący mogą skoncentrować się na procesach, co jest sprzeczne z ideami zwinnego zarządzania projektami.

Zsiadam teraz z mojej skrzynki na mydło, ale jeśli zastanawiasz się, czy poniżej nie jest tak naprawdę „scrum”, przeczytaj ponownie.

Ważne jest, aby oddzielić „funkcje”, które definiują historie użytkowników, od „elementów dostarczanych”, które zespół techniczny musi dostarczyć, aby wesprzeć te funkcje. W takim przypadku potrzeba zapisywania i pobierania zdjęć jest technicznym rezultatem, który Ty (jako zespół techniczny) musisz wdrożyć. Prawie każda historia będzie wymagała pewnych technicznych rezultatów.

Powodem tego jest to, że techniczny produkt (sam w sobie) nie jest czymś, co wytwarza wartość z perspektywy użytkownika. Jeśli zaczniesz śledzić techniczne produkty jako historie użytkowników, możesz łatwo wpaść w pułapkę traktowania produkcji technicznej jako generującej wartość biznesową. W ten sposób zamulenie wód pomyli pracę, która wspiera cele biznesowe (tj. Rzeczy, które kosztują pieniądze) z rzeczywistymi celami biznesowymi (tj. Rzeczy, które zarabiają pieniądze).

JimmyJames
źródło
Cholera, nie zauważyłem, że to stare pytanie ...
JimmyJames
Nie, to dobra odpowiedź. Sława!
Hannele
teams should not be too hung up on what scrum allowsjest problematyczne. Jest to kluczowy powód, dla którego Scrum nadal jest niezrozumiany. Kulty ładunków, które nawet nie są poprawne w praktyce, są utrwalane przez ciągłą ignorancję.
Alan Larimer
@AlanLarimer Zwinność to więcej niż scrum. Chodzi o zwinne budowanie procesów, które działają dla zespołów. Zgodziłbym się, że nazwanie czegoś scrumem, gdy nie jest to problematyczne, odrzucam jednak pogląd, że scrum jest szczytem procesów zarządzania projektami.
JimmyJames
Zgodzono się, że zwinna filozofia promuje adaptacyjne podejście do rozwoju produktu (ponad projekt, ponieważ skupia się Scrum) i że nie ma srebrnej kuli. Nikt nie podał statusu szczytu w tym pytaniu. Gdy zespoły / organizacje / grupy wybierają środowisko Scrum i mają pytania dotyczące jego zastosowania, kluczowe jest podkreślenie, że jest to środowisko, które wspiera (tak jak było podstawą) zwinną filozofię poprzez nierzucanie wielu szczegółów. Uświadomienie sobie wartości takiej elastyczności i innych jest ważne, aby uniknąć sekt ładunków i zidentyfikować różnicę między ramami a problemami procesowymi.
Alan Larimer,
1

Wszystkie powyższe odpowiedzi nie odwołują się do wiarygodnego dokumentu źródłowego frameworka Scrum: Przewodnik Scrum .

Backlog produktu zawiera wszystkie funkcje, funkcje, wymagania, udoskonalenia i poprawki, które stanowią zmiany, które należy wprowadzić w produkcie w przyszłych wydaniach.

Należy skoncentrować się na tworzeniu wartości. Czasami ta wartość pochodzi z prac technicznych, takich jak modernizacja infrastruktury. Nie wykluczaj tych przedmiotów!

Termin historia użytkownika nigdy nie pojawia się w Poradniku Scrumowym, ponieważ

jest to struktura, w której możesz zastosować różne procesy i techniki.

Korzystanie z historii użytkownika jest tylko jedną z możliwych technik rejestrowania PBI. Chociaż często widzi się format „Jako, chcę, więc ten”, może być sprzeczny z jego pierwotną intencją . Ten kłopotliwy format został również omówiony na Agile 2017 .

Zrozumienie i zastosowanie podziału pionowego będzie pomocne w zmniejszeniu wielkości elementów rejestru produktu (PBI). Rozważmy krojenie że pojedynczy zapisu i odczytania element do oszczędzania i odzyskać poz s .

Alan Larimer
źródło