Гибкие пользовательские истории для программного обеспечения для имитационного моделирования

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

У меня есть графический интерфейс, в котором я могу добавить два объекта-человека на плоскость, объект-мяч и один объект-человек. Затем я могу нажать кнопку PLAY, чтобы смоделировать ситуацию, когда человек A может бросить мяч, указав параметры. Я могу использовать физику, основанную на силе/скорости/направлении, а затем человек B может поймать мяч, основываясь на своем собственном положении. и время, пока он идет (где его движение задается чтением во входном файле).

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

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

Прямо сейчас они сидят в своей собственной пользовательской истории, просто написанной как задачи, такие как «Обработка событий». и «Система координат XYZ», которая, как мне кажется, не очень удачно расположена.

Что я пытаюсь понять: если у меня есть история пользователя:

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

Будет ли мой список задач (конкретно для бэкенда) включать:

  1. Реализовать систему координат xyz
  2. Реализовать обработчик событий и добавить человеческий объект в объект обработки событий?

Или я должен вставить эти задачи в историю пользователя, например

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

справиться с задачей реализации инфраструктуры системы координат и обработки событий?

(И отметить, что на самом деле за пределами примера у меня гораздо больше объектов и внутренней обработки.)


agile user-stories
person skyk    schedule 17.06.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

Затем, если это слишком велико, я бы, вероятно, разделил бросок и симуляцию ловли. Это реализация кода таким образом, который соответствует цели Agile. Если я заставлю Человека А бросить мяч, я смогу показать это пользователю и, возможно, научиться. Может быть, мы моделируем футбол и бросаем «вытянутый сфероид» (термин, обозначающий форму американского футбола) по идеальной спирали. Я показываю его пользователю, и он говорит: «Нет-нет, мы из Испании, мы имитируем бросок круглого мяча двумя руками над головой». Теперь вы узнали кое-что важное о проделанной работе и работе, которую предстоит выполнить (получатель не может поймать руками).

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

person Daniel    schedule 17.06.2020