Какие аргументы я могу использовать, чтобы «продать» концепцию BDD команде, не желающей ее принять?

11

Я немного вокальный сторонник методологии Behavior Driven Development (также известной как BDD). Я применяю BDD уже пару лет, и выбрал StoryQ в качестве своего предпочтительного фреймворка при разработке приложений DotNet. Несмотря на то, что я проходил модульное тестирование в течение многих лет и ранее перешел на подход, основанный на тестировании, я обнаружил, что я получаю гораздо больше пользы от использования инфраструктуры BDD, потому что мои тесты отражают цели требований в относительно ясный английский в моем коде, и потому что мои тесты могут выполнять несколько утверждений, не заканчивая тест на полпути - это означает, что я могу сразу увидеть, какие конкретные утверждения пройдут / не пройдены без отладки, чтобы доказать это.

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

Поэтому, учитывая все эти преимущества, вы можете легко представить эту концепцию остальной части команды. К сожалению, другие члены команды неохотно даже смотрят на StoryQ, чтобы оценить его должным образом (не говоря уже о том, чтобы развить идею применения BDD), и убедили друг друга попытаться удалить ряд элементов StoryQ из нашей собственной инфраструктуры тестирования ядра, даже хотя изначально они поддерживали использование StoryQ, и хотя код, который они хотят удалить, не влияет ни на какую другую часть нашей системы тестирования. Это в конечном итоге значительно увеличило бы мою рабочую нагрузку и действительно пошло бы на спад, так как из практического опыта я убедился в том, что это лучший способ работать в тестовом режиме в нашей конкретной рабочей среде и может привести только к большей улучшение качества нашего программного обеспечения, учитывая, что я мне показалось, что проще придерживаться теста, используя BDD. Чтобы уточнить, большинство из наших модульных тестов, как правило, довольно хрупкие и трудные в обслуживании, пережиток многих лет плохо примененного тестирования, когда нежелание придерживаться процесса, управляемого тестами, заставило разработчиков отступить от старых привычек и сделайте все их тестирование в конце проекта (эти же люди утверждают, что они Agile!).

Таким образом, вопрос действительно сводится к следующему:

  1. Какие аргументы я могу использовать, чтобы действительно понять, что для этой команды было бы лучше использовать StoryQ или, по крайней мере, принять методологию BDD?
  2. Можете ли вы указать мне какие-либо неподтвержденные доказательства, которые я могу использовать для обоснования своего аргумента о принятии BDD в качестве нашего стандартного метода выбора?
  3. Какие контраргументы, о которых вы можете подумать, могут предположить, что мое желание побудить команду принять BDD может быть ошибочным? Да, я счастлив, что оказался неправ, если аргумент является обоснованным.

ПРИМЕЧАНИЕ . Я не защищаю то, что мы полностью переписываем наши тесты, а скорее просто начинаю работать по-другому для всей будущей работы по тестированию, и, предпочтительно, так, как мы привлекаем наших клиентов.

А для тех, кто хочет больше узнать о BDD, могут быть полезны следующие ссылки:


Для тех, кто интересуется более подробной информацией, мы - небольшая команда из 4 человек, которая работает над 5 крупными проектами. «Пилотное испытание» для BDD первоначально длилось около 2 месяцев, а еще через 4 месяца. Команда согласилась, чтобы я продолжал работать таким образом, и должен был провести свои собственные испытания. После окончания судебного процесса я занимаюсь BDD около 2 лет, в то время как другие стали очень хорошо справляться с этой проблемой. Вместо того, чтобы навязывать «конфронтацию» по этому вопросу, я ищу способы мягко убедить команду избавиться от коллективных споров и выделить время, чтобы внести свой вклад.

S.Robins
источник
2
Давайте подумаем о «ИХ» - почему они хотят, чтобы это удалили? Должно быть выгодно для них - пытались ли вы выяснить их преимущества ПЕРВЫМ и узнать, какого среднего уровня можно достичь, ДО того, как предлагать свои преимущества :)
кандидат наук,
2
Старайтесь меньше продавать и больше учиться. По моему опыту, люди не хотят что-то продавать, но всегда хотят узнать что-то новое. Тогда пусть карты падают, где они могут. Если они все еще против этого, вы потерпели неудачу как преподаватель, или bdd - это еще не все, что вы говорите.
Кевин
1
@Kevin Я думаю, что вы пропустили мой предыдущий комментарий к Nupal, и, возможно, суть моего вопроса полностью. Вы взяли одно слово из моего вопроса и истолковали его вне контекста. Я на самом деле пытаюсь обучать, а не просто «продавать» как таковую. Я ищу конкретные моменты, которые я могу использовать, чтобы помочь мне преодолеть ненужное нежелание заниматься чем-то другим. Пожалуйста, ответьте, если вы хорошо осведомлены о предмете, вместо того, чтобы просто приводить провокационные заявления о моих способностях или технологиях, которые явно бесполезны с вашей стороны.
С.Робинс
2
Диаграммы двоичных решений? Купите копию Kno's TAoCP vol 4 и одолжите им.
Питер Тейлор
2
Я думаю, что проблема вашей команды не в самом BDD, а скорее в усталости методологии разработки. Я сам страдаю от этого. Приходит слишком много методологий, которые обещают революционизировать развитие. К сожалению, через несколько месяцев всегда есть еще одна новая методология и набор инструментов. Я стал рассматривать это как раздражающее отвлечение, а не возможность улучшить. Чтобы ввести BDD, вам придется преодолеть эту проблему.
Antonio2011a

Ответы:

5

Какие аргументы я могу использовать, чтобы действительно понять, что было бы лучше использовать StoryQ или, по крайней мере, применить методологию BDD?

«Клиент хочет этого».

ИМО, вы хотите продавать BDD своим клиентам / экспертам по доменам как минимум столько же, сколько команде разработчиков.

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

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

Дэн Норт рассказывает о том, как вы можете продать BDD бизнесу: http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

guillaume31
источник
Я видел эту презентацию, и вы правы, это хороший способ представить концепцию клиенту. В моем случае мне нужно сделать несколько маленьких шагов. Если единственное, что я могу убедить команду сделать, - это принять язык, у меня может быть шанс поощрить применение полного метода. Мне также нужно решить проблему, заключающуюся в том, что большинство наших клиентов являются внутренними и менее ориентированы на бизнес. Ваша точка зрения, однако, хорошо отмечена. :-)
S.Robins
5
  1. В группе, не желающей внедрять BDD, скорее всего, нет «аргументов», которые вы могли бы использовать, чтобы «преобразовать» своих коллег в полномасштабное принятие.
     
    Я думаю, что лучшее, что вы можете сделать, - это убедить их попробовать («тест дыма», «пробный прогон», «пилотный проект») - особенно если вы четко даете понять, что отбросите идею, если результаты тестирования отрицательны.
  2. Ваш подход к поиску неподтвержденных доказательств идеально вписывается в идею убедить команду попробовать. Для этого я просто поищу в Интернете что-то вроде «Истории успеха разработки, управляемой поведением», и выберу то, что мне легче использовать.
  3. Я могу подумать, что есть пара контраргументов, которые могут указывать на то, что ваше желание преобразовать усилия команды в BDD может быть ошибочным.
     
    Ничто из этого не является особенно конструктивным, особенно с точки зрения «защитника изменений», но, к сожалению, вам, вероятно, придется иметь дело именно с такой риторикой ( BTDTGTTS ):
     
    • Вы не можете гарантировать, что общая производительность команды улучшится
    • Вы не можете гарантировать, что усилия, вложенные в принятие BDD, обеспечат значительный возврат инвестиций
    • Команда достаточно хорошо обходилась без BDD, риск изменения нынешнего подхода не оправдан
    • Google (или Microsoft, или IBM - просто введите имя любого «респектабельного» поставщика программного обеспечения) работают без BDD, что «доказывает», что BDD не нужен
    • подходы, не относящиеся к BDD, не получили достаточных шансов в сравнительном тестировании
    • BDD может быть в порядке, но для этого и того модуля / проекта это не применимо

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

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

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

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

комар
источник
Спасибо за вдумчивый ответ. Так получилось, что я успешно участвовал в ограниченном тестировании, после которого команда согласилась на бессрочное применение BDD. Улучшения производительности были измеримыми, но, как вы упомянули, нет никакой гарантии, что это обязательно будет относиться ко всей команде, не найдя какого-либо способа побудить каждого члена команды попробовать это для себя, что, кстати, является мотивацией для постановки вопроса.
С.Робинс
@ С.Робинс интересный. Вы упомянули об этом ограниченном тестировании, как долго оно длилось? какая часть команды была вовлечена?
комар
Мы небольшая команда из 4 человек, работающая над 5 крупными проектами. Первоначально «тест» длился около 2 месяцев, а еще через 4 месяца. Команда согласилась, чтобы я продолжал работать таким образом, и должен был провести свои собственные испытания. После окончания судебного процесса я занимаюсь BDD около 2 лет, в то время как другие стали очень хорошо справляться с этой проблемой. Вместо того, чтобы навязывать «конфронтацию» по этому вопросу, я бы предпочел найти способы мягко убедить команду покинуть свои коллективные спины и выделить время, чтобы внести свой вклад! ;-)
S.Robins
Понимаю. Это делает ваш вопрос еще более интересным. Мне нужно время, чтобы пережевать это; как сейчас я просто не могу себе представить , как можно было бы добиться дальнейшего прогресса (за исключением «несправедливый» подходы , как использование мощности микро -Управление)
комар
@ S.Robins, пока я обращаю наше внимание - есть ли у вас модули, которые «смешивают» BDD и не BDD-части, или есть своего рода разделение на 100% BDD / 0% BDD-модулей?
комнат
-1

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

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

Билл Липер
источник
1
Я не знаю, согласен ли я с этим. Вы говорите, что без покупки разработчика правильный подход заключается в том, чтобы заставить руководство заставить его засыпать? Не приводит ли это к негодованию? Независимо от достоинств BDD, я думаю, что это приведет к худшим результатам. Т.е. вы выиграли битву и проиграли войну.
Кевин
@Kevin Я согласен с Кевином в этом. Обида и плохое самочувствие могут очень быстро сломать команду, и это само по себе может стать большим риском для продуктивности команды, чем просто оставить их работать неэффективно. Комментарий Кевина напоминает мне эту пословицу о том, что у меня нет гвоздя. В этом случае я не стремлюсь сделать что-то радикальное или героическое просто для того, чтобы идти своим путем. То, что я ищу, это мой "гвоздь".
С.Робинс,
Команда уже против них, о чем свидетельствует тот факт, что они берут тестовый код, который они написали. Это довольно враждебно для меня и требует вмешательства менеджера по развитию. Это их работа, чтобы вся команда работала гладко.
Билл Липер