Zespół Scrumowy nie przestrzega zasady YAGNI

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.

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ć.

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.

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.

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.

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ć.

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

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.

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! ”