Автор статьи: Дмитрий Курдюмов
Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.
Работая с продуктовыми командами разработки, я чаcто наблюдал два сценария написания требований к разрабатываемому продукту, и у обоих сценариев есть перекос в одну или в другую сторону:
Большой фокус в требованиях уделяется функциональной и технической части, то есть тому, чтобы описать, как это будет работать с технической части при отсутствии важной части требований про пользователя и его потребности и сценарии. Условно говоря, когда у заказчика появляется еще одно требование, то вместо того, чтобы сначала понять, как это будет работать со стороны пользователя, мы сразу начинаем думать про техническую реализацию и бежим скорее делать. Это приводит к тому, что на старте мы упускаем важные пользовательские сценарии и делаем много лишнего и ненужного.
Или же обратная сторона, когда мы уделяем слишком много времени анализу бизнес-требований, создавая огромные толмуты документации, с UML-диаграммами и доскональной проработкой всего. Таких требований получается в переизбытке, что в итоге их никто не читает или же читает наискосок. А еще сложнее такие требования менять и поддерживать.
В этой статье я хочу поделиться легковесным подходом к созданию бизнес-требований (acceptance-test driven developement или ATDD), который фокусирует команду на пользователях и бизнесе и улучшает понимание того, что мы делаем. И вдобавок встраивает качество в процесс разработки.
ATDD — разработка, основанная на приемочных тестах. Смысл в том, что, прежде чем писать код, мы создаем приемочные сценарии, чтобы под них уже писать код. И важно их создавать вплотную с бизнесом. Как правило, подход ATDD предполагает то, что мы собираемся с бизнес-заказчиком (или продактом, который является голосом заказчика и заинтересованных лиц) и командой (включая аналитиков, разработчиков и тестировщиков) и моделируем сценарии использования вместе, а далее под эти сценарии пишем код. Сценарии пишутся не со стороны технической реализации, а со стороны пользователя, чтобы учесть важные потребности.
Почему стоит собираться всей командой, включая разработчиков, тестировщиков дизайнеров и всех всех?
Во-первых, ваша команда получает все требования от первоисточника и лучше понимает, что необходимо сделать. Во-вторых, вам требуется меньше времени на то, чтобы потом обьяснить требования команде и вы не будете выступать испорченным телефоном. В-третьих — качество сценариев и их полнота будут лучше, так как участвует каждый. И четвертое — вся команда сможет задать интересные вопросы с разных углов зрения и разобрать сценарии вместе.
Порой на разработку требований уходят недели, и еще недели, чтобы донести это правильно до разработки, а потом еще недели на то, чтобы переделать, так как контекст в разработке мог потеряться. Здесь же на такую рабочую сессию вы можете уделять пару часов в неделю всей командой и иметь одинаковую и полную картинку у всей команды.
Как это делать на практике?
В начале любое требование бизнеса стоит сформулировать в пользовательской истории, то есть в контексте того,
Кто будет взаимодействовать с продуктом (персона).
Что будет делать (действие).
Зачем ему это нужно (цель).
Допустим, у вас есть пользовательская история:
Я, как пользователь мобильного банка, хочу понимать свои расходы за период, чтобы их оптимизировать. Имея такую пользовательскую историю нам в команде уже лучше понятен контекст того, что необходимо сделать и для чего.
А далее с помощью фреймворка Given - When - Then мы начинаем формулировать приемочные тесты.
Given — описывает состояние системы в данный момент времени.
When — описывает действие.
Then — что меняется после выполнения действия.
Пример:
Если я — клиент банка и у меня есть расход за период Х рублей.
То, когда я совершаю покупку на Y рублей,
В расходах я должен увидеть сумму расходов за период (день/неделя/месяц) сумм (Х;Y).
Если я — клиент банка и у меня есть расход за период Х рублей,
И, когда я совершаю возврат ранее совершенной покупки на Y рублей,
В расходах за тот период я должен увидеть сумм (Х;Y)-Y.
И так далее. В процессе диалога бизнеса и команды у вас рождаются сценарии.
Какие плюсы в итоге мы имеем:
Главное преимущества данного подхода в том, что он запускает диалог между бизнесом и командой и дает взгляд со стороны пользователя.
Следующее преимущество в том, что вы не просто начинаете писать код, реализовывая абстрактные технические требования от аналитика, а вы пишите код и сразу тестируете себя. То есть делаете так, чтобы приемочные сценарии отрабатывали. Эти сценарии также легко автоматизировать, чтобы проверять себя до тех пор, пока не отработает тест.
В конце разработки и заказчику и команде и продакту проще принимать работу, так как вы разговариваете на одном языке и вы вместе эти сценарии создавали. Возникает меньше конфликтов и двусмысленных требований.
Основной риск — не уйти в излишние детали. Не старайтесь продумать все до мелочей, выделите главные сценарии, которые вы хотите увидеть в первой версии вашего нового решения, а затем в следующий версиях уже улучшайте с помощью новых сценариев.
Если же вы видите, что сценариев получается слишком много, что они не умещаются в спринт, разделите пользовательскую историю на несколько и делаете последовательно. Также не надо забывать, что данные сценарии можно приоритизировать.
Как получить максимум от ATDD?
В добавок к ATDD использовать подход Test-driven developemnt (TDD) при разработке новой функциональности.
TDD полностью меняет традиционную разработку. Вместо того, чтобы писать код, вы сначала пишите unit-тест на небольшую функциональность. И далее пишите код до тех пор, пока тест не будет пройден. Данный подход позволяет встроить качество в разработку и сделать процесс тестирования — не этапом в разработке, а постоянным процессом проверки качества.
Также TDD является источником технической документации для команды. Хорошо написанные unit-тесты предоставляют рабочую спецификацию вашего функционального кода — и в результате модульные тесты фактически становятся значительной частью вашей технической документации. Точно так же приемочные тесты могут составлять важную часть вашей документации по требованиям.
Что имеем в итоге:
В начале мы создаем приемочные тесты вместе с заинтересованными лицами и заказчиками вместе с командой. Далее ориентируемся на них при разработке кода. Процесс разработки дополняем unit-тестами, которые пишутся перед тем, как начать писать код и проверяем, чтобы по каждой функции в коде отрабатывал тест. В конце разработки собираемся командой и бизнесом, смотрим работающее решение и собираем обратную связь.
Если вам понравилась статья, приходите в Telegram-канал Дмитрия.
Скоро в OTUS состоится открытое занятие «Проблемный заказчик», на котором обсудим:
— Типы заинтересованных сторон и как определить?
— Конфликт (что это, как с этим работать)
— Стратегии работы с конфликтными заинтересованными сторонами — работа над собой и самообладание (что, если проблема во мне?)
Регистрация доступна по ссылке.