Historie użytkowników są zbyt wysokie i koncepcyjne, zarząd oczekuje, że programiści wypełnią puste pola

Jestem zatrudniony w bardzo błyskotliwej firmie z prawdziwym zamiarem zdobycia XP. Komunikacja jest dobra, a kierownictwo jest otwarte na konstruktywną dyskusję, ale z powodu naglących ograniczeń czasowych niektóre pewne kwestie uważa się za zbyt trudne do omówienia.

W tej chwili jestem trochę zaniepokojony ilością zmian, które stają się konieczne podczas wdrażania opowieści. Uważam, że wiele z tych odkryć (które oczywiście wymagają czasu i wysiłku) jest obowiązkiem autorów opowiadań (klientów, użytkowników końcowych i właścicieli produktów), a nie twórców. Krótko mówiąc, historie użytkowników są zbyt pojęciowe i po prostu oddają podstawową intencję, ale brakuje im wystarczających szczegółów (zwłaszcza warunków wstępnych i dodatkowych, powiązania z innymi historiami, zależności itp.). Oczekuje się, że deweloper wypełni puste pola według własnego uznania, ponieważ programiści XP są jednocześnie projektantami i analitykami. Problem polega na tym, że wiele z tych pustych miejsc zostało odkrytych po tym, jak niektóre błędne założenia przeszły do ​​czasu oceny i kodu, ponieważ zauważono, że pojawiają się dodatkowe złożoności, niż początkowo oczekiwano. Nawet wtedy znalezienie właściwej rzeczy do wypełnienia wymaga czasu, który - w różnym stopniu - jest uważany za odstępstwo od wstępnych szacunków.

Szukam konstruktywnego sposobu przekazania tych implikacji kierownictwu w sposób, który nie przedstawiłby mnie jako kogoś, kto próbuje niepotrzebnie komplikować sprawy. Jestem nowy i jak dotąd nie ustaliłem dużej wiarygodności.

Twoje spostrzeżenia są mile widziane.

Blisko spokrewniony i w jakiś sposób daje odpowiedź: ile szczegółów na temat historii użytkownika może oczekiwać deweloper?

Sztuką jest nie unikać pustych miejsc. Sztuką jest wypełnienie tych pustych miejsc jak najwcześniej w procesie rozwoju.

Masz rację, że jeśli programiści dokonają założeń, zawsze będą się mylili, a to będzie kosztowało czas przebudowy oprogramowania później. Ale równie dobrze, jeśli oczekuje się, że ludzie biznesu wykonają pełny projekt z góry, kiedy tak naprawdę nie wiedzą, czego chcą, to samo się stanie.

To duża część pracy programisty, aby dowiedzieć się, czego chce klient, gdy często tak naprawdę nie wie.

Najpierw zadawaj pytania. Tam, gdzie odpowiedzi wydają się niezadowalające, stwórz prototyp. Pokaż klientowi, o co prosi, i pozwól mu powiedzieć, że tak naprawdę nie tego chce. Zacznij od papierowego prototypu, a następnie przejdź do prototypu opartego na HTML, bez kodu. Następnie wykonaj najmniejsze prace, których potrzebujesz, aby wyprodukować prawie działający produkt i pokazać im to. Pozostaw trudne fragmenty tak późno, jak to możliwe.

Może się to wydawać czasochłonne samo w sobie, ale w porównaniu do przebudowy rzekomo ukończonego produktu tak nie jest.

Zachowaj także, by historie były jak najmniejsze. Niezmiennie to, czego chce firma, jest epickie, coś, co można podzielić na wiele rezultatów. Jest to lepsze, ponieważ nie rozwiniesz się zbytnio, gdy spojrzą na kandydata na ostatnią wersję i krzykują: „Och nie, naprawdę nie tego szukaliśmy”.

Nawet wtedy znalezienie właściwej rzeczy do wypełnienia wymaga czasu, który - w różnym stopniu - jest uważany za odstępstwo od wstępnych szacunków.

Dla mnie to nie brzmi bardzo „XP”.

W żaden sposób nie jestem ekspertem od XP, ale AFAIK pomysł XP polega na ciągłym dostosowywaniu specyfikacji i szacunków za każdym razem, gdy otrzymujesz informacje zwrotne z procesu. A proces polega na: „trochę przeanalizować - trochę zaprojektować - trochę przetestować - a następnie uzyskać opinie użytkowników, aby jak najwcześniej skorygować błędne założenia. Możesz także spróbować uzyskać opinie użytkowników jeszcze wcześniej , na przykład , po zaprojektowaniu niektórych części oprogramowania (np. interfejsu użytkownika) na kartce papieru lub tablicy i przedyskutowaniu tego z użytkownikiem lub klientem . Nie sądzę, aby „XP sposób” zabraniał takiego podejścia tylko z powodu „ historie użytkownika".

Oto fajny artykuł na temat tego, jak szybciej uzyskać informacje zwrotne za pomocą specyfikacji. Myślę, że tego rodzaju myślenie jest niezależne od „metodologii”, a przedstawione tam argumenty pomogą ci w debacie z zarządem.

Podsumowując, jesteś w następującej sytuacji:

1. Jesteś nowy.
2. Projekt (zakładam, że mówisz o działającym projekcie) ma palące ograniczenia czasowe.
3. Deweloper powinien wypełnić puste pola według własnego uznania.
4. Firma, w której pracujesz, zamierza ćwiczyć XP. Jednak historie użytkowników wydają się nie być stosowane w sposób, który pasuje do metodologii XP. Z drugiej strony „ Oczekuje się, że deweloper wypełni puste pola według własnego uznania ”.

Pomyśl o punkcie 4: Moim zdaniem, zwinne praktyki powinny być dostosowane do potrzeb i kultury firmy / zespołu (a nie na odwrót). Określ, gdzie firma stosuje metodologię XP, a gdzie odchodzi. To podstawa konstruktywnego podejścia do twoich obaw.

Z powodu 1 i 2 nie jesteś obecnie w stanie zapytać, czy firma stosuje XP w rozsądny sposób. Rozpoczęcie dyskusji z zarządem najprawdopodobniej przedstawi cię jako osobę, która „ komplikuje ”. Możesz jednak zacząć omawiać swoje obawy z innymi programistami. Może znajdziesz programistów, którzy myślą tak, jak Ty. Być może istnieje starszy programista, który przekaże twoje obawy kierownictwu. Ale nie oczekuj, że wszystko szybko się zmieni, szczególnie nie w obecnym projekcie. Jednak projekt da ci dobrą okazję do zebrania większej ilości danych, co dodaje więcej treści konstruktywnemu podejściu.

Teraz do punktu 3: Myślę, że dobre historie użytkowników są pisane wspólnie przez klientów / użytkowników końcowych / właścicieli i programistów produktów. Okaż inicjatywę: poszukaj okazji, by bezpośrednio zapytać autorów historii użytkowników. Jeśli nie jest to możliwe, poproś starszego programistę lub kierownictwo, jak postępować z otwartymi pytaniami, na które muszą odpowiedzieć autorzy historii użytkowników. Może możesz przynajmniej mieć jakąś pisemną korespondencję. Ponieważ wypełniasz puste pola według własnego uznania, Twoim wyborem powinno być aktywne zaangażowanie klientów / użytkowników końcowych / właścicieli produktów.

W pewnym momencie masz wystarczająco dużo przemyśleń i obserwacji na temat tego, jak Twoja firma stosuje XP (lub ogólnie zwinne praktyki). Może minęło już trochę czasu i nie jesteś już postrzegany jako Greenhorn. Być może twoje aktywne zaangażowanie z klientem przyniosło pozytywne efekty. Może kolejny projekt już się rozpoczyna. Być może masz już jakieś kopie zapasowe od innych programistów. Może dowiesz się, że sposób, w jaki to działa, wcale nie jest zły. Chodzi o to, że wtedy będziesz miał wystarczająco dużo pomysłów, aby przekazać swoje obawy kierownictwu, w oparciu o prawdziwe doświadczenie i dane w Twojej firmie.

Szczerze mówiąc, historie użytkowników nie powinny zawierać zbyt wielu szczegółów. „Chcę, aby oprogramowanie wykonywało X, aby zaspokoić potrzeby biznesowe Y” powinno wystarczyć. W końcu nie chcesz, aby ludzie biznesu dyktowali, jak to zrobić - jesteś ekspertem od oprogramowania i najlepszych praktyk w tym zakresie.

To powiedziawszy, programiści muszą również zapytać : „jak to działa?”, „Co się stanie, gdy wejdzie to w interakcję z funkcją Z?”. Programiści nie stawiają wymagań, wdrażają.

Brzmi również tak, jakby przepaść między wdrażaniem a oceną była zbyt duża. Interesariusze powinni patrzeć na prototypy, na wpół wykonany kod co kilka dni. Dzięki temu możesz uzyskać informację zwrotną, zanim przejdziesz zbyt głęboko w chwasty.

Jeśli zostaniesz poproszony o oszacowanie historii, która wydaje ci się niekompletna, daj znać, że masz pytania na temat tej historii i że nie możesz podać właściwej oceny, zanim nie odpowiesz na te pytania.

Następnie zadaj pytania i upewnij się, że odpowiedzi staną się częścią historii.

Jeśli jesteś zmuszony podać oszacowanie, nawet jeśli na twoje pytania nie ma (wszystkich) odpowiedzi, możesz albo odmówić podania oszacowania, albo wyraźnie wskazać, że zakładasz najgorsze możliwe wyniki dla pozostałych pustych punktów w oszacowaniu (które prawdopodobnie sprawi, że twoje oszacowanie będzie wysoką wartością odstającą).

To, co robisz, nie jest zwinnym sposobem rozwoju. Zamiast tego pracujesz z niskimi wymaganiami jakościowymi. To nieprawda, że ​​zwinny sposób rozwoju nie polega na określaniu wymagań.

Zamiast tego muszą początkowo określić jak najwięcej, aw razie potrzeby zmienić później. Następnie dzielisz swoją pracę na części i wdrażasz w iteracjach. Po każdej iteracji masz coś ukończonego.

Różnica w rozwoju wodospadu polega na rozwoju wodospadu, wszystko jest implementowane z początkowymi wymaganiami i zmieniane na końcu.

Wygląda na to, że programiści zostali całkowicie usunięci z tworzenia historii użytkowników. Czy spodziewasz się, że będziesz w stanie przeczytać je jak szczegółową specyfikację i zbudować ją za pierwszym razem? Jeśli możesz to zrobić, nie potrzebujesz XP ani żadnej innej zwinnej metodologii.

Ktoś powinien zadawać pytania, jeśli historia jest zbyt niejasna. Gdzie odbywa się test akceptacyjny ?

Historie użytkowników mają ulec zmianie. Musisz sobie z tym poradzić.

Chociaż programista mógłby napisać historię / szczegółowe wymagania, nie widziałem wielu, którzy są w tym dobrzy. jesteśmy dobrzy w wskazywaniu problemów, sugerując lepsze przepływy, ale jako wkład do już dobrze napisanej sprawy.

Pracowaliśmy nad nowymi i istniejącymi produktami, przy czym w obu przypadkach były wymagania, w których tylko 5- wiersze i oczekiwano, że wypełnimy puste pola i sporządzimy „zrozumiały” lub bardziej skomplikowany dokument.

Projekty potoczyły się znacznie lepiej niż nasz profesjonalny pracownik, który pomógł w tym (lub w jednym przypadku wiceprezes, który przyłączył się, ponieważ nie było nikogo innego dostępnego). Tak czy inaczej jest to strata czasu na rozwój (chyba że nie wróci żadna informacja zwrotna, a termin się nie zmieni). więc moja sugestia: poproś o więcej szczegółów, podaj więcej, poproś o czasowe informacje zwrotne na temat twoich założeń i dokumentacji oraz oświadcz, że istnieje ryzyko, że nastąpi poprawka i opóźnienia, jeśli nie otrzymasz tych informacji przed datą x.

Bez względu na metodologię programowania, jeśli cokolwiek używasz do zdefiniowania wymagań, sprawia, że ​​deweloper przyjmuje założenia, należy przenieść je z powrotem na stronę biznesową. Często mam dobre pojęcie o tym, jaką odpowiedź wolałbym, więc odsuwam takie rzeczy:

XYZ jest dla mnie niejasny. Czy to znaczy ABC? A może coś mi brakuje? (Załóżmy, że XYZ jest wymaganiem, załóżmy, że ABC jest założeniem, które chciałbym poczynić jako programista)

Zajmuje o wiele mniej czasu, zanim wszystko zostanie wyjaśnione, zanim podejmiesz złe założenia, niż powtórzysz. Programiści, którzy odgadują wymagania, nie uzyskując potwierdzenia, że ​​ich domysły są słuszne, zwykle są złymi programistami i kosztują swoją firmę dużo pieniędzy. Jeśli zły menedżer nie pozwoli ci odrzucić rzeczy, to wytłumacz mu, ile jest droższy pod względem czasu i pieniędzy, aby zrobić to źle. Jeśli nadal nalega, zrób to, co mówi, a gdy zawiedzie UAT, następnym razem, gdy chcesz coś odrzucić, przypomnij mu, jak kosztowny był czas, kiedy ci nie pozwolił. Jeśli nadal nie chce słuchać, znajdź lepszego szefa.

Inną zaletą przywracania rzeczy jest to, że stopniowo firma nauczy się tego, czego potrzebujesz i da ci lepsze wymagania.

Jako deweloper,

Muszę w pełni zrozumieć specyfikę historii użytkownika,

dzięki czemu mogę pewnie ją oszacować i wdrożyć.

Innymi słowy, musisz zadawać pytania, dopóki nie zrozumiesz szczegółów tej historii. Odbywa się to w planowaniu iteracji i działa jako punkt decyzyjny: jeśli nie możesz go oszacować, nie możesz go zbudować.