Как проходил процесс планирования на последней работе

Процесс планирования на последнем проекте

На моем последнем проекте (разработка финансового приложения для Android с командами в разных часовых поясах) мы использовали гибридную методологию, сочетающую элементы Scrum и Kanban с акцентом на предсказуемость поставки и гибкость. Весь цикл можно разбить на несколько ключевых этапов.

Долгосрочное и квартальное планирование (Strategic Planning)

Этот этап проходил с участием Product Owner, Tech Lead и ключевых разработчиков (включая меня как старшего Android-разработчика).

1. Формирование дорожной карты (Roadmap): На основе бизнес-целей и аналитики PO формировал эпики и крупные фичи на квартал вперед. Мы, техническая команда, проводили первичную оценку рисков и архитектурных решений. Например, при планировании интеграции с новой платежной системой мы заранее выделяли время на исследование SDK и прототипирование.
2. High-Level Estimation: Для крупных инициатив мы проводили сессии планирования покера (Planning Poker), чтобы оценить их в story points. Это помогало PO приоритизировать не только по бизнес-ценности, но и по примерной трудоемкости.

Спринтное планирование (Sprint Planning, 2-х недельные итерации)

Каждый спринт начинался с двух встреч:

1. Backlog Refinement/Grooming (за 1-2 дня до планирования):

    *   **Детализация:** PO представлял отобранные для следующего спринта пользовательские истории (User Stories).
    *   **Технический декомпоз:** Мы, разработчики, разбивали истории на конкретные технические задачи в Jira: «Реализация ViewModel», «Интеграция API», «Написание UI-тестов».
    *   **Критерии приемки (DoD):** Совместно с QA уточняли **Definition of Done** для каждой задачи. Например: «Код написан, покрыт unit-тестами, прошел code review, UI соответствует макетам из Figma».

```kotlin
// Пример задачи, вынесенной из декомпоза истории "Отображение истории операций":
// Задача JIRA: AND-123 - Реализация DiffUtil в RecyclerView Adapter для плавных анимаций
class TransactionDiffCallback : DiffUtil.ItemCallback<Transaction>() {
    override fun areItemsTheSame(oldItem: Transaction, newItem: Transaction): Boolean {
        return oldItem.id == newItem.id
    }
    override fun areContentsTheSame(oldItem: Transaction, newItem: Transaction): Boolean {
        return oldItem == newItem // Transaction должен быть data-классом
    }
}
```

2. Сам митинг планирования (Sprint Planning Meeting, 2 часа):

    *   **Цель спринта:** PO формулировал Sprint Goal, например, «Пользователь может увидеть выписку за произвольный период».
    *   **Формирование бэклога спринта:** Команда совместно принимала решение, сколько отрефайненых задач мы берем в спринт, основываясь на своей **скорости (velocity)**. Мы учитывали плановые отпуска, обучение и техдолг.
    *   **Распределение и уточнение:** Задачи распределялись добровольно с учетом экспертизы. Я, как старший разработчик, часто брал задачи, связанные с **архитектурой (Clean Architecture, MVI)** или интеграцией нативных библиотек.

Ежедневное планирование и адаптация

• Дейлики (Daily Standup, 15 минут): Каждый разработчик отвечал на классические три вопроса, но с фокусом на препятствия. Если задача требовала больше времени, чем оценено, мы сразу это обсуждали и, при необходимости, перепланировали.
• Kanban-доска в Jira: Мы визуализировали поток задач. WIP-лимиты (Work In Progress) на этапе «В разработке» помогали избегать многозадачности и выявлять «узкие места» (например, если много задач ждало code review).

Ретроспектива и адаптация процессов

В конце спринта Sprint Retrospective была ключевой для улучшения планирования. Мы анализировали, что пошло не так: регулярно ли «всплывали» непредвиденные сложности? Были ли оценки точными? Например, после нескольких спринтов мы ввели правило: любая задача, оцененная выше 8 story points, обязательно должна быть разбита на подзадачи перед взятием в спринт.

Работа с техдолгом и срочными задачами

• Технический долг: Мы резервировали 15-20% емкости каждого спринта на рефакторинг, обновление зависимостей и улучшение производительности. Часть этих задач возникала из findings на code review.
• Срочные запросы (баги, хотфиксы): Для них у нас был отдельный экспресс-трек. Если задача признавалась критической, мы могли заменить ей наименее приоритетную задачу текущего спринта, сохраняя Sprint Goal.

Итог: Такой процесс позволял сочетать предсказуемость для бизнеса (за счет дорожной карты и оценок) с гибкостью для команды (за счет регулярного рефайнмента и ретроспектив). Моя роль, помимо непосредственной разработки, включала активное участие в декомпозиции, оценке технических рисков на этапе планирования и менторстве джуниоров в вопросах реалистичного планирования их работы.