Ответ
Идеальный таск — это атомарная, чётко определённая единица работы, которую можно выполнить, протестировать и закрыть без необходимости возвращаться за уточнениями.
Критерии (по аналогии с INVEST):
- Конкретный (Specific): Чётко описано, что нужно сделать.
- Измеримый (Measurable): Есть объективные критерии завершения (Definition of Done).
- Атомарный (Atomic): Охватывает одну логическую функцию или правку. Нельзя разбить на подзадачи без потери смысла.
- Самодостаточный (Self-contained): Содержит всю необходимую информацию для выполнения (ссылки, данные, окружение).
Плохой vs Идеальный таск:
-
Плохо:
"Починить баг с оплатой"- Неясно, что именно не работает, как воспроизвести и какой ожидается результат.
-
Идеально:
Заголовок: Исправить падение API-запроса POST /api/v1/order при пустом поле 'phoneNumber'. Описание: Шаги воспроизведения: 1. Отправить POST /api/v1/order с JSON: {"phoneNumber": "", "items": [1,2]} 2. Наблюдать Internal Server Error 500. Ожидаемое поведение: - Должен вернуться статус 400 Bad Request. - Тело ответа: {"error": "Field 'phoneNumber' cannot be empty"}. Критерии завершения: - [ ] Запрос с пустым phoneNumber возвращает 400 и корректное сообщение об ошибке. - [ ] Существующие юнит-тесты проходят. - [ ] Добавлен новый юнит-тест для этого кейса.
Ответ 18+ 🔞
А, ну ты глянь, какой тут у нас философский трактат про идеальные таски подъехал. Ёпта, да это же целая наука, блядь! Слушай, а ведь если вдуматься, то вся наша работа — это сплошная борьба с распиздяйством, которое начинается с кривого таска.
Вот представь: приходит тебе задачка «Починить баг с оплатой». И ты сидишь такой, чешу репу: «А что, собственно, починить-то, ёпта?». Это ж как прийти к хирургу и сказать: «Чё-то у меня внутри болит, почини». Да он тебе скажет: «Иди нахуй, блядь, с такими вводными, я не экстрасенс!». Так и тут.
А идеальный таск — это, блядь, как чёткий приказ в армии. Не «захватить вон ту хуйню», а «взять высоту 228.7, используя два взвода, подход с севера, артподготовка в 05:30». Всё, пиздец, вопросов нет. Делай.
Вот смотри, как это должно выглядеть, чтобы не было потом «ой, а я думал...»:
Заголовок: Исправить падение API-запроса POST /api/v1/order при пустом поле 'phoneNumber'.
Описание: Шаги, чтобы этот баг воспроизвести, блядь:
- Пнуть на сервер POST /api/v1/order с вот таким JSON:
{"phoneNumber": "", "items": [1,2]}. - Наблюдать, как всё ебётся об асфальт с Internal Server Error 500.
А должно быть так, сука:
- Сервер должен вернуть статус 400 Bad Request, а не пятисотую ошибку, как последний мудак.
- И в теле ответа чётко написать:
{"error": "Field 'phoneNumber' cannot be empty"}. Чтобы фронтендеры не гадали, что случилось.
И вот самое главное — когда таск можно закрывать нахуй:
- [ ] Запрос с пустым phoneNumber возвращает 400 и правильную ошибку.
- [ ] Все старые тесты не сломались (а то починишь одно — десять другого разъебаешь).
- [ ] Написан новый тест специально для этого случая, чтобы этот баг больше не вылезал, как чёрт из табакерки.
Вот это, блядь, и есть работа. А не «починить оплату». Потому что после «починить оплату» обязательно вылезет: «ой, а я имел в виду кнопку на фронте» или «ой, а я думал про другую ошибку в логах». И пошло-поехало, волнение ебать, терпения ноль ебать.
Запомни, чувак: хороший таск — это когда взял, сделал, проверил по пунктам и закрыл. И никто тебе потом не приплетёт, что ты не то сделал. Красота, ёпта!