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.
źródło
Odpowiedzi:
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.
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.
źródło
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.
źródło
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ą .
źródło
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.
źródło