Как получал задачи в проекте?

Получение и управление задачами в проекте

Это практический вопрос, который показывает понимание workflow'а и коммуникации в команде. Рассмотрю реальный процесс получения и выполнения задач.

Типичный процесс

1. Получение задачи из Jira / Linear / GitHub Issues

// Пример Jira тикета
┌─────────────────────────────────────┐
│ TASK-1234: Optimize user endpoint   │
├─────────────────────────────────────┤
│ Status: In Backlog -> Ready         │
│ Priority: High                      │
│ Assigned to: me                     │
├─────────────────────────────────────┤
│ Description:                        │
│ Current: GET /api/users takes 500ms │
│ Expected: < 100ms                   │
│ Reason: Missing database indexes    │
├─────────────────────────────────────┤
│ Acceptance Criteria:                │
│ - Query time < 100ms                │
│ - All tests pass                    │
│ - No breaking changes               │
│ - Performance metrics documented    │
├─────────────────────────────────────┤
│ Story Points: 5                     │
│ Sprint: Sprint 42                   │
└─────────────────────────────────────┘

2. Уточнение и обсуждение (очень важно!)

// Перед началом работы я:

// 1. Задаю вопросы в комментариях тикета
Comment: "Есть ли данные о текущей производительности? 
          Нужны ли метрики для мониторинга?
          Какова максимальная нагрузка на endpoint?"

// 2. Проверяю что всё понимаю
Comment: "Понимаю так: нужно добавить индексы на колонки 
          которые используются в WHERE и JOIN. 
          Правильно ли я? Есть ли ещё факторы?"

// 3. Обсуждаю подход
Comment: "Предлагаю: 
          1. Добавить индекс на user_id
          2. Добавить pagination для больших результатов
          3. Добавить кеширование в Redis
          Какой подход лучше по вашему мнению?"

Рабочий процесс (Workflow)

Шаг 1: Планирование (Planning)

# На планинге (планирования спринта):
# Я выбираю задачи которые реально могу сделать за спринт

# Факторы:
- Сложность (Story Points)
- Зависимости от других задач
- Мой текущий workload
- Потребность команды

# Я НЕ выбираю:
- Невозможные задачи
- Задачи без описания
- Задачи которые ждут других

Шаг 2: Разработка

// Процесс выполнения задачи

// 1. Создаю ветку от основной
git checkout -b feat/TASK-1234-optimize-users

// 2. Пишу тесты ПЕРВЫМИ (TDD)
// tests/integration/users.service.spec.ts
describe('UsersService.getAll', () => {
  it('should return all users in < 100ms', async () => {
    const start = Date.now();
    const users = await service.getAll();
    const duration = Date.now() - start;
    
    expect(duration).toBeLessThan(100);
    expect(users).toBeDefined();
  });
});

// 3. Пишу код
// users.service.ts
@Injectable()
export class UsersService {
  async getAll(): Promise<User[]> {
    // Добавляю индексы через миграцию
    // Оптимизирую SQL запрос
    return this.repository.find();
  }
}

// 4. Проверяю тесты
npm run test

// 5. Проверяю lint
make lint

// 6. Коммитю с хорошим сообщением
git commit -m "feat(users): optimize GET /users endpoint

- Add database index on user_id
- Use pagination for large result sets
- Add Redis caching layer
- Reduced query time from 500ms to 50ms

Closes TASK-1234"

Шаг 3: Code Review

// Я создаю Pull Request
// Описание PR должно быть полным

/* PR Description:

## Summary
Optimized GET /users endpoint to meet < 100ms SLA

## Changes
- Added index on users.id column
- Implemented pagination (limit 100)
- Added Redis cache with 5min TTL
- Updated tests to verify performance

## Performance Impact
Before: 500ms average
After:  50ms average
Improvement: 10x faster

## Testing
- All tests pass: npm run test
- Performance test: npx autocannon -c 100 -d 30 http://localhost:3000/users
- Load tested with 1000 concurrent requests

## Checklist
- [x] Tests pass
- [x] Lint passes
- [x] No breaking changes
- [x] Documentation updated
- [x] Performance metrics verified
*/

Во время Code Review:

Comments from reviewer:
"Good approach, but why Redis cache? 
 Database query is already fast after indexes."

My response:
"True! For this version I'll remove Redis caching.
 Added it thinking of future N+1 problems but it's not needed now.
 Removing to keep it simple (KISS principle)."

Шаг 4: Merge и Deployment

# После approval от 2+ reviewers
# PR автоматически мержится (если CI зелёный)

# Код переходит в staging
# Полное тестирование

# Потом в production
# Мониторим метрики

# Если всё ок - закрываем тикет
# Jira: Status -> Done

Коммуникация во время работы

Если заблокирован

// Я НЕ жду и НЕ молчу!
// Сразу пишу в Slack/Comments

"Заблокирован на TASK-1234:

Проблема: Не знаю как работает new authentication system
Что попробовал: Прочитал документацию, но её нет
Что нужно: Может быть быстрый call с @auth-specialist?
Время: Готов в любой момент"

// Лучше 30 минут болтовни чем 3 дня ожидания

Если найду баг

// Если обнаружу проблему в другом коде:

// Вариант 1: Критичный баг
git create issue "Critical: Database connection leak in PaymentService"
// Сразу пишу в Slack #backend
// Помогаю DEBUG

// Вариант 2: Несущественный баг
git create issue "Tech debt: Unused import in UserController"
// Можно сделать в следующем спринте

Если нужна помощь

Я спрашиваю:
✓ "Привет! У тебя есть 5 минут?"
✓ "Быстро объясни как работает кеширование здесь?"
✓ "Посмотри мой PR когда будет время"

Я НЕ говорю:
✗ "Всё сломалось" (какой код сломал?)
✗ "Это не работает" (что конкретно не работает?)
✗ "Помоги!!" (что нужно помощь?)

Размеры задач и планирование

// Задачи делю на размеры:

// 1. XS (1 point) - 30 минут
// Пример: "Добавить новый field в DTO"
await user.find({ where: { id } });

// 2. S (2 points) - 1-2 часа
// Пример: "Создать новый endpoint"
@Get('users/:id')
async getUser(@Param('id') id: string) {
  return this.usersService.findOne(id);
}

// 3. M (3-5 points) - половина дня
// Пример: "Оптимизировать endpoint с индексом и тестом"

// 4. L (8 points) - 1-2 дня
// Пример: "Переписать module на новый фреймворк"

// 5. XL (13+ points) - сплит на несколько задач!
// ❌ Никогда не беру такие в спринт целиком
// ✅ "Разбей на 2-3 задачи" - мой ответ

Что я делаю неправильно (и учусь)

// ❌ До: Начинал работу без уточнений
// Потом: "Ой, я понял неправильно"
// Потом: Переделывал всё

// ✅ Теперь: Сначала спрашиваю
// Потом: Пишу детальный план
// Потом: Обсуждаю подход
// Потом: Начинаю писать код

// Экономит часы времени!

Метрики которые я отслеживаю

interface MyMetrics {
  // Velocity (сколько points в спринт)
  velocity: 30-35,  // points per sprint
  
  // Quality (сколько багов в готовом коде)
  bugs_per_code_review: 0.5,  // найдено багов на PR
  
  // Speed (как быстро делаю)
  avg_task_hours: 4,  // часов на среднюю задачу
  
  // Collaboration (как работаю с людьми)
  pr_reviews_given: 5,  // сколько PR я review'ю
  help_requests: 3,  // помощь коллегам в неделю
}

Итог

Получение задач это не просто клик по тикету в Jira. Это:

1. Уточнение — полное понимание требований
2. Планирование — выбор правильного подхода
3. Исполнение — качественный код с тестами
4. Коммуникация — информирование команды о прогрессе
5. Сотрудничество — code review и помощь других
6. Мониторинг — проверка что всё работает после merge

Лучший способ получить хорошую задачу — показать что ты можешь хорошо выполнять имеющиеся!