Wady pionowych historii użytkowników

9

Zwinne podejście jest zorganizować pracę do pionowych historie użytkowników i dostarczać skoncentrowane, ale w pełni funkcjonującego kawałek z aplikacją typu koniec-koniec . Ponieważ jest to nowe podejście do tworzenia oprogramowania, czytam dużo literatury na temat tego, dlaczego jest to lepsze niż historie horyzontalne, ale nie znajduję wiele o wadach tego podejścia.

Już wypiłem zwinny płyn chłodzący i ja również zgadzam się, że krojenie ciasta w pionie ma wiele zalet w porównaniu z krojeniem poziomym. Oto krótka lista wad, które mógłbym wymyślić:

  • Deweloper może początkowo spowolnić wdrażanie funkcji, ponieważ musi zrozumieć wszystkie technologie wymagane do opracowania historii (interfejs użytkownika + warstwa usługowa + dostęp do danych + sieć itp.)
  • Ogólny projekt architektury (tworzenie szkieletu aplikacji) tak naprawdę nie pasuje do tej mantry (jednak niektórzy mogą argumentować, że rozwijanie / zmiana ogólnej architektury jest częścią historii użytkownika)

Jakie są jeszcze inne wady wycinania historii użytkowników w pionie?

Uwaga: Powodem, dla którego zadaję to pytanie, jest to, że zamierzam przekonać zespół, aby zaczął pisać historie w „pionowy sposób”, a ja chcę mieć możliwość wcześniejszego przedstawienia ewentualnych kompromisów, aby wygrały nie uważają tego podejścia za porażkę, gdy mają one wady.

c_maker
źródło
Nie rozumiem, w jaki sposób wymienione dwa punkty są wadami. Mówisz, że może być powolny, ale równie dobrze nie. Co rozumiesz przez ogólną architekturę, która nie pasuje? Znowu może pasować lepiej.
Dave Hillier
@DaveHillier: Jest sformułowany w taki sposób, że jest wadą. Na przykład firma może pomyśleć, że „powolny” czas wdrożenia jest wadą.
c_maker
Chcesz powiedzieć, że firma postrzega to jako wolniejsze?
Dave Hillier
Czy „przekrój pionowy” jest zasadniczo tym samym, co „problem przekrojowy”?
Robert Harvey
1
Jest bardzo dobry artykuł na temat historycznych i poziomych historii użytkowników, który szczegółowo opisuje zalety i wady każdego z nich, tutaj: deltamatrix.com/...
Robert Harvey

Odpowiedzi:

7

Nie znam żadnych długoterminowych wad. W perspektywie krótkoterminowej, a dla zespołu nowego w tego rodzaju rozwoju, główną wadą jest to, że trzeba się przyzwyczaić i trochę się nauczyć.

Najbardziej efektywnym sposobem pracy w pionie jest posiadanie programistów z pełnym stosem: w ten sposób historia może być zazwyczaj wykonana przez jedną osobę (lub więcej niż jedną, ale bez zadań związanych z potokowaniem ). Oczywiście wymaga to, aby programiści pracowali pionowo na stosie (od html do bazy danych w przypadku aplikacji internetowej).

Jeśli Twój zespół nie jest przyzwyczajony do pracy nad historiami wertykalnymi, najprawdopodobniej robią to odwrotnie: każda osoba będzie miała wiedzę tylko o jednej warstwie / warstwie aplikacji. Po wprowadzeniu historii pionowych można oczekiwać, że zespół podzieli je na zadania odpowiadające warstwom, a następnie rozdzieli zadania między różne osoby. To będzie bardzo nieefektywne.

Najlepszym podejściem, jakie mogę tu podać, jest początkowo tolerowanie tego potoku, przy jednoczesnym wyraźnym zaznaczeniu, że długoterminowy cel jest zupełnie inny. Niech członkowie zespołu na różnych warstwach sparują program, aby zbudować zaufanie i ostatecznie umożliwić ludziom całkowitą niezależność.

Nie zgadzam się z drugą odpowiedzią, że takie podejście powoduje dług techniczny. Może, ale każde inne podejście może.

Sklivvz
źródło
Spróbowałbym programowania w parach. Umożliwi to ludziom zdobycie wiedzy na temat innych potrzebnych im domen i pomoże uniknąć potoków.
user99561
7

Dużo myślałem o tym właśnie pytaniu.

Myślę, że ważne jest, aby rozróżniać podział na poszczególne obowiązki od podziału na obowiązki zespołowe. Skoncentruję tę odpowiedź głównie na zespołach krojenia.

Dla pewnego tła: pracowałem w projektach z programistami z pełnym stosem, programistami z jednym poziomem, zespołami pionowymi (z pełnym stosem), zespołami poziomymi (z jednym poziomem) i zespołami ukośnymi. Przez zespół diagonalny rozumiem, że zawiera wszystkie poziomy potrzebne do opowieści, ale niekoniecznie wszystkie poziomy w systemie, a także prawdopodobnie zawiera wielu programistów skupiających się na tych samych poziomach; innymi słowy w pionie w duchu, ale może nieco poziomo w wyglądzie lub w szczegółach wykonania.

Ostatnio pracowałem w grupie, która przekształciła się z zespołów poziomych w zespoły diagonalne (prawie pionowe). Szczególnie pouczające było obserwowanie tej samej grupy ludzi na dwa różne sposoby. To sprawia, że ​​niektóre zalety i wady są dość wyraźne.

Uzupełnię moją dotychczasową opinię następującym podsumowaniem:

Zespoły poziome

Zalety:

  • Pomaga w dobrym rozdzieleniu problemów i luźno powiązanych poziomów
  • Znacznie łatwiejsze zarządzanie dystrybucją obciążenia
  • Łatwy w obsłudze specjalistyczny przewodnik techniczny
  • Wspiera współpracę między poziomami, najlepsze praktyki, dumę i kulturę doskonałości
  • Dopasowuje się do naturalnych / pojawiających się wzorców komunikacji

Niedogodności:

  • Może prowadzić do izolacji poziomów, a tym samym utrudniać komunikację między poziomami
  • Włącza kulturę „bąbelkową” poziomu, jeśli nie jest narzucona
  • Trudno skorzystać z przywództwa ogólnego
  • Utrudnia generalistów

Zespoły pionowe / ukośne

Zalety:

  • Wszystkie części historii użytkownika w jednym zespole („one stop shop”)
  • W szczególności pomaga dostarczać historie n-tier w jednym sprincie (chociaż czy naprawdę tego potrzebujesz?)
  • Wspiera współpracę między poziomami i rozwój umiejętności ogólnych
  • Wspiera generalistów

Niedogodności:

  • Znacznie trudniejsze zarządzanie dystrybucją obciążenia
  • Umożliwia słabą separację problemów i ściśle powiązane poziomy
  • Utrudnia specjalizację poprzez ograniczenie komunikacji między poziomami; trudno jest zobaczyć, jak kultura doskonałości mogłaby powstać z tej struktury bez dodawania łagodzących zachowań horyzontalnych / specjalistycznych

Nie sądzę, aby członkostwo w zespole miało jedno uniwersalne rozwiązanie. Wydaje się jednak dość proste, że pionowy zespół jest lepszy dla organizacji wymagających uogólnienia. Jeśli twoi inżynierowie są generalistami i lubią pracować na pełnym stosie, to całkiem dobry powód, aby rozważyć zespoły pionowe. Zespół poziomy jest lepiej dopasowany do organizacji wymagających specjalistów. Jeśli twoi inżynierowie są specjalistami, to całkiem dobry powód, aby rozważyć poziome zespoły.

Jak wspomnieli inni, drugorzędne struktury / zachowania, które przecinają drugi kierunek, mogą pomóc złagodzić wady obu systemów. Jednym z interesujących czynników łagodzących jest czas trwania sprintu. Krótkie sprinty sprawiają, że niektóre wady zespołów poziomych są bardziej tolerowane. Jeśli możesz zbudować backend w tym tygodniu, a frontend w przyszłym tygodniu, może to być wystarczająco szybkie?

Aby zastosować niektóre z tych proponowanych zasad do rzeczywistego problemu ... Powiem, że przekroje poziome działały całkiem dobrze dla bardzo prawdziwego zespołu programistów SaaS, nad którym pracowałem, rozwiązując bardzo trudne problemy techniczne na każdym poziomie ( gdzie specjalizacja była moim zdaniem niezwykle ważna), gdzie częstotliwość dostaw (i niezawodność przy wysokiej szczegółowości / częstotliwości) była kluczowa dla sukcesu firmy. Należy pamiętać, że ten wniosek dotyczy bardzo konkretnego zespołu w świecie rzeczywistym, a nie ogólne stwierdzenie wyższości cięcia poziomego.

Jedno zastrzeżenie: prawdopodobnie jestem stronniczy w stosunku do przekonania o zdolnościach ogólnych u dowolnej osoby we współczesnym świecie tworzenia oprogramowania bez znaczącego dowodu, chociaż znam kilku rzadkich wyjątkowych generalistów. Wydaje mi się, że ogólność jest rzeczywiście wysokim (pionowym?) Porządkiem, szczególnie gdy każdy poziom rośnie w złożoności, a wraz z rozprzestrzenianiem się alternatywnych języków / platform / platform / wdrożeń, każdy spełnia inne potrzeby. W dzisiejszych czasach jack wszystkich transakcji może z łatwością być mistrzem żadnego. Co więcej, anegdotycznie stwierdzam, że większość osób chce się trochę specjalizować, również z pewnymi wyjątkami.

Będzie
źródło
Twoja analiza tutaj jest świetna i pasuje do tego, czego doświadczyłem. Nie zgadzam się, że zespoły horyzontalne mogą „utrudniać komunikację zależności między poziomami”: Powiedziałbym, że separacja pozioma sprawia, że ​​potrzeba wyraźnego kontraktu między poziomami jest jasna i oczywista. Po przeciwnej stronie zauważasz, że pionowe drużyny mogą prowadzić do ściśle powiązanych poziomów. Wreszcie, zgadzam się, że twierdzenia o zdolnościach ogólnych są prawie zawsze przesadzone (widziałem wiele naprawdę okropnych projektów zaplecza wykonanych przez „generalistów”, którzy naprawdę powinni trzymać się front-endu).
SebTHU,
Dobra uwaga, @SebTHU. Treść mojego pierwszego pocisku na temat wad zespołów poziomych w „utrudnianiu komunikacji ...” była niejasna. Chciałem zauważyć, że zespoły poziome mogą potencjalnie prowadzić do izolacji między poziomami, a tym samym utrudniać komunikację między poziomami. Jednak, o ile ci chodzi, może rzucić jasne światło na potrzebę wyraźnych kontraktów i rzeczywiście być funkcją wymuszającą prawidłowe określanie kontraktów. Zaktualizowałem tę część mojej odpowiedzi, aby wyjaśnić mój zamiar.
Czy
@Czy na podstawie tego „znacznie trudniejsze zarządzanie dystrybucją obciążenia”? Jeden facet wyciągający jedną historię i łączący wszystkie elementy wydaje mi się naprawdę prosty i skuteczny. „Umożliwia słabą separację problemów i ściśle powiązane poziomy”, kto mówi, że jest to bardziej prawdopodobne w zespole pionowym niż w hoz? Jeśli twój zespół jest zdyscyplinowany (co moim zdaniem jest wymagane od obu typów zespołów), nie powinno to stanowić problemu.
cottsak
6

Dużą wadą, którą znalazłem, jest to, że utrudnia zespołowi tworzenie aplikacji zgodnie z ujednoliconym podejściem architektonicznym.

Na wczesnych etapach projektu wszyscy będą pisać swoje warstwy w izolacji. Historie (i zaangażowane warstwy) zadziałają, ale patrząc wstecz na dostarczony produkt na końcu sprintu łatwo będzie zauważyć niewielkie różnice między pomysłami architektonicznymi każdego dewelopera.

Tego rodzaju rzeczy są nieuniknione, ale nie blokują. Próbowałem z tym walczyć na dwa sposoby:

  1. Przed wdrożeniem każdej historii przedyskutuj z zespołem długie dyskusje na temat projektu
    • Szybko się męczy. Często jest za wcześnie, aby ktokolwiek podejmował świadomą decyzję, a potem po prostu spierasz się o rzeczy, które i tak na pewno będą musiały się zmienić.
  2. Śmiało i rozwijaj się we względnej izolacji, pamiętając, że narastasz dług techniczny .
    • Kluczem tutaj jest zarejestrowanie długu technicznego (architektonicznego) jako problemu. Jest to coś, co trzeba będzie spłacić.
    • Po kilku sprintach łatwiej będzie zdecydować się na spójną i zunifikowaną architekturę. Wtedy powinieneś poprosić o sprint hartowniczy, aby spłacić część swojego długu technicznego (przerób istniejący kod). Alternatywnie możesz spłacić go fragmentarycznie podczas kolejnych iteracji projektu.

Jedynym innym problemem, jaki mogę wymyślić poza tym, jest to, że zwykle na początku projektu jest dużo kodu do dodania. Pisanie opowiadań o pionowych przekrojach oznacza, że ​​prędkość zespołu na pierwszych kilku opowiadaniach będzie sztucznie niska z powodu tego niezbędnego bojlera ... ale dopóki wszyscy są świadomi, że powinno to wpłynąć tylko na kilka pierwszych sprintu, wszystko jest w porządku.

MetaFight
źródło
2
Jak wynika to z faktu, że pracując niezależnie tworzysz dług techniczny? Wydaje się, że niekoniecznie tak jest
Sklivvz
To nie koniecznie sprawa, ale nie zwiększa jej prawdopodobieństwo. Weźmy na przykład duplikację kodu. Jeśli niektóre techniczne warunki domeny nie są jeszcze zestalone, dwóch deweloperów może napisać tę samą funkcjonalność w dwóch oddzielnych klasach. Jedyna różnica polega na tym, że jeden twórca nazwał to a, WobbleAdaptera drugi a WibbleConverter.
MetaFight,
3
Nie wyjaśniasz, dlaczego te problemy są bardziej prawdopodobne podczas dzielenia pracy w warstwach lub w pionie. I dlaczego miałbyś pisać wiele bojlerów w pierwszych iteracjach? Brzmi jak YAGNI
Dave Hillier
Niestety, przypuszczam, że płyta kotłowa to zły termin. Chodzi mi tylko o to, że ponieważ w pierwszych kilku sprintach trzeba będzie stworzyć wiele klas infrastruktury projektu, wiąże się to z jednorazowym kosztem.
MetaFight,
1
A dzielenie pracy w pionowe plastry oznacza, że ​​każda historia dotyka większej liczby warstw. Zwiększa to szansę, że dwóch programistów koduje części tej samej warstwy we względnej izolacji. Co może prowadzić do niedopasowanych podejść do wdrażania. ... wydaje się to bardzo abstrakcyjne ... Jestem skłonny zgodzić się, co sugeruję, może być względnie mało prawdopodobne!
MetaFight,
4

Nie znam też wad, ale historie pionowe mogą być źle wdrażane.

Kiedy zaczynałem karierę, dołączyłem do zespołu, który chciał zdobyć XP, ale nie mieli z tym doświadczenia. Popełnialiśmy wiele błędów podczas korzystania z pionowych historii użytkowników.

Jednym z problemów, które napotkaliśmy podczas pracy w poziomie, było to, że funkcje nie integrowały się dobrze na warstwach. Interfejsy API często nie pasowały do ​​specyfikacji, brakujących funkcji i wielu innych problemów. Często, ponieważ twórca gry przeniósł się na coś innego, musiałbyś albo na nich poczekać, albo zrobić to sam.

Przejście do robienia pionowych historii rozwiązało te problemy i zmniejszyło / wyeliminowało marnotrawstwo ponownej pracy w celu integracji.

Istnieje wiele praktyk XP, które wspierają ten sposób pracy. Każdy musi mieć możliwość pracy w dowolnym obszarze i każdy powinien naprawić znalezione błędy ( własność kodu zbiorowego ).

Gdy zmieniasz historie pionowe, może być trudna praca w obszarach, których nie znasz. Programowanie w parach może pomóc, jeśli nie masz pewności, złap kogoś w zespole, który się z nimi sparuje. Odkryłem, że programowanie par jest najszybszym sposobem na przyspieszenie dzięki nowej bazie kodu.

Bez silnych właścicieli ponad warstwami stwierdziliśmy, że pojawiło się pewne powielanie. Chociaż nie był to duży problem, musieliśmy się upewnić, że ćwiczyliśmy Refactor Bezlitośnie (z odpowiednimi testami w celu wsparcia).

Chociaż wspominam o wielu problemach, nie sądzę, że przyczyną były wertykalne historie użytkowników. W rzeczywistości problemy stały się bardziej widoczne. Po dokonaniu zmiany problemy nie były już zaciemniane w zespołach lub warstwach aplikacji.

Dave Hillier
źródło