Разработчики Backend подавлены пользовательскими историями

10

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

Мой ответ был таков

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

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

Как я могу решить проблему до того, как она загрязнит команду?

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

— Сили
источник

7

У меня не будет бэкэнд-историй, они не имеют смысла ... Однако я не хотел бы иметь таких менеджеров ... Я думал, что бэкенд-разработчики были рок-

— звездами

2

Создание отдельных фоновых историй подразумевает, что фоновая работа может быть расставлена по приоритетам отдельно от фронт-энда. Это может привести к тому, что приоритеты будут назначены таким образом, что работа с бэкэндом будет перенесена в конец журнала до тех пор, пока она не будет повторно включена в истории. Для проблемы с отсутствием признательности со стороны руководства, я рекомендую вам спросить об этом на Workplace.SE.

— Барт ван Инген Шенау

Мое фантазийное решение включает в себя случайные шлепки всех сторон. пощечину Стоп нытье. пощечина Перестаньте игнорировать критически важную роль, которую данные и бизнес-логика вносят в успех бизнеса, который оплачивает нашу аренду. пощечина Перестаньте есть чужие обеды. Это не холодильник твоей мамы.

— Эрик Реппен

1

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

— jwenting

4

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

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

Не должно быть людей, которые занимаются только back-end разработкой. Общий Agile-подход состоит в том, чтобы межфункциональные команды состояли из обобщающих специалистов, практикующих совместное владение кодом. Люди не должны быть сосредоточены исключительно на внутреннем или внешнем развитии, хотя они, безусловно, будут лучше, опытнее или лучше в некоторых вещах, чем другие.
Архитектура не зарабатывает ценность. С точки зрения пользователя - единственной точки зрения, которая действительно имеет значение - не имеет значения, есть ли у вас слои или доменные языки или даже если решение запрограммировано. Единственное, что имеет значение, - создали ли вы ценность для пользователей. Предлагаемая «история» от внутреннего разработчика является бессмысленным требованием - это краткое изложение проектных решений, которые с точки зрения пользователя / клиента не делают ничего для достижения желаемой функциональности. Другими словами, любая конкретная пользовательская история может быть достигнута любым количеством различных архитектурных проектов. Возможно, что пользовательская история может быть завершена без каких-либо изменений в серверной части. Это не делает это неверной историей.
Системное мышление все еще критически. Хотя архитектура может не приносить пользы, она по-прежнему имеет решающее значение для успеха. Бэкэнд-разработчик имеет некоторые действительные проблемы. Вы должны думать о том, как вы будете строить систему. Вы должны записать эти решения. Вся система важна, даже если только функции внешнего интерфейса - это то, что получит всю славу.

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

Требуйте, чтобы все работали везде в системе (front-end и back-end), если вам нужно, создайте пару программ, чтобы это могло произойти эффективно. Продолжайте создавать ориентированные на пользователя истории пользователей. Но также определите ключевые сценарии качества атрибутов, которые показывают, почему система спроектирована такой, какая она есть, и стимулируют принятие решений относительно «внутреннего» дизайна. Поднимите архитектурный дизайн, чтобы он больше не был невидимым.

— Майкл
источник

1

Спасибо за действенный ответ! Я хотел бы прояснить немного понимания, вызванного моей неправильной формулировкой. Он не просто "backend dev", на самом деле он работает по всему стеку даже в прошивках. Его главная проблема - архитектура бэкэнда, не получившая должного признания. И хотя архитектура сама по себе не приносит пользы, небрежная архитектура может сломать системы или, по крайней мере, сделать их очень дорогими в обслуживании. Мой план состоял в том, чтобы сделать больше разговоров об архитектуре во время совещаний по рассмотрению и планированию, а семинар по качеству выглядит также как отличный инструмент!

— Сили

FWIW, это не всегда практично, чтобы разработчик работал полный стек. Одним из требований моей нынешней компании может быть разработка CICS для мэйнфрейма IBM, MQ, Java в Mule ESB, Datapower, а затем, наконец, полноценный веб-интерфейс с jquery и другими шаблонами. Другая пользовательская история может быть связана с тем, что CORBA говорит на VMS COBOL, а другой бэкэнд написан на Gupta.

— Алан Шутко

@AlanShutko - точно. «Передний конец одного человека - это задний конец другого человека», верно? Это одна из причин, по которой мне не нравится сленг, такой как «back end» и «front end», особенно когда речь идет о нескольких компонентах в системе. Ваша точка зрения чрезвычайно важна! Даже «полный стек» - это относительный термин, который может означать разные вещи в разных частях системы!

— Майкл

11

Кажется, это социальная проблема, поэтому необходимо социальное решение.

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

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

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

— sleske
источник

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

— Сили

1

@Szili: Бэкэнд так плохо работает, что не заслуживает уважения, или он просто помечен галочкой, что его не узнают?

— Blrfl

Его бэкэнд-работа превосходна. Надлежащее признание и даже издевательства со стороны руководства являются проблемой.

— Сили

4

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

На самом деле это проблема. Очевидно, что вы не решите это с историями!

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

Стандартное гибкое решение этой проблемы заключается в применении более «вертикального» или «полного стека» подхода к разработке, когда ваши бэкэнд-разработчики берут истории сверху вниз, вместо того, чтобы просто работать в своей комфортной зоне внутреннего уровня, и внешние разработчики также тянутся к бэкэнду (*).

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

^{(*) Примечание: не все истории должны иметь внешний компонент или внутренний компонент. Элементы пользовательского интерфейса могут быть перетасованы без дополнительной серверной работы, а производительность является особенностью .}

— Sklivvz
источник

3

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

— Джимми Хоффа

1

Нет @JimmyHoffa Я хорошо знаком с серверной разработкой. Мой ответ в значительной степени гибок в учебнике. Как вы могли заметить, я не защищаю только людей с интерфейсом. Если вам не нравится agile, не используйте его, но я просто описываю, как работает методология, поэтому не думайте обо мне или о чем-то еще.

— Sklivvz

2

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

— Джимми Хоффа

1

@JimmyHoffa Но они не приносят никакой пользы конечному пользователю. Если бы это была команда только разработчиков бэкэнда, то пользователи были бы разработчиками фронтэнда. В этом случае ваши рассуждения будут иметь смысл, но это не так.

— Sklivvz

1

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

— Джимми Хоффа

1

Ваши проблемы:

У вас есть уровни управления в вашем бизнесе, где они не служат цели. Scrum, проворный, мне все равно. Управление и развитие должны быть изолированы от проблем бизнеса, решаемых менеджером по продукту, который имеет представление! @ # $ О технологии. Возможно, это сработало для Стива Джобса, но я никогда не сталкивался с ситуацией, когда менеджеры, не являющиеся техническими специалистами, находящиеся рядом с разработчиком, были полезными или, в конечном счете, служили для производства продукта наилучшего качества, который могла создать команда.
У вас есть разработчики, которые больше беспокоятся о внешности, чем решают проблемы. Это либо очень серьезная проблема с культурой (кажется, вероятно, учитывая весь этот феномен «майнера»), и / или у вас есть проблема с качеством разработки, которая также не потрясет меня из-за отсутствия уверенности.

Получить людей, которые не должны быть там из планирования и стояния. Любой, кто имеет представление о том, что back-end менее важен, чем front-end, - это тот, кому не нужно быть там, и на самом деле он там мешает процессу.

Кюветные истории. Да я серьезно. Если они вызывают такие проблемы, выбросьте их из шлюза. На моей нынешней работе мы просто придерживаемся критериев «выполнено» для конкретной задачи, которая обычно больше ориентирована на приложение, чем на пользователя, что может оскорбить тех, кто считает, что Agile (который постоянно менялся в течение 20-ти лет) победил ». не работает, если вы не следуете этому письму, но на самом деле, если мы профессионалы, нам не нужно ничего, что вызывает у нас проблемы. Смять их, перебросить через плечо.

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

— Эрик Реппен
источник

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

— Майкл

Это правда. Я не уверен, что гибкий манифест будет считаться достаточным для того, чтобы «делать это правильно» по многим стандартам всей индустрии обучения, которые были построены вокруг него, но как всегда идеи и какие из них имеют смысл для вас и Ваша команда должна иметь приоритет над влиянием, ИМО. Кроме того, вы получите столько ответов на этот вопрос о том, как правильно делать гибкие упражнения, сколько вы спросите студентов, каковы правила свиданий. Там нет замены для критического мышления.

— Эрик Реппен

Я бы не отказывался от пользовательских историй. На самом деле я прилагаю все усилия, чтобы представить их, поскольку у нас есть традиция игнорировать конечных пользователей. Аналогия со Стивом Джобсом очень удачная, поскольку наш генеральный директор - блестящий технический парень, основавший многомиллионную компанию. Единственное, в чем он потерпел неудачу, - это построил управленческий уровень, так что он оставался очень занятым выполненной работой. Это уступило место появлению звездной культуры, что вызывает беспокойство о внешности. Подводя итог: у нас культурная проблема. Но, учитывая это как данность, мне нужны инструменты, подобные тем, которые приведены в ответе, чтобы сделать необходимые шаги ребенка.

— Сили

В любом случае, я бы порекомендовал опытного разработчика с анальным интерфейсом, если у вас проблемы с UX. Там нет замены, за исключением некоторых замечательных универсалов, которым немногие захотят заплатить полную команду.

— Эрик Реппен