Musimy zrobić dokumentację użytkownika dla produktu, nad którym pracowaliśmy przez kilka ostatnich sprintów. Rozpoczynamy teraz nowy projekt w kolejnym sprincie, a organizacja producentów tworzy dokumentację dla wcześniej wyprodukowanego produktu jako historię użytkownika dla tego sprintu.
Zastanawiam się tylko o twoją opinię na temat tego podejścia. Osobiście nie zgadzam się, że dokumentacja jest historią użytkownika w Scrumie, ponieważ nie tworzy żadnego kodu.
EDYCJA: Dzięki za opinie chłopaki. Z tyłu głowy miałem wrażenie, że sprintem jest wdrożenie działającego oprogramowania, ale wasze poglądy zmieniły moje poglądy. Dziękuję za wszystkie odpowiedzi.
scrum
user-story
ediblecode
źródło
źródło
Odpowiedzi:
„Jako użytkownik X muszę wiedzieć, jak działa X” wydaje mi się uzasadnioną historią użytkownika. Może to skutkować pisemną dokumentacją lub pomocą online.
Chodzi nie tylko o kod - spełnia wymagania użytkowników.
źródło
Idealnie, dokumentacja jest częścią każdej historii użytkownika i nigdy się nie rozwija. Ale w prawdziwym świecie często się to nie zdarza. W takim przypadku należy utworzyć historię użytkownika, aby nadrobić zaległości związane z brakującą dokumentacją.
Masz rację, nie tworzy żadnego kodu. Ale spełnia wymagania użytkownika i należy nadać mu priorytet w stosunku do innych wymagań użytkownika.
Jeśli to oznacza, że nigdy się nie uda, ponieważ ta i ta funkcjonalność jest w trakcie opracowywania, prawdopodobnie nie potrzebowała tak bardzo dokumentacji.
źródło
Zgadzam się z oceną dokumentacji pdr, jeśli dotyczy dokumentacji wymaganej, technicznej lub projektowej. Idealnie powinien być włączony do pracy sprinterskiej.
Wydaje mi się, że dokumentacja produktu jest zupełnie inna, ponieważ jest to rzeczywisty produkt, o który poprosił użytkownik i który bezpośrednio zapewnia wartość dla użytkownika. Należy oczywiście rozumieć, że Dokumentacja Produktu zasadniczo nie jest Zadaniem Technicznym, ale Zadaniem Funkcjonalnym i może, ale nie musi być odpowiednim działaniem dla zasobu technicznego w projekcie.
Myślę, że powinna to być historia użytkownika, jednak uważam, że do tych zadań należy przypisać zasób projektu, który dobrze rozumie wymagania biznesowe, perspektywę użytkownika i dobre umiejętności pisania technicznego. Najlepiej byłoby, gdyby był to analityk biznesowy, jeśli jest dostępny, lub być może tester kontroli jakości wyższego rzędu z dokładnym zrozumieniem wymagań, historii użytkowników i dobrych umiejętności pisania technicznego. Może to być także programista, jednak dokumentacja produktu napisana przez programistów nie jest tak wysokiej jakości ani przydatna, ponieważ programiści zwykle są zbyt blisko szczegółów technicznych.
źródło
W naszej organizacji zespół narzędziowy odpowiedzialny za utrzymanie i ulepszanie naszego systemu ciągłej integracji używa Scrum, aby pomóc im zarządzać swoją pracą. Nie piszą kodu, ale mimo to ćwiczą Scruma.
Aby dokładnie odpowiedzieć na twoje pytanie, zapytam, czy zespół uważa, że dokumentacja jest częścią „Definicji Gotowości”, czy nie.
Jeśli zespół uważa, że dokumentacja jest częścią „definicji wykonanej”, nie ma potrzeby dodawania dodatkowej historii i historia nie może zostać zaakceptowana, chyba że dokumentacja jest napisana i zatwierdzona.
Jeśli zespół uzna, że dokumentacja nie jest częścią „definicji wykonanej”, stworzę osobną historię, aby właściciel produktu mógł zarządzać swoją pracą.
źródło