Кажется, что большая часть литературы по 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 и разработчиками в конце каждого спринта. Это место, где они честно / прозрачно обсуждают вещи, которые «пошли хорошо» или «не пошли хорошо», и какие выполнимые изменения будут внесены для следующего спринта, чтобы учесть моменты «не ладили» ,
Это позволило нам адаптироваться и даже учиться на опыте друг друга, и, прежде чем мы это узнали, мы значительно улучшились, что измеряется общей последовательностью скорости нашей команды.
источник
Agile принципы, безусловно, могут применяться в этих случаях. Как?
Вам не нужно есть всего слона за один укус. Agile просто просит вас показать, что вы очистили тарелку перед следующей порцией слона.
источник
Я нахожу, что люди, которые строго придерживаются пользовательских историй, будут либо просто участвовать в очень глупой попытке придумать надуманные способы, которыми технические изменения бэк-энда влияют на пользователя (без ведома пользователя, конечно, потому что они просто наивные пользователь, и вы говорите о сложных изменениях в вашей линии анализа данных или что-то в этом роде), или они просто будут в полном недоумении "как мы можем организовать эту работу!?!"
Я думаю, что очевидное решение должно быть более прагматичным. Если работа носит технический характер и не оказывает особенно заметного влияния на пользователя, не теряйте сон, пытаясь объяснить, как это происходит. Просто выберите очевидный и простой способ, которым он может принести пользу пользователям, а затем сориентируйте историю вокруг деталей, необходимых разработчикам для выполнения их работы. Я нахожу невероятным разочарование, когда ПО настаивает на отсутствии технической информации в истории, когда это абсолютно необходимо. Это просто не очень целостный взгляд на то, чем на самом деле является этот артефакт (история). Как они думают, что это существует только для них, в большинстве случаев это важно и для инженеров.
Для большинства из этих технических задач есть некоторые низкие результаты в отношении влияния на пользователя, будь то повышение эффективности, поэтому будущие поставки будут быстрее, повышение производительности, надежность и т. Д. Они не совсем то, о чем склонны думать люди, когда они думают о «пользовательских историях», но если бизнес хочет понять, почему вы берете на себя технический долг или что-то в этом роде, то эти объяснения обычно проще всего предоставить.
tl; dr не позволяйте scrumnazi усложнять вашу жизнь просто потому, что они слишком квадратные для адаптации. Быть адаптивным - в конце концов, ключевая концепция Agile. Строгое соблюдение Scrum или Agile обычно бросается в глаза или прагматизму и практичности (что на самом деле работает лучше всего).
источник
Я думаю, что проблема в том, чтобы придать пользовательским историям значение, которого у них нет. Scrum использует термин PBI, или Product Backlog Item, который, я думаю, гораздо лучше. PBI часто будут следовать формату истории пользователя, например, у вас может быть PBI типа «Подписчики должны иметь возможность просматривать свои данные о подписке», но вы также можете легко иметь PBI типа «Создать хранимую процедуру для получения сведений о подписчике». ».
Пользовательские истории - это инструмент . Они помогают вам сформировать описания функций и требования, основанные на том, чтобы поставить себя на место пользователя. Но так же, как гаечный ключ бесполезен, когда вам нужно повесить картинку, есть моменты, когда вам может не понадобиться пользовательская история.
Тем не менее, многие команды на самом деле просто играют быстро и свободно с «пользовательской» частью. У них могут быть «пользовательские истории», такие как «Как разработчик, я должен иметь возможность вызывать хранимую процедуру для получения подробностей подписчика», по сути, это «история разработчика». Это в равной степени действительный вариант, но лично я говорю, что пока вы можете описать, что необходимо сделать, и предложить набор критериев приемлемости, вряд ли имеет значение, есть ли у вас реальная история пользователя или нет.
источник
Эти типы приложений являются именно теми, в которых присутствует разный опыт и которые будут развиваться дальше. Члены команды будут иметь разное образование, разные хобби-проекты и разный опыт работы. Более того, если кто-то разрабатывает определенный фрагмент кода, то от разработчика можно ожидать, что он будет лучше всех знаком с кодом. Поэтому, возможно, имеет смысл поручить дальнейшие задачи разработки с использованием того же фрагмента кода одному и тому же разработчику.
В самом популярном гибком процессе, Scrum, есть покер планирования, где каждой задаче назначается уровень сложности. Уровень сложности не зависит от человека, который выполняет эту задачу в соответствии с процессом. Затем во время спринта люди считаются однородными, так что ожидается, что каждый человек сможет выбрать каждую задачу и выполнить ее. В простых проектах, подобных CRUD, это предположение верно. Но в очень сложных и сложных проектах это, конечно, не так.
Я бы не стал использовать гибкие процессы для подобных проектов. Ваш лучший выбор - избегать формальных процессов и просто использовать хорошее управление проектами. При принятии решения о том, кто реализует конкретную функцию, подумайте, кто обладает лучшими навыками, необходимыми для этой функции, и наилучшими знаниями существующего кода. Для этого не требуется никакого процесса. Вы, вероятно, захотите написать хорошие проектные документы для всех функций и поддерживать их в актуальном состоянии. Обратите внимание, что я не рекламирую модель, похожую на водопад: здесь не все проектные документы будут написаны в начале проекта; вместо этого вы будете писать новые проектные документы, так как необходимы новые функции.
источник