Сегодня на обучении мы разбирали график сгорания задач, и один из участников задал важный вопрос: «Как укладываться в спринт так, чтобы сгорание было равномерным? Ведь сначала идёт аналитика, потом разработка, затем код-ревью, тестирование… А если на каждом этапе ещё требуются согласования, то уложиться в двухнедельный спринт почти невозможно — одно только согласование может занять неделю. Что делать в такой ситуации?»*

Этот вопрос действительно заставляет задуматься.

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

Именно это и интересно в Scrum — меняя не сам процесс, а подход к нему, можно добиться значительных улучшений. Вместо строгой последовательности этапов нужно подумать: «Что мы можем делать параллельно?»

Вы можете возразить: «Но если мы начнём делать процессы параллельно, всё сломается!»

Давайте проверим:

• Сломается ли что-то, если разработка начнётся до полного завершения аналитики?

→ Нет, если ключевые требования уже понятны. Можно стартовать с прототипа или MVP. Да, может казаться, что есть вероятность ошибок, но для этого у нас есть Daily Scrum, на котором мы можем все обсудить.

• Сломается ли что-то, если тестирование начнёт писать тест-кейсы раньше?

→ Нет, это даже улучшит качество — тестировщики раньше увидят потенциальные риски. А разработчик сможет проверить по готовым тест кейсам код.

Попробуйте задать себе эти вопросы — и увидите, что большинство ограничений на самом деле в нашей голове. Ключевое прозрение: "Нет этапов — есть поток работы"

Самое сложное — изменить мышление: Kanban-доска — это не про роли, а про состояние задачи.

• Статус "Тестирование" — значит, сейчас идёт проверка, а не то, что "это зона ответственности только тестировщика".
• Статус "В разработке" — не означает, что аналитик или тестировщик не могут подключиться.

Как это работает на практике?

1. Не ждите "идеальных" условий

• Начинайте разработку, как только есть минимально понятные требования.

• Тестирование может набрасывать тест-кейсы ещё на этапе аналитики.

• Дизайнер может делать прототипы параллельно с обсуждением ТЗ.

2. Экономия времени за счёт параллельной работы

Да, в какой-то момент задача будет выглядеть как "три в одном":

• аналитик уточняет детали,
• разработчик уже пишет код,
• тестировщик готовит проверки.

Но зато вы:

• Быстрее выпускаете функциональность.
• Раньше получаете обратную связь.
• Меньше рискуете потратить время на ненужный функционал.

Вывод

Если продолжать работать строго последовательно:

❌ Вы теряете время на ожидание.

❌ Увеличиваете риск выпустить неактуальный функционал.

Если перейти на параллельную работу:

✅ Спринт становится предсказуемее.

✅ Команда двигается быстрее.

✅ Гибкость позволяет оперативно корректировать курс.

Попробуйте — и увидите, что "невозможное" возможно. 🚀