все эти хотелки. Но предварительное понимание все-таки должно быть.
Очень важно, чтобы к моменту планирования были проработаны постановки задач, проведена промежуточная аналитика, готов весь необходимый дизайн, были подключены все необходимые доступы, ключи к API или описания протоколов и всякое такое.
Бывают задачи или темы, к которым вообще непонятно, с какой стороны подходить. Нужен рисерч. Тут две стратегии: кому-то из команды потратить пару часов на исследование перед спринтом, либо взять задачу на рисерч в спринт, а реализацию делать уже в следующем спринте.
Если проект только-только начинается, там есть инфраструктурные задачи, без которых команда не сможет стартовать: подготовка репозитория, развертка фреймворка, создание базы данных, проектирование архитектуры. Все это стоит наладить немного заранее, за день-два до планирования первого спринта.
Подготовку лучше поручить самому опытному бойцу. Волей-неволей ему придется погрузиться в проект и продумать детали. У него могут возникнуть правильные вопросы, на которые лучше сразу найти ответы. Например, он найдет нестыковку интерфейсов и API. Если это обнаружится в ходе спринта – скорее всего, места для маневров будет мало.
В итоге один из ваших орлов проведет разведку боем, будет знать карту местности. И сможет отвечать на вопросы команды во время планирования. Это сильно помогает и ускоряет планирование.
Опытным путем мы пришли к тому, что нужно дать команде за час-два до планирования прочитать постановки и сформулировать вопросы. Ребята делать этого не любят и читают уклончиво. Логика такая: зачем напрягаться-читать, если на планинге все равно голосом проговорим. Мозг экономит энергию. Но если этого не проделать – планирование спринта может превратиться в многочасовой склочный базар. Приходится заставлять читать и думать. Как тренер в спортзале заставляет сделать пару дополнительных приседаний.
В итоге команда приходит на планирование с предварительной картиной спринта в голове. Осталось сверить картинки, декомпозировать хотелки на тикеты, оценить и понять, сколько задач мы реально успеем за спринт.
Нужно стремиться так декомпозировать задачи, чтобы их легко можно было посмотреть визуально. Это не всегда возможно, особенно в проектах с обилием математики или интеграций. Но для веба и мобильных приложений, в основном, получается.
Размер задач зависит от опыта команды. Мне нравится, когда каждый день можно глазами посмотреть, что поменялось в проекте. Постарайтесь делать декомпозицию, чтобы задачи было просто проверить, а трудоемкость была от 1 до 8 часов (если вы оцениваете в часах, а не в Story Points). Опять же, не всегда получается, да и опытная команда будет сопротивляться такой мелкой разбивке. Опытным нужны крупные куски. Но для молодых и дерзких управляемость сильно возрастает.
Сугубо технические задачи, типа «Удали поле id из таблицы Users» – дрянь. Формулировки лучше делать на уровне фич: «Форма обратной связи» или «Отправка письма о восстановлении пароля».
Долгий
