{"id":14255,"url":"\/distributions\/14255\/click?bit=1&hash=285b001e00cf7484224a6ff681b6d172d7d7337a0afbdd4342d725cf62cb249b","title":"\u0411\u044b\u043b\u0438 \u0432 \u0434\u0435\u0441\u044f\u0442\u043a\u0430\u0445 \u043e\u0442\u0435\u043b\u0435\u0439, \u043d\u043e \u043d\u0438 \u043e\u0434\u0438\u043d \u043d\u0435 \u0432\u043f\u0435\u0447\u0430\u0442\u043b\u0438\u043b?","buttonText":"\u0427\u0442\u043e \u0434\u0435\u043b\u0430\u0442\u044c","imageUuid":"4c6db631-4d4c-530c-9750-cf992e251f9d"}

Описание задач: блоки и принципы

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

Меня зовут Эдуард Аитов. Я Team Lead команд Токио и Берлин в медицинской компании “СберЗдоровье”. В этой статье я расскажу о частых проблемах в описаниях задачи, способе их решения и основных критериях качественной задачи.

Некоторые проблемы описания задачи

Постановка задачи — только на первый взгляд простой процесс. На самом деле он часто напоминает игру в «Сапёра», где каждое неверное действие может привести к известному результату: неверно объяснил суть задачи исполнителю и получил тыкву вместо новой фичи для приложения.

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

  • Описание, основанное на текущем контексте. Часто при описании задачи заказчик исходит из того, что он погружен в процесс и знает все подводные камни. В итоге из описания выпадает все то, что кажется очевидным. На практике это часто приводит к тому, что ни исполнитель, ни сам заказчик через некоторое время уже не могут понять, что имелось ввиду и какие есть неочевидные нюансы.

  • Нет критериев приемки. Если в задаче не описано, что должно получиться в итоге, есть шанс получить не тот результат, который ожидается. Особенно это актуально для задач, которые выполняются «в вакууме», то есть без контекста.

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

В итоге сочетание таких ошибок приводит к созданию плохого описания, с которыми раньше нам приходилось сталкиваться и в СберЗдоровье.

Реализовать API для новой карточки врачей

Для фронта требуется отдавать новый список параметров для карточки врачей, который описан в задаче [...]

Здесь на первый взгляд все понятно — надо реализовать API для новой карточки врачей. Но нет ни критериев приемки, ни шагов по реализации, ни бизнес-целей — в итоге задача напоминает выражение из сказки: «Поди туда — не знаю куда. Принеси то — не знаю что».

Пути решения

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

Причин сепарирования задачи на блоки несколько.

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

2. Разным ролям чаще нужны определенные блоки. Так:

  • стейкхолдеру важнее понимать бизнес-ценность;

  • разработчику в процессе реализации — нужно техническое описание шагов, которые следует сделать;

  • тестировщику или ревьюверу — критерии приемки задачи.

3. Можно передать максимальный контекст. Заказчику значительно рациональнее и проще качественно описать задачу, а не отвечать потом в личных сообщениях на ряд вопросов по ней.

В своей команде я придерживаюсь разделения на три логических блока: Why, What, DoD.

  • Первый блок — Why. Призван объяснить исполнителю, почему нужно сделать задачу — дает понимание, чего именно нужно добиться в рамках реализации. Например — «Для эффективной работы с Sentry, требуется провести ревизию ошибок». Такое краткое, но емкое объяснение поможет разработчику или другому специалисту учитывать контекст и зависимости, а также искать возможные способы реализации.
  • Второй блок — What. Нужен, чтобы конкретизировать задачу и объяснить, что именно надо сделать. Как правило, в блоке What прописывают набор действий, необходимых для реализации. При этом важно, чтобы это был не строгий манифест, а просто перечень действий — в таком случае у исполнителя будет свобода «маневра» для выбора подходов, инструментов и вариантов решения.

    Помимо этого, блок What также можно использовать для последующей оценки задачи — посмотрев, что требовалось реализовать, проверяющий может понять, насколько результат соответствует ожиданиям.

  • Третий блок — DoD (Definition of Done). Содержит критерии приемки, по которым можно понять, что задача завершена. Фактически Definition of Done — контракт между исполнителем, автором и проверяющим, который позволяет исключить дополнительные вопросы. DoD можно использовать в качестве чек-листа, с помощью которого исполнитель будет видеть, что от него требуется, а остальные — что сделано или что нужно проверить. Таким образом DoD уменьшает вероятность ошибки.

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

Реализовать API для новой карточки врачей

Why

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

What

1. URL итогового запроса: GET [...]

2. Входящие/возвращаемые параметры: [системный анализ]

3. Написать тесты: unit, api

4. Написать API документацию

DoD

Реализован новый метод API для карточки врачей, написаны тесты и документация

Кроме этого, в описание можно добавлять опциональный блок, который прописывают уже после реализации — QA Notes. Фактически это небольшая заметка, в которой исполнитель, максимально погруженный в суть задачи и особенности реализации, может подсказать проверяющему, что стоит проверить тщательнее, как сделать тест быстрее и качественнее. QA Notes — необязательный, но полезный блок, который помогает ускорить проверку.

Реализовать API для новой карточки врачей

Why ...

What ...

DoD ...

QA Notes

Протестировать URL:<...> с наборами параметров <...>, <...>, <...>, ожидаемое поведение: <...>

Документация API: <...>

Проверить негативные кейсы: <...>

Критерии качества задачи: INVEST

Наряду с разделением на логические блоки, также важно приводить описание задачи в соответствие критериям качества. Такие, например, декларирует набор принципов INVEST (INVEST — аббревиатура от названия шести принципов).

  • Independent — задача должна быть независимой. Ее выполнение не влияет на другие процессы. При этом, если ряд задач являются тесно связанными, их следует объединить в одну. Например, написание тестов тесно связано задачей по реализации функционала.
  • Negotiable — задача должна иметь пространство для маневра. Исполнитель должен иметь возможность обсуждать детали реализации во время выполнения. Он не должен быть в заранее установленных жестких рамках, а должен иметь возможность влиять на задачу.
  • Valuable — задача должна приносить бизнес-ценность. Даже если сама по себе задача может не привести к созданию полноценной, готовой к выпуску функции, она должна быть измеримым шагом на пути к этой цели — быть наглядной и показывать, что прогресс был достигнут.
  • Estimatable — должна быть возможность оценить задачу. Перед началом выполнения задачи должна быть возможность четко обозначить ее сроки. Если такой возможности нет — задача сформулирована неверно.
  • Small — задача должна быть небольшой. В идеале любая задача не должна занимать более 50% времени итерации. Все, что выходит за пределы этого диапазона в 50% времени итерации, следует считать слишком большим, чтобы его можно было оценить с хорошей степенью уверенности — такие большие задачи стоит выносить в эпики и декомпозировать.

  • Testable — задача должна быть тестируемой. Задачу следует считать завершенной, только если она прошла успешное тестирование. Если задачу невозможно протестировать из-за отсутствия информации или доступов, не следует включать ее в бэклог спринта.

Важно, что принцип INVEST применяется для описания задачи целиком.

Рекомендации: action points на основе наших советов

  • Попробуйте применить принцип Why - What - DoD при постановке задач. Простой подход с разделением описания на блоки позволит повысить качество задач с минимальным оверхедом. Мы приняли его в одной из команд и увидели улучшение качества.

  • Если после реализации задачи вы можете помочь в ее тестировании, добавьте блок QA Notes в задачу с описанием проверок.

  • Проверяйте качество поставленной задачи на соответствие принципам INVEST. Часто задача может не соответствовать некоторым пунктам из INVEST, но само понимание этих принципов поможет сделать задачи качественнее.
0
Комментарии
-3 комментариев
Раскрывать всегда