Які аргументи я можу використати, щоб "продати" концепцію BDD команді, яка не бажає її прийняти?

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

Це дійсно було для мене вершиною айсберга, оскільки я також зауважив, що мені вдається налагодити тест і код реалізації більш цілеспрямовано, в результаті чого моя продуктивність значно зросла і що я можу більше легко визначити, де виникає збій, якщо трапляється проблема, щоб зробити це все до збірки інтеграції завдяки результату, який пробивається в журнали збірки. Крім того, у StoryQ api є чудовий синтаксис, який легко засвоюється і який можна застосовувати надзвичайною кількістю способів, не вимагаючи зовнішніх залежностей для його використання.

Таким чином, з усіма цими перевагами, ви вважаєте, що легко ввести концепцію для решти команди. На жаль, інші члени команди неохоче навіть дивляться на StoryQ, щоб правильно її оцінити (не кажучи вже про розвагу ідеї застосування BDD), і переконали один одного спробувати вилучити ряд елементів StoryQ з нашої основної системи тестування, навіть хоча вони спочатку підтримували використання StoryQ, і навіть хоча код, який вони хочуть видалити, не впливає на будь-яку іншу частину нашої системи тестування. Це призведе до значного збільшення мого навантаження в цілому і справді йде проти зерна, оскільки я переконаний на практиці, що це кращий спосіб працювати тестово-першим способом у конкретних робочих умовах, і це може призвести лише до більшої поліпшення якості нашого програмного забезпечення, враховуючи I ' мені було простіше виконати тест спочатку за допомогою BDD. Для подальшого уточнення, більшість одиничних тестів, які ми, як правило, досить крихкі і важкі в обслуговуванні, перехід від років погано застосованого тестування, коли небажання дотримуватися тестового процесу спричиняло, що розробники відступають від старих звичок і зробити всі свої тестування в кінці проекту (ці ж люди претендують на спритність!).

Тож питання справді зводиться до наступного:

1. Які аргументи я можу використати, щоб реально визначити, що для цієї команди було б краще використовувати StoryQ або, принаймні, прийняти методику BDD?
2. Чи можете ви вказати мені якісь анекдотичні докази, які я можу використати для підтвердження свого аргументу щодо прийняття BDD як наш стандартний метод вибору?
3. Які протилежні аргументи, на вашу думку, можуть підказати, що моє бажання заохотити команду прийняти BDD може бути помилковим? Так, я радий бути неправдивим, якщо аргумент є обгрунтованим.

ПРИМІТКА . Я не прихильник того, щоб ми переписали свої тести в повному обсязі, а просто почати працювати по-різному для всіх майбутніх тестових робіт, а краще, таким чином, як ми залучаємо наших клієнтів.

А для тих, хто бажає дізнатися більше про BDD, можуть бути корисні наступні посилання:

• http://dannorth.net/introducing-bdd/
• http://en.wikipedia.org/wiki/Behaviour_driven_development
• http://behaviour-driven.org/Вступ

_{Для тих, хто цікавиться детальніше, ми невелика команда з 4-х, яка працює над 5 великими проектами. "Пілотне випробування" щодо BDD тривало спочатку близько двох місяців, а наступний - приблизно 4 місяці. Команда прийняла, що я повинен продовжувати працювати таким чином і повинен був робити власні випробування. Я працював у БДД вже близько 2 років з моменту закінчення судового розгляду, в той час як інші стали дуже хорошими у вирішенні цього питання. Замість того, щоб змушувати "протистояти" над проблемою, я шукаю способів обережно переконати команду зійти зі своїх колективних позаду і зробити час, щоб зробити свій трохи.}

Які аргументи я можу використати, щоб дійсно визначити, що було б краще використовувати StoryQ або принаймні застосувати методологію BDD?

"Замовник цього хоче".

ІМО Ви хочете продати BDD своїм клієнтам / експертам з домену хоча б стільки, скільки команді розробників.

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

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

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

1. У команді, яка неохоче приймає BDD, ймовірно, немає "аргументів", які можна використовувати для "перетворення" ваших колег на повномасштабне усиновлення.
    
   Я думаю, що найкраще, що ви можете зробити, - це переконати їх спробувати ("тест на дим", "сухий пробіг", "пілотний проект") - особливо, якщо ви зрозумієте, що ви кинете ідею, якщо результати тестування є негативними.
2. Ваш підхід до пошуку анекдотичних доказів ідеально підходить до ідеї переконати команду спробувати. Для цього я просто шукаю в Інтернеті щось подібне до "Історії успіху розвитку, спричиненої поведінкою", і вибираю те, що мені легше використовувати.
3. Є декілька зустрічних аргументів, які, на мою думку, можуть припустити, що ваше бажання перетворити зусилля команди на BDD може бути помилковим.
    
   Жодне з них не є особливо конструктивним, особливо з точки зору "захисника змін", але, на жаль, вам, мабуть, доведеться мати справу саме з такою риторикою ( BTDTGTTS ):
    
   • Ви не можете гарантувати, що загальна продуктивність команди покращиться
   • Ви не можете гарантувати, що зусилля, вкладені у прийняття BDD, дадуть значну рентабельність
   • команда пройшла досить добре без BDD, ризик зміни поточного підходу не виправданий
   • Google (або Microsoft, або IBM - просто заповніть ім’я будь-якого "поважного" постачальника програмного забезпечення) буде без проблем BDD, що "доводить", що BDD не потрібен
   • не-BDD підходи не отримали справедливих шансів у порівняльному тестуванні
   • BDD може бути загалом нормальним, але для цього та цього модуля / проекту це не застосовується

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

Статус "обмеженого тестування" по суті недійсний три з чотирьох аргументів, викладених вище, за винятком одного про "добропорядного продавця", проти якого можна протиставити надання анекдотичних доказів історії успіху (анекдотичні докази, ймовірно, не допоможуть для "великої зміни", але для обмежене тестування досить добре).

Якщо зміна дійсно варте і тестовий запуск влаштовано належним чином, ви помітите позитивний зсув у ставленні команди та керівництва, зробивши перехід до повномасштабних змін плавним і безболісним.

Ще одна перевага обмеженого пробного запуску полягає в тому, що він дозволяє уточнити та відкоригувати деталі цільового процесу, не завдаючи зайвих проблем і з меншим ризиком "пошкодження репутації" ідеї. Кожен раз, коли я брав участь у таких тестових запусках , я був приємно здивований, дізнавшись, наскільки плавно переходити до повномасштабного прийняття з найважливішими деталями, встановленими та уточненими на тестовому запуску.

Можливо, настав час набрати керівництво. Якщо ви спробували і побачили надійні результати, але команда працює, керівництво, можливо, доведеться залучати.

Це особливо актуально, якщо вони завдають шкоди компаніям, які є найпродуктивнішим членом команди. Будьте готові до люфту. Ви можете почати з підходу до управління та прагнуть, щоб команда перестала підривати вас, виймаючи свої тестові справи.