Wady pionowych historii użytkowników

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.

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.

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.

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.

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.