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

13

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

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

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

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

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

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

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

Яцек Кобус
источник
11
I'm afraid if such thing can become a precedence for upcoming, more complicated debates?- Это также нарушает ЯГНИ: беспокойство о будущем, которое может не произойти. Если вы собирались стоять на своем, вы должны были уже это сделать.
Роберт Харви
@gnat: Это не касается временных ограничений.
Роберт Харви
Не соответствует ли HAL-совместимость YAGNI?
Мэтью
@ Матве все это заняло одну неделю, и я также подготовил еще один прототип, используя простой JSON просто для того, чтобы избавиться от HAL, но он также был отклонен как «недостаточно гибкий». Команда изменила его, и эта измененная версия была наконец использована. HAL работает для нас как стандарт, набор руководящих принципов, и мне легче обеспечить единую структуру на всех конечных точках. Предыдущий API не использовал никаких стандартов, и он не закончился хорошо.
Яцек Кобус
5
Гибкость добавляет сложности. Пока команда понимает это, можно двигаться вперед.
Джон Рейнор

Ответы:

10

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

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

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

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

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

Док Браун
источник
5
Большинству людей приходится прикасаться к печи, чтобы узнать, что там жарко, а не к ней прикасаться. Программное обеспечение во многом то же самое. ++
RubberDuck
2
Ведение журнала проекта / дневника является ключевым для такого рода вещей. После того, как вы записали различные обсуждения, они стали более конкретными, чем воспоминания людей о беседах спустя месяцы или годы. Существует хороший вопрос на практике здесь .
Робби Ди
@RobbieDee: конечно, если это поможет команде узнать о YAGNI и KISS.
Док Браун
3
Третья пуля (работа над своими навыками «продажи» дизайна) не привлекает достаточного внимания. Вот почему разработчики все еще должны иметь (или работать над) хорошие коммуникативные навыки.
Рэндалл Стюарт
@RandallStewart: абсолютно. Но даже с лучшими коммуникативными навыками может быть трудно продать YAGNI людям, которые сами не делали некоторый опыт, или путают его с «быстрым и грязным», или учили, что «абстракция - это (всегда) хорошо», и поэтому попробуйте абстрагировать вещи ради абстракции, а не ради упрощения. Коммуникации нужны две стороны - одна, которая может хорошо объяснить вещи, и другая, которая хочет слушать и понимать.
Док Браун
8

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

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

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

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

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

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

Джон Ву
источник
1
Где в этом вопросе вы читаете, что команда ОП покинула путь YAGNI из-за требования прямой совместимости?
Док Браун
Прямая совместимость - это то, Content-Typeдля чего
Джек,
2
Я хочу назвать это чем-то другим, если хотите, возможно, расширяемостью. Дело в том же; это все еще НФР.
Джон Ву
1
Есть два способа сделать систему расширяемой. Один из способов - предвидеть множество потенциальных изменений требований и сделать их легко настраиваемыми «на всякий случай». Я уверен, что можно изобрести множество приемочных тестов для такого рода расширяемости. Или, делая вещи максимально простыми, чтобы кодовая база оставалась маленькой, легкой для понимания, а точки расширения или абстракции могут быть добавлены позже, когда они действительно необходимы. Последнее - ничто, для чего вы можете (или должны) писать тесты. Поэтому я не думаю, что это можно легко решить, «записав невысказанные NFR» ...
Док Браун
... так что это больше о том, как удержать команду, возможно, креативных разработчиков от предположений о NFR и придумывать их.
Док Браун
3

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

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

Мартин Маат
источник
3
+1 предвидеть и планировать перемены - это не то же самое, что переходить на астронавта с полной архитектурой и создавать внутреннюю платформу . Немного наработки могут помешать работе в будущем. Хотя команда OP, возможно, слишком склоняется в сторону гипотетики, фундаменталистский подход YAGNI, безусловно, неоптимален.
Амон
4
Звучит больше, вы бы с радостью переиграли ОП и делали те же ошибки в планировании «что если маркетинг в будущем будет…», чем остальная команда. Когда люди начинают создавать платформы вместо прикладного программного обеспечения, когда задача состоит в создании прикладного программного обеспечения, они почти всегда делают это неправильно.
Док Браун
@DocBrown Технически, я бы согласился. Однако этот случай, похоже, касается готовности содействовать, а не требовать личного уважения. Быть «правильным», с одной стороны, и быть полезным или полезным, с другой стороны. Что я читаю между строк, так это то, что ОП сдает свои позиции и предпочитает накачивать свое эго, подчеркивая свой опыт онлайн-аудитории, вместо того, чтобы вносить вклад в среду, в которой он больше не чувствует себя комфортно. Эта динамика типична для введения схватки.
Мартин Маат
@MartinMaat Я был немного разочарован тем, что они не согласились со мной. Я не понял, почему это произошло. В повседневной работе я помогаю им с обзорами кода и т. Д. Мы часто спорим, но мне это нравится, потому что конечный результат лучше; Я знаю, что они уважают мое мнение; Я всегда стараюсь использовать веские аргументы, которые поддерживают мои теории. В конце концов они выбирают лучший вариант, а также берут на себя ответственность за него. Команда сделала то, что должна была сделать - они решили проблему. Это была моя ошибка и ошибка владельца продукта, что этот вопрос был слишком широким и плохо описан с самого начала.
Яцек Кобус
2

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

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

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

BЈовић
источник
3
Демократия, вероятно, является причиной проблемы здесь, но не демократичность не является ИМХО решением, потому что она может легко создать более серьезные проблемы, чем те, которые описаны в вопросе - она ​​может фактически разрушить команду.
Док Браун
@DocBrown Вы просто противоречили себе в одном предложении. ИМО некоторые решения не решать людям. То, что ОП объяснил, является одним из них. Цитирую Армстронга для людей, которые не используют ЯГНИ: Вы хотели банан, но получили гориллу с бананом и целыми джунглями
BЈовић
2
Нет, это не противоречие (возможно, я не очень хорошо выразил свою точку зрения). Вещи просто не всегда "черно-белые". Просто потому, что демократия не работает в некоторых ситуациях, недемократичность не является гарантией улучшения ситуации и улучшения ситуации. Часто это не так просто.
Док Браун
1
С демократией вы не обязательно получаете «правильную» вещь, которую вы получаете, с чем согласны большинство людей. И это может быть ошибочным. И часто «правильная» вещь имеет проблемы с общественным признанием. YAGNI не должен быть наручниками, которые будут мешать вам вводить правильные абстракции, которые позволят вам легко добавлять «гориллу» или «целые джунгли», если это необходимо.
oopexpert
@oopexpert Проблема в том, что они могут вам понадобиться. YAGNI ведет переговоры против инженерной мысли. Правильные абстракции - это одно, а добавление вещей, которые вам могут не понадобиться, - разные вещи.
BЈовић
2

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

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

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

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

oopexpert
источник
2

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

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

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

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

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

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

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

Ewan
источник
1

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

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

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

Робби Ди
источник
1

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

Кертис Рид
источник