Кто про что, а я продолжаю о наболевшем. Так вот, после осознания для чего мне делать дело (боль снята вопросом "Что ты будешь делать с результатом задачи"), может возникнуть острая боль от синдрома "Хреново описанная задача". Это уже боль не одной души, а сразу нескольких, эмпатично усливающаяся по мере продвижения задачи по просторам jira. У меня есть несколько правил, которые я прошу соблюдать каждую команду с которой работаю. Мне помогает, может и вам пригодится: 1. Задача должна быть атомарной. Требование в задаче не должно вызывать конфликтов, перекрывать другие требования\задачи, быть кратким и ясным.​ Сама задача должна быть про одну работу (например, вам нужно выводить пользователю на какую-то форму из справочника ИНН и название организации, в форме нет такого поля, в справочнике нет атрибута ИНН, в этом случае - добавить на форму поле вывода сведений из справочника и добавление новых атрибутов в тот же справочник - это 2 задачи). 2. Задача должна быть полной, т.е. восприниматься изолированно, для его понимания не должны требоваться вспомогательные материалы, кроме ссылки на конкретный пункт\абзац спецификации требований в конфл. ​или текстовом документе. 3. Задача (реализация задачи) должна быть проверяема - должен существовать как минимум один способ однозначно проверить, что задача выполнена.​ Например, если это задача на анализ - по результату должна быть спецификация, и ее можно посмотреть. Если разработка - должно быть указано, где в репозитории версия с этой задачей, и каким тест-кейсом ее проверять; если тестирование - должен быть отчет о тестировании, хотя бы в комментарии, но со скринами\видео теста. 4. Задача должна быть связана с функцией или фичей (я прошу указывать это меткой типа Фича1, кто-то делает это иерархической организацией задачи в стори), бизнес-требованиями (указаны в тексте задачи с указанием пунктов ТЗ или номеров и дат протоколов, писем с запросами) и модулем (указан компонент).​ 5. Задача должна читаться и восприниматься всеми имеющими к ней отношениями однозначно и использовать принятую терминологию и паттерны.​ Если у вас принят термин "Натянуть ролёвку на модуль" для задачи не надо изобретать что-то иное типа "имплементировать модель распределения привилегий в бизнес-компонент". 6. Миссия должна быть выполнимой. Требование должно быть выполнимым с приемлемым риском в рамках таких ограничений, как стоимость, график, технические, правовые, этические, нормативные требования и безопасность.​ 7. Длительность задачи - 6 часов или меньше. Если вдруг задача больше, лучше ее распилить на несколько - менеджеру будет проще управлять, разработчику проще работать в границах рабочего дня, аналитику не нужно писать трактат обо всём.