Zespół Scrumowy nie przestrzega zasady YAGNI

13

Na spotkaniu SCRUM zespół ds. Produktu debatował na temat funkcji interfejsu API, która zostanie wykorzystana przez aplikację mobilną. Mieliśmy makietę pokazującą, jak powinien wyglądać ekran i jakie kluczowe elementy powinien on zawierać („układ”).

Na podstawie tego i dyskusji, którą przeprowadziłem z właścicielem produktu, stworzyłem prototyp odpowiedzi API (HAL + JSON). To był bardzo prosty, zgodny z HAL JSON, który nie zrobił nic więcej niż reprezentował rzeczy, które były na makietach. Nie wpłynęły na mnie przyszłe pomysły, które były przewidywane przez ludzi biznesu, ponieważ mają oni tendencję do częstej zmiany swoich pomysłów i zdecydowałem się na minimalistyczne podejście. Moja propozycja została odrzucona przez zespół i przegłosowano mnie 7 do 1.

Zespół postanowił zastosować bardziej złożoną, nie-semantyczną abstrakcyjną strukturę json, która pozwala na większą elastyczność w rozmieszczaniu układu. Wadą tego podejścia jest zestaw jednolitych obiektów, które z założenia mogą mieć właściwości puste i puste. Pomyśleli także, że fajnie byłoby umożliwić testowanie A / B, ale opierało się to tylko na ich przewidywaniach, ponieważ nie mieliśmy takiego wymagania.

Przez większość czasu debatowaliśmy o rzeczach, które nie były częścią sprintu ani nie były wymienione na makietach. Opisane problemy to „co jeśli marketing w przyszłości będzie…”, „co jeśli firma może chcieć od nas…”.

Ja i właściciel produktu jesteśmy doświadczonymi programistami. W przeszłości mieliśmy tego rodzaju problemy. Staramy się przestrzegać zasad YAGNI i KISS . Reszta zespołu jest nieco mniej doświadczona i chociaż znają te zasady, wydają się ich nie rozumieć.

Uzgodniliśmy ich rozwiązanie, ponieważ zespół jako całość jest dla nas ważniejszy i nie chcieliśmy walczyć o coś, co nie jest tak ważne. Ale obawiam się, czy coś takiego może stać się precedensem dla nadchodzących, bardziej skomplikowanych debat? Jak radzić sobie z takim zachowaniem? Czy jest coś, co ja, jako lider zespołu, mogę zrobić lepiej?

Warto wspomnieć, że produkt jest MVP na wczesnym etapie.

Jacek Kobus
źródło
11
I'm afraid if such thing can become a precedence for upcoming, more complicated debates?- To także narusza YAGNI: martwienie się o przyszłość, która może się nie wydarzyć. Jeśli miałeś zamiar nie ustępować, powinieneś już to zrobić.
Robert Harvey
@gnat: Nie dotyczy to ograniczeń czasowych.
Robert Harvey
Czy zgodność z HAL nie podlega YAGNI?
Matthew
@Mateusz, cała sprawa zajęła tydzień, a ja również przygotowałem kolejny prototyp przy użyciu zwykłego JSON, aby pozbyć się HAL, ale został również odrzucony jako „niewystarczająco elastyczny”. Zespół zmodyfikował go i ta zmodyfikowana wersja została ostatecznie użyta. HAL działa dla nas jako standard, zbiór wytycznych i łatwiej jest mi egzekwować jednolitą strukturę na wszystkich punktach końcowych. Poprzednie API nie używało żadnych standardów i nie kończyło się dobrze.
Jacek Kobus,
5
Elastyczność dodaje złożoności. Dopóki zespół to rozumie, można iść do przodu.
Jon Raynor,

Odpowiedzi:

10

Czuję twój ból, już tam byłam. IMHO tego rodzaju problemy są spowodowane faktem, że masz zespół 8 osób, który jest już zbyt duży, abyś zawsze mógł podejmować najlepsze strategiczne decyzje.

W zespole liczącym 8 lub więcej szans jest duża liczba miernych programistów jest większa niż liczba doświadczonych. To często prowadzi do sytuacji, w których lepsze decyzje są przegłosowane przez mierne. To nie brzmi zadowalająco, zwłaszcza gdy jesteś (lub myślisz, że jesteś) jednym z bardziej doświadczonych facetów, ale przynajmniej tak samo jest w przypadku naprawdę złych decyzji.

Faktem jest, że niewiele można z tym zrobić, dopóki zespół się nie zmieni , przynajmniej jeśli wszystko pozostanie demokratyczne, więc albo

  • naucz się z tym żyć
  • współpracować z zespołem przez rok lub dwa lata, dzielić się własną wiedzą i mieć nadzieję, że z czasem poznają wartość YAGNI i KISS
  • pracuj nad własnymi umiejętnościami „sprzedaży” projektu lub strategicznych decyzji zespołowi
  • spróbuj przejść do innego (być może mniejszego) zespołu, w którym Twój poziom wiedzy jest zbliżony do średniej dla całego zespołu

Myślę, że jedynym sposobem na poznanie i zrozumienie prawdziwej wartości minimalistycznego podejścia i YAGNI jest skorzystanie z kilku doświadczeń. Na przykład, angażując się w utrzymanie starszego systemu z wieloma błędnymi prognozami „co jeśli”, niewłaściwymi decyzjami projektowymi motywowanymi argumentami „na wszelki wypadek” lub zawierającymi wiele nadmiernie uogólnionego kodu frameworka, który tak naprawdę nigdy nie był potrzebny. Ale nie jest to nic, czego możesz nauczyć członków zespołu w ciągu dwóch dni, niektóre doświadczenia ludzie muszą sami zrobić.

Doktor Brown
źródło
5
Większość ludzi musi dotknąć pieca, aby dowiedzieć się, że jest gorący i nie należy go dotykać. Oprogramowanie jest takie samo. ++
RubberDuck,
2
Prowadzenie dziennika projektu / pamiętnika jest kluczem do tego rodzaju rzeczy. Po zarejestrowaniu różnych dyskusji, które miały miejsce, są one o wiele bardziej konkretne niż wspomnienia rozmów z miesięcy lub lat później. Jest to dobre pytanie na praktyce tutaj .
Robbie Dee,
@RobbieDee: jasne, jeśli to pomoże zespołowi dowiedzieć się o YAGNI i KISS.
Doc Brown
3
Trzecia kula (praca nad własnymi umiejętnościami w zakresie „sprzedaży” projektu) nie przyciąga wystarczającej uwagi. To dlatego programiści nadal muszą mieć dobre umiejętności komunikacyjne (lub pracować nad nimi).
Randall Stewart
@RandallStewart: absolutnie. Ale nawet przy najlepszych umiejętnościach komunikacyjnych sprzedaż YAGNI może być trudna dla ludzi, którzy sami nie zrobili pewnych doświadczeń lub mylą go z „szybkim i brudnym” lub zostali wykształceni, że „abstrakcja jest (zawsze) dobra”, więc spróbuj do abstrakcyjnych rzeczy dla abstrakcji zamiast dla uproszczenia. Komunikacja potrzebuje dwóch stron - jednej, która potrafi dobrze wytłumaczyć i drugiej, która jest gotowa słuchać i rozumieć.
Doc Brown
8

Przekazywanie zgodności jest uzasadnionym problemem

Jeśli jeden z siedmiu deweloperów, którzy głosowali na ciebie, jest architektem, jego prawem jest wprowadzenie NFR w razie potrzeby, a jednym z tych NFR może być „kompatybilność do przodu”, szczególnie gdy wspierasz zdalny komponent systemu, który może mieć bardziej rzadki charakter harmonogram wydania. Nie chcesz, aby użytkownicy musieli instalować nową wersję aplikacji, ponieważ nie pomyślałeś o przyszłości.

Podobnie jak inne wymagania, potrzebujesz kryteriów akceptacji

Biorąc to pod uwagę, wszelkie NFR muszą być udokumentowane jako wymagania i muszą mieć zdefiniowane kryteria akceptacji . Ponadto musisz wymyślić sposób ich przetestowania . Właśnie dlatego YAGNI jest ważny - nie chcesz pisać kodu, którego nie można przetestować, a jeśli jedynym celem tego kodu jest obsługa funkcji, której nikt nie używa, trudno jest go przetestować.

To nie powinno być wezwanie do osądu

Sugeruję, abyś zgodził się, aby zespół zgodził się na niewypowiedziany wymóg, który najwyraźniej spóźniłeś się i go spisał. Po zdefiniowaniu sposobu jego przetestowania wdrożenie powinno zakończyć się co najmniej jednym testem i dlatego nie powinno to być kwestią głosowania.

John Wu
źródło
1
Gdzie w pytaniu czytasz, że zespół PO opuścił ścieżkę YAGNI z powodu wymogu zgodności do przodu?
Dok. Brown
Content-TypeNagłówek jest zgodny z nagłówkiem
Jack
2
Jestem gotów nazwać to czymś innym, jeśli chcesz, może rozszerzalnością. Chodzi o to samo; wciąż jest to NFR.
John Wu
1
Istnieją dwa sposoby na rozszerzenie systemu. Sposób, w jaki ktoś próbuje przewidzieć wiele potencjalnych zmian wymagań i sprawić, by wszystko było wysoce konfigurowalne „na wszelki wypadek”. Jestem pewien, że można wymyślić wiele testów akceptacyjnych dla tego rodzaju rozszerzalności. Lub, utrzymując rzeczy tak proste, jak to możliwe, dzięki czemu podstawa kodu pozostaje niewielka, łatwa do uchwycenia, a punkty rozszerzenia lub abstrakcje można dodać później, gdy są naprawdę potrzebne. To drugie jest niczym, do czego możesz (lub trzeba) pisać testy. Dlatego nie sądzę, że można to łatwo rozwiązać poprzez „zapisanie niewypowiedzianych NFR”…
Doc Brown,
... więc chodzi raczej o to, jak powstrzymać zespół być może kreatywnych programistów od przyjęcia założeń dotyczących NFR i wynalezienia niektórych.
Doc Brown
3

Wygląda na to, że Twój zespół programistów stara się ułatwić zespołowi ds. Produktu, tworząc platformę, która pozwala im na szybkie próby, co najwyraźniej chciałby mieć zespół ds. Produktu. Twoje podejście przypomina raczej „dosłownie dać im to, o co proszą, i nie myśl za nich”.

Gdybym był właścicielem produktu, założę się, że byłbym o wiele szczęśliwszy, gdyby zespół programistów przyjął pierwsze podejście niż drugie.

Martin Maat
źródło
3
+1 przewidywanie i planowanie zmian to nie to samo, co przejście na pełną architekturę astronautów i stworzenie wewnętrznej platformy . Trochę gruntu w tej chwili może zapobiec wielu pracom w przyszłości. Podczas gdy zespół OP może być nieco zbyt pochylony w kierunku hipotetycznych, fundamentalistyczne podejście YAGNI jest z pewnością nieoptymalne.
amon
4
Brzmi bardziej, że z radością przegłosujesz PO i popełnisz te same błędy w planowaniu „a jeśli marketing w przyszłości…” niż reszta zespołu. Kiedy ludzie zaczynają budować frameworki zamiast oprogramowania, gdy zadaniem jest tworzenie oprogramowania, prawie zawsze robią to źle.
Doc Brown
@DocBrown Technicznie zgodziłbym się. Wydaje się jednak, że w tej sprawie chodzi o chęć ułatwienia w porównaniu z wymaganiem osobistego szacunku. Bycie „właściwym” z jednej strony w porównaniu do bycia użytecznym lub pomocnym z drugiej strony. To, co czytałem między wierszami, jest takie, że OP traci grunt i decyduje się podkręcić swoje ego, podkreślając swoje doświadczenie publiczności internetowej, zamiast wkładać się w środowisko, w którym nie czuje się już komfortowo. Ta dynamika jest typowa dla wprowadzenia scrum.
Martin Maat,
@MartinMaat Byłem trochę rozczarowany faktem, że się ze mną nie zgodzili. Nie rozumiem, dlaczego tak się stało. Podczas codziennej pracy pomagam im w recenzowaniu kodu itp. Często się kłócimy, ale podoba mi się to, ponieważ końcowy wynik jest lepszy; Wiem, że szanują moją opinię; Zawsze staram się używać poprawnych argumentów, które wspierają moje teorie. W końcu wybierają najlepszą opcję, a także biorą za nią odpowiedzialność. Zespół zrobił to, co powinien - rozwiązał problem. To był błąd mojego i właściciela produktu, że sprawa była zbyt szeroka i źle opisana od samego początku.
Jacek Kobus,
2

Cóż, moim zdaniem demokracja nie działa właściwie - ani w systemie politycznym, ani w zespole, w którym większość programistów jest młodsza lub przeciętna.

Twoje słowo jako lidera zespołu i jednej z najbardziej doświadczonych osób w zespole powinno mieć większy wpływ niż reszta zespołu. Jeśli YAGNI jest dla Ciebie ważny, powinieneś zrobić prezentację na ten temat. Dyskutuj o tym i pokaż im, dlaczego jest to dobre.

W końcu twoja odpowiedzialność jest wyższa niż za innych ludzi. To nie tylko pisanie kodu, ale także prowadzenie ludzi.

BЈовић
źródło
3
Demokracja jest prawdopodobnie przyczyną problemu, ale brak bycia demokratycznym nie jest rozwiązaniem IMHO, ponieważ może łatwo wprowadzić większe problemy niż te opisane w pytaniu - może zepsuć zespół.
Dok. Brown
@DocBrown Po prostu zaprzeczyłeś sobie w tym samym zdaniu. Niektóre decyzje IMO nie zależą od ludzi. To, co wyjaśniło OP, jest jednym z nich. Cytując Armstronga dla osób, które nie używają YAGNI: Chciałeś banana, ale dostałeś goryla trzymającego banana i całą dżunglę
7овић
2
Nie, to nie jest sprzeczność (może nie wyraziłem dobrze mojej opinii). Rzeczy po prostu nie zawsze są „czarno-białe”. Tylko dlatego, że demokracja nie działa dobrze w niektórych sytuacjach, brak demokracji nie gwarantuje poprawy sytuacji i poprawy sytuacji. Często nie jest to takie proste.
Doc Brown
1
W demokracji niekoniecznie uzyskuje się „właściwą” rzecz, którą osiąga większość ludzi. I to może być wadliwe. I często „właściwa” rzecz ma problem z akceptacją społeczną. YAGNI nie powinny być kajdankami, które utrudniają wprowadzanie odpowiednich abstrakcji, które w razie potrzeby umożliwiają łatwe dodanie „goryla” lub „całej dżungli”.
oopexpert
@ oopexpert Problem polega na tym, że możesz ich potrzebować. YAGNI mówi przeciwko inżynierii. Właściwe abstrakcje to jedno, a dodawanie rzeczy, których możesz nie potrzebować, to różne sprawy.
BЈовић
2

Wydaje się, że jest trochę zamieszanie w YAGNI.

Programiści często myślą, że przestrzegają YAGNI, pomijając abstrakcje, które utrzymają system „zamknięty dla modyfikacji i otwarty dla rozszerzenia”.

O ile nie „rozszerzysz” systemu o „oczywiście” nie wymaganą funkcjonalność, nie będziesz mieć do czynienia z YAGNI. Wprowadzenie abstrakcji, w których może nastąpić rozszerzenie, to już wspomniana „kompatybilność w przód”.

Osobiście uważam, że tylko głęboka znajomość dziedziny pomoże w podejmowaniu decyzji dotyczących abstrakcji i gdzie ją zlokalizować.

oopexpert
źródło
2

Problem z YAGNI I KISS polega na tym, że są one całkowicie subiektywne i niejasne.

Json ?? YAGNI! po prostu wyślij ciąg csv!

przedmioty ?? KISSTUPID !!! po prostu użyj gotos !!

Rola „Team Leader” nie jest dobrze zdefiniowana, ale sugeruję, abyś dystansował się od wyrażania subiektywnych opinii na temat technicznych wyborów twojego zespołu. Nawet jeśli uważasz, że się mylą. Trzymaj się krótkiej listy dobrze zdefiniowanych wymagań.

  • testy jednostkowe kodu
  • testy integracyjne dla apis
  • zautomatyzowane testy interfejsu użytkownika dla produktu końcowego
  • wymagania dotyczące wydajności i skalowania

jeśli zespół zda pozytywny test na wszystkie wymagania biznesowe i podstawową wydajność w skali wymagań technicznych, masz działający produkt.

Potem po prostu naciska, aby zrobić to samo, ale szybciej

Ewan
źródło
1

Wszyscy w zespole muszą uzgodnić definicję ukończenia . Bez tego jesteś podatny na olbrzymie ilości pełzania zakresu, punktów widzenia i drania podstawowych wymagań.

Wszystko, co zostanie dostarczone ponad to, musi znajdować się w zaległościach, które również będą miały własną definicję „zrobione”.

Jeśli chodzi o priorytety, metoda MoSCoW zawsze dobrze nam służyła - YMMV.

Robbie Dee
źródło
1

Moją pierwszą myślą na ten temat jest ... Dlaczego zespół martwi się o zmiany? Czy mają jakieś historyczne zrozumienie właściciela produktu, które sprawia, że ​​czują, że muszą zbudować pierwsze rozwiązanie, które będzie bardziej konfigurowalne, aby ułatwić przyszłe ulepszenia? Jeśli Twoje rozwiązanie zajmie 2 dni, a ich 5 dni, tak, to ponad dwa razy dłużej. Ale jeśli zmiana planu zajęłaby każdorazowo 2 dni, ale ulepszenie ich zajęłoby 1 dzień, ich plan wydaje się bardziej skuteczny na dłuższą metę. Nie sądzę, aby w tym pytaniu była PRAWA lub ZŁA decyzja. To zależy od innych czynników, IMHO. Jednak masz rację co do tego sposobu myślenia, jeśli w innych rozwiązaniach podwaja LOE bez żadnych bezpośrednich wskazówek (niektóre dowody na to, że wymagana jest dodatkowa złożoność dla skalowalności, odporności itp.). Moją sugestią byłoby zaangażowanie właściciela produktu w te rozmowy, ponieważ muszą oni pomóc w ustalaniu priorytetów. Jeśli twoje rozwiązanie ma 5 punktów i spełniłoby to teraz potrzebę, ale to, co chcą zrobić, wymagałoby 50 punktów i dwóch lub więcej sprintów, organizacja producentów może powiedzieć „poczekaj, planujemy wydanie MVP o wysokim priorytecie i nie mogę spędzić 2 tygodni na tworzeniu funkcjonalności, której nie ma w planie! ”

Curtis Reed
źródło