"Tell stories, do not write them" - advice from Gojko Adjic

"Рассказывайте истории, не пишите их" - совет от Гойко Аджича

Опубликовано 16.02.2018
Автор Алексей Кривицкий

Глава книги Гойко Аджича и Дэвида Эванса: "Пятьдесят быстрых идей улучшить ваши пользовательские истории" в редакции Алексея Кривицкого.

Книга издаётся на русском языке в середине 2018 года.

Рассказывайте истории, не пишите их

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

Чтобы всё стало предельно ясно – если некая команда пассивно получает документы в порядке передачи информации, вне зависимости от того, как они называются, существуют ли на бумаге, в wiki, или в системе электронных запросов – это не настоящая работа с пользовательскими историями. Организации с таким процессом не получат всей полноты преимуществ итеративной разработки.

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

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

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

Ключевые преимущества

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

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

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

Как сделать, чтобы это работало

Есть несколько общих причин записывать детализированные истории. Большинство этих потребностей можно удовлетворить без передач документов.

Вот наиболее распространённые поводы:

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

Наиболее распространённое оправдание для передачи документов - это необходимость формального утверждения рамок проекта. Не вдаваясь в то, насколько это формальное утверждение правильно или неправильно - если вам нужно его иметь - отложите подписание на время после обсуждений историйи. Подписывайте истории по мере их обсуждения. Мы работали с несколькими командами в регулируемых средах, где условия процесса требовали, чтобы спонсор бизнеса утверждал объём работы. В таких случаях бизнес спонсор подписывал спецификации с примерами, полученными в результате совместной проработки и анализа историй.

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

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

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

Henrik Kniberg is coming down to rock the stage at #agilerockconf!

Agile Rock Conference 2018 приветстует Хенрика Книберга!

Книга "Scrum and XP from trenches", бесподобные видео по Spotify - это далеко не всё, чем известен Хенрик. И мы очень рады, что он принял наше приглашение выступить на конференции и поджемить.

Читать статью

Scrum Ukraine: весна уже здесь (даже если ещё так не кажется)

Scrum Ukraine: весна уже здесь (даже если ещё так не кажется)

Весенние витамины самообучения:


Два бесплатных постера.
Пять полезных статей.
Три глубоких курса.
Одна (но очень громкая) конференция.

Читать статью