Tworzenie i zarządzanie zaległości produktu
autorstwa Mitcha Laceya.Właściciel, Mitch Lacey & Associates, Inc. Firma specjalizuje się w przyjmowaniu i ulepszaniu Agile i Scrum.
Styczeń 2012
W tym artykule Mitch Lacey wyjaśnia znaczenie zaległości produktu, opisuje, co tworzy dobrą zaległość i przedstawia niektóre najlepsze rozwiązania dotyczące tworzenia i utrzymywania zaległości.
Dotyczy
Zarządzanie cyklem eksploatacji aplikacji; Team Foundation Server
W tym artykule:
Wprowadzenie
Dziennik zaległości produktu
Historie użytkownika
Szacowanie
Określanie priorytetów
Bieżąca zaległość produktu
- Porządkowanie
Wnioski
Zaległość produktu to spriorytetyzowana lista wszystkich cech i funkcji niezbędnych do wykonania projektu.Dobra zaległość produktu jest sercem każdego prawidłowo funkcjonującego zwinnego zespołu i ma następujące cechy:
Jest priorytetyzowany w celu zapewnienia, że zespół najpierw utworzy najważniejsze funkcje.
Jest szacowany przez zespół, aby dać jasność właścicielowi produktu i umożliwić mu odpowiadanie na pytania, takie jak „Kiedy te historyjki zostaną wykonane?”.
Obejmuje wszystkie prace niezbędne do wykonania projektu.
Jest to dokument żywy, który stale się zmienia i ewoluuje, odzwierciedlając bieżące realia projektu.
Dobra zaległość produktu nie zapewnia automatycznie dobrego oprogramowania.Jednak brak dobrej zaległości produktu często skutkuje niekompletnym oprogramowaniem, które nie spełnia wymagań klientów i zainteresowanych stron.
Zarządzanie zaległością produktu to praca w pełnym wymiarze czasu.Proste techniki mogą być pomocne w przypadku zmiany przytłaczającego i czasochłonnego procesu na interaktywny, iteracyjny proces skutecznie angażujący członków zespołu, klientów i zainteresowane strony.Istotne jest zatem, aby opanować solidne techniki ułatwiające tworzenie, priorytetyzowanie i utrzymanie swojej zaległości produktu.
Dziennik zaległości produktu
Dziennik zaległości produktu to spriorytetyzowana, dynamiczna główna lista wszystkich cech i funkcji niezbędnych do wykonania projektu.Zaległości produktu często obejmują wymagań, historyjek użytkownika (e.g. wymagania), błędy zadań badawczych (kolce) i usprawnienia techniczne.Te elementy są szacowane w jednostkach abstrakcyjnych, które są często nazywane punktami wątku.
Zaległości produktu obejmują cały nakład pracy, jakiego będzie wymagał projekt i z biegiem czasu ewoluują.W związku z tym zawierają nie tylko nowe funkcje dla produktu, ale także poprawki błędów i badania — wszystko, co zajmie zespołowi czas.Cała praca, którą wykona zespół, musi pochodzić z zaległości produktu: są do drzwi wejściowe do projektu.Jeżeli zaległość produktu zawiera całą pracę, właściciel produktu, zespół i kierownictwo mają lepszy obraz pracy pozostającej do wykonania i ograniczają ryzyko niespodzianek w ostatniej chwili.
Na początku każdego projektu jest mało prawdopodobne, że masz listę jednoznacznych, dobrze zdefiniowanych elementów zaległości produktu gotową do oszacowania i spriorytetyzowania.Zamiast tego prawdopodobnie będziesz mieć stos karteczek z zanotowanymi historyjkami i może jedną lub dwie specyfikacje funkcjonalne.Jako właściciel produktu masz zadanie doprowadzić ten chaos do jako takiego porządku, tak aby zespół mógł rozpocząć szacowanie zaległości.
Historie użytkownika
Pierwszym krokiem jest konwersja wszystkich pomysłów i notatek na historyjki użytkownika, które wyrażają funkcjonalność żądaną przez użytkownika końcowego (działanie oprogramowania), ale bez szczegółów implementacji (jak tworzyć oprogramowanie spełniające te wymagania).Tytuł każdego wątku użytkownika powinien wyglądać w następujący sposób: „Jako <użytkownik> chcę <funkcja>, tak aby <powód>.”
Podobnie jak sama zaległość produktu, każda historyjka użytkownika będzie ewoluować z biegiem czasu.W trakcie trwania projektu zespół będzie ustalał priorytety i szacował te wątki, dodawał do nich szczegółowe informacje oraz dzielił je na mniejsze wątki lub usuwał je wszystkie.Te, które są wprowadzane do sprintów, są implementowane i dostarczane klientom.
Aby dowiedzieć się więcej o historyjkach użytkownika, zobacz Tworzenie lub dodawanie informacji o zaległościach związanych z produktem i Seria ujęć elementu zaległości za pomocą programu PowerPoint.
Po przekonwertowaniu wszystkich pomysłów i notatek na historyjki użytkownika jest czas na szacowanie i priorytetyzację.
Szacowanie
Z definicji szacowanie jest niedokładne.Jednak możesz stać się znacznie lepszym w tworzeniu stosunkowo dokładnych oszacowań wraz z czasem, praktyką oraz udziałem całego zespołu. Pierwszym krokiem jest zebranie zespołu w celu dostarczenia oszacowań elementów zaległości produktu.Gdy zespół oszacowuje każdą historyjkę, daje jej oszacowanie względnego rozmiaru z abstrakcyjną jednostką miary nazywaną punktem historyjki.
Oszacowania są istotne dla dwóch powodów:
Pomagają odpowiedzieć na pytanie "Kiedy zostaniemy ukończone?".
Pomagają właścicielowi produktu określić priorytet każdego elementu.
Szacunki dają właścicielowi produktu i zespołowi obraz kosztu danej historyjki, co z kolei ułatwia właścicielowi produktu priorytetyzowanie historyjek wzajemnie.Im większy szacowany nakład pracy, tym więcej czasu i zasobów będzie wymagać implementacja.Dlatego element, który mógł być bardzo pożądany przez właściciela produktu, może stać się mniej ważny, jeśli cena jest zbyt wysoka.
Zespół możne użyć Pokera planowania, dużej tablicy lub innych technik, aby oszacować pracę pod kątem punktów wątku.Aby uzyskać więcej informacji na temat technik szacowania oraz szybką lekcję w kwestii punktów historyjek, zobacz Szacowanie i Optymalizacja i szacowanie zaległości.
Po oszacowaniu przez zespół wszystkich historyjek jest czas na priorytetyzację.
Określanie priorytetów
Wszystkie zaległości produktu są priorytetyzowane pod względem wartości biznesowej i ryzyka.Właściciel produktu porównuje każdy element z dziennika zaległości do innych, aby ustalić jego względny priorytet.Aby to zrobić, właściciel produktu bierze pod uwagę rozmiar każdego elementu, jego wartość dla firmy i wszelkie ryzyko powiązane.Elementy są posortowane w kolejności malejących priorytetów.Elementy o wysokim priorytecie wyświetlane są blisko lub na samej górze listy zaległości produktu, a elementy niższego priorytetu znajdują się blisko lub na samym dole listy.Zespoły wybierają, czym się zająć przy następnym sprincie, pośród wielu elementów o najwyższym priorytecie, tak aby najważniejsze elementy zostały ukończone jako pierwsze.
Nie każdy element w zaległości ma taki sam rozmiar.Niektóre można ukończyć w trakcie jednego sprintu, ale w przypadku innych, które są bardzo duże, zespół nie ma pewności, co się z tym wiąże lub jak długo zajmie ich implementacja.To jest w porządku.Wraz z przenoszeniem elementów bliżej góry zaległości zespół będzie je zmniejszał i bardziej skupiał na nich uwagę, tak aby wszyscy lepiej rozumieli pracę, którą zajmą się w nadchodzących sprintach.
Podobnie jak w przypadku szacowania, priorytetyzowanie początkowej zaległości produktu może budzić przerażenie.Jak można skutecznie równoważyć konkurencyjne potrzeby zainteresowanych stron, uwzględniając jednocześnie produkt końcowy, ryzyka i koszty?Na szczęście kilka technik istnieją, które ułatwić zadanie, łącznie z gry innowacji i względną wagę.Zobacz Określanie priorytetów i Optymalizacja i szacowanie zaległości, aby uzyskać więcej informacji na temat tych i innych technik.
Niezależnie od wybranej techniki ustalania priorytetów, musisz uporządkować pracę, aby zapewnić, że zespół tworzy funkcje, które są najbardziej wartościowe dla firmy, zainteresowanych stron i klientów.Jeśli nie ustalisz priorytetów pracy, zwiększasz ryzyko dostarczenia historyjek użytkownika o niższym priorytecie zamiast wyższym oraz niekompletności historyjek użytkownika w razie zmiany zasobów i harmonogramów.
(Aby uzyskać więcej informacji o charakterze elementów zaległości, zobacz Tworzenie lub dodawanie informacji o zaległościach związanych z produktem i Planowanie Agile i iteracje).
Bieżąca zaległość produktu
W tym co zostało opisane dotąd skupialiśmy się na przejściu do szacowania i priorytetów zaległości produktu.W przeciwieństwie do dokumentu wymagań, zaległości produktu nie są tworzone na początku projektu i pozostawiane na półce.Zamiast tego zaległość produktu ewoluuje, poszerzając się i zmniejszając zgodnie z realiami projektu.Niektóre elementy zaległości produktu stają się nieistotne i należy je usunąć.Inne będą promieniowały do powierzchni i będą musiały zostać podzielone na mniejsze wątki.Nowe historyjki użytkownika będą dodawane, szacowane i priorytetyzowane wraz z pojawianiem się dodatkowych wymagań.
Zespół i udziałowcy są zaangażowani w tworzenie i zarządzanie zaległościami produktu, ale właściciel produktu ponosi za nie ostateczną odpowiedzialność.Właściciel produktu musi zapewnić przejrzystość i aktualność dziennika zaległości, dzięki czemu zarówno klienci, jak i zespół będą mieć jasny obraz planu pracy dla wersji projektu.Nawet gdy projekt jest realizowany z rozmachem, właściciele produktu mają jeszcze dużo pracy do wykonania, aby zachować zaległość produktu w dobrej formie:
Dodawanie i priorytetyzowanie nowych historyjek
Proszenie zespołu o szacowanie nowych historyjek i ponowne szacowanie starych, jak są one lepiej zrozumiałe
Recenzowanie nadchodzących historii użytkownika z zespołem w celu odpowiedniego rozbicia pozycji
Spotkanie z klientami i zainteresowanymi stronami w celu przeglądu i dodania wymagań
Każda osoba może dodawać elementy do listy zaległości produktu w dowolnym momencie, ale tylko właściciel produktu może je priorytetyzować.Właściciel produktu jest również jedyną osobą, która można przypisać priorytet historyjce.Wszyscy pozostali członkowie zespołu i zainteresowane strony powinni pozostawiać puste pole priorytetu historyjki, nawet jeśli używają elektronicznego narzędzia monitującego o tę informację.
Po dodaniu historii właściciel produktu dokonuje wstępnej oceny jego priorytetu według własnego zrozumienia.Omówi historyjkę z jej twórcą, aby lepiej ją zrozumieć, tak aby z kolei on mógł odpowiedzieć na pytania z zespołu.We wstępnie ustalonym czasie podczas każdego sprintu właściciel produktu będzie się spotykał z zespołem w celu omówienia nowych historyjek i wspólnie je szacował, tak aby dokładniej ustalić ich priorytety względem innych historyjek w zaległości.Ten proces jest nazywany porządkowaniem zaległości.
Porządkowanie
Pielęgnacja zaległości produktu, jak wspomniano wcześniej, musi odbywać się regularnie.
W metodyce Scrum zespół powinien poświęcić 5-15% czasu w każdym sprincie na działania porządkowe.Zespół musi zrozumieć, co nadchodzi i co się zmienia, tak żeby można było podzielić duże wątki, które mają coraz wyższe priorytety, oszacować wątki, które zostały utworzone i wykonać przyszłościowe projektowanie i planowanie dla nadchodzących wątków.Aby zapewnić, że tak się stanie, właściciel produktu i zespół powinni podczas każdego spotkania związanego z planowaniem sprintu, przeznaczyć trochę czasu na wspólne porządkowanie zaległości.Aby uzyskać więcej informacji na temat planowania sprintów, zobacz Sprint, planowanie i Planowanie iteracji.
Podczas dwutygodniowego sprintu lubię organizować to spotkanie w drugim tygodniu.Daje to właścicielowi produktu wystarczająco dużo czasu, aby odbyć znaczącą rozmowę z klientami i zainteresowanymi stronami, zrozumieć zmiany w branży i wyjaśnić wątki użytkownika i wątki, które są nowe lub stają się coraz ważniejsze.Jest to również logiczny czas podczas sprintu, aby zacząć przewidywać nadchodzące sprinty.Można zdecydować, kiedy posiedzenie ma się odbyć.Ważną rzeczą jest zapewnienie wystarczającej ilości czasu podczas sprintu na działania porządkowe.
W trakcie typowego spotkania porządkującego właściciel produktu przedstawia, co nowego, co się zmieniło i co planuje na kilka następnych sprintów.Oprócz szacowania nowych historyjek i dzielenia tych, które muszą być wykonane szybko, zespół czas podczas tego spotkania przegląda również bieżącą architekturę systemu i planuje lub projektuje przyszłe funkcje.Podczas tego procesu oszacowania dla historyjek często się zmieniają i nowe historyjki się pojawiają, ponieważ większe historyjki są dzielone na mniejsze.
Proces ten wydaje się prosty, ale może przysporzyć trochę wysiłku.Aby ułatwić działanie, właściciel produktu musi być przygotowany do odpowiedzi na pytania.Konflikt może nastąpić, jeśli na przykład właściciel produktu planuje wykonanie historyjki w następnym sprincie, ale nie może zapewnić jasności, której potrzebuje zespół, aby dostarczyć dobrego oszacowania.Jeśli tak się stanie podczas spotkań poświęconych planowaniu sprintu, Scrum Master powinien pouczyć właściciela produktu w zakresie informacji, jakie powinien dostarczyć od klienta i zainteresowanych stron dla zespołu.
Na końcu każdego spotkania porządkującego właściciel produktu powinien opublikować zmiany zainteresowanym stronom i klientom, tak aby wszyscy widzieli, co jest nowego, co nadchodzi i jaki jest zaktualizowany plan wersji.
Dobra zaległość produktu pomaga zapewnić, że tworzone oprogramowanie zawiera najważniejsze funkcje określone w rozmowach z klientami i zainteresowanymi stronami oraz zdefiniowane w historyjkach użytkownika.Aby utworzyć i utrzymywać dobrą zaległość produktu, musisz aktywnie i regularnie współpracować z grupą zainteresowanych stron/klientów i zespołem — w każdym sprincie.
Zbudowanie dobrej zaległości nie zapewnia dobrego systemu, ale brak dobrej zaległości prawie zawsze ostatecznie sprawi, że system nie będzie spełniał oczekiwań klienta.Innymi słowy nieaktualizowanie zaległości prawie zawsze spowoduje niepowodzenie projektu.
Właściciel produktu to praca na pełny etat, a w zakres odpowiedzialności wchodzi dziennik zaległości.Traktuj rolę poważnie.Utrzymuj w dobrym stanie zaległość produktu — klienci będą Ci wdzięczni.
Zobacz też
Koncepcje
Żądanie i opinie zainteresowanych stron procesu przy użyciu programu Access w sieci Web zespołu
Śledzenie pracy i zarządzanie przepływem pracy
Inne zasoby
Pobierz działania instalacji jednego serwera [samouczka]
Sterowanie procesami i szablony procesów w przypadku serwera Team Foundation Server