Всем привет! За полтора года наша команда разработки в YADRO написала с нуля четыре полноценных приложения для операционной системы kvadraOS. В их числе «Заметки», «Файлы», «Фото», «Сообщения», а пятое приложение — «Контакты» — сейчас в работе. Проекты разные по объему, требованиям и связям с системой, но всех их объединяет современный стек (Kotlin + Compose) и чистая архитектура. 

Изначально хотела поделиться с вами историями успешных запусков, но… передумала. Описание ошибок, на мой взгляд, приносит больше пользы, чем рассказы, как делать хорошо и правильно. Поэтому сконцентрировалась, наоборот, на разном и не всегда позитивном опыте планирования разработки. 

Дисклеймер: «вредные советы» буду намеренно утрировать, чтобы подчеркнуть важность тех или иных решений. Нам, к счастью, удалось избежать большинства крайностей, но какие-то из советов мы не специально, но применяли.

Когда я была разработчиком, вопросы планирования разработки меня волновали мало. Только в роли тимлида я посмотрела на процесс создания приложения иначе. Ведь теперь нужно выполнять декомпозицию, определять, как эффективнее взять в работу задачи, при этом учитывать огромное количество факторов и не забывать про интересы каждого разработчика. 

Передо мной открылся целый мир, от настройки и проработки которого зависят сроки релиза, качество проекта, впечатление пользователей, моральный дух команды и многое другое. А также бескрайнее поле для экспериментов и всякого рода сюрпризов.

Одним из главных открытий стало то, что планирование —  это не встреча в календаре и не разовое мероприятие, а процесс, состоящий из нескольких этапов:

1. Определение MVP. Составление оптимального списка фич, с которых начнется разработка.

2. Ревью требований для MVP. Детальное знакомство с тем, что предстоит реализовать.

3. Декомпозиция MVP. Разделение сторей (story) на задачи оптимального размера.

4. Планирование работ команды. Распределение бэклога задач по спринтам до релиза.

Каждый из этапов я и опишу в статье. Расскажу, что в него входит и как простыми действиями можно сразу все испортить, — на реальных примерах.

Здесь и далее по тексту: сторя — сущность в Jira, фича — сам функционал, который требуется реализовать. 

Этап 1. MVP против «всё везде и сразу»

Работа над большим проектом может начинаться с выбора: выпускаем ли мы небольшое, но уже полезное и функциональное приложение (MVP) или нам сразу нужна полная версия в релизе. 

Размеры MVP могут отличаться в зависимости от возможностей команды и сроков. О том, как грамотно составить минимальную версию продукта, написано уже множество статей и книг. 

Я определяю MVP как максимально полезный для пользователя продукт, который можно выпустить в поставленные сроки без потери качества. Он должен быть логически закончен, без внезапных тупиков и обрывов на пути пользователя и обязательно приносить пользу. Например, без добавления в избранное или дерева папок можно первое время обойтись, а вот отсутствие возможности удалить созданное будет выглядеть незаконченно. 

Как сделать плохо

• Начать работу сразу над всеми фичами большого приложения. Составить список всех и базовых, и специфических фич — самых нужных и тех, которые пользователю не будут нужны регулярно.

• Описать требования и создать макеты для всего и сразу одним скопом. В идеале — одним документом и единым макетом без разбивки по блокам.

• Потратить как можно больше времени на детальную и максимально точную проработку требований, чтобы ни у кого в команде не возникало вопросов.

• Выполнив предыдущие три пункта, заложить основы для водопада по спринтам.

Наш негативный опыт

Приложение «Контакты» было решено выпустить в полном объеме, так как нужно было заменить полностью дефолтное приложение и поддержать весь функционал. Про работу с ним ранее писал мой коллега. Мы сконцентрировались на проработке полного функционала и попали в ловушку «всего и сразу». 

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

Как сделать лучше:

• Выделить из общего функционала базу для MVP.

• Реализовать MVP, не отдавая в релиз, и тщательно провести тестирование мини-версии.

• Оставшийся функционал разделить на этапы улучшений.

• После реализации всех этапов подготовить приложение к релизу. 

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

В целом, я пришла к выводу, что вне зависимости от продуктовой концепции разработка в любом случае должна начинаться с MVP. 

Наш положительный опыт

Из пяти приложений три («Заметки», «Файлы» и «Фото») выходили в формате настоящего MVP, где функционал был сильно урезан, но уже нес ценность пользователю. Мы взяли в работу меньшее количество фич. 

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

Этап 2. Ревью требований

Итак, мы определились со списком фич для приложения, превратили их в стори. Они идут в работу дизайнеру и аналитику, а после приходят на ревью команде разработки. 

Как сделать плохо

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

• Позвать на обсуждения даже тех людей, кто не будет работать над приложением, в том числе аналитиков и тестировщиков.

• Не записывать обсужденные решения.

• Коллективно дописывать требования в мессенджерах и почте, не фиксируя их в общем документе.

• Тратить время на обсуждение удобства расположения кнопок, забывая про роль дизайнера и его экспертизу.

Наш негативный опыт

Работая над приложением «Сообщения», мы часто проводили ревью большой командой и для всех макетов разом. После нескольких таких встреч «на выживание» мы пришли к другому формату: стали смотреть макеты по частям, отталкиваясь от сторей или use-кейсов.

В начале работы над «Контактами» мы не всегда фиксировали новые договоренности и изменения. Делали как раньше: в других приложениях поток информации был значительно ниже. Достаточно было обсудить, сделать и перейти к следующей сторе, не было необходимости фиксировать каждую мелочь. Но в «Контактах» деталей было значительно больше, поэтому вариант коллективно все запоминать не сработал ни разу. Что-то забывалось, и некоторые моменты мы обсуждали по кругу. 

Как сделать лучше

• Отдать предпочтение асинхронным ревью.

• Звать на встречи только тех, кто принимает решения и обладает нужной экспертизой. Так решения принимаются быстрее.

• Фиксировать договоренности сразу и в одном месте, чтобы не допускать повторных обсуждений уже решенных вопросов.

• Бороться с желанием решить все вопросы до начала разработки и прибить требования гвоздями. Часть нюансов всплывает только на этапе глубокого погружения в работу над задачей — и это нормально.

Наш положительный опыт

Ревью требований «Заметок», «Файлов» и «Фото» проходили в основном в асинхронном режиме. Ссылки на макеты и требования отправляли команде для комментирования, все вопросы решались по возможности письменно и в том же документе (ответами на комментарии). Для более сложных вопросов собирали встречу и следили за числом участников. 

Этап 3. Декомпозиция

Когда требования и дизайн утверждены, начинается этап превращения пользовательских сценариев в пул задач для разработчиков. Проведя декомпозицию для пяти больших проектов, я пришла к выводу, что не существует стандартного размера для задач. Но в оценке можно отталкиваться от некоторых факторов.

Число человек в команде. Чем их больше, тем мельче должны быть задачи. Так как увеличивается количество зависимостей в коде: быстрее закрывается одна задача — быстрее мы двигаемся дальше. Меньшее количество кода также порождает меньше конфликтов.

Уровень разработчиков. Чем он выше, тем объемнее может быть задача. Меньше рисков, что разработка затянется, можно жестче и точнее планировать зависимости.

Уровень взаимодействия в команде. Чем сплоченнее команда, тем проще справляться с зависимостями и конфликтами — можно делать задачи крупнее. Сыгранной команде разработчиков высокого уровня можно отправить задачи с наименьшей декомпозицией, они разберутся сами.

Связанность функционала. Чем больше зависимостей, тем мельче должна быть задача.

Зависимости на другие команды. Так как всегда есть риски нарушения сроков от других команд, задача может подвиснуть и скопить за собой цепочку коммитов. Реализацию функционала с зависимостью лучше вынести в отдельную небольшую задачу

В схеме это можно изобразить так:

Чем мельче задача, тем меньше зависимостей и конфликтов она вызывает. Объемы кода небольшие — процесс от анализа до мержа проходит быстро. 

С другой стороны, большое количество задач требует больше времени на сопровождающие операции: тестирование, проведение задачи по статусам, контроль и заполнение тасок (то, что я называют бюрократией Jira). Также возрастает нагрузка на лида за счет возможного увеличения хаоса, затрат на распараллеливание работ в команде и обновление плана (подробнее об этом — в следующем шаге). Поэтому решение, как именно резать задачи, принимается индивидуально для каждого проекта и команды.

По этой схеме можно определять средний размер задач проекта, главное — не пытаться нарезать все ровно по 3 дня. В реальном проекте будут встречаться самые разные оценки, от одного дня до двух недель.

Проблематика оценки задач — тема для отдельного материала, подробно останавливаться на ней я не буду. Подробнее про то, как оценивать задачи, можно почитать у Роберта Мартина в книге «Идеальный программист», а также в статье Task estimation: Conquering Hofstadter's Law.

Как сделать плохо

• Разбить все стори на задачи одинакового размера по 3 дня или по неделе.

• Делать задачи как можно крупнее, чтобы их было меньше, для сокращения объема процессов вокруг их ведения (ту самую бюрократию в Jira). При этом не учитывать зависимости, размеры команды, уровень и т. д.

• Держать декомпозицию в голове и создавать задачи по ходу.

• Не делать декомпозицию для самих сторей, рассчитывая только на декомпозицию задач. Например, формулировать сторю так: вместо «реализовать возможность выбора пункта назначения поездки» — «реализовать весь сценарий заказа такси».

Наш негативный опыт

Для проекта «Контакты» я решила поменять среднюю оценку задачи в сторону увеличения, чтобы сократить Jira-бюрократию. В расчетах опиралась на то, что после реализации «Сообщений» команда сильно выросла. Но не учла тот факт, что функционал переплетается гораздо сильнее. В итоге получилось несколько очень объемных задач, от реализации которых зависели все остальные. 

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

Для проектов «Сообщения» и «Файлы» мы создали объемные стори, которые требовали большого количества времени на анализ, декомпозицию и тестирование. Некоторые из них содержали до 20-30 задач. Управление таким массивом задач в рамках одной стори неудобно и сложно укладывается в концепцию процессов разработки.

Как сделать лучше

• Обращать внимание на декомпозицию сторей, а не только на задачи для разработки. Всегда помнить, что сторя — это небольшая часть функционала, которую можно реализовать за один спринт.

• При определении среднего размера задач учитывать факторы, описанные в схеме выше.

• Декомпозировать весь объем сторей, чтобы точнее определить сроки релиза.

• Визуализировать декомпозицию и хранить ее так, чтобы с ней мог ознакомится каждый участник команды. Так все будут понимать, на какой стадии проект, сколько процентов уже сделано и какой функционал еще предстоит реализовать.

Наш положительный опыт

Я практически идеально определила среднее время задачи для проектов «Заметки», «Файлы», «Фото» и «Сообщения». При этом задачи в «Сообщениях» были намного мельче, чем в «Фото», но проекты двигались ровно по срокам.

Задачи мы с командой оценивали итеративно, избегая большого объема за один заход. Визуализация списка задач по приложению позволила сэкономить время на планировании, увидеть зависимости и проще ориентироваться в большом объеме сторей.

Мне не удалось найти удобный виджет в Jira для простого и наглядного отображения дерева задач проекта. Как вспомогательный инструмент для декомпозиции и последующего планирования я использую интерактивные доски (типа Miro, Sboard, Холст и т. д). Да, это двойная работа, но в результате это значительно экономит время. Мне легко ориентироваться, что предстоит сделать, что от чего зависит и в какой последовательности лучше распутывать клубок. 

Например, так выглядела декомпозиция для некоторых сторей по проекту «Сообщения»: 

Этап 4. Сроки и параллельная разработка 

Когда задачи нарезаны и оценены, необходимо определить возможный срок релиза. 

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

Здесь начинается шахматное планирование, где нужно учесть множество факторов. 

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

Точнее всего расчеты получились для компонента «Фото», работы мы завершили по намеченному плану. Команда двигалась достаточно быстро: не было новых зависимостей и сложностей, никаких неожиданных обстоятельств. 

Как сделать плохо

• Предварительно не распределять задачи по спринтам.

• Брать задачи последовательно, избегая параллельной работы и малейших конфликтов в коде.

• Никогда не спрашивать команду, кто чем хочет заниматься.

• Не общаться со смежными командами, разрабатывать продукт своим кругом, не рассказывать о глобальных изменениях по принципу «в релизе сами посмотрят».

• Видеть, что сроки сдвигаются, но никому об этом не говорить, пытаться успеть, а потом сделать сюрприз.

• Складывать только чистое время, указанное в задачах, и не закладывать запасы.

• Верить, что изначальные расчеты верны, и никак не корректировать сроки в процессе

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

Наш негативный опыт

Перед выходом «Сообщений» в релиз мы достаточно поздно сообщили смежным командам об изменениях в связи с заменой старого платформенного приложения на новое. При выявлении критических зависимостей и проблем пришлось сдвинуть релиз.

Почти не закладывали временных запасов для компонентов «Заметки», «Файлы», «Фото» и «Сообщения». В случае «Фото» они и не пригодились, а вот в «Сообщениях» в сроки мы не уложились — релиз пришлось сдвигать. 

Заменили старое приложение на новое во втором спринте релиза (за две недели до фриза) и не оставили достаточно времени на проверку. В итоге обнаружили ряд блокирующих проблем и перенесли релиз.

Как сделать лучше

• Распределить задачи внутри команды таким образом, чтобы каждый разработчик работал над проектом. При этом эффективность команды не должна критически снижаться, а основное время не должно уходить на разрешение мерж-конфликтов. Чтобы избежать историй, когда два разработчика сделают сторю быстрее, чем четыре.

• Заранее делать анонсы изменений, получать их подтверждение от заинтересованных команд.

• Закладывать больше времени на тестирование приложения после включения в основную ветку.

• Актуализировать план по мере реализации и быстро перестраиваться, когда что-то идет не так.

• Определять, кто над каким функционалом хочет работать, чтобы повысить вовлеченность и мотивацию. 

• Всегда своевременно сообщать продуктовой команде о рисках по сдвигам сроков. 

Наш положительный опыт

Перед большими изменениями в «Файлах» мы заранее сделали анонс, чтобы выявить неучтенные зависимости. Благодаря этому практически сразу вскрылось несколько важных вопросов, которые получилось решить до фриза в комфортные сроки.

На опыте выпуска двух приложений составили подробный чек-лист по выпуску нового приложения и отдельный — по замене дефолтного. Список помогает оценить время на подготовку к релизу и составить план. Пополняем его с каждым новым выпуском, потому что почти всегда есть что добавить.

Завершили планирование — приступаем к разработке

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

Вот несколько лайфхаков, которые помогают нам в процессе следования плану прийти к хорошему результату:

• На этапе скелета приложения первые несколько задач примерно на спринт мы мержим без тестирования. Приложение либо живет на отдельной ветке, либо не включается в сборку, поэтому к пользователям в таком виде оно, естественно, пойдет нескоро. На старте это сильно экономит время и позволяет быстрее распараллелить работу, так как база будет написана. В дальнейшем, под следующими задачами, функционал тщательно проверяется.

• Если задачи переходят на следующий спринт, переписать план и, если потребуется, перераспределить задачи между разработчиками. Воспринимать это как этап плана и норму в работе над сложным проектом.

• Пересобирать команду, если это устраивает всех участников. Для быстрого старта можно собрать команду, которая в короткий срок создаст крепкую базу, и передать ее другой команде. Также хорошо помогает в моменте добавить людей на определенные задачи, если это действительно ускорит, а не замедлит работу. 

• Тесно взаимодействовать с продуктовой командой, вместе корректировать план и оговаривать сроки каждый раз, когда есть риски.

• Если команда сталкивается с задачами, которые требуют более глубокого погружения в тему и расширенного анализа, заводим отдельный тикет на исследование. Например, для добавления плеера в «Файлах» мы проводили анализ существующих библиотек, уже доступных решений в других наших компонентах — выбирали лучший под требования вариант. Такой подход позволяет внимательнее изучить область, собрать и проверить прототип, быстрее найти уязвимости, обойти все тупики, обкатать несколько решений, если требуется.

Разработка качественного и востребованного приложения начинается не с первой строчки кода, а с ответов на множество вопросов и выстраивания процесса планирования.

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

Двигаясь от проекта к проекту, наши команды многому учатся и растут, совершенствуют подходы и активно работают над тем, чтобы «вредные советы» оставались только шутками в чатах.

Краткие выводы

• Качественно составленная и продуманная минимальная версия приложения значительно приближает релиз, а итеративный подход наращивания функционала сбережет время и силы команды. Позволит гибче планировать, отказаться от очередного этапа улучшений в пользу более раннего релиза и делать дальнейшие шаги, ориентируясь на реакцию пользователей. 

• Асинхронное ревью требований, проведенное по частям, повышает качество проработки требований и экономит время на этапе разработки.

• Хорошая декомпозиция, выполненная с учетом проекта и команды, может выиграть время за счет уменьшения цепочек коммитов и конфликтов.

• Доверие и налаженные взаимодействия в команде спасут любой проект. Именно это помогало нам сглаживать шероховатости на любом этапе.

• Внимательный подход к оценке проекта даст больше шансов на получение более реального представления о сроках завершении. Стоит заложить на этот этап больше времени. 

• План начинает терять актуальность почти сразу после презентации его продуктовой команде — и это нормально.

А на какие грабли планирования наступали вы? И что можете дополнить в позитивные или негативные практики? Пишите в комментариях — с радостью почитаю про опыт коллег.