Архитектурные принципы как «нефункциональные» истории пользователей

Question

Я собираюсь запустить экспериментальный проект в нашей компании, чтобы внедрить гибкие методы, в том числе использование пользовательских историй. Прочитав две книги Майка Кона, Agile Estimating and Planning в частности и User Stories Applied, я теперь имею более четкое представление о том, как действовать. У меня есть уверенность в совершенствовании наших методов наряду с практикой.

Однако есть одна вещь, которая меня не убеждает. In this blog post Майк Кон определяет конкретные типы пользовательских историй, которые он назвал ограничениями, которые могут использоваться для определения так называемых нефункциональных требований. Лично мне не нравится слово ограничение и даже использование классического шаблона «Как ..., я хочу ..., чтобы ...».

Скорее я постараюсь сделать клиент, чтобы писать, всегда на картах, возможно, с выше шаблон, те, что Ник Rozanski и Йон Вудс называется, в своей фантастической книге Software Systems Architecture, архитектурные принципы:

«Архитектурный принцип - это утверждение веры, подхода или намерения, которое определяет определение архитектуры».

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

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

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

Answer 1

Вы когда-нибудь пробовали использовать любой подобный подход? Я не пробовал что-то совсем похожее, но когда я был мастером Scrum в моей команде, у нас было общее архитектурное руководство и видение проекта (в котором все команды были частью), о котором мы напомнили себе, во время различных контрольных и адаптивных точек Sprint, а также Scrum Project, например, во время ретроспективы, совещаний по планированию Sprint и даже ежедневных встреч Scrum. Некоторые способы, которыми мы напомнили нам, заключались в добавлении Done Criterias для задач, которые включали один принцип для соблюдения архитектурных рекомендаций, и его также можно было бы добавить как небольшую заметку в Backlogs. В моем предложении ниже я упомянул, как это выглядело с действительно высокого уровня.

Вы отговариваете его по любой причине? Нет, совсем нет. Я говорю, что ваше предложение хорошее, и вы должны попробовать его для совещания по планированию. И, как было предложено Кеном Швабером и Джеффом Сазерлэнд в их Scrum Guide, вы должны осмотреть и адаптироваться во время 3-х очков в Sprint - «В Scrum есть три пункта для проверки и адаптации. Ежедневное собрание Scrum используется для проверки прогресса в направлении Цель Sprint и сделать адаптацию, которая оптимизирует ценность следующего рабочего дня. Кроме того, собрания Sprint Review and Planning используются для проверки прогресса в достижении цели выпуска и для адаптации, которая оптимизирует значение следующего Sprint. Наконец, Sprint Retrospective используется для обзора прошлого Sprint и определения того, какие адаптации сделают следующий Sprint более продуктивным, полноценным и приятным ».

Есть ли у вас какие-либо предложения по этому вопросу? Можно ли предположить, что этот проект «Agile» в вашей компании только начинается, и у вас еще нет единого проекта? Если да, я бы посоветовал вам организовать 2-недельный семинар по планированию широкой версии проекта. Целью этого семинара было бы привлечение всех заинтересованных сторон, ОО, СМ и Менеджеров проектов в одном месте и разработка Суперпользовательской истории и видения, а также остальная часть отставаний, разбитых на суперпользовательскую историю. Суперпользовательская история была бы видение цели проекта на высоком уровне. Если вы уже это сделали, пожалуйста, проигнорируйте это предложение, но моя точка зрения заключается в том, что представление высокого уровня или история суперпользователя могут/должны иметь часть, которая упоминается в соответствии с архитектурным принципом, установленным в вашей компании.

Преимущества этого? Он привлекает заинтересованные стороны к архитектурному и техническому аспекту продукта прямо из Super User Story, что помогает создать хорошее понимание видения между бизнесом и технической стороной, и нельзя жить без другого.

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

Спасибо, Сид.

Answer 2

Это было предметом обсуждения, которое я видел в январе этого года на Архитектурном заводе. Я отследил его. Это была Ли Ингрэм «Бизнес-ориентированная архитектура: пример из текущего запуска». Я не могу найти слайды, но он говорил о идее всеобъемлющих принципов, которые определяют, как должны выполняться требования.

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

Answer 3

Я настоятельно рекомендую Jeff Patton's presentation on user story mapping.

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

Answer 4

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

• Система будет поддерживать максимальное использование 30 пользователей.
• Импорт должен выполняться ежедневно.
• Все фильтры и результаты поиска должны быть размещены на одной странице.

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

Answer 5

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