Про груминг требований

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

Груминг требований — это командная практика, в рамках которой происходит уточнение и детализация требований к задаче до начала разработки.

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

Расскажи об опыте груминга ТЗ

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

Участники:

🔘системные аналитики
🔘тестировщики
🔘разработчики

Цели:

🟤Решить проблему излишней декомпозиции за счет более явного описания требований. Изначальный подход — максимально декомпозировать — приводил к потере общей связности требований. Разработчикам было трудно воспринимать большие ТЗ. Фокус решили сделать на четкую и понятную постановку задачи

🟤Сделать оценку времени на выполнение задачи более точной за счет учета мнения всей команды

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

🟤Получать больше информации о технической стороне работы веб-приложения и доносить ее до бизнеса на этапе согласования требований

Как проходил процесс груминга?

У нас была распределенная команда, поэтому собирались онлайн. Тайминг — 1 час. В повестке не более 3 задач. Задачи должны быть по одной теме, например, один функционал / один раздел. Предварительно высылался черновик ТЗ.

Аналитик подробно рассказывал о доработке, а разработчики и тестировщики должны были задавать вопросы. Сначала это приводило к кейсу «все понятно, ок», что говорило о низкой вовлеченности. В итоге стали назначать ответственных разработчика и тестировщика, которым будет отдана задача в работу. Они высказывались по задаче обязательно. Также во время груминга оставляли комментарии по тексту: кто и что предложил. Затем аналитик правил ТЗ и досогласовывал с заказчиком.

Какие плюсы/минусы у этого подхода?

✔️ сокращение числа дефектов из-за неясностей, минимизация двойной работы и работы в стол

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

Основные риски — затянуть обсуждение и уйти в детали, перейти на личности. Аналитику важно быть модератором и заручиться поддержкой «судьи» — того, кто может принять окончательное решение в спорной ситуации, например, лида команды аналитики. Также есть риск упустить нюансы, если задачи обсуждаются «по верхам».

Как ты оцениваешь эффективность этого подхода в вашей команде?

Мы не собирали статистику, но точно были хорошие эффекты для всех участников:

🤎 Для аналитиков — обратная связь от людей с незамыленным взглядом, бо́льшая погруженность в тех. ограничения системы, идеи по упрощению реализации от разработки на начальном этапе
🤎 Для разработчиков — избегание типовых ошибок за счет вовлеченности на раннем этапе, а также минимизация переписывания кода
🤎 Для тестировщиков — возможность на раннем этапе понять чего хочет бизнес. Это снижает неопределенность и дает больше уверенности в том, что баг, а что — нет
🤎 Для заказчика и руководителей — задачи стали точнее оцениваться, ушли кейсы, когда оценка могла быть превышена в 1,5-2 раза

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

📖📖📖

Для меня груминг — это инвестиция в качество, при которой выигрывают все: аналитики получают более четкие вводные, разработчики — меньше переделок, а тестировщики — ясность. Хороший груминг — это вклад в зрелость команды.

#интервьюшная