В каком виде передавали задачи?

Методы передачи задач в iOS-разработке

В профессиональной iOS-разработке задачи передаются в структурированной формализованной форме, а не как простые текстовые описания. Основные виды:

1. Issue/Ticket в системах управления проектами (JIRA, GitHub Issues, Linear)

Это основной формализованный вид. Каждая задача содержит:

Title: [iOS] Реализовать кастомный переход между экранами профиля
Description:
- Цель: Анимированный переход при тапе на аватар
- Требования:
  - Использовать UIViewPropertyAnimator
  - Длительность: 0.5 секунды
  - Curve: easeInOut
- Критерии приемки (Acceptance Criteria):
  1. При тапе на аватар экран профиля появляется с масштабированием из центра аватара
  2. Возврат к предыдущему экрану через swipe-down
  3. Поддержка iOS 14+
- Ссылки:
  - Дизайн: [ссылка на Figma]
  - Аналоги: ветка #432 (переход в галерее)
- Технические заметки:
  - Использовать протокол TransitionCoordinator
  - Интеграция с существующим NavigationController

2. Технические спецификации (Tech Spec) для сложных задач

Для архитектурных изменений или сложных функций создается отдельный документ:

// Пример структуры Tech Spec для новой фичи

Feature: Offline Mode для карт
Specification Version: 1.2

## Архитектура
1. Создать новый модуль `MapCacheModule`
2. Использовать паттерн Repository:
   - `MapRepository` (публичный интерфейс)
   - `LocalMapStorage` (CoreData)
   - `RemoteMapService` (Network)

## Ключевые классы
protocol MapCacheProtocol {
    func saveRegion(_ region: MapRegion) async throws
    func loadRegion(by id: String) async throws -> MapRegion?
}

class MapCacheManager: MapCacheProtocol {
    private let storage: LocalMapStorage
    private let network: RemoteMapService
    // ... implementation
}

3. User Story с критериями приемки

В Agile-подходах задачи часто формулируются как User Stories:

Как пользователь,
Я хочу сохранять любимые места на карте,
Чтобы быстро находить их без повторного поиска.

Критерии приемки:
- Возможность тапать на место и добавлять в "Избранное"
- Отдельный раздел в меню с списком избранных мест
- Синхронизация избранных мест между устройствами (если пользователь залогинен)

4. Задачи на рефакторинг или технические улучшения

Для таких задач используется особый формат:

Refactor: Убрать Force Unwrap в модуле Payment
Current State: 15 случаев force unwrap (`!`) в PaymentProcessor
Target State: 0 force unwrap, использование безопасного unwrapping через guard/if let
Approach:
1. Заменить все `let amount = payment.amount!` на `guard let amount = payment.amount else { return }`
2. Добавить логирование для случаев nil
3. Обновить тесты для покрытия nil-сценариев

5. Code Review задания через Pull Request (GitHub/GitLab)

После завершения задачи код передается через Pull Request с детальным описанием:

## Что сделано
- Реализована кастомная анимация перехода между ProfileViewController и AvatarViewController
- Добавлен новый класс ProfileTransitionAnimator, реализующий UIViewControllerAnimatedTransitioning

## Изменения в архитектуре
- Расширен AppCoordinator для поддержки custom transitions

## Тестирование
- Добавлены UI-тесты для проверки анимации
- Обновлены snapshot-тесты для новых состояний

## Особенности реализации
- Использовал UIPresentationController для управления контекстом
- Анимация основана на CGAffineTransform с ключевыми кадрами

Ключевые принципы передачи задач

• Детализация: Каждая задача должна содержать достаточную информацию для реализации без дополнительных уточнений
• Измеримость: Критерии приемки позволяют четко определить завершение задачи
• Контекст: Ссылки на связанные задачи, дизайн, документацию
• Техническая ясность: Для разработчика должно быть понятно, какие технологии/паттерны применять

В профессиональных командах передача задачи — это не просто "сделать фичу", а четкий контракт между менеджером/дизайнером и разработчиком с конкретными требованиями, критериями завершения и техническими ограничениями. Это минимизирует недоразумения и повышает качество конечного продукта.