Читать нас в Telegram

Стандартизация требований в Scrum-проектах

Рубрика: Статьи
1 января 2017 23:52
4870
1

Тема форматов описания требований часто обсуждается бизнес-аналитиками. В этой статье я поделюсь своим опытом в данной области на примере недавнего проекта, где, применяя один стандартизованный формат для описания требований, мы облегчили работу тестировщиков и разработчиков, повысили производительность команды и создали более эффективный поток проектов.

Проблемы при отсутствии стандартов:

Начало и завершение Scrum-проекта

Эффект от стандартизации описаний требований я опишу на примере проекта с одним из наших клиентов — компанией, владеющей социальными сетями и сайтами с миллионной посещаемостью. Представьте себе: быстро развивающийся Agile-проект, амбициозные планы по покорению рынков. Однако вся проектная документация сводилась к описанию текущих процессов разработки и пользовательским инструкциям. Заинтересованные стороны не видели смысла инвестировать в создание сотен страниц документации, что, в целом, было весьма спорно.

У клиента уже была собственная команда разработчиков, тем не менее, он нуждался в большем количестве ресурсов для реализации амбициозных планов. Поэтому с нашей стороны к проекту присоединились аналитики и разработчики. Имелись планы и на команду тестировщиков.

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

Команда была распределенной. Часть разработчиков находилась в США (в разных штатах). Там же жили и владельцы бизнеса, и владелец продукта. Вторая часть команды – в Минске. Также пользователи системы были разбросаны по разным часовым поясам. Постоянное общение по рабочим вопросам было важной частью процесса разработки, поэтому разница во времени создавала дополнительные сложности в работе.

Что было до стандартизации описания требований

До прихода к практике стандартизированного описания требований пользовательские истории были описаны без соблюдения какого-либо конкретного формата: требования не были достаточно подробными, сценарии отсутствовали или были слишком короткими, и в целом такой информации было просто недостаточно для разработчиков. Это привело к негативным последствиям, в том числе:

После стандартизации описания проектных требований

Для улучшения ситуации команда разработчиков начала использовать подход стандартного описания требований с классической структурой:

Как <пользовательская роль/тип>, я хочу <название фичи>, чтобы получить <краткое описание пользы от данной фичи>

В дополнение были сценарии приемки работ, описываемые по следующему шаблону:

Сценарий Приемки 1:

ДАНО (какая-то ситуация/предварительное условие)
И (дополнительные обстоятельства/предварительное условие)
КОГДА (событие/действие, выполненное пользователем)
ЗАТЕМ (ожидаемый результат – что должно произойти для удовлетворения требований пользователя, рассмотренных выше).

Сценарий Приемки 2: …

До этого, когда к проекту присоединялись новые разработчики, которые начинали изучать систему, они мало что могли понять из пользовательских историй вроде «При добавлении агента влияния в очередь система должна показывать нотификацию в панели управления».

Новый формат описания требований значительно облегчил жизнь разработчикам и QA-инженерам — теперь у них появилось полное описание необходимых шагов и ссылки на соответствующие страницы.

Это снизило количество задаваемых вопросов, появилось единое понимание «что есть качество» и его конкретные метрики.

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

Пример пользовательской истории со сценарием приемки:

Пользовательская история:

Как менеджер по обслуживанию клиентов, я хочу иметь возможность исключить членов опроса из результатов поиска, так, чтобы легко различать пользователей, уже добавленных в опрос и еще не добавленных, а также быстро добавлять новых пользователей.

Сценарий приемки*:

Менеджер по обслуживанию клиентов исключает участников опроса из списка членов
ДАНО Менеджер хочет пригласить новых пользователей для участия в опросе
И существуют пользователи, ранее приглашенные для участия в опросе
И появляются новые пользователи, которые еще не были приглашены для участия в опросе
КОГДА выбирается Опрос(ы) в поле «Исключить участников опроса» и применяется фильтр
ТОГДА отфильтрованный список пользователей не должен включать в себя пользователей, которые уже являются членами выбранных с помощью фильтров опросов.

* Указанный выше сценарий стал первичным, он был выбран из трех сценариев для пользовательской истории, которые были созданы для обеспечения полного охвата при выборе функции «фильтр».

Преимущества унификации описания требований

Стандартизация и тестирование

Стандартизированные требования помогают тестировщикам гораздо быстрее понять систему, ее функции и модули. Тестирование становится гладким, а сценарии приемки охватывают все функциональные потоки. В результате время тратится на тестирование системы, а не на ее предварительное изучение. Тестировщики могут также внести свой вклад в полноту описания требований, указав на какой-либо упущенный аспект функции. Кроме того, подробное описание сокращает количество информации о функции или модуле. Недоразумения и неправильные интерпретации, основанные на личных точках зрения, также исключаются.

Управление текущими изменениями в требованиях

Хранение пользовательских историй в JIRA является подушкой безопасности для будущих бизнес-аналитиков проекта, команды разработчиков и всех, кто присоединится к проекту в будущем. Если часть процесса в системе должна быть изменена, проще сделать это благодаря обширным возможностям поиска по ключевым словам в JIRA, где легко найти требования к конкретному сценарию и увидеть, какие сценарии нужно рассмотреть. В данном проекте при осуществлении дополнительных тестов наиболее важных функций надежные и заинтересованные пользователи были назначены «наблюдателями» для выполнения соответствующих задач в JIRA.

Они выполняли тесты приемки на предмет понимания функции и ее готовности к релизу. Также наблюдали за задачей с самого начала, чтобы можно было отследить, что происходит с требованием; проверить его описание, как только оно будет создано, и дать знать бизнес-аналитикам и владельцам продукта о необходимости обновлений.

Вывод

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

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

Об авторе

Елена Бельковская окончила Белорусский государственный университет по специальности в области экономики. До прихода в Itransition работала экономистом. В настоящий момент Елена — бизнес-аналитик, успешно применяющий семилетний опыт работы в ИТ и знания гибких методологий разработки ПО. В работе Елена эффективно использует аналитические навыки в проектах для предприятий, включая разработку требований и управление ими, разработку функциональной и учебной документации, планирование бизнес-анализа и оценки. Реализует коммуникации по проекту, решает вопросы проектирования систем.

Темы: Лучшая практика, Материалы от друзей Tproger, Методологии разработки, Управление проектами
0