В каком виде видишь рабочую задачу, полученную от аналитика

Как видит рабочую задачу Java разработчик от аналитика

В рабочей практике аналитик передаёт задачу в разных форматах, но все они должны содержать необходимую информацию для реализации.

1. User Story (Пользовательская история)

Это наиболее распространённый формат в Agile методологии:

As a [пользователь/роль]
I want [функциональность]
So that [бизнес-ценность]

Criteria (Критерии приёмки):
- Критерий 1
- Критерий 2
- Критерий 3

Example: 
As a Customer
I want to see order history
So that I can track my purchases

Criteria:
- Показать последние 10 заказов
- Отсортировать по дате (новые сверху)
- Показать статус доставки

2. Техническая спецификация (Technical Specification)

Более детальное описание для сложных задач:

Задача: Интеграция платёжной системы Stripe

Описание:
Реализовать возможность оплаты заказов через Stripe

Требования:
- Создать Payment API
- Обработать успешные платежи
- Обработать отказы платежа
- Сохранить информацию о платеже в БД

Технические детали:
- Использовать Stripe Java SDK
- В БД добавить таблицу payments
- Вебхук для подтверждения платежа
- Error handling для всех сценариев

Мок-данные / примеры:
- Stripe test card: 4242 4242 4242 4242
- Успешный платёж должен вернуть transaction_id

Критерии приёмки:
- Сможет обработать 1000 платежей в минуту
- Откат платежа занимает < 5 секунд
- 99.9% успешность обработки

3. Баг репорт (Bug Report)

Название: Исключение при загрузке списка пользователей

Описание:
Когда пользователь открывает страницу со списком юзеров,
происходит ошибка 500 Internal Server Error

Шаги воспроизведения:
1. Войти в систему
2. Перейти на /users
3. Ошибка происходит

Expected: Должен показать список всех пользователей
Actual: 500 Internal Server Error

Логи:
java.lang.NullPointerException at UserService.getUsers:42

Environment:
- Java 17
- Spring Boot 3.1
- PostgreSQL 14

4. Что разработчик ищет в задаче

От задачи я жду:

1. Чёткую цель

• Что нужно сделать?
• Какая проблема решается?

2. Критерии приёмки

• Как понять, что выполнено?
• Когда считается "готово"?

3. Технические детали

• Какая БД? Какие API?
• Есть ли интеграции?
• Какие ограничения?

4. Входные данные

• Примеры API request/response
• Структура данных
• Граничные случаи

5. Нефункциональные требования

• Производительность
• Безопасность
• Масштабируемость

5. Пример "идеальной" задачи

Заголовок: 
Реализовать API для получения статистики продаж

Описание:
Создать REST endpoint для получения ежемесячной статистики продаж
по категориям товаров за последний год.

Требования:
- GET /api/v1/stats/sales?period=monthly&months=12
- Вернуть JSON с суммой продаж по каждой категории
- Кэшировать результат на 24 часа
- Доступно только для role=ADMIN
- Производительность: ответ < 1 сек

Example Request:
GET /api/v1/stats/sales?period=monthly

Example Response:
{
  "data": [
    {
      "month": "2024-01",
      "categories": [
        {"name": "Electronics", "revenue": 15000},
        {"name": "Books", "revenue": 5000}
      ]
    }
  ]
}

Критерии приёмки:
- Endpoint возвращает корректные данные
- Проверка прав доступа работает
- Кэш срабатывает
- Тесты покрывают > 90%
- Производительность < 1 сек для 10k продаж

6. Что делать, если информации недостаточно

Разработчик должен:

• Задать уточняющие вопросы
• Предложить решение
• Согласовать подход с аналитиком
• Документировать решение

Плохо когда аналитик пишет: "Сделай login" Хорошо когда пишет: "Реализовать аутентификацию через JWT с refresh token"

Если задача неясна - задай вопросы в начале, не тратя время на неправильную реализацию.