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

Question

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

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

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

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

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

То, что я пытаюсь понять: Если у меня есть история пользователя:

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

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

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

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

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

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

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

Answer 1

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

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

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