этом разработка продукта – это командный вид спорта. Разработчики и тестировщики должны в определенной степени участвовать в ранних стадиях рабочего процесса, чтобы понимать, на чем основаны пользовательские истории, UX-дизайн и другие базовые решения в отношении продукта. Они должны быть заинтересованы в том, чтобы задавать вопросы и вносить свой вклад на всех этапах рабочего процесса. Аналогичным образом менеджеры по продуктам и дизайнеры должны быть в курсе событий, происходящих в зоне ответственности разработчиков и тестировщиков, тем более что там часто возникают непредвиденные вопросы или неполадки. В Intuit у нас была любимая поговорка: хорошие идеи приходят отовсюду. О достигнутом внутри команды уровне сотрудничества можно судить по тому, насколько чаще члены команды, говоря о своих коллегах, употребляют местоимение «мы» вместо «они».
Эффективное сотрудничество помогает команде формировать общее видение и избегать различных проявлений недопонимания, что также позволяет двигаться быстрее. Каждый член команды ежедневно принимает множество решений, так или иначе относящихся к созданию общего продукта. Если все участники процесса имеют общее видение и совместные цели, то они с большей вероятностью будут принимать персональные решения, направленные на достижение общих интересов.
Жесткая расстановка приоритетов
Вы должны поддерживать актуальность бэклога с учетом приоритетности входящих в него заданий. Важно иметь четкое представление о наборе пользовательских историй, которые планируется отработать в следующем цикле, как только для этого появятся ресурсы. Применение такого подхода позволяет действовать быстро. Команды разработчиков высокотехнологичных продуктов обычно работают в динамичной среде, для которой характерна быстрая смена требований и приоритетов. При этом явно недостаточно присваивать заданиям такие нечеткие приоритеты, как высокий, средний и низкий. Если в бэклоге будет 15 заданий с высоким приоритетом, то как понять, к какому из них разработчик должен приступить в первую очередь? Поэтому необходимо дополнительное ранжирование заданий, входящих в состав бэклога. Я являюсь сторонником жесткой расстановки приоритетов (в противовес расплывчатому ранжированию заданий). Четкая расстановка заданий внутри бэклога дает ясное понимание того, какое из них стоит первым в очереди на отработку. Это также значительно облегчает определение места в бэклоге для вновь поступающих заданий.
Тонкость заключается в том, что жесткая расстановка приоритетов не означает отсутствие гибкости этого процесса. Вы должны четко представлять себе приоритеты ранжирования в любой момент времени; но при этом также должны уметь быстро реагировать на изменение существующих или появление новых требований. Я вижу здесь аналогию с водой и льдом. Большую часть времени бэклог подобен льду: порядок ранжирования находящихся в нем заданий фиксирован – находится в замороженном состоянии. Но с появлением новых требований или изменением приоритетов вы на короткое время растапливаете лед, переводя его в жидкое состояние, чтобы произвести перенастройку. После определения новой очередности выполнения заданий вы снова замораживаете свой бэклог. Следование такому подходу гарантирует, что всякий раз, когда кто-то из членов команды обращается к бэклогу за получением нового задания, он имеет дело с его максимально актуальной версией. Таким образом, разработчик может просто брать задание, стоящее первым в очереди, ни с кем при этом не советуясь и не тратя время на получение дополнительных подтверждений.
Создавайте для разработчиков адекватное описание продукта
Важно предоставить разработчикам всю информацию, необходимую для создания желаемого продукта. Набор хорошо написанных пользовательских историй, усиленный соответствующими вайрфреймами или макетами, обычно хорошо справляется с этой задачей. При наличии готового руководства по стилю и отсутствии необходимости обновления базовых компонентов UX обычно бывает достаточно одних только вайрфреймов. Однако, если нужно передать визуальные детали дизайна, следует использовать макеты. Для чисто серверных функций, не содержащих UX-компонентов, вайрфреймы не требуются. Постановка задачи для разработчиков не должна ограничиваться одним лишь описанием «счастливого пути», то есть ожидаемого сценария поведения пользователя. Необходимо предусмотреть и другие применимые условия и состояния. Но при этом следует обеспечивать определенный баланс интересов. С одной стороны, вы хотите предоставить разработчикам достаточно полное определение продукта, чтобы они могли приступить к своей части работы с уверенностью, что вы не упустили из виду никаких важных аспектов. С другой стороны, вы не хотите столкнуться с ситуацией, когда на обдумывание каждой детали тратится так много времени, что сроки создания продукта значительно увеличиваются.
Опережайте разработчиков
Многие команды испытывали трудности с интеграцией своего UX-дизайна в процесс Agile-разработки. В руководстве по Scrum в явном виде не говорится о том, как можно справиться с этой проблемой наилучшим образом. Понятно, что в случае, когда проектировщик создает вайрфреймы для пользовательской истории одновременно с тем, как разработчик пытается писать для этой же истории программный код, итоговый результат не будет представлять собой ничего хорошего. Для того чтобы команды, практикующие Agile, могли достичь максимальной скорости, разработчики должны быть в состоянии немедленно приступить к работе над новой пользовательской историей. Это означает, что пользовательские истории и проектные артефакты должны быть заранее подготовлены к передаче на этап разработки. Таким образом, чтобы обеспечить стабильность рабочего потока, проектировщики должны опережать текущий этап разработки как минимум на один или два спринта.
Другими словами, к сроку окончания спринта N они должны уже подготовить артефакты проектирования для спринта N+1 или даже N+2. Конечно, для этого проектировщикам потребуются качественно написанные пользовательские истории, поэтому менеджеры по продукту должны в свою очередь опережать дизайнеров также на один или два спринта.
Цель состоит в том, чтобы убедиться, что вы никогда не заставите разработчиков сидеть без дела, и у вас наготове всегда будет бэклог для очередного спринта. Это также требует соблюдения баланса, поскольку делать заранее слишком много заготовок для спринтов может быть неразумно из-за того, что все может измениться. Несмотря на то что я описал ситуацию в терминах Scrum, это также справедливо и для Канбана. Исходя из продолжительности цикла работы дизайнеров, продакт-менеджер должен обеспечить достаточное количество заданий, готовых для проектирования. Аналогично, исходя из продолжительности цикла разработки, дизайнеры должны обеспечить достаточное количество карточек заданий в столбце «Готово для разработки».
Ни менеджеры по продуктам, ни проектировщики не должны работать в вакууме. Необходимо выделить определенное количество времени в текущем спринте на то, чтобы члены команды могли просмотреть и обсудить пользовательские истории и проекты для будущих спринтов.
Разбивайте истории на фрагменты
Применение Agile предусматривает работу с небольшими фрагментами. Ранее я уже упоминал, что масштаб пользовательских историй не должен превышать некий разумный предел (то есть количество баллов, которыми оценена трудоемкость реализации каждой истории). Кроме того, вы должны стремиться разбивать истории на как можно более мелкие фрагменты. Если у вас есть история, трудоемкость которой оценена в
