Во время исследования вы должны углубиться в следующие вопросы.
• Кто те заказчики или пользователи, которым, по вашему мнению, пригодится это решение?
• Как они решают свои задачи сейчас, пока продукта еще нет?
• Как изменится их мир, когда вы покажете свое решение?
• Какие внешний вид и способ взаимодействия должны быть у вашего решения?
• Сколько времени займет реализация?
Существует много практик, которые могут оказаться полезными в этой дискуссии, в частности карты историй. Они могут помочь вам осознать, как люди работают сегодня, а затем соотнести ваши идеи с состоянием всей системы после реализации решения.
Во время исследования очень важно проверить свои предположения и проделать работу по их подтверждению. Это можно сделать, глубоко проанализировав бизнес-правила или внешние предписания. Можно также поработать некоторое время непосредственно с заказчиками и пользователями, чтобы понять, как они это делают. В рамках этой работы прототипы вашего решения должны быть созданы и проверены на целевой аудитории. Кроме того, постройте технические прототипы для того, чтобы можно было выявить технические риски.
Изучайте и обсуждайте, чтобы найти небольшое и жизнеспособное решение.
Радуйтесь каждому пункту вашего решения, благополучно отправленному в корзину или обратно в бэклог возможностей, чтобы разобраться с ним в другой раз. Наши возможности могут представлять собой очень большие камни, но внутри этих камней порой таятся бриллианты и драгоценные металлы. Разбейте камни и извлеките оттуда действительно ценное, не обращая внимания на простую породу, а затем порадуйтесь, что отбросили все ненужное.
Во время исследования вы можете принять решение о создании небольших вещей, которые помогут вам в изучении, в частности прототипов архитектуры или графического дизайна.
Спайк – термин, используемый для небольших фрагментов программы или исследования, которые мы разрабатываем с целью изучить что-то конкретное. Своим происхождением он обязан сообществу экстремального программирования, где так называли работу, которая могла не войти непосредственно в создаваемый продукт. Используйте истории, чтобы описывать спайки, которые будет создавать ваша команда с целью что-либо изучить.
Когда вы уверены, что выделили небольшой набор историй, которые должны реализовать и предъявить пользователям и заказчикам, настало время подойти поближе к релизу. Список историй, реализация которых даст релиз полезного продукта, называется релизным бэклогом.
Погрузитесь в детали каждой истории во время разработки
Наши возможности поначалу могли быть похожи на большие камни. Исследовательские обсуждения разбивают их на части и отделяют пустую породу от ценных металлов. Но разработка может идти быстрее и эффективнее, если нам удастся разбить эти части на как можно более мелкие фрагменты (помня о том, что каждый фрагмент должен быть чем-то, что мы можем создать и таким образом нечто изучить). Чтобы сделать это, понадобится еще больше обсуждений, в ходе которых мы углубимся в подробности и детали.
Я нарисовал здесь замечательную камнедробилку: с одной стороны я загружаю в нее эти большие необработанные камни, внутри которых есть ценные металлы, а с другой стороны получаю камни, идеально подходящие по размеру для следующего цикла разработки. Я называл бы этот агрегат машиной семинаров по историям – мне кажется, это название отлично описывает то, что мы делаем.
Мы проводим углубленные обсуждения с программистами и тестировщиками, а также другими членами команды, вовлеченными в разработку продукта, чтобы очень, очень тщательно проанализировать детали. Это наши последние и самые продуктивные обсуждения, на них мы должны прийти к соглашению относительно способов подтверждения готовности или критериев приемки для небольших частей нашего программного продукта, ведь следующим шагом будет их разработка. Поскольку известно, что на этих обсуждениях мы делим проект на части, используйте их, чтобы привести истории к правильным размеру и форме, пригодным для отправки на следующий спринт разработки или итерацию.
Используйте аналитические семинары по историям, чтобы обсудить детали, разбить истории на части и прийти к реалистичным и конкретным соглашениям относительно того, что именно вы создаете.
Я люблю называть эти последние обсуждения семинарами по историям, потому что каждый знает: совещания непродуктивны, а семинары придуманы для того, чтобы сделать определенную работу. Можно проводить их столько, сколько нужно, хоть каждый день. Иногда достаточно лишь одного в течение сессии планирования. В Scrum, процессе Agile, такие семинары можно проводить в ходе приведения бэклога в порядок. Но когда бы вы ни решили провести эти обсуждения, они непременно должны состояться.
Продолжайте обсуждать в процессе разработки
Машина семинаров по историям производит продукт для следующего аппарата на конвейере – машины разработки Agile. Здесь я нарисовал реальный процесс работы этой машины: с одной стороны мы загружаем в нее маленькие истории правильного размера, а с другой стороны получаем идеально работающий маленький кусочек программного продукта – или того, что описывает ваша история.
Несмотря на то что вы работали очень усердно, даже последние продуктивные обсуждения не предскажут всего, что вы узнаете, начав разработку. Поэтому запланируйте ежедневные спонтанные обсуждения. Отведите время для них на ежедневных планерках.
Если вы разработчик и у вас в какой-то момент появились вопросы, а деталей, которые вы узнали из обсуждений истории, недостаточно для ответов, найдите кого-то, чтобы продолжить дискуссию. Не стоит винить в этом плохие требования. Вспомните, что раньше, перед началом разработки, вы работали вместе с коллегами, чтобы определить все необходимое для нее. Но мы люди, и никто не может всего предусмотреть.
Если вы владелец продукта, дизайнер UX, бизнес-аналитик или еще кто-то из членов команды, которая решала, что нужно создавать, не стесняйтесь пойти в отдел разработки и посмотреть, как идут дела. Обещаю: чем раньше вы увидите что-то работающее, тем раньше поймете что-то важное. Кроме того, возможно, создателю этого работающего фрагмента не помешает отзыв о его детище.
