Комментарии 15
Нас заливало постоянными и неконтролируемыми изменения (добросами) в дизайне фичи. В работе рождались новые идеи и допилы. Мы брались за все изменения без какого-либо анализа...
А аналитика у вас нет? Бизнес-идеи вбрасываются непосредственно в разработку?
У нас есть аналитики, но они продуктовые и сфокусированы на метриках продукта.
Про идеи - тут нужно понимать, что допилы/добросы могут быть как по дизайну, так и технические. Изменение дизайна сначала обсуждались Гейм Дизайнерами (+ иногда с привлечением Продюсера/Аналитиков или других отделов) и потом вкидывались непосредственно в команду. Технические задачи генерит сама команда разработки (например, сделать рефакторинг). Зачастую и те, и другие изменения не являются критичными для первого релиза фичи, поэтому их всегда можно отложить на будущее.
Забыл поворчать в пятницу - поворчу сейчас. Вы все сделали совершенно правильно, вот только такие статьи - не обижайтесь, сам хожу по этим граблям - напоминают построение велосипедов. Методологии построения работы, лучшие практики и пр. давно уже разработаны и описаны, осталось их применять (где-то допиливая по месту). У вас есть системные аналитики, просто по факту их роль играет разработка. Соответственно, все, что Вы сделали - заставили разработчиков эту роль правильно играть. И вот когда они стали фильтровать все входящие свистелки и хотелки, обсуждать их с соседскими командами, смотреть на объявленные ранее сроки и т.д. - а это все как раз работа системного аналитика - "Вот тут-то мне карта и попёрла!". И да, если документация идет как часть выходных артефактов, то и время на нее должно закладываться, как и на прочую работу.
Да, мы, безусловно, берем в основу известные методологии разработки - куда без этого) Но реализация этих методологий на практике всегда разная. Зачастую все команды встречаются с одинаковыми проблемы, но решение у всех своё. Не зря же на Ретро поднимаются и обсуждают сложные кейсы. Команда вправе сама решать - как им изменять и улучшать процессы... и это нормально. Поэтому у всех свой прекрасный велосипед , который в основе имеет один и тот же механизм работы (методологию)) Я пришла к выводу, что велосипеды неизбежны и одного красивого масштабного решения нет ... как только приняла это, стало намного проще в работе применять простые (но эффективные) решения. А в этой статье решила поделиться именно практикой, а не писать лекцию - какой плохой или хороший Agile/Waterfall)
Затрону еще вопрос с Системным аналитиком - считаю, что в рамках Enterprise это полезная роль, но в GameDev есть особенность работы - фича - это не бизнес-процесс, который мы автоматизируем, правим или заново выстраиваем. У нас дизайн игровых фичей, точные результаты успешности фичи мы получаем только с реальных данных, т.е. покупают игроки в игре что-то или нет) Поэтому над определением дизайна работают много людей - это и Гейм Дизайнер, Продюсер, Аналитики, отдел Монетизации и т.д. Если бы был кто-то 1 , кто точно знал - как оптимально делать, то мы бы с радостью забрали такого человека в команду) В нашем случае мы не перекладываем решение по дизайну на разработку, мы лишь обсуждаем всей командой - насколько изменение критично для нашего релиза, нам важно услышать мнение специалистов в своей сфере и взять полезный от них фидбэк)
Привет бывшим коллегам,
>Обсуждаем все изменения в дизайне фичи в открытых Slack-каналах
На текущем проекте тоже пришли к тому что любой диалог, требующий координации больше чем двух сотрудников, должен обсуждаться в соответствующем общем чате. Это особенно актуально во время удаленной работы.
Расскажите подробней про Capacity и Complexity
На основе чего вы рассчитываете Capacity команды? Вы ведете time sheets или что-то более простое для учета времени, потраченного на задачи? Просто считаете количество задач (тогда как вы суммируете задачи разных размеров)? Заранее оцениваете в "не-временнЫх" единицах вроде "берем идеальную задачу и сравниваем остальные с ней - такая же, дольше, проще" или "прогноза подводных камней - просто, нужно подумать, вообще не понятно" (а есть переоценка во время work in progress)?
Как вы измеряете Complexity? Эти единицы можно складывать? Как они сопоставляются с Capacity?
Как считаем Complexity - это сумма Оценок задач в Эпике. Задачи мы оцениваем в Story Point. Оценку дает команда разработки целиком (у нас есть разбиение на клиентских и серверных разработчиков, они оценивают по-отдельности) через Покер планирование. Так сложилось, что 0.5SP у нас выливается в 1 день разработки, 1SP - 1.5-2 дня, 2 SP - 4-5 дней (сейчас меня могут закидать помидорами, потому что SP как бы низя переводить в дни, но мы так делаем))). Есть важное правило - мы не берем в работу задачи с оценкой больше чем в 2 SP, т.к. это как черный ящик, поэтому мы инвестируем доп. время на этапе расписания на проведение RnD, чтобы дать более точные оценки и декомпозировать задачу. Лучше это делать в самом начале, чем в середине разработки понять, что там скрылся рефакторинг на 10SP. Периодически мы проверяем, попадаем ли мы в оценки - через данные в Jira + сравниваем успели мы сделать планируемый скоуп к нужному времени или нет))
Как считаем Capacity - закладываем, что за 2 недели мы делаем 5 Story Point (эта цифра взята из практики, а не из головы). Мы учитываем, в какую дату сможет подключиться каждый из разработчиков, закладываем на каждого разработчика время на отпуск + возможный больничный + риски на возможные изменения в скоупе фичи (это число мы как раз рассчитываем).
Оба числа просто сравниваются и если Complexity>Capacity, то из фичи убираются задачи пока Complexity и Capacity не станут равным.
Спасибо! Хотя я еще вопросов принес :)
Наверняка у вас встречаются ситуации, когда одна задача становится заблокированой на некоторое время (нужно чего-то дождаться, отвлечься на срочное - да тот же отгул на день). Вы как-то учитываете это при проверках "попадаем в оценки или нет"? Сколько суммарно времени может уходить на "задача в работе, но не делается"?
Как много у вас задач-прилетов "все в огне, нужно сделать вчера", не связанных с бэклогом итерации? Какое соотношение между ними и выявленными "подводными камнями" задач в работе, без которых не запуститься?
Также кажется, что у найденного подводного камня есть две судьбы - либо без него вообще нельзя, и на задачу будет потрачено больше времени (и это вы не только закладываете заранее, но и проверяете впоследствии), либо это "можно отложить". Вопрос - есть ли у вас в бэклоге такие фиче- и технические долги? Как вы их приоритизируете относительно новых фич-реквестов, по какому принципу набираете в бэклог итерации?
И есть ли у вас какие-нибудь best practicies и прочие трюки, чтобы сформулировать Definition of Done, с которым все (разработчики и стейкхолдеры) будут иметь в виду одно и то же? (что также должно минимизировать расхождение между прогнозируемой сложностью и фактическими затратами, ведь nice to have, который не подразумевался заранее, можно с чистой совестью отложить или даже выкинуть)
Да, конечно, учитываем. Если человек уходит в отпуск/отгул/заболел, то такие кейсы учитываются в нашем изначальном Capacity команды еще перед стартом разработки, поэтому это не должно сказываться на финальной дате. Если это что-то незапланированное, то у нас всегда есть запас из % рисков. Если уже что-то сверху, мы рассчитываем оставшееся Capacity команды и оставшееся Complexity фичи и снова их сравнивать, главное понимать - сколько будет простаивать задача.
“Сколько суммарно времени может уходить на “задача в работе, но не делается“? ” - тут не совсем поняла вопрос, можешь раскрыть?В нашем случае - крупной фичей занимается выделенная команда, мы ее не трогаем совсем и тут могут быть только изменение дизайна/незапланированный рефакторинг/забытый функционал . Но при этом у нас есть еще часть людей , кто может заниматься залетными задачами или другими менее крупными фичами и вот тут мы можем стопать работу менее приоритетной фичи и давать что-то критичное.
Задачи-прилеты - это всегда вопрос приоритетов для бизнеса. Тут должен задаваться только 1 вопрос - Что для нас важнее на текущий момент? Продюсер/Product Owner должен делать выбор. Сделать сразу 2 задачи и при этом не изменить срок готовности или не увеличить состав команды - так не получится) Поэтому для нас залетные задачи - это только те, что могут полностью заблокировать работу игры на проде. Например, упали серваки - естественно, это становится приоритетом №1 в работе команды.Технический долг, естественно, есть) Каждый спринт мы выделяем у команды разработки 5%-10% их времени на техдолг (это просто волевое решение)). Если есть что-то крупное и важное, что требует длительной активной разработки, то мы выделяем прям как фичу и эта фича лежит в нашем продуктовом бэклоге и у нее есть ценность для бизнеса в том числе. Мы понимаем, что забить на техдолг нельзя... иначе продукту в определенный момент будет очень плохо)
У нас нет внешних стейкхолдеров, только заказчик в лице Продюсера или Геймдизайре, которые находятся внутри команды. Пока мы обходимся без формализованного процесса составления DoD. Но нам помогает быть на одной волне - хорошая атмосфера в команде, плотный контакт и нацеленность на единый результат. Все друг другу помогают, готовы ответить на вопросы. Мы часто показываем промежуточные результаты работы и даем фидбэк. В условиях удаленки - обязательно нужны общие синки (обсуждайте вместе все проблемы и задавайте вопросы), максимальная открытость в переписке в каналах (команде должно быть комфортно высказывать свое мнение. привлекайте в обсуждения людей). Пока мы обходимся без формализованного процесса составления DoD
1. Кажется, я замудрил с вопросом, поэтому позволь переобуться на ходу. Как именно вы проверяете, попадаете вы в оценки или нет? Если используете реально затраченное время - откуда его берете и как обеспечиваете его адекватность?
Немного контекста моего интереса. У нас есть проблемы а-ля "недожарили задачу, а стейкхолдеры не могут ответить прямщаз" и "делали задачку, и вдруг прод загорелся - отвлеклись на 2-3 дня". Мы пытались помечать unexpected-задачи, чтобы на основе статистики понять процент рисков для такой же "закладки" и отработать их причины - вышло по-бюрократически муторно и не очень точно ¯\_(ツ)_/¯ Например, мы забываем двигать или тегать карточки, таск-трекер не считает, сколько времени задача была в статусе "заблокировано", ну и ситуации бывают куда гибче и хитрее этих ваших процессов и инструментов :)
4. Я не могу не спросить. Бывает такое, что в стремлении сделать как можно лучше разработчики слишком увлекаются "игрой со шрифтами" и в итоге продалбывают какой-нибудь важный кусочек функциональности?
Отвечу по-частям:
1.1 Сбор статистики - в трекинга всегда грязные данные и их чистить очень сложно. Из Jira я беру только те данные, которые можно быстро почистить. Смена статусов с большой командой - это очень сложно и жестко контролировать точно не получить (будете контролировать - будет гнев команды на вас)) не стоит заставлять)
Если хотите оценить попадаете ли вы в оценку, то смотрите на больших цифрах.... Предположим, у вас делает 1 итерации весом 50SP всего 1 разработчик - по времени это, например, 50 дней. Когда завершается итерация/фича - вы смотрите в целом, ваши 50SP уложились в 50 дней? Если +/- да, значит в целом всё норм, если 50SP вы сделали за 100 дней - то тут уже явно всё плохо, значит нужно углубляться в детали. Обычно я смотрю меридиану потраченного времени для разных весов задач - 0.5SP/ 1SP/ 2SP/ 3SP. Именно так мы нашли, что задачи на 3SP всегда занимают разное время - от 0.5 дня до 2х недель, поэтому от такого веса мы отказались и декомпозируем.
1.2. Unexpected-задачи - в моем понимании, это задачи с приоритетом Блокер (т.е. важнее текущая фича и прод без этой задачи просто развалиться) + это всегда неожиданная хрень (для нас, например, это выход idfa - это внешний фактор) + повлиять на появление таких задач практически невозможно. Но тут нужно понимать:
- если вы постоянно встречаетесь с одной и той же проблемой “прод загорелся ” - это уже не unexpected-задача (при этом причины в проблем прода могут быть всегда разные). Значит, нужно системно бороться с этой проблемой, т.е. выделять время разработки на фиксы (это нужно еще уметь продать вашему product owner, но зачастую продуктовики сами заинтересованы в стабильности своего продукта). Если выделить время на системное решение проблемы не получается, то просто увеличивайте риски при разработке основной итерации. Прям считайте, сколько примерно в среднем времени (не пытайтесь оценить точно ... это тут не нужно) вы тратите каждый раз на тушение пожаров и это время закладывайте в риски.
- если всё-таки всё, что прилетает это действительно unexpected-задача - то просто закладывайте в риски. Вы не сможете это контролировать факт появления, только вы можете митигировать эту потенциальную проблему, например, заложив это в риски разработки.
1.3 Заблокированные задачи - нужно понимать частоту появлений и кто-кого блочит. Если это внутри команды - попробуйте на раннем этапе проставить зависимости между задачами, на статусах обсуждать заранее - кто и кого может заблочить по работе и у кого какие планы (тут снова должны быть хорошие коммуникации у команды). Если блокеры со стороны внешних стейкхолдеров и к ним копиться всегда много вопросов - то стоит налаживать контакт с ними... не могут ответить в моменте , значит организуйте чаще с ними мини-созвоны, где можно будет обсудить все вопросы. Если постоянно возникают вопросы, которые можно было задать и на раннем этапе - то пробуйте выделять больше времени при декомпозиции фичи. Это уже проблема не в том, что стейкхолдеры не отвечают, а в том, что разработка не детально расписывает задачи.Да, такое бывает) Нам помогают синки. Лид/ПМ видит, что человек уже 2 дня делает одну задачу и застрял на одном месте, а должен был уже сдавать в куа - значит, стоит туда капнуть и узнать в чем затык) Возможно человек просто не знает как решить задачку и ему нужна просто помощь) ну или он чем-то увлекся)
Обычно я смотрю меридиану потраченного времени для разных весов задач - 0.5SP/ 1SP/ 2SP/ 3SP
Если я правильно понял, то речь идет о медиане, она же 50th percentile. Физический смысл - "половина задач будет сделана за это или меньшее время". Вам достаточно того, что вы прогнозируете только половину задач? Или вы (вообще кто-то кроме тебя ходит на эти экраны Jira?) проверяете и другие характеристики распределения? Боюсь, я не настолько дружу со статистикой, чтобы что-то предполагать...
Да, речь про медиану) Значение - половина значений находится ниже этого значения, а другая половина находится выше этого значения. Кроме самого значения медианы , важна плотность распределения задач относительно медианы + правильно построенная выборка. Грубо говорят, если бОльшая часть задач находит близко к медиане, то значит оцениваем норм. Если нет и разброс очень большой, то возможно тут проблема и стоит покопать. Очень грубый пример -
1day , 1.5d, 1.9d, 2.1d, 2.2d, 2.3d, 2.5d - распределение норм
1d , 1.5d, 1.9d, 2.1d, 3d, 6d, 9d - распределение не норм
Невозможно найти какую-то одну единственную статистику , которая покажется вам - всё хорошо или всё плохо, к сожалению. Поэтому смотрим кучу разных разрезов и каждая из них может дать сигнал в совершенно разных ситуациях. Пробуйте разные и не бойтесь грязных данных, даже они могут быть показательны. главное, делать это регулярно.
Релизы без выгорания и овертаймов: как мы меняли процессы работы над крупными игровыми фичами