Это оказалось дольше, чем я планировал (это началось как комментарий), но я надеюсь, что добавленная длина / детали полезны, и вы найдете их оправданными.
Agile не является специфичным для приложений CRUD
Кажется, что большая часть литературы по agile ориентирована на бизнес-приложения типа CRUD, где пользователь в значительной степени осведомлен о том, что происходит за кулисами. (Это нормально, потому что большая часть написанного кода, вероятно, принадлежит этому классу.)
Я думаю, что это потому, что легче создавать простые для подражания примеры этого типа, а не потому, что методология нацелена на такие системы. Если вы создадите не очень простой для подражания пример, вы рискуете завести читателя в тупик, пытаясь понять пример, когда ваша цель - учить читателя гибким концепциям.
Пользовательские истории! = Требования
Для этого типа приложений связь между пользовательскими историями (требованиями) и задачами разработки в основном проста: просто разделите пользовательскую историю на несколько задач.
Пользовательская история - это не то же самое, что требование. Правда, могут быть некоторые совпадения в зависимости от того, насколько «высокоуровневым» является требование, но, как правило, не одно и то же. У меня складывается впечатление, что вы сталкиваетесь с той же ловушкой, в которую попали многие мои бывшие менеджеры: думать о пользовательских историях просто как об синонимах «требований», что аналогично тому, когда пользователи SVN пытаются перейти на Git, но продолжают мышление с точки зрения SVN. (Затем они сталкиваются с проблемами из-за плохих исходных предположений.)
ИМХО, ключевое отличие между требованиями и пользовательскими историями заключается в том, что требования подробно определяют, как должны вести себя определенные компоненты системы; это спецификации, которые включают входы, выходы, предположения / предварительные условия, возможные исключения и т. д. Они сосредоточены на том, что делает система .
OTOH, пользовательские истории фокусируются на ожидаемом результате для конечного пользователя, не пытаясь создать подробную поведенческую спецификацию для компонентов системы. Они ориентированы на ожидаемый пользовательский опыт .
То, что я делал раньше, и это была практика, принятая моей командой, заключалась в том, чтобы разбивать истории пользователей на задачи. Ваши задачи могут быть настолько конкретными или расплывчатыми, насколько вы хотели / нуждались в них, но они должны были стать вашими индикаторами прогресса для фактической работы, проделанной для доведения истории до готового состояния.
пример
Я грубо вспоминаю США, в которых я работал несколько лет назад, когда пользователям нужно было самостоятельно назначать контрольные примеры, чтобы все в команде знали, над какими TC они работают, чтобы избежать дублирования усилий; пользовательский интерфейс был (n внутренним) веб-приложением. Пользователь видел только кнопку, но история была разделена на несколько задач, которые включали некоторые технические детали реализации и т. Д.
Видимость пользователя
Но есть другой тип приложений, где большая часть кода имеет дело со сложной обработкой, которая не видна непосредственно пользователю.
Можно ли как-то сделать его видимым для пользователя?
Рассмотрим GPS. Когда вы пропустили свой ход, вы не увидите реальный процесс перерасчета маршрута, но пользователь действительно получит несколько полезных отзывов (например, «Пересчет ...»).
Компиляторы могут отображать предупреждения или ошибки или включать новые настройки / опции в GUI, чтобы пользователи могли видеть, что что-то новое было добавлено. Я думаю, что пользователи для компиляторов будут программистами, верно? Разве они не увидят поддержку нового стандарта?
Хотя поддержка нового стандарта, скорее всего, будет на уровне функций и должна быть разбита на пользовательские истории, убедитесь, что, по крайней мере, в некоторых случаях вы не пытаетесь использовать истории, когда вместо них следует использовать функции ?
Анализ изображения в автомобиле может быть сформулирован таким образом, чтобы пользователь знал, что вероятность попадания в автомобильную аварию уменьшена. Например:
Как пассажир в автомобиле с самостоятельным вождением, мне нужно, чтобы вероятность того, что транспортное средство в результате аварии в результате столкновения с нераспознанным объектом окажется как можно ближе к нулю, чтобы я мог путешествовать более безопасно.
В США на высоком уровне фиксируются вещи, которые вы обычно должны указывать, используя комбинацию функциональных и нефункциональных требований, включая безопасность, безопасность и т. Д.
Тем не менее, требование может быть больше о системе; например:
Функция abcв компоненте Aдолжна иметь уменьшенное пороговое значение допуска в алгоритме сравнения изображений, чтобы лучше обнаруживать объекты, движущиеся медленно.
Для меня это было бы легко задачей в пользовательской истории, которую я упомянул выше, под названием что-то вроде: уменьшить толерантность в функции,A.abc а затем включить в нее другие важные детали.
Для системы симуляции жидкости вы можете даже иметь индикатор выполнения, который обеспечивает обратную связь о фоновых задачах, которые выполняет система, если это имеет смысл. (Всегда есть способ проинформировать пользователя о чем-то, хотя вы можете избежать спама.)
Я не знаю достаточно о конкретных доменах, о которых вы упомянули, чтобы придумать более качественные и / или более реалистичные примеры, но если вы не согласитесь, вы можете использовать различные способы предоставления отзывов пользователей о чем-то менее заметном, что система может делать, то есть могут быть способы сделать невидимые вещи более заметными. (Даже если это сводится к написанию набора замечаний к выпуску, в которых документируется, насколько быстрее производительность системы теперь достигается благодаря вашим усилиям и т. Д.)
Отношения между историями и задачами
Здесь может быть очень сложно соотносить задачи и пользовательские истории.
Наш подход состоял в том, чтобы пользовательские истории были сосредоточены на том, что было за запрос, почему он был сделан, и какие вещи должны были быть правдой, чтобы считать США «выполненными». , Как всегда осталось из США и слева разработчика (ов).
Разработчик (и) разбил бы проблему, описанную в США, на набор задач, над которыми они будут работать.
Я говорю об этом как о человеке, который по большей части занимался серверным программированием на стороне сервера, которое, вероятно, настолько «невидимо», насколько вы можете получить для конечного пользователя.
В зависимости от того, что мне нужно было сделать, я иногда использовал AJAX, чтобы показать простую анимацию / gif «загрузка ...», чтобы пользователь знал, что ему нужно немного подождать, чтобы завершить что-то еще, не создавая неправильного впечатления. Иногда это было так просто. Задача для этого была бы уместной.
Различная парадигма, практика и опыт
Существуют ли методы для преодоления этой проблемы, или мы просто должны принять это и извлечь из него выгоду?
Помимо принятия смены парадигмы, практики и накопленного опыта, вероятно, сказать гораздо больше. Я часто видел людей, пытающихся использовать ярлыки в процессе. Я бы посоветовал против этого, особенно если вы начинаете. По мере того, как вы получаете больше опыта, вы можете позволить себе некоторую гибкость, но избегайте подрывать себя.
Учитывая вашу предыдущую формулировку, вы все еще думаете об историях, как если бы они были «переименованными требованиями», что, на мой взгляд, является ложным предположением. Я думаю, что это признак более глубокой проблемы, касающейся фундаментальных различий между Agile и не Agile подходами.
Во-вторых, я думаю, вы должны согласиться с тем, что agile - это смена парадигмы по сравнению с водопадом, что означает, что, хотя процесс преследует схожие цели, они решают его по-разному. (Подумайте, SVN против Git, если это поможет.)
Попытайтесь улучшить свое текущее понимание концептуальных различий между требованиями и пользовательскими историями и признайте, что это не одно и то же.
Учимся на своих спринтах - Ретроспективы
Что я не могу подчеркнуть, так это ретроспектива между Scrum Master и разработчиками в конце каждого спринта. Это место, где они честно / прозрачно обсуждают вещи, которые «пошли хорошо» или «не пошли хорошо», и какие выполнимые изменения будут внесены для следующего спринта, чтобы учесть моменты «не ладили» ,
Это позволило нам адаптироваться и даже учиться на опыте друг друга, и, прежде чем мы это узнали, мы значительно улучшились, что измеряется общей последовательностью скорости нашей команды.