Как быть успешным на семинарах по спецификациям BDD?

Сегодня мы попытались внедрить BDD в процесс разработки программного обеспечения, проведя семинар по спецификациям.

Для этого семинара у нас было 2 разработчика, 1 тестер и 1 бизнес-аналитик. Семинар продолжался 1:30, и к концу нам удалось выяснить некоторые сценарии BDD для нашей новой функции. Мы пытались сосредоточиться на поиске сценариев, которые мы могли бы пропустить, и сложных сценариев.

В конце семинара некоторые люди были фактически недовольны семинаром.

Один разработчик почувствовал, что потратил впустую свое время, поскольку бизнес-аналитик давал сценарии напрямую и рассматривал их вместе с ней. Бизнес-аналитик не чувствовала себя уверенно с нашим охватом сценария (было ощущение, что мы могли бы пропустить другие важные вещи), но, что более важно, чувствовала, что этот семинар также был пустой тратой времени, так как она могла сама разобраться во всех этих сценариях. и в более короткий период времени .

Этот экспериментальный семинар длился 1:30, и к концу мы не чувствовали себя достаточно уверенными в том, что сделали ... уверены, что могли бы потратить на это больше времени, но, честно говоря, большинство людей устали после 1:30 мозгового штурма, чтобы заняться бизнесом правила от мозга BA.

Итак, мой вопрос, как такой семинар может работать на самом деле. В теории, учитывая, что у вас есть новая функция для разработки, вы помещаете дерево «amigos» (dev / tester / ba) в одну комнату, чтобы они могли совместно работать над написанием различных требований для новой функции с использованием примеров. Я вижу все выгоды от этого. Особенно с точки зрения обмена знаниями и общего продукта / конечной цели / выполненного видения.

Наш вывод из этого эксперимента заключался в том, что на самом деле более экономически выгодно сначала иметь БА, чтобы он самостоятельно работал над примерами, и только потом - сценарии, которые будут рассмотрены / переработаны 3 «амиго»., Имея БА для самостоятельной работы, мы на самом деле чувствуем себя более уверенными в том, что мы меньше будем упускать вещи + мы все равно будем пересматривать сценарии, чтобы потом перепроверить. Мы не думаем, что достаточно просто провести одноразовый сеанс мозгового штурма / обдумывания, чтобы серьезно покрыть все требования к новой функции. Бизнес-аналитик на самом деле лучший человек для такого рода вещей. Лучшее, что мы можем сделать, это просмотреть то, что она написала, и посмотреть, будет ли у нас общее понимание (что может привести к переписыванию некоторых из ее сценариев или добавлению новых, которые она могла бы пропустить).

Итак, как вы можете заставить это работать эффективно на практике ?

Если вы можете извлечь сценарии из описания, все готово.

Анти-паттерн, который я часто вижу в BDD, - люди, чувствующие необходимость подробно обсудить и записать каждый сценарий.

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

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

И вы можете спросить: «Является ли восстановление учетной записи частью этой функции?»

«Они могут быть двумя функциями, если хотите.»

«Хорошо, у нас есть сценарии для создания, чтения, обновления, удаления; это должно быть достаточно просто. Давайте поговорим о восстановлении учетной записи; это звучит более интересно».

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

Если вы никогда не делали этого раньше или сомневаетесь, обсудите сценарии.

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

При наличии контекста.
Когда происходит событие,
тогда должен произойти результат.

• Есть ли какой-то другой контекст, который для того же события приводит к другому результату?
• Есть ли другой результат, который также важен?

Если все за столом выглядят скучно, функция, с которой вы разговариваете, вероятно, понятна. Часто достаточно сказать: «Это должно работать как X , но вместо Y ». Это то, что Дэн Норт называет « пирог с имбирем» ; это как рецепт шоколадного торта, но с имбирем вместо шоколада.

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

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

Иногда BDD не работает.

Другая возможность состоит в том, что вы найдете сценарий, в котором заинтересованная сторона не уверена. «О, я не думал об этом! Я не уверен». Вместо того, чтобы пытаться пригвоздить бизнес и наказать его с уверенностью, возможно, на этом этапе стоит отказаться от BDD и попробовать что-то простое, чтобы получить некоторую обратную связь и дать бизнесу то, что они могут повторить. Не усложняйте изменения и пишите сценарии, как только есть лучшее понимание того, что происходит.

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

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

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

• Простые и сложные вещи (известные) часто понятны, и вам не нужно подробно рассказывать о сценариях.

• Очень сложный материал (неизвестно) вообще не понят. Вы можете узнать это, поговорив по сценариям. Отсутствие определенности означает, что BDD здесь не будет работать, поэтому итерируйте что-то, что легко изменить, и получите быструю обратную связь. Любая практика, которая сохраняет ваши настройки, например, тестирование AB, также хороша в этом пространстве.

• BDD блестяще работает в промежуточном (познаваемом) пространстве как механизм передачи знаний и раскрытия двух других пространств. Это не молоток, и не все это гвоздь. На самом деле, если вы можете сосредоточить время на разговорах на чем-либо, дело не в примерах, которые вы можете найти; речь идет о поиске примеров, которые вы не можете .

Продолжительность встречи не ваша проблема. Это нормально, что эти встречи продолжаются долго. НО все должны выходить из этого, чувствуя себя уверенно. Это не ваша проблема.

Я бы предложил короткую встречу для обсуждения требований. Запланируйте вторую встречу через несколько дней, чтобы все знали, что к этому времени они должны быть готовы.

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

Не выбрасывайте все, что вы не согласны, но пометить его как спорные. Если очень краткий разговор с человеком, который написал это, поможет, сделайте это, но главным образом сохраните это.

ТОГДА проведите совещание по планированию / дизайну. Имейте твердую повестку дня для этой встречи (начните с колоды карт, положите спорные наверху) и не позволяйте ей отклоняться от курса. Убедитесь, что вы вышли из этой встречи, и все спорные вопросы были решены.

Всегда убедитесь, что все на собрании готовы к теме этой встречи!

Никогда не используйте собрание, чтобы «провести мозговой штурм» вместе. Это тратит впустую время каждого.

Общий рецепт эффективных встреч:

• попросите кого-нибудь подготовить пункты для обсуждения
• требовать, чтобы все участники изучили (а не просто прочитали) эти предметы
• собирать комментарии заранее и требовать, чтобы все участники изучили (а не просто прочитали) их
• провести собрание для принятия решений

О жалобах ...

Давайте начнем с этих:

Один разработчик почувствовал, что потратил впустую свое время, поскольку бизнес-аналитик давал сценарии напрямую и рассматривал их вместе с ней.

Что он делал в мастерской. Так что это кажется мне капризным и плохим оправданием. Я подозреваю, что этот разработчик просто не любит (или оба) тщательного изучения семинара и его ограничений по расписанию.

Бизнес-аналитик не чувствовал себя уверенно с нашим освещением сценария (было ощущение, что мы могли пропустить другие важные вещи)

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

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

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

Может быть, на этот раз встреча была медленной, это не значит, что так будет всегда. И, как внештатный сотрудник, я бы, пройдя некоторое обучение, чтобы понять это правильно, получил бы больше уверенности в том, что освещение было лучше на семинаре с 3 участниками с различным мышлением и с одним диктатором.

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

Предложения

• Будьте позитивны и подчеркивайте, что если процесс верный, вы станете лучше.

• Попробуйте оптимизировать семинар и держать его на ходу.

• Возможно, предоставьте некоторое пространство для анализа «одинокого волка», начав семинар с того, что каждый разработает несколько сценариев самостоятельно (еще лучше, до семинара), а затем сортирует их и объединяет.

И если вы не думаете, что делать этот мозговой штурм нужно, хорошо: пусть БА будет работать один, но затем , по крайней мере, проведите обзор как семинар. Чем больше глазных яблок , тем лучше, чтобы процитировать Эрик Рэймонд «S Закон Линуса» :

Given enough eyeballs, all bugs are shallow.

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

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