Недостатки вертикальных пользовательских историй

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

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

• Первоначально разработчик может медлить с реализацией функции, потому что он / она должен понимать все технологии, необходимые для разработки истории (пользовательский интерфейс + уровень обслуживания + доступ к данным + работа в сети и т. Д.)
• Общий дизайн архитектуры (создание основы приложения) не совсем подходит под эту мантру (однако некоторые могут утверждать, что разработка / изменение общей архитектуры - это часть пользовательской истории)

Каковы еще некоторые недостатки вертикальной нарезки пользовательских историй?

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

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

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

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

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

Я не согласен с другим ответом, что этот подход приносит технический долг. Может, но может и любой другой подход.

Я много думал об этом точном вопросе.

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

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

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

До сих пор я округлю свое мнение следующим сравнением:

Горизонтальные команды

Преимущества:

• Способствует хорошему разделению проблем и слабо связанных уровней
• Гораздо проще управление распределением нагрузки
• Легко для специалиста технического руководства для управления
• Способствует внутриуровневому сотрудничеству, лучшим практикам, гордости и культуре превосходства
• Соответствует естественным / возникающим моделям общения

Недостатки:

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

Вертикальные / Диагональные Команды

Преимущества:

• Все части пользовательского рассказа в одной команде («одна остановка»)
• Специально помогает доставлять n-уровневые истории в одном спринте (хотя вам это действительно нужно?)
• Способствует межуровневому сотрудничеству и развитию общих навыков
• Поддерживает универсалов

Недостатки:

• Гораздо сложнее управление распределением рабочей нагрузки
• Обеспечивает плохое разделение проблем и тесно связанные уровни
• Препятствует специализации, сокращая внутриуровневое общение; трудно понять, как культура превосходства могла возникнуть из этой структуры без добавления смягчающего горизонтального / специализированного поведения

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

Как уже упоминали другие, вторичные структуры / поведения, которые срезают другое направление, могут помочь смягчить недостатки любой системы. Одним из интересных смягчающих факторов является продолжительность спринта. Короткие спринты делают некоторые недостатки горизонтальных команд более терпимыми. Если вы можете создать бэкэнд на этой неделе и фронтенд на следующей неделе, это может быть достаточно быстро?

Чтобы применить некоторые из этих предложенных принципов к реальной проблеме ... Я скажу, что горизонтальные срезы работали очень хорошо для очень реальной команды разработчиков SaaS, над которой я работал, которая решала очень сложные технические проблемы на каждом уровне ( где специализация была, на мой взгляд, невероятно важной), где частота доставки (и надежность при высокой степени детализации / частоте) имела решающее значение для успеха в бизнесе. Обратите внимание, что этот вывод предназначен для очень конкретной команды реального мира, а не общего утверждения о превосходстве горизонтальной нарезки.

Одно предостережение: я, вероятно, пристрастен к вере в утверждения универсалистских способностей любого человека в современном мире разработки программного обеспечения без существенных доказательств, хотя я знал нескольких редких исключительных универсалистов. Я чувствую, что общность - это действительно высокий (вертикальный?) Порядок, особенно когда каждый уровень усложняется и с распространением альтернативных языков / платформ / сред / развертываний, каждый из которых отвечает различным потребностям. Особенно в эти дни мастер на все руки может легко стать мастером. Кроме того, я обнаружил, что большинство людей хотят специализироваться совсем немного, опять же с некоторыми исключениями.

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

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

Подобные вещи неизбежны, но не блокируют. Я пытался бороться с этим двумя способами:

1. Проводите длительные обсуждения дизайна с командой перед реализацией каждой истории
   • Это быстро утомляет. Для кого-то слишком рано принимать обоснованное решение, и тогда вы просто заканчиваете спором по поводу вещей, которые определенно должны будут измениться в любом случае.
2. Идите вперед и развивайтесь в относительной изоляции, помня о том, что вы наращиваете технический долг .
   • Ключевым моментом здесь является регистрация технического (архитектурного) долга как проблемы. Это то, что нужно будет вернуть.
   • После нескольких спринтов вам будет проще выбрать целостную и унифицированную архитектуру. Это когда вы должны запросить усиленный спринт, чтобы погасить часть вашего технического долга (рефакторинг существующего кода). Кроме того, вы можете расплатиться по частям в течение следующих итераций проекта.

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

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

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

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

Переход на работу в «Вертикальных историях» решил эти проблемы и сократил / исключил затраты на переработку для интеграции.

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

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

Без сильных владельцев слоев мы обнаружили, что появилось некоторое дублирование. Хотя это не было большой проблемой, нам нужно было убедиться, что мы практикуем Refactor Mercilessly (с соответствующими тестами для поддержки).

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