Да, речь про медиану) Значение - половина значений находится ниже этого значения, а другая половина находится выше этого значения. Кроме самого значения медианы , важна плотность распределения задач относительно медианы + правильно построенная выборка. Грубо говорят, если бОльшая часть задач находит близко к медиане, то значит оцениваем норм. Если нет и разброс очень большой, то возможно тут проблема и стоит покопать. Очень грубый пример - 1day , 1.5d, 1.9d, 2.1d, 2.2d, 2.3d, 2.5d - распределение норм 1d , 1.5d, 1.9d, 2.1d, 3d, 6d, 9d - распределение не норм
Невозможно найти какую-то одну единственную статистику , которая покажется вам - всё хорошо или всё плохо, к сожалению. Поэтому смотрим кучу разных разрезов и каждая из них может дать сигнал в совершенно разных ситуациях. Пробуйте разные и не бойтесь грязных данных, даже они могут быть показательны. главное, делать это регулярно.
Отвечу по-частям: 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 дня делает одну задачу и застрял на одном месте, а должен был уже сдавать в куа - значит, стоит туда капнуть и узнать в чем затык) Возможно человек просто не знает как решить задачку и ему нужна просто помощь) ну или он чем-то увлекся)
Да, конечно, учитываем. Если человек уходит в отпуск/отгул/заболел, то такие кейсы учитываются в нашем изначальном Capacity команды еще перед стартом разработки, поэтому это не должно сказываться на финальной дате. Если это что-то незапланированное, то у нас всегда есть запас из % рисков. Если уже что-то сверху, мы рассчитываем оставшееся Capacity команды и оставшееся Complexity фичи и снова их сравнивать, главное понимать - сколько будет простаивать задача. “Сколько суммарно времени может уходить на “задача в работе, но не делается“? ” - тут не совсем поняла вопрос, можешь раскрыть?
В нашем случае - крупной фичей занимается выделенная команда, мы ее не трогаем совсем и тут могут быть только изменение дизайна/незапланированный рефакторинг/забытый функционал . Но при этом у нас есть еще часть людей , кто может заниматься залетными задачами или другими менее крупными фичами и вот тут мы можем стопать работу менее приоритетной фичи и давать что-то критичное. Задачи-прилеты - это всегда вопрос приоритетов для бизнеса. Тут должен задаваться только 1 вопрос - Что для нас важнее на текущий момент? Продюсер/Product Owner должен делать выбор. Сделать сразу 2 задачи и при этом не изменить срок готовности или не увеличить состав команды - так не получится) Поэтому для нас залетные задачи - это только те, что могут полностью заблокировать работу игры на проде. Например, упали серваки - естественно, это становится приоритетом №1 в работе команды.
Технический долг, естественно, есть) Каждый спринт мы выделяем у команды разработки 5%-10% их времени на техдолг (это просто волевое решение)). Если есть что-то крупное и важное, что требует длительной активной разработки, то мы выделяем прям как фичу и эта фича лежит в нашем продуктовом бэклоге и у нее есть ценность для бизнеса в том числе. Мы понимаем, что забить на техдолг нельзя... иначе продукту в определенный момент будет очень плохо)
У нас нет внешних стейкхолдеров, только заказчик в лице Продюсера или Геймдизайре, которые находятся внутри команды. Пока мы обходимся без формализованного процесса составления DoD. Но нам помогает быть на одной волне - хорошая атмосфера в команде, плотный контакт и нацеленность на единый результат. Все друг другу помогают, готовы ответить на вопросы. Мы часто показываем промежуточные результаты работы и даем фидбэк. В условиях удаленки - обязательно нужны общие синки (обсуждайте вместе все проблемы и задавайте вопросы), максимальная открытость в переписке в каналах (команде должно быть комфортно высказывать свое мнение. привлекайте в обсуждения людей). Пока мы обходимся без формализованного процесса составления DoD
Как считаем 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 не станут равным.
Привет)) Плюсую) удаленка прям подтолкнула вести общение максимально открыто на всех... теперь не получится услышать новости на кухне во время обеда) Слак стал практически всем миром))))
Да, мы, безусловно, берем в основу известные методологии разработки - куда без этого) Но реализация этих методологий на практике всегда разная. Зачастую все команды встречаются с одинаковыми проблемы, но решение у всех своё. Не зря же на Ретро поднимаются и обсуждают сложные кейсы. Команда вправе сама решать - как им изменять и улучшать процессы... и это нормально. Поэтому у всех свой прекрасный велосипед , который в основе имеет один и тот же механизм работы (методологию)) Я пришла к выводу, что велосипеды неизбежны и одного красивого масштабного решения нет ... как только приняла это, стало намного проще в работе применять простые (но эффективные) решения. А в этой статье решила поделиться именно практикой, а не писать лекцию - какой плохой или хороший Agile/Waterfall) Затрону еще вопрос с Системным аналитиком - считаю, что в рамках Enterprise это полезная роль, но в GameDev есть особенность работы - фича - это не бизнес-процесс, который мы автоматизируем, правим или заново выстраиваем. У нас дизайн игровых фичей, точные результаты успешности фичи мы получаем только с реальных данных, т.е. покупают игроки в игре что-то или нет) Поэтому над определением дизайна работают много людей - это и Гейм Дизайнер, Продюсер, Аналитики, отдел Монетизации и т.д. Если бы был кто-то 1 , кто точно знал - как оптимально делать, то мы бы с радостью забрали такого человека в команду) В нашем случае мы не перекладываем решение по дизайну на разработку, мы лишь обсуждаем всей командой - насколько изменение критично для нашего релиза, нам важно услышать мнение специалистов в своей сфере и взять полезный от них фидбэк)
У нас есть аналитики, но они продуктовые и сфокусированы на метриках продукта. Про идеи - тут нужно понимать, что допилы/добросы могут быть как по дизайну, так и технические. Изменение дизайна сначала обсуждались Гейм Дизайнерами (+ иногда с привлечением Продюсера/Аналитиков или других отделов) и потом вкидывались непосредственно в команду. Технические задачи генерит сама команда разработки (например, сделать рефакторинг). Зачастую и те, и другие изменения не являются критичными для первого релиза фичи, поэтому их всегда можно отложить на будущее.
Да, речь про медиану) Значение - половина значений находится ниже этого значения, а другая половина находится выше этого значения. Кроме самого значения медианы , важна плотность распределения задач относительно медианы + правильно построенная выборка. Грубо говорят, если бОльшая часть задач находит близко к медиане, то значит оцениваем норм. Если нет и разброс очень большой, то возможно тут проблема и стоит покопать. Очень грубый пример -
1day , 1.5d, 1.9d, 2.1d, 2.2d, 2.3d, 2.5d - распределение норм
1d , 1.5d, 1.9d, 2.1d, 3d, 6d, 9d - распределение не норм
Невозможно найти какую-то одну единственную статистику , которая покажется вам - всё хорошо или всё плохо, к сожалению. Поэтому смотрим кучу разных разрезов и каждая из них может дать сигнал в совершенно разных ситуациях. Пробуйте разные и не бойтесь грязных данных, даже они могут быть показательны. главное, делать это регулярно.
Отвечу по-частям:
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 дня делает одну задачу и застрял на одном месте, а должен был уже сдавать в куа - значит, стоит туда капнуть и узнать в чем затык) Возможно человек просто не знает как решить задачку и ему нужна просто помощь) ну или он чем-то увлекся)
Да, конечно, учитываем. Если человек уходит в отпуск/отгул/заболел, то такие кейсы учитываются в нашем изначальном Capacity команды еще перед стартом разработки, поэтому это не должно сказываться на финальной дате. Если это что-то незапланированное, то у нас всегда есть запас из % рисков. Если уже что-то сверху, мы рассчитываем оставшееся Capacity команды и оставшееся Complexity фичи и снова их сравнивать, главное понимать - сколько будет простаивать задача.
“Сколько суммарно времени может уходить на “задача в работе, но не делается“? ” - тут не совсем поняла вопрос, можешь раскрыть?
В нашем случае - крупной фичей занимается выделенная команда, мы ее не трогаем совсем и тут могут быть только изменение дизайна/незапланированный рефакторинг/забытый функционал . Но при этом у нас есть еще часть людей , кто может заниматься залетными задачами или другими менее крупными фичами и вот тут мы можем стопать работу менее приоритетной фичи и давать что-то критичное.
Задачи-прилеты - это всегда вопрос приоритетов для бизнеса. Тут должен задаваться только 1 вопрос - Что для нас важнее на текущий момент? Продюсер/Product Owner должен делать выбор. Сделать сразу 2 задачи и при этом не изменить срок готовности или не увеличить состав команды - так не получится) Поэтому для нас залетные задачи - это только те, что могут полностью заблокировать работу игры на проде. Например, упали серваки - естественно, это становится приоритетом №1 в работе команды.
Технический долг, естественно, есть) Каждый спринт мы выделяем у команды разработки 5%-10% их времени на техдолг (это просто волевое решение)). Если есть что-то крупное и важное, что требует длительной активной разработки, то мы выделяем прям как фичу и эта фича лежит в нашем продуктовом бэклоге и у нее есть ценность для бизнеса в том числе. Мы понимаем, что забить на техдолг нельзя... иначе продукту в определенный момент будет очень плохо)
У нас нет внешних стейкхолдеров, только заказчик в лице Продюсера или Геймдизайре, которые находятся внутри команды. Пока мы обходимся без формализованного процесса составления DoD. Но нам помогает быть на одной волне - хорошая атмосфера в команде, плотный контакт и нацеленность на единый результат. Все друг другу помогают, готовы ответить на вопросы. Мы часто показываем промежуточные результаты работы и даем фидбэк. В условиях удаленки - обязательно нужны общие синки (обсуждайте вместе все проблемы и задавайте вопросы), максимальная открытость в переписке в каналах (команде должно быть комфортно высказывать свое мнение. привлекайте в обсуждения людей). Пока мы обходимся без формализованного процесса составления DoD
Как считаем 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 не станут равным.
Привет))
Плюсую) удаленка прям подтолкнула вести общение максимально открыто на всех... теперь не получится услышать новости на кухне во время обеда) Слак стал практически всем миром))))
Да, мы, безусловно, берем в основу известные методологии разработки - куда без этого) Но реализация этих методологий на практике всегда разная. Зачастую все команды встречаются с одинаковыми проблемы, но решение у всех своё. Не зря же на Ретро поднимаются и обсуждают сложные кейсы. Команда вправе сама решать - как им изменять и улучшать процессы... и это нормально. Поэтому у всех свой прекрасный велосипед , который в основе имеет один и тот же механизм работы (методологию)) Я пришла к выводу, что велосипеды неизбежны и одного красивого масштабного решения нет ... как только приняла это, стало намного проще в работе применять простые (но эффективные) решения. А в этой статье решила поделиться именно практикой, а не писать лекцию - какой плохой или хороший Agile/Waterfall)
Затрону еще вопрос с Системным аналитиком - считаю, что в рамках Enterprise это полезная роль, но в GameDev есть особенность работы - фича - это не бизнес-процесс, который мы автоматизируем, правим или заново выстраиваем. У нас дизайн игровых фичей, точные результаты успешности фичи мы получаем только с реальных данных, т.е. покупают игроки в игре что-то или нет) Поэтому над определением дизайна работают много людей - это и Гейм Дизайнер, Продюсер, Аналитики, отдел Монетизации и т.д. Если бы был кто-то 1 , кто точно знал - как оптимально делать, то мы бы с радостью забрали такого человека в команду) В нашем случае мы не перекладываем решение по дизайну на разработку, мы лишь обсуждаем всей командой - насколько изменение критично для нашего релиза, нам важно услышать мнение специалистов в своей сфере и взять полезный от них фидбэк)
У нас есть аналитики, но они продуктовые и сфокусированы на метриках продукта.
Про идеи - тут нужно понимать, что допилы/добросы могут быть как по дизайну, так и технические. Изменение дизайна сначала обсуждались Гейм Дизайнерами (+ иногда с привлечением Продюсера/Аналитиков или других отделов) и потом вкидывались непосредственно в команду. Технические задачи генерит сама команда разработки (например, сделать рефакторинг). Зачастую и те, и другие изменения не являются критичными для первого релиза фичи, поэтому их всегда можно отложить на будущее.