The post has been translated automatically. Original language: Russian
This is the eighth part of a series about BDD. In the seventh part, "Typical Mistakes and Antipatterns," we 've figured out what's going wrong. In the ninth, "The Pros, Cons, and When BDD is not Needed," let's summarize the entire series.
Knowing what BDD is and implementing it in a team are different tasks. Let's look at how to do this with minimal risks.
Step 1. Select the pilot function
A good candidate:
• with complex rules and a few exceptions;
• where there have been disputes or alterations before;
• small: for 2-3 days of development.
A bad candidate: a technical task with no business rules or a huge feature for a month.
Step 2. Agree on the roles
Determine who will take on the role of business, development, and testing. If there is no business expert in the team, decide in advance who they will be and how much time they are willing to devote.
Step 3. Have your first meeting
A simple template for 30-40 minutes:
1. The product manager or analyst briefly explains the purpose of the function (5 minutes).
2. The team takes turns naming rules and examples (20 minutes).
3. All red questions are recorded, and a responsible person and a deadline (5 minutes) are assigned for each one.
4. We decide whether the function is ready for development (5 minutes).
Step 4. Create a common vocabulary
The terms of the subject area need to be fixed. For example, booking a meeting room:
| Term | Which means |
| Booking | A record of that room employed by an employee for a specific time |
| Intersection | A situation where there are two bookings partially or completely coincide in time |
| Butt to butt | One booking ends exactly Then when the other one starts |
The dictionary is stored in the repository next to the scripts and is updated with them.
Step 5. Determine where to store and how to check the scripts.
• .The feature files are in the repository next to the code.
• Script changes are reviewed in the same way as the code, with the reviewer checking the wording as well.
• Scripts are run in CI.
Step 6. Evaluate the result
Don't count the number of scenarios: This is a metric activity, not benefit. It is more useful to observe such indicators:
• how many questions and ambiguities were found before the start of development;
• how many alterations and bugs are associated with a misunderstanding of requirements (compare with similar functions before the pilot);
• How long do meetings take and do they pay off?;
• how much the team trusts the tests: are there any "reds" who ignore everything.
The pilot is usually evaluated after a few weeks. The timing depends on the size of the team and the frequency of releases.
How to deal with resistance
• "This is unnecessary bureaucracy." Start with one meeting and one function, show specific questions found.
• "Business has no time." Shorten the meeting to 30 minutes and come with a draft of the examples.
• "Developers are bored writing scripts." Automate only those rules that are important to the business, and leave the rest to unit tests.
• " Everything works for us anyway." Then maybe you don 't need BDD yet. Come back to the question when there are disputes about the requirements.
Result
BDD implementation starts small: one function, one meeting, multiple scenarios. If you see fewer misunderstandings after a few weeks , continue to expand your practice. In the final part, "The pros, Cons, and when BDD is not needed," let's evaluate the entire approach.
How would you start implementing it in your team? What function would be suitable for a pilot?
Это восьмая часть серии о BDD. В седьмой части, «Типичные ошибки и антипаттерны», мы разобрали, что идёт не так. В девятой, «Плюсы, минусы и когда BDD не нужен», подведём итог всей серии.
Знать, что такое BDD, и внедрить его в команде — разные задачи. Разберём, как сделать это с минимальными рисками.
Шаг 1. Выберите пилотную функцию
Хороший кандидат:
• со сложными правилами и несколькими исключениями;
• в которой раньше возникали споры или переделки;
• небольшая: на 2–3 дня разработки.
Плохой кандидат: техническая задача без бизнес-правил или огромная функция на месяц.
Шаг 2. Договоритесь о ролях
Определите, кто выступит в роли бизнеса, разработки и тестирования. Если эксперта по бизнесу в команде нет, заранее решите, кто им будет и сколько времени он готов уделять.
Шаг 3. Проведите первую встречу
Простой шаблон на 30–40 минут:
1. Продукт-менеджер или аналитик кратко объясняет цель функции (5 минут).
2. Команда по очереди называет правила и примеры (20 минут).
3. Все красные вопросы фиксируются, для каждого назначается ответственный и срок (5 минут).
4. Решаем, готова ли функция к разработке (5 минут).
Шаг 4. Заведите общий словарь
Термины предметной области нужно зафиксировать. Для примера с бронированием переговорной:
| Термин | Что означает |
| Бронь | Запись о том, что комната занята сотрудником на конкретное время |
| Пересечение | Ситуация, когда две брони частично или полностью совпадают по времени |
| Встык | Одна бронь заканчивается ровно тогда, когда начинается другая |
Словарь хранится в репозитории рядом со сценариями и обновляется вместе с ними.
Шаг 5. Определите, где хранить и как проверять сценарии
• .feature-файлы лежат в репозитории рядом с кодом.
• Изменения сценариев проходят ревью так же, как код, причём ревьюер проверяет и формулировки.
• Сценарии запускаются в CI.
Шаг 6. Оцените результат
Не считайте количество сценариев: это метрика активности, а не пользы. Полезнее наблюдать за такими показателями:
• сколько вопросов и неясностей нашли до начала разработки;
• сколько переделок и багов связано с недопониманием требований (сравните с похожими функциями до пилота);
• сколько времени занимают встречи и окупаются ли они;
• насколько команда доверяет тестам: есть ли «красные», которые все игнорируют.
Пилот обычно оценивают через несколько недель. Сроки зависят от размера команды и частоты релизов.
Как справиться с сопротивлением
• «Это лишняя бюрократия». Начинайте с одной встречи и одной функции, покажите конкретные найденные вопросы.
• «Бизнесу некогда». Сократите встречу до 30 минут и приходите с готовым черновиком примеров.
• «Разработчикам скучно писать сценарии». Автоматизируйте только те правила, которые важны бизнесу, а остальное оставьте юнит-тестам.
• «У нас всё и так работает». Тогда, возможно, BDD вам пока не нужен. Вернитесь к вопросу, когда появятся споры о требованиях.
Итог
Внедрение BDD начинается с малого: одна функция, одна встреча, несколько сценариев. Если через несколько недель вы видите меньше недопониманий, продолжайте расширять практику. В заключительной части, «Плюсы, минусы и когда BDD не нужен», оценим подход целиком.
С чего бы вы начали внедрение в своей команде? Какая функция подошла бы для пилота?
Share
