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