Я планировал нарезать бэкенд-разработку на истории пользователей по вертикали. Но бэкэнд из нашей команды начал жаловаться, что это делает их работу невидимой.
Мой ответ был таков
на совещаниях по планированию спринта и обзору мы обсуждаем бэкэнд-задачи перед заинтересованными сторонами, чтобы это было видно, и
поддержание высокого качества во время проекта приведет к более медленному старту, чем у других команд, но у нас будет стабильная скорость в течение проекта. И скорость очень заметна для заинтересованных сторон.
Он по-прежнему настаивает на том, чтобы у него были такие истории: «Как разработчик, мне нужен слой домена, чтобы я мог инкапсулировать бизнес-логику».
Как я могу решить проблему до того, как она загрязнит команду?
Корень проблемы заключается в том, что наше руководство систематически рассматривает бэкэнд-работу как невидимую и призывающую разработчиков или других уничижительных терминов.
источник
Ответы:
В описанной ситуации есть несколько неправильных вещей, очевидной проблемой является отсутствие уважения к фоновым разработчикам. Поскольку этот вопрос помечен как agile, я собираюсь отодвинуть другие ответы, предполагая, что это только социальная проблема. В вашей истории есть несколько неприятных запахов и возможных анти-паттернов, ни один из которых не имеет отношения к невежественному управлению или даже к тому, как вы режете истории.
Тот факт, что группа людей в команде чувствует себя ущемленным из-за того, что они не получают славы от работы, привел к появлению нескольких возможных проблем.
Моя рекомендация - относиться к архитектуре как к первоклассному гражданину, но делайте это правильно. Проведите семинар по качественным атрибутам с заинтересованными сторонами . Вовлекайте ключевые заинтересованные стороны в обзоры архитектуры или, по крайней мере, обобщайте основные проектные решения на важных этапах. Нарисуйте архитектуру на большой бумаге и сделайте ее видимой, чтобы вся команда могла ее увидеть.
Требуйте, чтобы все работали везде в системе (front-end и back-end), если вам нужно, создайте пару программ, чтобы это могло произойти эффективно. Продолжайте создавать ориентированные на пользователя истории пользователей. Но также определите ключевые сценарии качества атрибутов, которые показывают, почему система спроектирована такой, какая она есть, и стимулируют принятие решений относительно «внутреннего» дизайна. Поднимите архитектурный дизайн, чтобы он больше не был невидимым.
источник
Кажется, это социальная проблема, поэтому необходимо социальное решение.
Если (насколько я понимаю) бэкэнд-разработчики чувствуют, что их игнорируют и пренебрегают, и считают, что их работа недостаточно ценится, то процесс разработки мало что может сделать, чтобы это изменить.
Если я правильно понимаю, мне кажется, что разработчики считают, что у них должны быть, по крайней мере, свои «собственные» пользовательские истории, чтобы они могли указать на них и сказать: «Это то, что мы сделали, только мы, бэкенд-ребята / девчонки». Тем не менее, разрезать истории «по горизонтали», как это плохо, и я согласен с вами разрезать их по вертикали.
Наилучшим решением, вероятно, является тихая беседа с разработчиком (ями) (индивидуально или в составе группы) и решение основной проблемы, которая, похоже, вызывает уважение. В какой-то момент это, вероятно, должно будет перейти к управлению.
источник
На самом деле это проблема. Очевидно, что вы не решите это с историями!
В общем, одной из особенностей гибкой разработки является прозрачность. Это также означает, что это делает ваши организационные проблемы более явными .
Стандартное гибкое решение этой проблемы заключается в применении более «вертикального» или «полного стека» подхода к разработке, когда ваши бэкэнд-разработчики берут истории сверху вниз, вместо того, чтобы просто работать в своей комфортной зоне внутреннего уровня, и внешние разработчики также тянутся к бэкэнду (*).
Другими словами: сделайте так, чтобы все приносили пользу вашим конечным пользователям.
(*) Примечание: не все истории должны иметь внешний компонент или внутренний компонент. Элементы пользовательского интерфейса могут быть перетасованы без дополнительной серверной работы, а производительность является особенностью .
источник
Ваши проблемы:
У вас есть уровни управления в вашем бизнесе, где они не служат цели. Scrum, проворный, мне все равно. Управление и развитие должны быть изолированы от проблем бизнеса, решаемых менеджером по продукту, который имеет представление! @ # $ О технологии. Возможно, это сработало для Стива Джобса, но я никогда не сталкивался с ситуацией, когда менеджеры, не являющиеся техническими специалистами, находящиеся рядом с разработчиком, были полезными или, в конечном счете, служили для производства продукта наилучшего качества, который могла создать команда.
У вас есть разработчики, которые больше беспокоятся о внешности, чем решают проблемы. Это либо очень серьезная проблема с культурой (кажется, вероятно, учитывая весь этот феномен «майнера»), и / или у вас есть проблема с качеством разработки, которая также не потрясет меня из-за отсутствия уверенности.
Получить людей, которые не должны быть там из планирования и стояния. Любой, кто имеет представление о том, что back-end менее важен, чем front-end, - это тот, кому не нужно быть там, и на самом деле он там мешает процессу.
Кюветные истории. Да я серьезно. Если они вызывают такие проблемы, выбросьте их из шлюза. На моей нынешней работе мы просто придерживаемся критериев «выполнено» для конкретной задачи, которая обычно больше ориентирована на приложение, чем на пользователя, что может оскорбить тех, кто считает, что Agile (который постоянно менялся в течение 20-ти лет) победил ». не работает, если вы не следуете этому письму, но на самом деле, если мы профессионалы, нам не нужно ничего, что вызывает у нас проблемы. Смять их, перебросить через плечо.
И вы, возможно, захотите напомнить этому разработчику, что люди, о которых им действительно нужно беспокоиться, являются их непосредственными сверстниками, а не людьми, которые слишком невежественны для планирования спринта.
источник