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

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

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ń.

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.

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.

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).

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 .