Работая с продуктовыми командами разработки, я чаcто наблюдал два сценария написания требований к разрабатываемому продукту, и у обоих сценариев есть перекос в одну или в другую сторону:

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

2.Или же обратная сторона, когда мы уделяем слишком много времени анализу бизнес-требований, создавая огромные толмуты документации, с UML-диаграммами и доскональной проработкой всего. Таких требований получается в переизбытке, что в итоге их никто не читает или же читает наискосок. А еще сложнее такие требования менять и поддерживать.

В этой статье я хочу поделиться легковесным подходом к созданию бизнес-требований (acceptance-test driven developement или ATDD), который фокусирует команду на пользователях и бизнесе и улучшает понимание того, что мы делаем. И вдобавок встраивает качество в процесс разработки.

Читать далее

https://habr.com/ru/post/679376/?utm_source=habrahabr&utm_medium=rss&utm_campaign=679376