Скрам-команда не следует принципу ЯГНИ

На совещании SCRUM команда разработчиков обсуждала функцию API, которая будет использоваться мобильным приложением. У нас был макет, который показал, как должен выглядеть экран и какие ключевые элементы он должен содержать («макет»).

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

Команда решила использовать более сложную, несемантическую абстрактную структуру json, которая обеспечивает большую гибкость при компоновке макета. Недостатком этого подхода является то, что мы получили набор однородных объектов, которые могут иметь нулевые и пустые свойства в зависимости от дизайна. Они также подумали, что было бы неплохо сделать A / B-тестирование возможным, но оно основывалось только на их прогнозах, поскольку у нас не было таких требований.

Большую часть времени мы обсуждали вещи, которые не были частью спринта и не упоминались на макетах. Описанные проблемы были «что если маркетинг в будущем будет ...», «что если бизнес может захотеть, чтобы мы…».

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

Мы договорились об их решении, так как команда в целом важнее для нас, и мы не хотели бороться за то, что не так важно. Но я боюсь, что такая вещь может стать прецедентом для будущих, более сложных дебатов? Как бороться с таким поведением? Есть ли что-нибудь, что я, как руководитель группы, могу сделать лучше?

Стоит отметить, что продукт является MVP на ранней стадии.

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

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

Факт в том, что вы ничего не можете с этим поделать, пока команда не изменится , по крайней мере, если дела останутся демократичными, так что либо

• научиться жить с этим
• Работайте с командой в течение одного или двух лет, поделитесь собственным опытом и надеемся, что они со временем узнают ценность YAGNI и KISS
• работать над своими навыками «продажи» дизайнерских или стратегических решений команде
• попробуйте перейти в другую (возможно, меньшую) команду, где ваш собственный уровень знаний ближе к среднему по всей команде

Я думаю, что единственный способ узнать и понять реальную ценность минималистского подхода и YAGNI - это поделиться некоторыми впечатлениями из первых рук. Например, участвуя в обслуживании устаревшей системы с большим количеством неправильных прогнозов «что если», неправильных проектных решений, мотивированных аргументами «на всякий случай», или содержащими много общего кода платформы, который фактически никогда не был необходим. Но это ничто, чему вы можете научить членов вашей команды за два дня, некоторые события, которые люди должны сделать сами.

Прямая совместимость является законной проблемой

Если один из семи разработчиков, которые проголосовали за вас, является архитектором, он имеет право вводить NFR по мере необходимости, и одним из этих NFR может быть «прямая совместимость», особенно если вы поддерживаете компонент удаленной системы, который может иметь более разреженный график выпуска. Вы не хотите, чтобы пользователям приходилось устанавливать новую версию приложения, потому что вы не думали заранее.

Как и другие требования, вам нужны критерии приемлемости

При этом любые NFR должны быть задокументированы как требования и должны иметь определенные критерии приемлемости . Кроме того, вы должны придумать способы их тестирования . Вот почему важен YAGNI - вы не хотите писать код, который не может быть протестирован, и если единственная цель кода - поддерживать функцию, которую никто не использует, это сложно протестировать.

Это не должно быть решение суда

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

Похоже, что ваша команда разработчиков пытается облегчить работу команды разработчиков, создавая среду, которая позволяет им проводить быстрые испытания, что, по-видимому, очень хотелось бы команде разработчиков. Ваш подход больше похож на «буквально дайте им то, о чем они просят, и не думайте о них».

Если бы я был владельцем продукта, держу пари, я был бы намного счастливее, если бы команда разработчиков выбрала первый подход, а не второй.

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

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

В конце концов, ваша ответственность выше, чем для других людей. Это не только писать код, но и направлять людей.

Я думаю, что в YAGNI есть небольшая путаница.

Разработчики часто думают, что следуют YAGNI, когда пропускают абстракции, которые будут держать систему «закрытой для модификации и открытой для расширения».

Если вы не «расширяете» систему «явно» не запрошенной функциональностью, вы не имеете дело с YAGNI. Введение абстракций, где может произойти расширение, - это уже упоминавшаяся «прямая совместимость».

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

Проблема с YAGNI AND KISS в том, что они абсолютно субъективны и расплывчаты.

?? JSON YAGNI! просто отправьте строку csv!

объекты?? KISSTUPID !!! просто используйте gotos!

Роль «руководителя группы» не совсем ясна, но я бы посоветовал вам дистанцироваться от субъективных мнений о технических решениях ваших команд. Даже если вы чувствуете, что они не правы. Придерживайтесь короткого списка четко определенных требований.

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

если команда может выполнить прохождение тестов для всех бизнес-требований и базовых показателей производительности в масштабах технических требований, у вас есть рабочий продукт.

После этого просто подталкиваю к тому же, но быстрее

Все в команде должны согласиться с определением сделано . Без этого вы склонны к огромному количеству ползучести, точек зрения и дестабилизации основных требований.

Все, что доставлено сверх этого, должно быть в резерве, которое само по себе также будет иметь свое определение выполненного.

Что касается приоритетов, метод MoSCoW всегда служил нам хорошо - YMMV.

Моя первая мысль об этом ... Почему команда обеспокоена изменениями? Есть ли у них какое-то историческое понимание Владельца продукта, которое заставляет их чувствовать, что им нужно создать первое решение, которое будет немного более настраиваемым, чтобы облегчить будущие улучшения? Если ваше решение заняло бы 2 дня, а их 5 дней, да, это более чем в два раза дольше. Но если изменение вашего плана будет занимать 2 дня каждый раз, а улучшение их - 1 день, их план кажется более эффективным в долгосрочной перспективе. Я не думаю, что есть правильное или неправильное решение в этом вопросе. Это зависит от других факторов, ИМХО. Тем не менее, вы правы в отношении этого мышления, если в других решениях они удваивают LOE без каких-либо прямых указаний сделать это (некоторые доказательства того, что для масштабируемости, надежности и т. Д. Требуется дополнительная сложность). Мое предложение состояло бы в том, чтобы привлечь владельца продукта к этим разговорам, потому что они должны помочь с расстановкой приоритетов. Если ваше решение составляет 5 баллов, и оно будет отвечать потребностям сейчас, но то, что они хотят сделать, потребует 50 баллов и двух спринтов или более, ПО может сказать: «Держись, у нас запланирован выпуск с высоким приоритетом этого MVP и не могу потратить 2 недели на разработку функциональности, которой нет в планах! "