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

Нужно было что-то делать.

Что поменялось?

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

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

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

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

Утомительные совещания по планированию – такая распространенная проблема, что многие команды интуитивно предпочитают проводить обсуждения историй в дни, предшествующие таким совещаниям. Как правило, такие обсуждения занесены в их ежедневники как «совещания по предпланированию», «окончательная обработка бэклога» или «лакировка бэклога». Но что происходит чаще всего? Та самая тягомотина, которую они так ненавидят на планировании, просто переносится на другой день. Словно пытаясь усугубить проблему, членов команды просят прервать их текущую продуктивную работу, чтобы посидеть на скучном совещании. Неудивительно, что никто не испытывает восторга по этому поводу.

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

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

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

Если среди ваших сотрудников найдется несколько человек, которые очень хотят, чтобы их пригласили на обсуждение, но количество участников и без того так велико, что под угрозу поставлена продуктивность, попробуйте шаблон сотрудничества «Аквариум». Он заключается в том, чтобы дать им возможность присутствовать, не участвуя активно или минимально влияя на окончательный результат. Чаще всего люди обнаруживают, что происходящее не настолько важно, как они ожидали. Спустя какое-то время вы и сами заметите, что они охотно предоставляют другим возможность обсуждать детали, а затем узнают результаты из последующих обсуждений.

Процесс происходит так: от трех до пяти человек работают вместе у доски. Это значит, что они в аквариуме.