Системные истории для гибкой архитектуры

Question

При попытке применить гибкие принципы к нашему процессу разработки, в частности принципам scrum и истории пользователей, подобным XP, мы столкнулись с проблемой архитектуры.

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

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

Edit: Я нашел this research из Ольборгского университета о "историях разработчиков".

Есть ли у вас опыт, идея или оппозиция?

Спасибо заранее! (это мой первый вопрос!): D)

Answer 1

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

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

Давайте подумаем об «архитектурном долге» (подобно техническому долгу) как времени, которое необходимо потратить на строительство инфраструктуры и архитектуры. В отличие от технического долга (который начинается с нуля и нарастает, когда команда создает функциональность без надлежащего рефакторинга), команда начинает с архитектурным долгом и должна работать, чтобы уменьшить ее. Время, затрачиваемое на сокращение архитектурного долга, означает, что затрачивается меньше времени на создание функциональности, т. Е.более низкая скорость команды и сокращение выхода спринта. Таким образом, архитектурный долг похож на технический долг. Если возникнут требования, которые не соответствовали нынешней архитектуре, тогда уровень архитектурного долга увеличился бы.

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

Архитектурные работы все равно должны управляться функциональностью. Другими словами, команда должна создать инфраструктуру для поддержки и включения конкретной истории пользователей. Не только потому, что они думают, что это будет полезно в будущем. The YAGNI principle применяется к подобному подходу.

Answer 2

Мой ответ here.

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

Answer 3

Это так же просто, как вставка Убедитесь, что компонент членства может быть протестирован отключен от всех других компонентов «пользователь» истории, ваше отставанию следует иметь системы/разработки историй, до тех пор, как он синхронизирован с желанием владельца продукта такой реализации.

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

Answer 4

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

Answer 5

В нашей команде мы называем это «IT-карты», которые являются карточками формы: «Как разработчик. Я не хочу реорганизовать xyz-компонент. Уменьшить стоимость обслуживания и повысить гибкость».

Члены команды могут выбрать любую IT-карту, которую они считают важной, вместо того, чтобы всплывать «Feature-card» из приоритетного отставания.

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

Я нашел его несколько недостающим как средство переструктурирования системы. Трудно оправдывать длительные отклонения от потока создания функции.

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