Чеклист описания задач для разработчиков https://cdn.tough-dev.school/materials/8-task-rules.pdf Нравятся все пункты. Но добавлю пару комментариев: 1️⃣ Пункт 4 «указана методика тестирования», я бы заменил на «how to demo», т.к. тестирование все таки более глубокий процесс. 2️⃣ Под задачей в данном чеклисте подразумевается целая фича - epic, а не отдельная user story. И немного замечаний к примерам далее. Первый пример - Делаем промо-коды для дня рождения Заголовок содержит избыточное «делаем». Представьте беклог, в котором все задачи начинаются с «делаем». Зачем каждый раз писать это слов и тратить на него экранное место?… Подобные слова лучше не использовать в заголовках. К тому же, авторы сами говорят о том, что задача должна описывать результат, а не процесс. Как улучшить: озаглавить задачу «Промо-коды для дня рождения» - этого достаточно. Второй пример - «тип сотрудника» в отчетах для бухгалтерии Тут у меня вопросов нет, пример отличный. Третий пример - отрефакторить подсистему логистики С первого взгяляда пример показался хорошим. Но взглянув на него глазами разработчика, всплыли проблемы: Во-первых, заголовок «отрефакторить» никак не специализирует решаемую проблему. Во-вторых, по сути, в этом примере бизнесовая задача спрятана за технический термин. По определению, рефакторинг - это процесс изменения структуры кода без изменения его функциональных свойств. Тут же в систему добавляются новые фичи - поддержка нескольких партнеров, алгоритмы выбора между ними. Это явно новое бизнес-требование, а не «рефакторинг». В-третих, сама задача очень туманная. Про будущее много предположений, а про настоящее - требований мало. Так разработку может унести в проработку решения сильно наперед. Как улучшить: Заголовок: «Поддержка нескольких партнеров для доставки» Текст: <убрать все гипотезы на будущее, уточнить как будем добавлять новых поставщиков в будущем> И не дискредитировать слово «рефакторинг», пряча за него бинесовые задачи! =) И напоследок, замечу, что чем раньше обнаруженна ошибка - тем дешевле ее исправить. Поэтому ошибки в понимании задачи - самые дорогие. Следовательно, самый главный пункт чеклиста - это пункт 4 how to demo. Ведь этот пункт призван заранее дать команде понимание, как заказчик будет проверять, удовлетворяет ли результат его ожидания.