Системные истории для гибкой [закрытой] архитектуры
Символ немного быстрее, поэтому если у Вас будет столбец, который Вы ЗНАЕТЕ, то будет определенная длина, использовать символ. Например, храня (M) пиво / (F) emale / (U) nknown для пола или 2 символов для штата США.
3 ответа
ИМО, отставание , а не должно включать истории разработчиков. Владелец продукта не может разумно расставить приоритеты наряду с бизнес-функциями. А что произойдет, если владелец продукта сочтет одно из них неважным и вытащит его из бэклога? Если команда затем настаивает на сохранении истории, вы попадаете в ситуацию, когда право собственности на бэклог становится неясным.
Тем не менее, я определенно думаю, что команде необходимо построить архитектуру на ранней стадии проекта. Одна из проблем моего проекта заключалась в том, что мы слишком много внимания уделяли функциональности в первых нескольких спринтах.
Давайте подумаем об «архитектурном долге» (аналогично техническому долгу) как о времени, которое нужно потратить на создание инфраструктуры и архитектуры. В отличие от технического долга (который начинается с нуля и нарастает по мере того, как команда производит функциональность без надлежащего рефакторинга), команда начинает с архитектурного долга и должна работать над его сокращением. Время, затрачиваемое на сокращение архитектурного долга, означает, что меньше времени тратится на создание функциональности, т. Е. Более низкая скорость работы команды и снижение результатов спринта. В этом смысле архитектурный долг подобен техническому долгу. Если возникнут требования, которые не соответствуют текущей архитектуре, то уровень архитектурного долга увеличится.
Помните, что команда должна решить (и иметь возможность обосновать Владельцу продукта), как они собираются тратить свое время. И поэтому они могут разделить свои усилия между функциональностью, техническим долгом и архитектурным долгом по своему усмотрению.
Однако работа над архитектурой должна по-прежнему определяться функциональностью. Другими словами, команда должна создать инфраструктуру для поддержки и включения конкретной пользовательской истории. Не только потому, что они думают, что это пригодится в будущем. Принцип ЯГНИ применим к такому подходу.
Это так же просто, как поставить Убедитесь, что компонент членства можно протестировать отдельно от всех других компонентов «пользовательская» история, в вашем бэклоге ДОЛЖНА быть система / разработка- историй, если они синхронизированы с желанием владельца продукта о такой реализации.
Вот как мы обычно помещаем нефункциональные требования в бэклог, например: «Модель предметной области должна работать в другом центре обработки данных под балансировка нагрузки »и т. д.
Мой ответ здесь применим.
Существует очень сложный баланс между работой над архитектурой и работой, связанной с конкретными функциями. Технически оба подходы допустимы и работают, но чем дольше вы откладываете какое-то количество полезного продукта (результаты спринта), тем больше вы рискуете, что не создаете нужный продукт (требования пользователя, требования к производительности и т. Д.). Как можно раньше дойдите до момента, когда вы сможете выполнить тесты на уровне системы, чтобы доказать, что ваш продукт работает, и продемонстрировать ценность и направление продукта своим заинтересованным сторонам.