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

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

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

• Новая кровь. Когда владельцы продуктов (product owners) формируют требования, они зачастую не закладывают много времени на их тщательное описание. Это происходит из-за нехватки времени и желания как можно раньше начать разработку. Или владелец продукта не знает, как правильно задокументировать требования. В любом случае опыт членов команды и их знание продукта во многом определяет успех хода разработки. Но что происходит, когда новые специалисты приходят на проект? Правильно оформленная документация поможет новым членам команды быстрее познакомиться с проектом и с разрабатываемым продуктом /сервисом. Это особенно важно для больших, долгосрочных проектов, где отсутствие документации может привести к серьезным осложнениям.
• Оценки. Если требования описаны бессистемно, без взаимно понятных правил и четко установленных стандартов, оценить эти требования становится невозможным. Если что-то было упущено в требованиях, а разработчики уже приступили к работе, образуется проблемное место (англ. bottleneck, узкое место — явление, при котором производительность или пропускная способность системы ограничена одним или несколькими компонентами или ресурсами), время теряется впустую и реализация задерживается.
• Планирование. Без стандартизации описания требований разработка достоверных графиков проектных работ будет весьма затруднена. Когда владельцы продукта не предоставляют подробные требования к будущей разработке, страдает качество разрабатываемого продукта из-за большего количества ошибок. На исправление ошибок уходит гораздо большее количество времени, чем прогнозировалось в спринте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

Об авторе

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