Ревью требований аналитиков: что, как, зачем. Качественные требования

Привет!
В статье поговорим о тестировании требований.
Наверняка назревает вопрос : а что это за слово странное такое «ревью»? Все очень просто — для корректной постановки задач на разработку необходима проверка требований и согласование их внутри команды. Об этом и поговорим в сегодняшнем посте. Погнали!

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

Ревью требований — по сути обычная проверка того, что написал аналитик. Как вы знаете, аналитик — тоже человек (неожиданно), и ему свойственно где-то допускать неточности, так как зачастую приходится описывать несколько задач за спринт параллельно. Это очень важный этап в работе аналитика: согласовать ФТ лучше не только с заказчиком, но и командой, так как она отвечает за реализацию задачи.

Зачем проверять требования?

Первое. На этапе реализации требований до передачи задачу на разработку важно сделать быть в контексте того, что вообще происходит. Ревью — процесс не всегда приятный, представьте: ресурс тратит почти вся команда и проверяет твою каждую фразу несколько раз. Тем не менее, аналитику это полезно, чтобы понимать, куда ему дальше расти. Даже негативный фидбек позволяет видеть ошибки и стараться не допускать их в дальнейшем. А значит, писать более крутые требования!

Второе. От корректно проведенного ревью зависит развитие продукта: уменьшение количества багов/лишних вопросов на этапе реализации и так далее.

Как проводить ревью?
Я описываю в статье то, какой опыт у меня на работе.
Процесс ревью проходит следующим образом: как только требования зафиналены, я передаю их на проверку другому аналитику, QA, тимлиду и PM. Вы скажете — дофига что-то. На самом деле, это стоит того. Каждый их них просматривает требования по следующим характеристикам:

1) Декомпозиция. Одна страничка на Confluence — одна функциональность. Если вы смотрите на сплошной текст и не видите ему конца и края, требования лучше разбить на подразделы.

2) Однозначность. Всем понятно, для чего используется тот или иной термин, нет двусмысленности в понятиях. Для специфичных терминов заведен глоссарий.

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

4) Тестируемость. Можно ли протестировать функционал? Чтобы помочь QA автоматизировать тест-кейсы, прикладываем в требования пару сценариев использования. Тогда и проверять новую задачу будет легче.

5) Осуществимость. Если тут возникли вопросы, хочется сказать только: «Жалко конечно, этого добряка :( »
Оценку реализации лучше делать до постановки задачи аналитику, но если вопросы возникли на данном месте, когда требования уже написаны, прямая дорога к заказчику на продумывание нового решения. (или, если нам повезло, решение формируется внутри команды)

6) Полнота. Не написано лишнего, но есть все, что нужно. Кратко и желательно сухо: функционал, сценарии, состав данных(и что вам еще надо) . Я люблю прикладывать к требованиям схему процесса в нотации BPMN.

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

Вот как-то так нехитро можно построить процесс проверки требований. И пусть потратить на эту работу час-два бывает очень жаль, лучше делать правки на этапе ТЗ, потому что — Золотая фраза: «на этапе формирования требований изменить проект дешевле всего»

Всем успехов!