Scrum команда не дотримується принципу YAGNI

Під час зустрічі з SCRUM команда продукту обговорювала функцію в API, яку споживатиме мобільний додаток. У нас був макет, який показав, як повинен виглядати екран і які ключові елементи він повинен містити ("макет").

На підставі цього та обговорення, який я мав із власником продукту, я створив прототип відповіді API (HAL + JSON). Це був дуже простий, сумісний з HAL JSON, який не мав нічого іншого, як представляти речі, що були в макетах. На мене не впливали майбутні ідеї, які були передбачені діловими людьми, оскільки вони мають тенденцію часто змінювати свої ідеї, і я вирішив застосувати мінімалістичний підхід. Мою пропозицію команда відхилила, і я перехитрив 7 - 1.

Команда вирішила використати більш складну, несемантичну абстрактну структуру json, що дозволяє досягти більшої гнучкості в організації компонування. Недоліком цього підходу є те, що ми закінчилися набором рівномірних об'єктів, які можуть мати нульові та порожні властивості за задумом. Вони також подумали, що було б непогано зробити тестування A / B можливим, але це базувалося на їх прогнозах лише тому, що у нас не було такої вимоги.

Більшу частину часу ми дискутували про речі, які не були частиною спринту та не згадувались у макетах. Описані проблеми були "що, якщо маркетинг у майбутньому буде ...", "що, якщо бізнес може захотіти, щоб ми ...".

Я та власник продукту - досвідчені програмісти, і подібні проблеми ми спостерігали раніше. Ми намагаємось слідувати принципам YAGNI та KISS . Решта команди трохи менш досвідчені, і хоча вони знають ці принципи, вони, схоже, не розуміють їх.

Ми погодилися з їх вирішенням, оскільки команда в цілому для нас важливіша, і ми не хотіли битися за щось, що не так важливо. Але я боюся, якщо таке може стати прецедентом для спірних, складніших дебатів? Як боротися з такою поведінкою? Чи є щось, що я, як керівник команди, можу зробити краще?

Варто згадати, що продукт є MVP на ранній стадії.

Я відчуваю твій біль, бував там. ІМХО подібні проблеми викликані тим, що у вас є команда з 8 осіб, яка вже занадто велика, щоб ви завжди могли приймати найкращі стратегічні рішення.

У команді розміром 8 і більше шансів висока кількість посередніх програмістів вище, ніж кількість досвідчених. Це часто призводить до ситуацій, коли кращі рішення перемагають посередні рішення. Це не здається задовільним, особливо коли ти (або думаєш, що ти є) одним з більш досвідчених хлопців, але принаймні те саме часто стосується дійсно поганих рішень.

Факт полягає в тому, що ви не можете багато з цим зробити, доки команда не зміниться , принаймні, якщо все залишиться демократичним,

• навчитися жити з цим
• працюйте з командою протягом одного-двох років, діліться власним досвідом та сподіваюся, що вони з часом дізнаються про цінність YAGNI та KISS
• працювати над власними навичками "продажу" дизайну чи стратегічних рішень команді
• спробуйте перейти на іншу (можливо меншу) команду, де ваш власний рівень знань ближче до середнього рівня для всієї команди

Я думаю, що єдиний спосіб дізнатися та зрозуміти реальну цінність мінімалістичного підходу та YAGNI - це зробити досвід з перших рук. Наприклад, залучившись до підтримання застарілої системи з безліччю неправильних прогнозів "що робити", неправильних дизайнерських рішень, мотивованих аргументами "на всякий випадок", або містять безліч перегенералізованого рамкового коду, який насправді ніколи не потрібен. Але цього ви не можете навчити членів вашої команди за два дні, певний досвід, який люди повинні скласти самостійно.

Сумісність вперед - це законна проблема

Якщо хтось із семи розробників, які перехитрили вас, є архітектором, це його право вводити NFR за потребою, і один з цих НФР може бути "сумісністю вперед", особливо якщо ви підтримуєте компонент віддаленої системи, який може мати більш рідкісний характер. графік випуску. Ви не хочете, щоб користувачі мали встановлювати нову версію програми, тому що ви не думали заздалегідь.

Як і інші вимоги, вам потрібні критерії прийняття

При цьому будь-які НФР повинні бути задокументовані як вимоги та повинні мати визначені критерії прийняття . Також ви повинні придумати засоби їх тестування . Ось чому YAGNI важливий - ви не хочете писати код, який неможливо перевірити, і якщо єдиною метою коду є підтримка функції, якою ніхто не користується, це важко перевірити.

Це не повинно бути викликом судового рішення

Я б запропонував вам змусити команду погодитись на невисловлену вимогу, яку ви, мабуть, пропустили, і запишіть її. Після того, як ви визначили засіб його тестування, ваша реалізація повинна провалити хоча б один тест, і тому це не має бути питанням голосування.

Здається, що ваша команда розробників намагається полегшити команду продуктів, створивши рамку, яка дозволяє їм робити швидкі випробування, що, очевидно, те, що дійсно хотіла б мати команда продуктів. Ваш підхід більше схожий на "буквально дайте їм те, що вони просять, і не думайте за них".

Якби я був власником продукту, я думаю, я був би набагато щасливішим, коли команда розробників використовує перший підхід, ніж другий.

Ну, на мою думку, демократія не працює належним чином - ні в політичній системі, ні в команді, де більшість програмістів є молодшими та посередніми.

Ваше слово як керівника команди та одного з найдосвідченіших людей у ​​команді повинно мати більший вплив, ніж решта команди. Якщо YAGNI важливий для вас, вам слід зробити презентацію про це. Обговоріть про це та покажіть їм, чому це добре.

Зрештою, ваша відповідальність вища, ніж перед іншими людьми. Це не тільки писати код, але й орієнтувати людей.

Думаємо, що в ЯГНІ є невелика плутанина.

Часто розробники думають, що вони слідують за YAGNI, коли вони опускають абстракції, які будуть тримати систему "закритою для модифікації та відкритою для розширення".

Якщо ви не "розширите" систему з "очевидно" не вимагається функціоналом, ви не маєте справу з YAGNI. Введення абстракцій, де може відбутися розширення, є вже згаданою "сумісністю вперед".

Моя особиста думка полягає в тому, що лише глибоке знання домену допоможе приймати рішення абстрагування та де їх знайти.

Проблема YAGNI AND KISS полягає в тому, що вони абсолютно суб'єктивні та розпливчасті.

json ?? ЯГНІ! просто надішліть рядок csv!

об’єкти ?? KISSTUPID !!! просто використовуйте gotos !!

Роль "Лідера команди" недостатньо визначена, але я б радив відмовитися від висловлення суб'єктивних думок щодо технічного вибору вашої команди. Навіть якщо ви відчуваєте, що вони помиляються. Дотримуйтесь короткого списку чітко визначених вимог.

• одиничні тести на код
• інтеграційні тести для apis
• автоматизовані тести користувальницького інтерфейсу для кінцевого продукту
• вимоги до продуктивності та масштабування

якщо команда може досягти проходження тестів на всі бізнес-вимоги та основні показники роботи за масштабними технічними вимогами, у вас є діючий продукт.

Після цього його просто натискання робити те саме, але швидше

Усі в колективі повинні погодитися з визначенням зробленого . Без цього ви схильні до величезної кількості повзучості сфери, точок зору та базісності основних вимог.

Все, що надходило вище та вище, повинно бути у відставанні, яке також має власне визначення зробленого.

Щодо пріоритетів, метод MoSCoW завжди нам добре служив - YMMV.

Перша моя думка з цього приводу - це ... Чому команду турбують зміни? Чи мають вони історичне розуміння Власника продукту, що змушує їх відчувати, що їм потрібно створити перше рішення, щоб бути трохи більш налаштованим, щоб полегшити майбутні вдосконалення? Якщо ваше рішення зайняло б 2 дні, а їх 5 днів, так, це більше вдвічі. Але якщо зміна вашого плану займе 2 дні кожен раз, але покращення їх зайняло б 1 день, їх план здається більш ефективним протягом тривалого перевезення. Я не думаю, що в цьому питанні є ПРАВИЛЬНЕ чи НЕправильне рішення. Це залежить від інших факторів, ІМХО. Однак ви справедливі щодо цього мислення, якщо в інших рішеннях вони подвоюють ЛОЕ, не маючи прямих вказівок на це (деякі докази того, що додаткова складність необхідна для масштабованості, надійності тощо). Моя пропозиція полягатиме в тому, щоб залучити власника продукту до цих розмов, оскільки їм потрібно допомогти у визначенні пріоритетності. Якщо ваше рішення налічує 5 балів, і воно би задовольнило потребу зараз, але для того, що вони хочуть зробити, потрібно 50 балів і два спринти або більше, PO може сказати: "Тримайся, ми запланували випуск цього MVP, запланованого і не можу витратити 2 тижні на розробку функціональних можливостей, яких немає в дорожній карті! "