Ile szczegółów na temat historii użytkownika może oczekiwać deweloper?

15

Największą wadą zwinnego rozwoju, z jaką się spotkałem, jest to, że ludzie nie zaangażowani w rozwój koncentrują się na mantrze, że historia użytkownika (3-10 idealnych osobodni) nie powinna zawierać więcej niż 1-3 zdań takich jak:

Jako klient mogę korzystać z wyszukiwania tekstowego, aby znaleźć produkty, których szukam.

Dając to zdanie, kierownicy projektu oczekują ode mnie, jako programisty, dokonania oceny i opracowania historii. Zakładają, że zwinny rozwój oznacza, że ​​takie zdania to wszystko, co muszą przekazać programistom.

Nie będę ich winić, ponieważ dobrze znana literatura na temat zwinnego rozwoju stwarza wrażenie, że to rzeczywiście zadziałałoby. Przeczytałem około 2 stron w języku naturalnym na historię w „Planning XP”, ale to wszystko. Ponieważ „działające oprogramowanie” jest uprzywilejowane w stosunku do „kompleksowej dokumentacji”, wydaje się, że tego tematu zasadniczo się unika.

Rzeczywistość jest oczywiście taka, że ​​jeśli deweloper ma taką możliwość, rozmowa z klientem przedstawia długą listę wymagań, jakie klient ma wobec tej historii:

  • Potrzebujemy operatorów logicznych, takich jak AND i OR.
  • Potrzebujemy rozmytego wyszukiwania wszystkich terminów.
  • Musimy wyszukiwać według pojedynczych słów, a także według frazy.
  • Nie chcemy znaleźć produktów spełniających kryteria X, Y i Z.
  • Chcemy posortować wynik. Aha, a przy okazji, użytkownik może wybrać kryteria sortowania w polu kombi z opcjami a, b i c.

Widzisz więc, że nie mówię o szczegółach technicznych, projekcie oprogramowania, a nawet szczegółach implementacji. To czyste wymagania. Im dłużej rozmawiamy, tym bardziej klient zdaje sobie sprawę, że tak naprawdę jest wiele do powiedzenia na temat tego, czego chce.

Ale dość często znajduję się w sytuacji, gdy takie informacje nie są dostarczane lub są bardzo tandetne. Ani nie jest możliwe, żebym przeprowadził wywiad, ani osoba, która byłaby w stanie przeprowadzić wywiad, nie dostarczy mi wyniku.

Czasami menedżerowie nawet wymyślają szczegóły techniczne, takie jak „chcemy wyszukiwać Lucene”, ale nie chcą myśleć o tym, czy chcą znaleźć tylko nazwy produktów lub ich opisy. Czasami myślę, że są po prostu leniwi;)

Dla mnie jest to najważniejszy problem w projektach, w których pracuję (aplikacja internetowa e-biznes, 500-2000 osobodni na projekt). Rozwiązałem ten problem dość często, a menedżerowie zdają sobie sprawę, że większość programistów ma problem z tą sytuacją. Uważają jednak, że programiści są po prostu zbyt „perfekcjonistami”. Wydają się zirytowani, że programiści „zawsze chcą mieć wszystko określone”.

Ze względu na brak ogólnie przyjętych liczb trudno się kłócić. Wszyscy wiedzą, jak długo powinna trwać iteracja. Ale nikt nie jest w stanie powiedzieć, jakie wymagania są potrzebne do oszacowania i opracowania historii.

Czy masz jakieś referencje?

Wolfgang
źródło
1
Czy nie chodzi o to, że wykonujesz jak najmniej pracy, aby wyszukiwanie tekstowe działało, a następnie poprawiało w razie potrzeby? (lub właściciel produktu uczy się bardziej precyzyjnie)
Telastyn
1
@Telastyn: Nie, jeśli klient chce wyceny z góry.
Wolfgang,
2
Następnie podaj szacunkową minimalną ilość pracy potrzebnej do wykonania tego, o co proszą. Próba określenia całości zakresu w próżni jest jednym z kluczowych błędów, których zwinny chce uniknąć.
Telastyn
1
Tak, brakowało mi punktu „minimum”. Teraz rozumiem.
Wolfgang,

Odpowiedzi:

8

Trochę brakuje ci zręczności. Czego domagają się historię użytkownika, widzę jak co najmniej sześciu szukaj jeden goły, i po jednym dla każdej ze swoich punktach. Z pewnością zaplanuj wystarczająco dużo, aby nie wpaść w róg, z którego wydostanie się będzie kosztowny, ale cała idea polega na tym, że zapewniasz minimum potrzebne do zapewnienia pewnej wartości i robisz to wystarczająco szybko, aby uzyskać szybką informację zwrotną.

Kiedy dzielisz taką historię, nie tylko ułatwia to oszacowanie, ale pozwala właścicielowi produktu na ustalenie priorytetów w bardziej szczegółowy sposób. Z pewnością podoba im się możliwość sortowania wyników wyszukiwania, ale może nie jest to tak ważne, jak inny element zaległości, który jest całkowicie niezwiązany z wyszukiwaniem.

Również na pomysł programistów potrzebujących wszystkiego, co określone, spróbuj spojrzeć na to z punktu widzenia klienta. Wiele razy to tak, jakbyś kupował samochód, a sprzedawca pyta, jaki kolor ma gałka wycieraczki przedniej szyby. Wiele szczegółów, które możemy uznać za ważne, jest całkowicie nieistotnych z punktu widzenia klienta. Pracowałem tam, gdzie wymagania są bardzo zawyżone i wierzcie mi, nie jest to zbyt zabawne. Na rodzaj swobody, na którą narzekasz, wielu programistów chciałoby mieć.

Karl Bielefeldt
źródło
Podoba mi się pomysł dzielenia historii. Może sprawić, że będą trochę za małe (jak 2 godziny zamiast 2 dni), ale myślę, że to w porządku. Tak naprawdę chciałbym, ponieważ poprawia to strukturę oprogramowania (odsprzęganie), ponieważ programiści są zmuszeni rozdzielić funkcje i zatwierdzić je osobno. Nadal martwię się o to, że mogę zostać zmuszony do podejmowania niedoinformowanych decyzji, które klient cofnie, co może stać się nieefektywne. Ale twój punkt widzenia na „minimum potrzebne” całkowicie uderza!
Wolfgang
+1 za punkt na „gołych kościach”. Niektóre niejasne punkty ...
Ashkan Kh. Nazary
@Wolfgang: O „decyzjach, które klient cofnie”: Stanie się tak, bez względu na zastosowaną metodykę. Tylko w Agile dzieje się to wcześniej, więc marnuje się mniej wysiłku.
śleske
6

Wygląda na to, że pierwszy problem polega na tym, że nie należy stosować oszacowań czasu do historii użytkowników. Powinieneś wziąć historię i zastosować „punkty opowieści”, które są ogólnym oszacowaniem złożoności od 1 do NIESKOŃCZONOŚCI. Punkty fabularne są często uruchamiane na przykład 1,2,3,5,8,133,20 ... (Każda organizacja ma swoje własne zasady). Zasadniczo mają one zastosowanie:

1 - Możesz to zrobić we śnie i nie warto tego wdrażać. 2 - Rozumiesz to i możesz to zrobić szybko, bez ryzyka przekroczenia. 3 - Rozumiesz to, ale może być niespodzianka lub dwie. 5 - Przechodzę do drobnych badań i wiąże się z niewielkim ryzykiem. 8 - To duże zadanie, wymaga wielu badań i może nie zmieścić się w sprincie. 13 - To jest ogromne i na pewno nie zmieści się w sprincie. Istnieje ogromne ryzyko. itp.

Ogólnie rzecz biorąc, każda historia użytkownika, która ma 8 lub więcej lat, musi zostać podzielona na mniejsze historie.

Jeśli nie masz informacji, aby to zrobić, zdecydowanie powinieneś przekazać je kierownikowi projektu i powiedzieć, że potrzebujesz więcej informacji.

Naprawdę powinieneś szacować czas dopiero po zaakceptowaniu historii do sprintu, ale nawet wtedy mniej nacisku na to. Chodzi o to, że gdy twój zespół przyzwyczai się do procesu wskazywania, możesz zmierzyć jego przybliżoną wydajność na sprint w punktach fabularnych i zaplanować w ten sposób. Nie chcesz planować w krótszym czasie niż sprint. Chodzi o to, że jeśli poprawnie rozkładasz zadania, aby wiele opowieści mieściło się w sprincie i mieściło się w zakresie 1-5 punktów, oznacza to, że są wystarczająco dobrze zdefiniowane.

Wygląda też na to, że szefowie w twojej firmie nie rozumieją, czym jest „historia”. Krytyczną częścią „historii użytkownika” są kryteria wyjścia. Kryterium wyjścia to krótkie zdanie lub dwa, które jednoznacznie opisują, w jaki sposób można wykazać, że przechowywanie zostało zakończone. Idealnie powinno być to coś, co powiedzieli twoi pracownicy QA „tak, możemy to przetestować”. Ważną kwestią jest to, że PM muszą zrozumieć, że historia użytkownika jest kompletna, gdy oprogramowanie spełnia „kryteria wyjścia”. „Ale my tego nie chcieliśmy” nie przerywa. Jeśli nie chcieli tego, co zostało dostarczone, ale spełniło kryteria wyjścia, muszą wprowadzić nową historię.

Z pewnością jest tu element „szkolenia PM”. Muszą się dowiedzieć, że niejasne historie prowadzą do dużych punktów historii i że jeśli niejednoznacznie zdefiniują historię, aby uzyskać to, czego chcą, muszą to zrobić ponownie.

Oczywiście, jeśli interesariusze nie zbierają wystarczającej ilości informacji, musisz, a jeśli musisz, to o wiele więcej pracy, prawda? Na długo przed moimi zwinnymi dniami odniosłem sukces, podając bardzo duże oszacowania i wyraźnie mówiąc, że oszacowania były tak duże, aby uwzględnić ryzyko spowodowane brakiem informacji. Musiałem przyjąć najgorszy przypadek dla wszystkich pytań i oszacować na podstawie tego najgorszego przypadku. Przekonałem się, że menedżerowie byli bardziej skłonni podać więcej szczegółów, gdy zobaczyli, że szacunki spadają.

To nie gra w system ... to jest całkowicie poprawne. Jeśli nie wiesz, czy to „A”, czy „B”, szacujesz na podstawie tego, który daje największy szacunek na Twoją dupę.

Gort the Robot
źródło
Ten pomysł też mi się podobał. Ale: 1. nadal nie dostarcza mi informacji potrzebnych do rozwoju, oraz 2. szef lub klient uważa, że ​​zostali „oszukani” i nie zaakceptują mojej oceny. W końcu musi pasować do ich budżetu. Punkty fabularne też mi nie pomagają, ponieważ są w zasadzie takie same jak „idealne” dni. Czy masz na myśli kryteria akceptacji? Tak, lubię je, ale tak naprawdę nie jestem tak wybredna, w jakiej formie są dostarczane wymagania. Obawiam się o ich liczbę.
Wolfgang,
1
„kryteria wyjścia” i „kryteria akceptacji” to w większości to samo, ale podoba mi się „kryteria wyjścia”, ponieważ mówi „jeśli to, co robimy, pasuje do tego, historia jest skończona bez względu na to, czy naprawdę tego chcesz”. Niestety większy problem jest nierozwiązywalny. Ludzie zawsze będą chcieli tego, czego chcą, nie wiedząc, czego chcą. Najlepsze, co możesz zrobić, to użyć metod, które go wyróżniają.
Gort the Robot
Cóż, wierzę, że jestem całkiem dobry w „zmuszaniu ich do mówienia” ;-) Chodzi o to, że często nie mam okazji, aby to zrobić, a jakiś bezradny kierownik projektu zapycha rurkę informacyjną między klientem a deweloperem.
Wolfgang,
1

Z moich doświadczeń wynika, że ​​wiele zmian lub projektów, nad którymi pracuję, dotyczy tego właśnie problemu. Custom X chce czegoś i ma pojęcie o tym, czego chce, ale daje ci tylko niewielką wartość wymagań e-mail. Jest tak głównie dlatego, że klient nie „dokładnie” wie, czego chce. Właśnie dlatego większość zadań naszego działu obsługi klienta polega na spełnianiu wymagań klientów i filtrowaniu potrzebnych informacji, a także przewidywaniu, czego NAPRAWDĘ klient będzie chciał lub czego naprawdę potrzebuje.

Powiedzmy, że klient (dla mnie) chce, aby dział naszej aplikacji internetowej zwrócił mu listę wszystkich numerów telefonów. Nigdy nie określają, czy mają na myśli fizyczne, logiczne, przypisane do osoby lub lokalizacji itp. Po prostu chcą wszystkich numerów telefonów. Jako programista mogę usiąść i pomyśleć o kilkunastu pytaniach, które musiałbym zadać klientowi, podobnie jak ty. Ale, jak mówisz, nie jest to możliwe. Dlatego posiadanie dobrego działu obsługi klienta znającego produkt i klienta jest nieocenione.

Gdy tego rodzaju połączenie przychodzi do naszych przedstawicieli, są oni w stanie omówić je z klientem, wiedząc, czego potrzebują, aby uzyskać właściwe odpowiedzi. Mają też uprzedzenie, by wiedzieć, o co prosił klient w przeszłości i wiedzą wystarczająco dużo o systemach, które opracowujemy, że mogą powiedzieć coś tak lub nie, nawet nie pytając klienta.

Jasne, będziesz mieć wiele przypadków, w których klient będzie nadal potrzebował czegoś innego, czego zarówno ty, jak i usługi klienta przegapicie, ale tak się zawsze stanie. Twoim celem, a także usługami klienckimi, powinno być zminimalizowanie opóźnienia między opracowaniem czegoś a odzyskaniem go od klienta wraz ze zmianami, które należy wprowadzić. A to sprowadza się tylko do komunikacji i szkoleń z obsługi klienta.

Może nie jest to dla ciebie tak wykonalne, jak w tym miejscu, w którym jestem, ale dobra komunikacja i zaufanie z przedstawicielami klientów prawie zawsze pomoże ci stopniami i zmniejszy frustrację i zwiększy satysfakcję klienta. Możesz także łatwiej określić ramy czasowe dla swoich projektów zamiast wzruszać ramionami i mówić: „Nie znam pełnego zakresu projektu, więc nie wiem, jak długo to potrwa”. Mamy tutaj ten sam problem, a lepsza komunikacja i szkolenia pomagają nam ustalić rozsądne terminy i konsekwentnie je dotrzymywać.

Krystaliszny niebieski
źródło
Mój problem polega na tym, że ta linia komunikacyjna jest często zbyt wolna i zła. I nie mam na to wpływu.
Wolfgang,
+1 za podkreślenie wartości wczesnej informacji zwrotnej. Myślę, że idzie to w parze z zasadą gołej kości w przyjętej odpowiedzi
Ashkan Kh. Nazary
@Wolfgang to inna (i znacznie trudniejsza) historia;)
Ashkan Kh. Nazary
1

Klient

Chcę szukać produktów

Kierownik produktu Przeanalizowałem historię klienta i opracowałem następujące wymagania. Każde wymaganie zostało zapisane jako osobna historia użytkownika.

  • Wyszukaj produkty
  • Sortuj wynik
  • Filtruj wyniki wyszukiwania

Deweloper Otrzymałem historie użytkowników od menedżera produktu. Przeanalizowałem każdą historię użytkownika i wymyśliłem listę zadań dla każdej historii użytkownika.

  • Wyszukaj produkty
    1. Zadanie 1: Zmiany w bazie danych
    2. Zadanie 2: zmiany po stronie serwera
    3. Zadanie 3: Zmiany w interfejsie użytkownika

Klient, kierownik produktu i programista są udziałowcami tego procesu. Wszyscy muszą wziąć udział w procesie analizy, zanim prace będą mogły się rozpocząć. Pamiętaj, że jest to bardzo uproszczony przykład.

Nasze historie użytkowników są analizowane i dopracowywane w następującej kolejności (z pewnymi odmianami oczywiście):

Help Desk -> Właściciel produktu -> Kierownik produktu -> Kierownicy działów (starsi programiści, qa lead itp.) -> Programiści

Po tym, jak wszyscy odpowiedni interesariusze wniosą wkład w proces analizy, możemy oszacować, ile czasu zajmie nam dostarczenie historii. Proces szacowania, który obserwujemy, oparty jest na szybkości i wiedzy poszczególnych programistów.

Nie twierdzę, że jest to poprawny sposób robienia rzeczy, ale działa naprawdę dobrze w naszej organizacji.

CodeART
źródło