Несколько лет назад небольшой командой сделали тестовый прототип PvP-шутера, который внезапно выстрелил. Тогда ни разработчики, ни процессы не были готовы к такой популярности, мы развивали проект здесь и сейчас — с энтузиазмом хватались за все понравившиеся идеи и старались реализовать их к ближайшему апдейту.
Когда команда увеличилась вдвое, а работы кратно прибавилось, старые процессы перестали работать. Мы могли запросто утонуть в операционке, если бы вовремя не начали меняться.
Материал для тех, кто задумался о долгосрочном планировании или начал выстраивать процессы у себя. Внутри я подробно рассказал про наш опыт: как мы целиком обновили воркфлоу разработки, внедрили Jira, систему оценки фичей ICE, методологию планирования GIST, а также целую пачку новых инструментов и гуглдоков. Теперь мы на несколько месяцев вперед точно знаем, что будет в проекте.
Так мы вполне комфортно работали, пока не объединили команды с двух проектов, переехали в новый офис и начали расширяться. А вместе с ростом пришли и проблемы.
Над проектом работало уже около 50 человек, некоторые из них удаленно. Теперь цельную картину по проекту знали немногие: продакт-овнер, проджект-менеджер и несколько лидов. Остальные занимались конкретным задачами, часто не до конца понимая, зачем и какие цели ими решают, а это не очень хорошо. Лиды распределяли таски по сотрудникам, те выполняли их в порядке получения, а после — запрашивали в личке новые. Из-за этого было не всегда ясно, над чем работает конкретный сотрудник, какой у него загруз, может ли он взять еще задачу.
Разумеется, по проекту вели всю необходимую документацию: роадмап, диздоки, планы, описание фичей, всевозможные ТЗ и так далее. Но у нас не было общей доски, единой структуры, системы: задачи утопали в потоках информации, документы и ссылки приходилось искать по разным чатам, статусы по задачам было неудобно отслеживать, а комментарии и правки регулярно терялись.
Бывали случаи, когда кто-то кого-то недопонял и таск просто не делался никем. Или, например, когда сотрудник просидел пару дней вообще без задач, а потом получил сложную и с дедлайном, истекающим вчера (ага, приятный сюрприз).
В итоге там чуть не успели, здесь немного задержали, тут еще переделали — и 30 фичей заливаются за 3 дня до релиза, а мы судорожно чиним конфликты слияния и баги с тестов. Когда к новому апдейту мы в очередной раз овертаймили и все равно не успевали в сроки — окончательно поняли, что пора меняться.
В результате мы практически полностью пересобрали процессы разработки. Интегрировали Jira и теперь каждый в команде видит, что происходит в проекте. А еще внедрили долгосрочную систему планирования и научились заглядывать в будущее, чтобы минимизировать любые риски и быть гибкими, если вдруг что-то пойдет не так.
Сейчас над Pixel Gun 3D работают около 70 человек: 15 в геймдизайне, 15 в QA, 20 в техотделе и 20 в арт-отделе. Со старым воркфлоу мы бы большую часть времени тратили на организацию, а с новым — можем спокойно сосредоточиться на задачах.
Но пришли мы к текущему состоянию не сразу. Обо всем по порядку.
Redmine нас не устраивал во всем: концептуально, интерфейсом, в плане удобства. Сейчас он наверняка стал лучше, но тогда заставить всю команду пользоваться им было невозможно, поэтому решили найти новый инструмент, который был бы удобен для всех. Перебрали множество популярных.
Asana
Asana быстро отвалилась, потому что тогда не позволяла реализовать три уровня вложенности. Не было физического объекта — тикета, в котором еще тикет, еще тикет и все они видны на доске. А это было одним из наших ключевых требований.
Trello
Попробовали Trello, но с ним только усложнили и разделили организацию процессов арта и разработки. Пайплайн арт-отдела (про них мы подробно писали в этом материале) сильно отличаются от процессов разработки фичей, поэтому мы не могли статусы задач сделать одинаковыми для всех отделов.
Также было недостаточно автоматизации, поэтому использовали от трех до шести разных досок. А еще пришлось написать большой гайд, как работать с карточками на досках (правила копирования, перемещения, возвращения карточек назад были крайне неочевидными). Было очень неудобно, поэтому проработали в таком формате совсем недолго.
Jira
Третьим инструментом выбрали Jira. На ней в итоге и остановились.
Поэтому сперва мы разделили доски: две у арт-отдела, две у техотдела (для программистов и тестировщиков) и «Департаменты» для всех остальных. Но с таким количеством было сложно работать. Приходилось мониторить сразу несколько, например, для художников могли завести задачу в «Продакшене», «Багах» или вообще в «Департаменте».
К этому мы пришли примерно за три месяца: спроектировали процессы, написали документацию и все настроили. Так проработали полгода и решили сделать все еще проще — сократить количество досок до двух. Их и используем до сих пор:
Пример. Нам нужно выпустить апдейт 21.4 с сезонным контентом. Обновление 21.4 — это эпик; контент для него (оружие) — задачи; этапы реализации оружия (визуал, механики) — подзадачи. Структура простая и понятная:
Так выглядит эпик с задачами
Немного расскажу про некоторые кастомные поля тикета. Они стандартны для всех уровней вложенности:
Список автоматизаций
Запуск вручную
Для каждого релиза у нас есть набор повторяющихся задач по его сопровождению. Чтобы не терять время на заведение таких задач вручную, мы создаем один эпик на релиз-менеджера и запускаем из него правило на создание дочерних задач с уже заполненными полями и исполнителями. Все просто.
Аналогично для каждого сезона готовим утвержденное количество единиц контента. Из эпика по сезонному контенту запускаем правило, создающее тикеты на каждую единицу. Вручную лишь редактируем названия тикетов.
Автоматический запуск
На доске «Релиз» запрещены все типы задач, кроме эпиков и багов. Потому что специалисты ошибаются при перемещении между проектами и создают задачи не в тех местах (для создания задачи Jira выбирает последний проект, даже если исполнитель находится уже в другом). А так, как права на удаление задач есть только у проджект-менеджеров и лидов, то возникает путаница из ошибочных задач.
Правильнее сказать — возникала. Сейчас внутри эпика автоматизация создает копию задачи в проекте «Продакшен», затем удаляет оригинал на доске «Релиз».
Или другой пример. Когда баг доходит до статуса «готово» на доске «Продакшен», то создается его копия в проекте «Релиз» и перемещается на мердж (для того, чтобы можно было контролировать влитие в основную ветку). Разумеется, это только некоторые примеры автоматизации, которые мы используем.
Доска «Релиз»
Как выглядит рабочий процесс по этой доске подробно и по пунктам:
1. Из бэклога, где хранятся идеи по проекту, фиче-овнер (обычно геймдизайнер) берет фичу в разработку, переносит в составление ТЗ и начинает препродакшен: пишет ТЗ, диздок, конфиги, макеты интерфейсов и прочее.
2. На любом этапе он может показать задачу продакт-овнеру, для этого кидает ее в контроль TЗ. Продакт-овнер получает уведомление и дает фидбек в любом виде. Если фидбека много — собирают совещание, обсуждают ТЗ, реализацию, возвращаются в предыдущий статус составление ТЗ и фиче-овнер продолжает работу.
3. Как только тикет проходит контроль продакт-овнера и его все устраивает, он переносит тикет в готовые ТЗ. Проджект-менеджер получает уведомление, сверяется с планом и, когда приходит время — переносит в разработку.
4. В данной доске разработка — отдельный статус, который на деле включает в себя множество процессов — здесь осуществляют основную работу с контентом, поэтому эти задачи вынесли в отдельную доску «Продакшен», чтобы не смешивать с доской «Релиз». О ней отдельно расскажу ниже.
Итак, когда фича попадает сюда, то фиче-овнер получает уведомление. Он должен пройти чек-лист передачи задачи в продакшен:
5. Когда фиче-овнер хочет показать задачу, то просит собрать билд и скидывает тикет на контроль фичи. Продакт-овнер получает уведомление, смотрит, дает фидбек и возвращает в разработку.
6. Если с фичей все хорошо и у продакт-овнера нет фидбека, то она переносится в мердж. Это очередь из тикетов для вливания в основную ветку девелоп.
Заглушка «мердж запрещен»
7. Когда из мерджа фича переносится в девелоп — значит, она готова к релизу. Когда релизим апдейт, то через Jira тоже выпускаем обновление: старые тикеты архивируются и потом по ним можно будет посмотреть ретроспективу.
Билд-лист
Доска «Продакшен»
Задачи назначают на нужных исполнителей и далее идет поэтапная работа. Расскажу подробнее про воркфлоу.
1. Каждый специалист видит все задачи, но, чтобы не путаться, обычно выставляет фильтры «Мои задачи» или «Все мои задачи». Последние видно, если специалист указан в любом из полей таска.
Если у сотрудника одновременно несколько похожих задач к выполнению, то он уточняет приоритет у своего лида.
2. Дальше тикет берут в работу. На этом этапе к нему могут завести билеты на отладку для отдела QA с просьбой что-нибудь протестировать.
Пример автоматизации
На примере технических фичей. Такие тикеты автоматически попадают в столбец к тестированию и дальше подключается тестировщик: если нужно что-то переделать, то заводит дочерний тикет на исполнителя; если все хорошо — отправляет в готово.
3. Когда работа над задачей закончена, то она может отправиться на контроль. Это происходит, если в поле approvers указан специалист.
5. Далее QA-лид назначает исполнителя, задача переносится в столбец на тестировании и начинается проверка. На все найденные баги заводят дочерние тикеты. Когда все протестировано и ошибок нет, то тикет переносится в готово и закрывается.
Когда все подзадачи закрыты, задача продолжает двигаться по доске «Релиз». В итоге добавляется в проект и релизится.
Мы могли прикидывать задачи на месяц вперед, квартал или полгода. Но до конца подробного составления плана доходило редко — обычно придумывали какую-нибудь амбициозную фичу с большим потенциалом и бросались на нее. Воркфлоу был примерно такой:
GIST состоит из четырех этапов: goals (цели), ideas (идеи), step-projects (проекты), tasks (задачи). Каждый из них имеет разные горизонты планирования и частоту обновления, а вместе — это основа планирования по проекту.
Стикеры с идеями раскрашены в те же цвета, что и глобальные цели — так наглядно понятно, какие результаты преследуют в рамках задач.
Доска в Miro. Сверху вниз: цели, ключевые результаты, идеи и разделение идей по апдейтам
В постановке глобальных целей есть этап подготовки, когда продакт-овнер собирает метрики проекта, чтобы аргументировать свою позицию — что и зачем нужно улучшить. Для каждой цели должны быть ключевые результаты или метрики, которые было бы легко проверить. Обычно от трех до пяти, так проще за ними следить. Чтобы достичь результатов, выбирают не конкретные задачи, а идеи и гипотезы. Например, «визуал оружия и добавление классов может улучшить монетизацию» — эта гипотеза не детализирована, а довольно абстрактна. Как именно классы будут добавлены — зависит от исполнителей.
Далее идеи и гипотезы отправляют в гугл-таблицу оценки идей по системе ICE:
Таблица оценок по ICE
Чтобы нивелировать субъективность, продюсер, продакт-овнер, ГД-лид и проджект-менеджер оценивают идеи на отдельных вкладках гугл-таблицы, не глядя на других. Затем на общей странице выводится среднее арифметическое.
Иногда несколько простых идей могут оказать гораздо более сильный эффект, чем одна сложная. Но над масштабными идеями тоже нужно работать и не обязательно реализовывать их целиком. Для этого существуют проекты. Их оформили в виде эпиков в Jira. Дальше эпики разделяют на конкретные задачи.
Мы оцениваем фичи по перспективности от большего к меньшему. В соответствии с рейтингом перспективности, проджект-менеджер заполняет роадмап. Чем выше у фичи оценка ICE, тем раньше мы ее берем в работу. Через месяц собираемся, смотрим результаты, добавляем идеи, пересобираем список.
После этого проджект-менеджер переносит самые высокооцененные фичи в таблицу «Планирование» и вместе с техлидом ее заполняет. В ней указывают исполнителей и приблизительные сроки реализации. После этого таблица автоматически рассчитывает, сколько на каждого специалиста запланировано рабочих дней, чтобы реализовать все его задачи.
Зная, сколько у нас всего времени от текущего момента до даты релиза, сколько уйдет на тестирование и форс-мажоры (за 5 дней до релиза фичи уже должны вливаться в девелоп), мы можем видеть, успевает ли сотрудник. Если нет — делегируем другому. Если некому делегировать — откатываем фичу. Например, если для разработчика запланировали работы на 15 дней, а до релиза у нас 10, то задачи на 5 дней с него нужно распределить по другим специалистам.
Таблица с нагрузкой специалистов в рабочих днях
На этом же этапе (а иногда и на этапе заполнения роадмапа) создают эпики в Jira и складывают в бэклог на доске «Релиз». По возможности составляют ТЗ.После финализации этой таблицы проджект-менеджер заполняет гант техотдела на месяц вперед. Его заполняют по важности: от блокеров (делают в первую очередь) к низкоприоритетным. Также в гант вносят информацию от HR: отпуска, больничные, отгулы.
Гант
Перестали тратить ценное время на амбициозные фичи, результат которых нельзя оценить по метрикам. Например, можно два месяца потратить на фичу, которая ни на что не повлияет или даже сделает хуже (придется откатывать и тратить еще месяц). Таких случаев у нас теперь не бывает.
Что касается внедрения Jira, то она повлияла на общее удобство и скорость работы. Мы избавились от лишней коммуникации в Slack, документы фиксируются прямо в задачах и не теряются в переписках, что тоже экономит время на поиск нужной информации.
Также повысилась осведомленность команды. Теперь все причастные к проекту ясно понимают, какую задачу и для чего делают, так как все есть на доске перед глазами.
Итого. Важно уделять время средне- и долгосрочному планированию, даже если у вас небольшая команда и молодой проект. Малое количество времени, потраченное на планирование, сэкономит большое количество времени, потраченное на разработку.
habr.com
Когда команда увеличилась вдвое, а работы кратно прибавилось, старые процессы перестали работать. Мы могли запросто утонуть в операционке, если бы вовремя не начали меняться.
Материал для тех, кто задумался о долгосрочном планировании или начал выстраивать процессы у себя. Внутри я подробно рассказал про наш опыт: как мы целиком обновили воркфлоу разработки, внедрили Jira, систему оценки фичей ICE, методологию планирования GIST, а также целую пачку новых инструментов и гуглдоков. Теперь мы на несколько месяцев вперед точно знаем, что будет в проекте.
Как было раньше
Несколько лет назад в команде Pixel Gun 3D было порядка 20 человек и все могли поместиться в одной комнате. Вопросы и задачи часто обсуждали голосом практически с рабочих мест, что-то оговаривали в Slack. Был постоянный синк друг с другом, поэтому потребности в регулярных утренних статусах, общих презентациях или ретроспективах попросту не было.Так мы вполне комфортно работали, пока не объединили команды с двух проектов, переехали в новый офис и начали расширяться. А вместе с ростом пришли и проблемы.
Над проектом работало уже около 50 человек, некоторые из них удаленно. Теперь цельную картину по проекту знали немногие: продакт-овнер, проджект-менеджер и несколько лидов. Остальные занимались конкретным задачами, часто не до конца понимая, зачем и какие цели ими решают, а это не очень хорошо. Лиды распределяли таски по сотрудникам, те выполняли их в порядке получения, а после — запрашивали в личке новые. Из-за этого было не всегда ясно, над чем работает конкретный сотрудник, какой у него загруз, может ли он взять еще задачу.
Разумеется, по проекту вели всю необходимую документацию: роадмап, диздоки, планы, описание фичей, всевозможные ТЗ и так далее. Но у нас не было общей доски, единой структуры, системы: задачи утопали в потоках информации, документы и ссылки приходилось искать по разным чатам, статусы по задачам было неудобно отслеживать, а комментарии и правки регулярно терялись.
Бывали случаи, когда кто-то кого-то недопонял и таск просто не делался никем. Или, например, когда сотрудник просидел пару дней вообще без задач, а потом получил сложную и с дедлайном, истекающим вчера (ага, приятный сюрприз).
В итоге там чуть не успели, здесь немного задержали, тут еще переделали — и 30 фичей заливаются за 3 дня до релиза, а мы судорожно чиним конфликты слияния и баги с тестов. Когда к новому апдейту мы в очередной раз овертаймили и все равно не успевали в сроки — окончательно поняли, что пора меняться.
В результате мы практически полностью пересобрали процессы разработки. Интегрировали Jira и теперь каждый в команде видит, что происходит в проекте. А еще внедрили долгосрочную систему планирования и научились заглядывать в будущее, чтобы минимизировать любые риски и быть гибкими, если вдруг что-то пойдет не так.
Сейчас над Pixel Gun 3D работают около 70 человек: 15 в геймдизайне, 15 в QA, 20 в техотделе и 20 в арт-отделе. Со старым воркфлоу мы бы большую часть времени тратили на организацию, а с новым — можем спокойно сосредоточиться на задачах.
Но пришли мы к текущему состоянию не сразу. Обо всем по порядку.
Поиск инструментов
На момент внедрения новых процессов в компании был один таск-трекер Redmine, но им пользовались только техотдел и QA. Остальные отделы ставили и обсуждали задачи в Slack или голосом, а потом записывали кто куда: в заметки, личный таск-трекер и так далее.Redmine нас не устраивал во всем: концептуально, интерфейсом, в плане удобства. Сейчас он наверняка стал лучше, но тогда заставить всю команду пользоваться им было невозможно, поэтому решили найти новый инструмент, который был бы удобен для всех. Перебрали множество популярных.
Asana
Asana быстро отвалилась, потому что тогда не позволяла реализовать три уровня вложенности. Не было физического объекта — тикета, в котором еще тикет, еще тикет и все они видны на доске. А это было одним из наших ключевых требований.
Trello
Попробовали Trello, но с ним только усложнили и разделили организацию процессов арта и разработки. Пайплайн арт-отдела (про них мы подробно писали в этом материале) сильно отличаются от процессов разработки фичей, поэтому мы не могли статусы задач сделать одинаковыми для всех отделов.
Также было недостаточно автоматизации, поэтому использовали от трех до шести разных досок. А еще пришлось написать большой гайд, как работать с карточками на досках (правила копирования, перемещения, возвращения карточек назад были крайне неочевидными). Было очень неудобно, поэтому проработали в таком формате совсем недолго.
Jira
Третьим инструментом выбрали Jira. На ней в итоге и остановились.
Управление проектом
Если кратко, то структура Jira выглядит так:
- Таск-трекер состоит из проектов.
- Проект содержит kanban-доски.
- Доска содержит столбцы (статусы задач).
- Столбцы содержат задачи.
Поэтому сперва мы разделили доски: две у арт-отдела, две у техотдела (для программистов и тестировщиков) и «Департаменты» для всех остальных. Но с таким количеством было сложно работать. Приходилось мониторить сразу несколько, например, для художников могли завести задачу в «Продакшене», «Багах» или вообще в «Департаменте».
К этому мы пришли примерно за три месяца: спроектировали процессы, написали документацию и все настроили. Так проработали полгода и решили сделать все еще проще — сократить количество досок до двух. Их и используем до сих пор:
- Релиз. Менеджерская доска, которой чаще всего пользуются лиды и фиче-овнеры. Здесь глобальный процесс работы над фичами: от ТЗ до релиза.
- Продакшен. Доска, на которой происходит основной процесс разработки фичей, особенно нужна исполнителям. Здесь непосредственно реализация: от написания кода до тестирования.
Задачи
Все начинается с создания эпика — это проект из множества задач, которые делятся на подзадачи. Именно такие три уровня вложенности мы искали, когда выбирали таск-трекер.Пример. Нам нужно выпустить апдейт 21.4 с сезонным контентом. Обновление 21.4 — это эпик; контент для него (оружие) — задачи; этапы реализации оружия (визуал, механики) — подзадачи. Структура простая и понятная:
- Эпики на доске «Релиз». Заводит проджект-менеджер после утверждения продакт-овнером и продюсером роадмапа на квартал.
- Внутри эпиков — задачи на доске «Продакшен». Заводит фиче-овнер.
- Внутри задач — подзадачи на доске «Продакшен». Ситуативно в ходе работы заводит фиче-овнер или исполнитель.
- Есть еще «Баги», они стоят чуть обособленно на доске «Продакшен».
Немного расскажу про некоторые кастомные поля тикета. Они стандартны для всех уровней вложенности:
- Approvers. Используется для фидбека. В нем указывают сотрудника, который должен посмотреть задачу. Если поле пустое, то тикет нельзя кинуть в столбцы на рабочих досках для контроля (об этом расскажу ниже).
- Участники. Используется в редких случаях, когда нужно указать более одного исполнителя.
- QA. Указывают специалиста для тестирования.
- Ветка. В какой ветке делают фичу. Облегчает поиск фичи и помогает при вливании в проект.
- Версия. На какую версию запланирован релиз фичи. По версиям формируется дашборд.
- Ожидаемое поведение и наблюдаемое поведение. Текстовые поля, которые используются для описания багов.
Автоматизация
Отдельная крутая штука в Jira, которая сильно облегчает жизнь, экономит время и избавляет от рутины — автоматизация. Используем постоянно, причем все это бесплатно и нативно. Ее можно разделить на две группы: запускаемая вручную или автоматически.
Запуск вручную
Для каждого релиза у нас есть набор повторяющихся задач по его сопровождению. Чтобы не терять время на заведение таких задач вручную, мы создаем один эпик на релиз-менеджера и запускаем из него правило на создание дочерних задач с уже заполненными полями и исполнителями. Все просто.
Аналогично для каждого сезона готовим утвержденное количество единиц контента. Из эпика по сезонному контенту запускаем правило, создающее тикеты на каждую единицу. Вручную лишь редактируем названия тикетов.
Автоматический запуск
На доске «Релиз» запрещены все типы задач, кроме эпиков и багов. Потому что специалисты ошибаются при перемещении между проектами и создают задачи не в тех местах (для создания задачи Jira выбирает последний проект, даже если исполнитель находится уже в другом). А так, как права на удаление задач есть только у проджект-менеджеров и лидов, то возникает путаница из ошибочных задач.
Правильнее сказать — возникала. Сейчас внутри эпика автоматизация создает копию задачи в проекте «Продакшен», затем удаляет оригинал на доске «Релиз».
Или другой пример. Когда баг доходит до статуса «готово» на доске «Продакшен», то создается его копия в проекте «Релиз» и перемещается на мердж (для того, чтобы можно было контролировать влитие в основную ветку). Разумеется, это только некоторые примеры автоматизации, которые мы используем.
Доска «Релиз»
Расскажу подробнее о том, как устроены доски. Начнем с «Релиза». Это доска с самыми высокоуровневыми задачами — теми фичами, которые войдут в апдейт.
Как выглядит рабочий процесс по этой доске подробно и по пунктам:
1. Из бэклога, где хранятся идеи по проекту, фиче-овнер (обычно геймдизайнер) берет фичу в разработку, переносит в составление ТЗ и начинает препродакшен: пишет ТЗ, диздок, конфиги, макеты интерфейсов и прочее.
2. На любом этапе он может показать задачу продакт-овнеру, для этого кидает ее в контроль TЗ. Продакт-овнер получает уведомление и дает фидбек в любом виде. Если фидбека много — собирают совещание, обсуждают ТЗ, реализацию, возвращаются в предыдущий статус составление ТЗ и фиче-овнер продолжает работу.
3. Как только тикет проходит контроль продакт-овнера и его все устраивает, он переносит тикет в готовые ТЗ. Проджект-менеджер получает уведомление, сверяется с планом и, когда приходит время — переносит в разработку.
4. В данной доске разработка — отдельный статус, который на деле включает в себя множество процессов — здесь осуществляют основную работу с контентом, поэтому эти задачи вынесли в отдельную доску «Продакшен», чтобы не смешивать с доской «Релиз». О ней отдельно расскажу ниже.
Итак, когда фича попадает сюда, то фиче-овнер получает уведомление. Он должен пройти чек-лист передачи задачи в продакшен:
- Фиче-овнер в рамках одного совещания с лидами отделов презентует задачу, лиды выбирают исполнителей, вместе делят ее на подзадачи и заводят тикеты без подробных описаний.
- Создают структуру: количество тикетов и подзадач, выбирают исполнителей и прогнозируют сроки. Эту информацию получает проджект-менеджер и актуализирует планы.
- Далее проводят второе совещание, где фиче-овнер презентует задачу исполнителям — это повышает осведомленность и дает понимание, что и зачем мы делаем. Как следствие — растет качество продукта.
5. Когда фиче-овнер хочет показать задачу, то просит собрать билд и скидывает тикет на контроль фичи. Продакт-овнер получает уведомление, смотрит, дает фидбек и возвращает в разработку.
6. Если с фичей все хорошо и у продакт-овнера нет фидбека, то она переносится в мердж. Это очередь из тикетов для вливания в основную ветку девелоп.
Тут техлид получает уведомление и меняет исполнителя — выбирает специалиста, который будет вливать этот тикет в основную ветку девелоп. Для этого используем Git. Слияние веток может привести к неприятным последствиям, поэтому у нас настроено ограничение на максимальное количество тикетов. Специалист переносит сначала заглушку, а потом тот тикет, который будет заливать. Другие специалисты по этой заглушке сразу понимают, что в этот момент другие фичи вливать нельзя.
7. Когда из мерджа фича переносится в девелоп — значит, она готова к релизу. Когда релизим апдейт, то через Jira тоже выпускаем обновление: старые тикеты архивируются и потом по ним можно будет посмотреть ретроспективу.
Доска «Продакшен»
Здесь непосредственно происходит основная часть разработки фичей. Доску используют все отделы. Любой сотрудник может создать любую задачу — на ней достаточно статусов, чтобы полностью описать ее выполнение от начала до конца.
Задачи назначают на нужных исполнителей и далее идет поэтапная работа. Расскажу подробнее про воркфлоу.
1. Каждый специалист видит все задачи, но, чтобы не путаться, обычно выставляет фильтры «Мои задачи» или «Все мои задачи». Последние видно, если специалист указан в любом из полей таска.
Если у сотрудника одновременно несколько похожих задач к выполнению, то он уточняет приоритет у своего лида.
2. Дальше тикет берут в работу. На этом этапе к нему могут завести билеты на отладку для отдела QA с просьбой что-нибудь протестировать.
На примере технических фичей. Такие тикеты автоматически попадают в столбец к тестированию и дальше подключается тестировщик: если нужно что-то переделать, то заводит дочерний тикет на исполнителя; если все хорошо — отправляет в готово.
3. Когда работа над задачей закончена, то она может отправиться на контроль. Это происходит, если в поле approvers указан специалист.
4. Если же задачу требуется вливать в девелоп, то ее отправляют в столбец к тестированию.
5. Далее QA-лид назначает исполнителя, задача переносится в столбец на тестировании и начинается проверка. На все найденные баги заводят дочерние тикеты. Когда все протестировано и ошибок нет, то тикет переносится в готово и закрывается.
Когда все подзадачи закрыты, задача продолжает двигаться по доске «Релиз». В итоге добавляется в проект и релизится.
Долгосрочное планирование: GIST, ICE и гугл-таблицы
Когда мы выстроили рабочие процессы в Jira, руки дошли до системы долгосрочного планирования. Конечно, у нас было множество идей в бэклоге — список фич и контента на ближайший релиз и все остальное, но четкая система планирования как таковая — отсутствовала.Мы могли прикидывать задачи на месяц вперед, квартал или полгода. Но до конца подробного составления плана доходило редко — обычно придумывали какую-нибудь амбициозную фичу с большим потенциалом и бросались на нее. Воркфлоу был примерно такой:
- Продюсер и продакт-овнер выбирали задачи на апдейт на основе личных предпочтений — это могли быть как задачи из бэклога, так и их новые идеи.
- Проджект-менеджер получал список задач и заполнял гант (формат выстраивания этапов во времени и со связью между собой).
- После заполнения ганта начиналась реализация задач.
GIST состоит из четырех этапов: goals (цели), ideas (идеи), step-projects (проекты), tasks (задачи). Каждый из них имеет разные горизонты планирования и частоту обновления, а вместе — это основа планирования по проекту.
- Цели устанавливают на длительный срок.
- Идеи реализуют от одного месяца (в зависимости от их сложности).
- Проекты выполняют в пределах месяца.
- Задачи оперируются в рамках нескольких дней.
Стикеры с идеями раскрашены в те же цвета, что и глобальные цели — так наглядно понятно, какие результаты преследуют в рамках задач.
В постановке глобальных целей есть этап подготовки, когда продакт-овнер собирает метрики проекта, чтобы аргументировать свою позицию — что и зачем нужно улучшить. Для каждой цели должны быть ключевые результаты или метрики, которые было бы легко проверить. Обычно от трех до пяти, так проще за ними следить. Чтобы достичь результатов, выбирают не конкретные задачи, а идеи и гипотезы. Например, «визуал оружия и добавление классов может улучшить монетизацию» — эта гипотеза не детализирована, а довольно абстрактна. Как именно классы будут добавлены — зависит от исполнителей.
Далее идеи и гипотезы отправляют в гугл-таблицу оценки идей по системе ICE:
- Impact (влияние) — влияние идеи на ключевой результат.
- Confidence (уверенность) — уверенность в оценках влияния и легкости реализации.
- Ease (легкость реализации) — оценка ресурсов, которые необходимы для реализации идеи.
Чтобы нивелировать субъективность, продюсер, продакт-овнер, ГД-лид и проджект-менеджер оценивают идеи на отдельных вкладках гугл-таблицы, не глядя на других. Затем на общей странице выводится среднее арифметическое.
Иногда несколько простых идей могут оказать гораздо более сильный эффект, чем одна сложная. Но над масштабными идеями тоже нужно работать и не обязательно реализовывать их целиком. Для этого существуют проекты. Их оформили в виде эпиков в Jira. Дальше эпики разделяют на конкретные задачи.
Мы оцениваем фичи по перспективности от большего к меньшему. В соответствии с рейтингом перспективности, проджект-менеджер заполняет роадмап. Чем выше у фичи оценка ICE, тем раньше мы ее берем в работу. Через месяц собираемся, смотрим результаты, добавляем идеи, пересобираем список.
После этого проджект-менеджер переносит самые высокооцененные фичи в таблицу «Планирование» и вместе с техлидом ее заполняет. В ней указывают исполнителей и приблизительные сроки реализации. После этого таблица автоматически рассчитывает, сколько на каждого специалиста запланировано рабочих дней, чтобы реализовать все его задачи.
Зная, сколько у нас всего времени от текущего момента до даты релиза, сколько уйдет на тестирование и форс-мажоры (за 5 дней до релиза фичи уже должны вливаться в девелоп), мы можем видеть, успевает ли сотрудник. Если нет — делегируем другому. Если некому делегировать — откатываем фичу. Например, если для разработчика запланировали работы на 15 дней, а до релиза у нас 10, то задачи на 5 дней с него нужно распределить по другим специалистам.
На этом же этапе (а иногда и на этапе заполнения роадмапа) создают эпики в Jira и складывают в бэклог на доске «Релиз». По возможности составляют ТЗ.После финализации этой таблицы проджект-менеджер заполняет гант техотдела на месяц вперед. Его заполняют по важности: от блокеров (делают в первую очередь) к низкоприоритетным. Также в гант вносят информацию от HR: отпуска, больничные, отгулы.
Когда все распределено по исполнителям, план и гант сформированы, то фичи переходят в разработку.
Рабочий процесс целиком
Подытожу все вышесказанное и тезисно расскажу про весь рабочий процесс разработки: от планирования до загрузки в проект.- В Miro расписывают абстрактные идеи для будущих релизов. То, что можно реализовать и добавить в игру. Это наш роадмап. В Jira все идеи попадают в виде эпиков в бэклог.
- Идеи оценивают по методу ICE. Затем выводится среднее арифметическое.
- В порядке приоритета и оценок переносят в общий план по проекту. Проставляют фиче-овнеров и примерные сроки реализации для распределения ресурсов.
- Автоматически подсчитывается количество рабочих дней, которые нужны специалисту для выполнения всех задач. Задачи распределяют так, чтобы не перегружать исполнителей и успеть все в срок.
- Из плана уже переносят в гант на техотдел, где учитываются приоритеты по задачам. А также отпуска, больничные и отгулы, чтобы понимать, когда сотрудники будут недоступны.
- Начинают непосредственную реализацию задач, которые двигаются по доске «Релиз».
Результаты
С новой методологией GIST и грамотной организацией документов мы сильно расширили горизонт планирования. Теперь есть четкое понимание, что войдет в апдейт, который выйдет через три месяца, хотя раньше не было уверенности в том, что будет в следующем.Перестали тратить ценное время на амбициозные фичи, результат которых нельзя оценить по метрикам. Например, можно два месяца потратить на фичу, которая ни на что не повлияет или даже сделает хуже (придется откатывать и тратить еще месяц). Таких случаев у нас теперь не бывает.
Что касается внедрения Jira, то она повлияла на общее удобство и скорость работы. Мы избавились от лишней коммуникации в Slack, документы фиксируются прямо в задачах и не теряются в переписках, что тоже экономит время на поиск нужной информации.
Также повысилась осведомленность команды. Теперь все причастные к проекту ясно понимают, какую задачу и для чего делают, так как все есть на доске перед глазами.
Итого. Важно уделять время средне- и долгосрочному планированию, даже если у вас небольшая команда и молодой проект. Малое количество времени, потраченное на планирование, сэкономит большое количество времени, потраченное на разработку.
Потратить время сейчас, чтобы сэкономить потом: как мы выстраивали процессы разработки и планирования на игровом проекте
Несколько лет назад небольшой командой сделали тестовый прототип PvP-шутера, который внезапно выстрелил. Тогда ни разработчики, ни процессы не были готовы к такой популярности, мы развивали проект...
habr.com