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

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

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

Погрузитесь в детали каждой истории во время разработки

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

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

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

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

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

Продолжайте обсуждать в процессе разработки

Машина семинаров по историям производит продукт для следующего аппарата на конвейере – машины разработки Agile. Здесь я нарисовал реальный процесс работы этой машины: с одной стороны мы загружаем в нее маленькие истории правильного размера, а с другой стороны получаем идеально работающий маленький кусочек программного продукта – или того, что описывает ваша история.

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

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

Если вы владелец продукта, дизайнер UX, бизнес-аналитик или еще кто-то из членов команды, которая решала, что нужно создавать, не стесняйтесь пойти в отдел разработки и посмотреть, как идут дела. Обещаю: чем раньше вы увидите что-то работающее, тем раньше поймете что-то важное. Кроме того, возможно, создателю этого работающего фрагмента не помешает отзыв о его детище.

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

Оценивайте каждую часть