Джефф Паттон - Пользовательские истории. Искусство гибкой разработки ПО

Вот как может выглядеть весь цикл разбиения камней.

А сейчас разберемся со всем этим подробнее.

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

Первое качественное обсуждение истории – высокоуровневая («Кто?», «Что?», «Почему?») дискуссия, ее основная цель – принять решение: «да» или «нет». Причем «да» не означает, что мы немедленно приступаем к разработке. Это значит: пойдем дальше, проводя углубленные обсуждения, чтобы полностью понять историю. Но я не хочу двигаться вперед и тратить много времени на разговоры, если выяснится, что идея изначально для нас не годится. «Нет» – вежливый способ сказать: «Ерунда». Поэтому давайте назовем этот этап «решение того, развивать идею или отбросить ее». Помните: нам всегда требуется разработать больше, чем мы способны, так что отбросить бесперспективную возможность прежде, чем она съест слишком много времени и сил, – стоящее решение.

Обсуждайте возможности, чтобы удостовериться в целесообразности решения проблемы и принять решение, развивать его или отбросить.

После того как вы приняли решение двигаться вперед, настало время углубиться в исследования. Старайтесь узнать побольше, чтобы найти решение, достойное реализации. И не забудьте его всерьез минимизировать. Стремитесь как можно значительнее уменьшить объем требуемой работы, но при этом получить максимальный положительный эффект.

Во время исследования вы должны углубиться в следующие вопросы.

• Кто те заказчики или пользователи, которым, по вашему мнению, пригодится это решение?

• Как они решают свои задачи сейчас, пока продукта еще нет?

• Как изменится их мир, когда вы покажете свое решение?

• Какие внешний вид и способ взаимодействия должны быть у вашего решения?

• Сколько времени займет реализация?

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

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

Изучайте и обсуждайте, чтобы найти небольшое и жизнеспособное решение.

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

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

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