• как конкретно ведет себя программный продукт внутри интерфейса – какие бизнес-правила действуют, как нужно валидировать данные;
• сколько времени потребует разработка продукта с учетом всех технических деталей (на этом этапе мы обсуждаем все настолько подробно, что оценки могут быть довольно точными).
Помните: пока еще ничего не решено окончательно. Если дискуссия приводит к решениям, которые слишком сложны или дороги, вернитесь на шаг назад и обсудите проблемы, которые вы решаете, а также альтернативные способы решения.
Придите к соглашению о том, что нужно разработать. После того как по результатам обсуждения вам удалось выработать одинаковое понимание, перейдите к поиску ответов на вопросы.
• По каким критериям можно будет определить, что работа над программным обеспечением закончена?
• Что будет происходить во время демонстрации программного обеспечения, когда мы будем оценивать его все вместе?
Говорите и записывайте. Используйте доски или большие листы бумаги, чтобы рисовать картинки, записывать примеры и рассматривать варианты. Не позволяйте своим решениям испариться. Записывайте их на досках или на бумаге, чтобы каждый мог их видеть. Сфотографируйте записи и картинки, чтобы позднее задокументировать информацию.
Оперируйте примерами. Где только возможно, используйте специфические примеры поведения пользователей: какие конкретно данные могут быть введены, что именно пользователи увидят в результате, – словом, любые примеры, которые лучше всего иллюстрируют вашу историю.
Разделяйте и уменьшайте. Обсуждая детали и думая о затратах на разработку, вы, возможно, обнаружите, что истории слишком велики, чтобы уместиться в стандартный цикл. Поработайте вместе с группой, чтобы разделить крупные истории или уменьшить их, удалив все лишнее.
Но все это не будет работать, если:
• нет совместной работы – кто-то один описывает, что нужно сделать, а все остальные слушают;
• разговор идет только о критериях приемки, но никто не вспоминает об истории и о «Кто?», «Что?», «Почему?»;
• не рассматриваются варианты реализации как с функциональной, так и с технической стороны.
Планирование спринта или итерации
Некоторые практики Agile воспринимают эти важнейшие обсуждения историй во время сессий планирования как планирование итерации или спринта. Это не так страшно, если вы имеете дело с командами, эффективно работающими вместе и начинающими дискуссию, хорошо понимая своей продукт. У команд, с которыми я работал на протяжении многих лет, это был устоявшийся способ работы.
Тем не менее самая частая жалоба, которую я слышу от команд, работающих по Agile, заключается в том, что эти совещания по планированию – зачастую долгие изматывающие мероприятия. В какой-то момент все соглашаются разработать то-то и то-то, даже если на самом деле никакого общего понимания нет, просто чтобы закончить это мучительное совещание.
Никола Адамс и Стив Барретт, RAC Insurance (Perth, Australia)
Мой первый опыт работы в мире проектов Agile в роли бизнес-аналитика был тяжелым и горьким уроком о превосходстве командной работы над печатным словом.
Никола Адамс
Контекст
Историю трансформации от методологии водопада к Agile в компании RAC Incurance (Западная Австралия) рассказывает Никола, квалифицированный бизнес-аналитик с большим опытом в традиционном подходе к разработке программного обеспечения. В ее обязанности входило сотрудничество с бизнесом, понимание предметной области и составление функциональных спецификаций, в соответствии с которыми команда IT создавала продукт. Коммуникация происходила по следующей схеме.
Наибольшее внимание уделялось детальным спецификациям, где старались не пропустить ни одной детали. Поскольку было очевидно, что разработчики не читают документацию, были внедрены специальные стратегии смягчения проблемы (например, пошаговые руководства по спецификациям), но они не решали ее полностью. Как правило, между окончанием работы над спецификацией и моментом, когда ее нужно было использовать для поддержки разработки и тестирования, проходило довольно много времени.
С чего все началось?
Устоявшийся подход к письменным спецификациям не стали отменять в одночасье. Концепцию написания требований на обратной стороне карточки внедрить было нелегко. Как Никола могла ожидать, что разработчики и тестировщики внедрят необходимую функциональность, за которую она несла ответственность, если у них нет необходимой информации? Фокус просто переместился на создание последовательностей действий пользователя, почти ничем не отличающихся от традиционных функциональных требований, за исключением размера; схема коммуникации не изменилась.
Чтобы передать требования команде на сессиях разработки, Никола:
• собирала требования партнеров по бизнесу;
• глубоко анализировала требования и данные;
• создавала последовательности действий пользователя (каждая занимала от одной до пяти страниц), где описывались требования, дизайн решения и критерии приемки;
• излагала эти требования команде с использованием проектора и отвечала на вопросы присутствующих.
К несчастью, результаты не впечатляли. Подготовительные сессии были скучными и утомительными, большая часть команды никак не включалась в обсуждение. Кроме того, Никола чувствовала, что зря тратит время на подготовку историй, так как команда чаще всего игнорировала их во время разработки.
После одной из сессий Сэм, эксперт в предметной области, одновременно играющий роль владельца продукта, заметил: «Если это и есть проект Agile, я не желаю в этом участвовать!»
Нужно было что-то делать.
Что поменялось?
Менеджер проекта Стив собрал команду, чтобы обсудить проблему. В результате команда приняла несколько важных решений: исключить из процесса документы с историями, привлечь к подготовке историй как команду бизнеса, так и разработчиков, а также явно включить в процесс окончательную обработку бэклога и работу над историями.
Теперь Никола не просто выполняла требуемые от нее действия, а активно участвовала в процессе. Следующая сессия разработки разительно отличалась от всех предшествующих. В конференц-зале не сидела скучающая команда, пассивно наблюдающая за экраном, где демонстрировались истории действий пользователя. Члены команды, включая владельца продукта, экспертов в предметной области и разработчиков, активно работали с визуальными моделями и другими артефактами и живо обсуждали истории.
Схема коммуникации изменилась. Никола больше не работала «испорченным телефоном» между бизнесом и IT – теперь она выступала координатором обсуждений между теми, кто понимал цели бизнеса, теми, кто хорошо знал нужды пользователей, и командой разработки, которая знала, что можно реализовать.
И представителям бизнеса, и команде разработки очень понравился новый формат, все они активно включились в процесс. Наконец удалось достичь одинакового понимания проблем, требующих решения, различные точки зрения, существовавшие в группе, позволили команде найти оптимальные решения в условиях ограничений, а Никола уже не чувствовала такого сильного давления и больше времени посвящала работе. Никола наконец ощутила себя своей!
В толпе не может быть сотрудничества
Утомительные совещания по планированию – такая распространенная проблема, что многие команды интуитивно предпочитают проводить обсуждения историй в дни, предшествующие таким совещаниям. Как правило, такие обсуждения занесены в их ежедневники как «совещания по предпланированию», «окончательная обработка бэклога» или «лакировка бэклога». Но что происходит чаще всего? Та самая тягомотина, которую они так ненавидят на планировании, просто переносится на другой день. Словно пытаясь усугубить проблему, членов команды просят прервать их текущую продуктивную работу, чтобы посидеть на скучном совещании. Неудивительно, что никто не испытывает восторга по этому поводу.
Проблема не в том, что обсуждать истории очень сложно. Да, иногда это может вызывать трудности, но абсолютно любые обсуждения станут гораздо тяжелее, если вы попытаетесь привлечь к ним слишком много людей. Если к тому же большая часть этих людей не заинтересована в участии или не мотивирована, считайте, что дело провалено. Вы знаете, о ком я говорю, – эти люди надеются, что никто не замечает их смартфоны, на которых они играют под столом.
Позвольте членам команды самим решать, хотят ли они участвовать в обсуждении. Если позднее они будут жаловаться на принятые решения, просто не забудьте пригласить их в следующий раз.
Если хотят участвовать все, попробуйте шаблон сотрудничества «Аквариум», описанный в следующем примере. В этом случае заинтересованные могут прийти, принять участие, если хотят, или уйти, если обнаружат, что не происходит ничего интересного.
Если среди ваших сотрудников найдется несколько человек, которые очень хотят, чтобы их пригласили на обсуждение, но количество участников и без того так велико, что под угрозу поставлена продуктивность, попробуйте шаблон сотрудничества «Аквариум». Он заключается в том, чтобы дать им возможность присутствовать, не участвуя активно или минимально влияя на окончательный результат. Чаще всего люди обнаруживают, что происходящее не настолько важно, как они ожидали. Спустя какое-то время вы и сами заметите, что они охотно предоставляют другим возможность обсуждать детали, а затем узнают результаты из последующих обсуждений.
Процесс происходит так: от трех до пяти человек работают вместе у доски. Это значит, что они в аквариуме.