Zaplecze twórców zapisane przez historie użytkowników

10

Planowałem podzielić rozwój backendów na historie użytkowników w pionie. Ale facet z naszego zespołu zaczął narzekać, że to czyni ich pracę niewidoczną.

Moja odpowiedź brzmiała:

na spotkaniach dotyczących planowania i przeglądu sprintu omawiamy zadania zaplecza przed interesariuszami, aby było to widoczne, oraz
utrzymanie wysokiej jakości podczas projektu spowoduje wolniejsze tempo początkowe niż w przypadku innych zespołów, ale będziemy mieć stałą prędkość podczas projektu. A prędkość jest bardzo widoczna dla interesariuszy.

Nadal nalega na takie historie: „Jako programista muszę mieć warstwę domen, aby móc zawrzeć logikę biznesową”.

Jak mogę rozwiązać problem, zanim zanieczyści zespół?

Przyczyną problemu jest to, że nasze kierownictwo systematycznie uważa pracę zaplecza za niewidoczną i wywołuje programistów, lub innych pejoratywnych terminów.

— Szili
źródło

7

Nie mam historii backendów, nie mają one sensu .. Jednak nie chciałbym mieć tego rodzaju menedżerów .. Myślałem, że backend devs byli kiedyś

— gwiazdami

2

Tworzenie osobnych historii zaplecza oznacza, że prace zaplecza mogą być traktowane priorytetowo niezależnie od interfejsu użytkownika. Istnieje ryzyko, że priorytety zostaną przypisane w taki sposób, że praca zaplecza zostanie sprowadzona do dolnej części zaległości, dopóki nie zostanie ponownie włączona do historii frontonu. Jeśli chodzi o problem z brakiem uznania ze strony kierownictwa, polecam, aby o to zapytać w Workplace.SE.

— Bart van Ingen Schenau

Moje fantastyczne rozwiązanie polega na sporadycznym uderzaniu wszystkich stron. klaps Przestań marudzić. klaps Przestań ignorować niezwykle ważną rolę, jaką dane i logika biznesowa przyczyniają się do sukcesu firmy, która płaci nasz czynsz. klaps Przestań jeść obiady innych ludzi. To nie jest lodówka twojej mamy.

— Erik Reppen

1

pokrój tematy pionowo, a następnie pokrój powstałe historie na zadania horyzontalne.

— jwenting

5

W opisanej sytuacji jest kilka rzeczy źle, oczywistym problemem jest brak szacunku dla programistów zaplecza. Ponieważ to pytanie jest oznaczone jako zwinne, zamierzam odpowiedzieć na inne odpowiedzi sugerujące, że jest to tylko problem społeczny. W twojej historii jest kilka nieprzyjemnych zapachów i możliwych anty-wzorów, z których żaden nie ma związku z nieświadomym zarządzaniem, a nawet z tym, jak kroisz historie.

Fakt, że grupa osób w zespole czuje się lekceważona za to, że nie czerpała chwały z pracy, dopełniła kilku możliwych problemów.

Nie powinny istnieć osoby, które zajmują się jedynie rozwojem zaplecza. Powszechnym podejściem zwinnym jest tworzenie zespołów interdyscyplinarnych składających się z uogólniających specjalistów, którzy praktykują współdzielenie kodu. Osoby nie powinny koncentrować się wyłącznie na rozwoju zaplecza lub frontu, chociaż z pewnością będą bardziej doświadczone lub lepsze w niektórych sprawach niż w innych.
Architektura nie zarabia na wartości. Z perspektywy użytkownika - jedynej perspektywy, która naprawdę ma znaczenie - nie ma znaczenia, czy masz warstwy lub języki domeny, a nawet, czy rozwiązanie jest zaprogramowane. Liczy się tylko to, czy stworzysz wartość dla użytkowników. Proponowana „historia” od dewelopera zaplecza jest nonsensem - jest to streszczenie decyzji projektowych, które z punktu widzenia użytkownika / klienta nie robią nic, aby osiągnąć pożądaną funkcjonalność. Innymi słowy, dowolna historia użytkownika może zostać osiągnięta przez dowolną liczbę różnych projektów architektury. Możliwe jest, że historia użytkownika może zostać ukończona bez modyfikacji zaplecza. Nie oznacza to, że jest to nieprawidłowa historia.
Systematyczne myślenie jest nadal krytyczne. Chociaż architektura może nie zarabiać na wartości, wciąż ma kluczowe znaczenie dla sukcesu. Deweloper zaplecza ma pewne ważne obawy. Powinieneś pomyśleć o tym, jak zbudujesz system. Powinieneś zapisać te decyzje. Cały system jest ważny, nawet jeśli tylko funkcje front-endu otrzymają całą chwałę.

Radzę traktować architekturę jako obywatela pierwszej klasy - ale rób to we właściwy sposób. Przeprowadź warsztaty dotyczące atrybutów jakości z interesariuszami . Angażuj kluczowych interesariuszy w przeglądy architektury lub przynajmniej podsumowuj kluczowe decyzje projektowe na ważnych etapach. Narysuj architekturę na dużym papierze i spraw, aby była widoczna, aby cały zespół mógł ją zobaczyć.

Wymagaj, aby wszyscy rozwijali się w dowolnym miejscu w systemie (front-end i back-end), w razie potrzeby sparuj program, aby było to możliwe. Kontynuuj tworzenie zorientowanych na użytkownika historii użytkowników. Ale także zidentyfikuj kluczowe scenariusze atrybutów jakości, które pokazują, dlaczego system został zaprojektowany w taki sposób, w jaki jest, i stymulują podejmowanie decyzji dotyczących projektu „zaplecza”. Podnieś wygląd architektury, aby nie była już niewidoczna.

— Michał
źródło

1

Dziękujemy za wykonalną odpowiedź! Chciałbym wyjaśnić trochę zrozumienia wynikającego z mojego złego sformułowania. On nie jest tylko „backend dev”, w rzeczywistości pracuje nad całym stosem, nawet w oprogramowaniu układowym. Boli go architektura backendowa, która nie jest odpowiednio rozpoznawana. I chociaż architektura sama w sobie nie zarabia, niechlujna architektura może zepsuć systemy lub przynajmniej spowodować, że będą one bardzo kosztowne w utrzymaniu. Moim planem było ułatwienie rozmów na temat architektury podczas spotkań przeglądowych i planistycznych, a warsztaty wysokiej jakości również wyglądają jak świetne narzędzie!

— Szili

FWIW, nie zawsze jest praktyczne, aby programista pracował na pełnym stosie. Jednym z wymagań mojej obecnej firmy może być opracowanie CICS na komputerach mainframe IBM, MQ, Java w Mule ESB, Datapower, a na końcu rozbudowany interfejs WWW z jquery i innymi szablonami. Inna historia użytkownika może obejmować CORBA rozmawiającą przez VMS COBOL, a inny backend jest napisany w Gupcie.

— Alan Shutko

@AlanShutko - dokładnie. „Fronton jednej osoby jest back-endem innej osoby”, prawda? Jest to jeden z powodów, dla których nie lubię slangu typu „back end” i „front end”, zwłaszcza gdy mówimy o wielu komponentach w systemie. Twój punkt jest niezwykle ważny! Nawet „pełny stos” jest terminem względnym, który może oznaczać różne rzeczy w różnych częściach systemu!

— Michael

11

To wydaje się być problemem społecznym, więc będzie wymagało rozwiązania społecznego.

Jeśli (jak rozumiem) programiści zaplecza czują się ignorowani i lekceważeni, i czują, że ich praca nie jest wystarczająco ceniona, wówczas proces programowania może niewiele zrobić, aby to zmienić.

Jeśli dobrze rozumiem, wygląda na to, że deweloperzy uważają, że powinni mieć przynajmniej „własne” historie użytkowników, aby mogli wskazać na nie i powiedzieć: „To właśnie zrobiliśmy, tylko nas backend chłopaki / dziewczęta”. Jednak opowiadanie w taki sposób „poziomo” jest złym pomysłem i zgadzam się z tobą, aby pokroić je w pionie.

Najlepszym rozwiązaniem jest prawdopodobnie cicha rozmowa z danym deweloperem (programistami) (indywidualnie lub w grupie) i rozwiązanie podstawowego problemu, który wydaje się budzić szacunek. W pewnym momencie prawdopodobnie będzie to wymagało eskalacji do zarządzania.

— Śleske
źródło

Dziękuję za odpowiedzi. Problem jest rzeczywiście społeczny. Dzisiaj rozmawialiśmy o wczorajszym sporze, a wspomniany deweloper powiedział mi, że chodzi raczej o lata systematycznego braku szacunku dla jego zaplecza, niż o jego pogląd na nasz obecny projekt i jego zrozumienie procesu scrum. Uzgodniliśmy, że pójdziemy naprzód z historiami pokrojonymi pionowo.

— Szili

1

@Szili: Czy backend działa tak źle, że nie zasługuje na szacunek, czy po prostu zaznacza, że nie zostaje rozpoznany?

— Blrfl

Jego praca backendowa jest doskonała. Problemem jest prawidłowe rozpoznawanie, a nawet nękanie w zarządzaniu.

— Szili

4

Przyczyną problemu jest to, że nasze kierownictwo systematycznie uważa pracę zaplecza za niewidoczną i wywołuje programistów, lub innych pejoratywnych terminów.

Rzeczywiście to jest problem. To oczywiste, że nie rozwiążesz tego za pomocą historii!

Ogólnie rzecz biorąc, jedną z cech zwinnego rozwoju jest przejrzystość. Oznacza to również, że sprawia, że problemy organizacyjne stają się bardziej widoczne .

Standardowym zwinnym rozwiązaniem tego problemu jest przyjęcie bardziej „pionowego” lub „pełnego stosu” podejścia do rozwoju, w którym twórcy backendu opowiadają historie od góry do dołu, zamiast po prostu pracować w strefie komfortu warstwy zaplecza, oraz frontend devs podobnie rozciągają się w kierunku backendu (*).

Innymi słowy: spraw, aby wszyscy wytwarzali wartość dla użytkowników końcowych.

^{(*) Uwaga: nie wszystkie historie muszą zawierać komponent front-end lub back-end. Elementy interfejsu użytkownika można przetasować bez dodatkowej pracy zaplecza, a wydajność jest cechą .}

— Sklivvz
źródło

3

Wygląda na to, że nie rozumiesz rozwoju backendu. Zobacz, jak niewielka jest wartość dobrego faceta zaplecza, gdy faceci frontonu wykonują wszystkie modelowanie danych i implementację logiki w frontonie, a następnie czekają sześć miesięcy. Większość dobrych inżynierii nie jest dobra w generowaniu natychmiastowej wartości, chodzi o generowanie długoterminowych dywidend. Twoje podejście zastosowane do budowy mostów sprawiłoby, że każdy most stałby tylko na tydzień i nie miałby projektu ani architekta, ponieważ nie są one bezpośrednią wartością.

— Jimmy Hoffa

1

Nie @ JimmyHoffa Jestem całkiem obeznany z programowaniem back-end. Moja odpowiedź jest dość zwinna. Jak można zauważyć, nie zalecam posiadania tylko ludzi z frontu. Jeśli nie lubisz zwinnych, nie używaj go, ale po prostu opisuję, jak działa metodologia, więc nie zakładaj niczego o mnie ani nic innego.

— Sklivvz

2

Część, w której zbacza z tropu, polega na tym, że mówisz, że faceci z zaplecza nie wytwarzają wartości i powinni po prostu wykonywać prace front-end, jeśli nie jest to twoja intencja w tej odpowiedzi, powinieneś naprawdę przeredagować to, aby było bardziej jasne co masz na myśli?

— Jimmy Hoffa

1

@JimmyHoffa Ale nie wytwarzają żadnej wartości dla użytkownika końcowego. Gdyby to był zespół tylko programistów zaplecza, użytkownicy byliby programistami frontonu. W takim przypadku twoje rozumowanie miałoby sens, ale wydaje się, że tak nie jest.

— Sklivvz

1

Jeśli w twoim świecie wartość jest wytwarzana tylko przez stworzenie produktu interaktywnego dla użytkownika, a programiści nie są do tego potrzebni, wtedy w twoim świecie najwyraźniej architekci i kierownicy projektów, analitycy biznesowi, HR i wszyscy inni są nieistotni. W moim świecie wartość jest wytwarzana przez jakość projektowania i wdrażania systemów, tak że przyszły rozwój funkcji nie wymaga wędrowania przez pajęczą bazę danych dostępu, ponieważ ceniony był tylko produkt możliwy do interakcji z użytkownikiem ... Wdrożenie jakości jest wartością . Może nie od razu, ale na dłuższą metę.

— Jimmy Hoffa

1

Twoje problemy to:

W swoim biznesie masz warstwy zarządzania, w których nie służą one żadnemu celowi. Scrum, zwinny, nie obchodzi mnie to. Zarządzanie i rozwój powinny być izolowane, a problemy biznesowe powinny być rozwiązywane przez kierownika produktu, który ma pomysł! @ # $ Ing na temat technologii. Być może zadziałało to dla Steve'a Jobsa, ale nigdy nie byłem w sytuacji, w której menedżerowie bez wiedzy technicznej, będąc blisko dewelopera, byli zdrowi lub ostatecznie służyli do wytworzenia produktu najlepszej jakości, jaki zespół mógł stworzyć.
Masz deweloperów, którzy bardziej martwią się wyglądem niż rozwiązywaniem problemów. Jest to albo bardzo poważny problem kulturowy (wydaje się prawdopodobne, biorąc pod uwagę to całe zjawisko „górnika”) i / lub masz problem z jakością dewelopera, który również mnie nie zaskoczy, biorąc pod uwagę brak pewności siebie.

Wyciągnij ludzi, którzy nie muszą tam być, z planowania i gotowości. Każdy, kto ma pojęcie o tym, że back-end jest mniej ważny niż front-end, to ktoś, kto nie musi tam być i faktycznie utrudnia ten proces.

Historie rowów. Tak jestem poważny. Jeśli powodują tego rodzaju problemy, wyrzuć je ze śluzy. W mojej obecnej pracy po prostu trzymamy się kryteriów „wykonanych” dla danego zadania, które zazwyczaj bardziej skupiają się na aplikacji niż na jej użytkowniku, co może obrażać tych, którzy myślą, że zwinny (który ciągle się zmienia od 20 lat) wygrał ” działa, jeśli nie zastosujesz się do litery, ale tak naprawdę, jeśli jesteśmy zawodowcami, nie potrzebujemy niczego, co przysporzy nam problemów. Zmiażdż je, przerzuć przez ramię.

I możesz przypomnieć temu deweloperowi, że ludzie, o których tak naprawdę powinni się martwić, są ich najbliższymi rówieśnikami, a nie ludźmi, którzy są zbyt nieświadomi, aby planować sprint.

— Erik Reppen
źródło

Dobra rada. Pamiętaj, że w zwinnym manifeście nie ma nic o „historiach użytkowników” i są one po prostu popularną praktyką, która pojawiła się przy określonych procesach. Możesz być tak zwinny dzięki opowieściom użytkowników, jak bez…

— Michael

To prawda. Nie jestem pewien, czy zwinny manifest zostałby uznany za wystarczający, aby „robić to dobrze” według wielu standardów całej branży szkoleniowej, które zostały wokół niego zbudowane, ale jak zawsze pomysły i które z nich mają sens dla ciebie i Twój zespół powinien mieć pierwszeństwo przed wpływami, IMO. Otrzymasz również tyle odpowiedzi z tego frontu na temat tego, jak „sprawnie postępować” poprawnie, jak pytając studentów college'u, jakie są zasady randkowania. Nie ma substytutu dla krytycznego myślenia.

— Erik Reppen

Nie porzuciłbym historii użytkowników. Właściwie ciężko pracuję, aby je przedstawić, ponieważ mamy tradycję lekceważenia użytkowników końcowych. Analogia Steve'a Jobsa jest bardzo trafna, ponieważ nasz CEO jest genialnym facetem technicznym, który uruchomił wielomilionową firmę. Jedyną rzeczą, na której mu się nie udało, było zbudowanie warstwy menedżerskiej, więc był bardzo zaangażowany w wykonywaną pracę. Dało to początek pojawieniu się kultury gwiezdnej, co powoduje obawy o wygląd. Podsumowując: mamy problem kulturowy. Ale biorąc to pod uwagę, potrzebuję narzędzi takich jak te w odpowiedzi, aby kroki dziecka były potrzebne.

— Szili

Tak czy inaczej, poleciłbym doświadczonego programistę do zatrzymywania analiów, jeśli masz problemy z UX. Nie ma substytutu, z wyjątkiem niektórych wspaniałych generalistów, z których niewielu kiedykolwiek chciałoby zapłacić pełny zespół.

— Erik Reppen