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

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

Оценивайте вместе с ключевыми партнерами

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

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

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

Выпустите релиз и продолжайте оценивать

Я нарисую еще одни, последние весы. На одну чашу мы кладем части, которые проанализировали, протестировали с участием заказчиков и пользователей и продемонстрировали заинтересованным лицам в своей компании. Эта чаша очень похожа на ту, что упоминалась несколько шагов назад, на стадии тестирования с пользователями и заказчиками. А на другой чаше снова лежит слово «достаточно», но в этот раз оно означает «достаточно для предъявления заказчикам и пользователям и получения нужных результатов». Как только чаши сравнялись, выпускайте релиз.

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

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

Если рассматривать лишь проект, ваша работа уже закончена – вы его предъявили. Но пока вы просто сделали некий продукт. А жизнь продукта начинается, когда он представлен пользователям. Обещаю: начав обращать внимание на то, что люди делают с вашим продуктом, вы обязательно увидите возможности его немного улучшить. Запишите их и примените в начале описанной здесь модели.

Это и есть реальный жизненный цикл – во всяком случае, жизненный цикл истории.

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

Глава 12. Берем в руки камнедробилку

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

 Основная причина № 1. Чтобы пройти весь путь от неясной идеи до маленьких конкретных фрагментов программы, поступающих в разработку, требуется очень много обсуждений. Один человек просто не может их все обеспечить. И если вы построите процесс так, что он зависит от одного человека, этот человек может стать «бутылочным горлышком» и, несомненно, очень скоро им станет.

 Основная причина № 2. Один человек не обладает всеми нужными компетенциями и не сможет посмотреть со всех возможных точек зрения, чтобы прийти к наилучшему решению. Только сотрудничество людей с различными навыками позволяет создать по-настоящему полезный продукт.

Владелец продукта не может в одиночку написать все истории и присутствовать на всех обсуждениях. Это не работает.

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

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