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

Question

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

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

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

Редактировать: Я нашел это исследование Ольборгского университета о "истории разработчиков".

Есть ли у вас какой-либо опыт, идея или возражение?

Заранее благодарю вас!(это мой первый вопрос!:D)

Answer 1

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

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

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

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

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

Answer 2

Мой ответ здесь применяется.

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

Answer 3

Это так же просто, как поместить Убедитесь, что компонент членства можно протестировать, отключив от всех других компонентов история "пользователя", в вашем бэклоге ДОЛЖНЫ быть истории системы / разработки, при условии, что они синхронизированы с желанием владельца продукта такой реализации.

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

Answer 4

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

Answer 5

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

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

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

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

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