Я время делю на внутренние дела (командные) и внешние (общение с бизнесом и т.д.), а оба типа этих дел есть в каждом пункте, поэтому сложно сказать, сколько времени уделяется на каждый пункт. По календарю у меня получается такая схема: 16 часов на команду и 24 часа в неделю на "внешние" вопросы (согласования с бизнесом и т.д.). Но не всегда все 24 часа в неделю заняты внешним общением, тогда я просто беру и делаю внутренние задачи. Я бы не советовал выделять конкретное время под каждый пункт, по крайней мере, у меня это не работает. Просто выделяйте слоты, и, когда есть свободное время, выполняйте накопившиеся дела.
Обычно в команде есть кто-то, кому интересно брать на себя ответственность за команду, релизы. Основной и единственный мотиватор: пробовать себя в роли лида и развивать управленческие и софт скиллы. Это все выясняется и обсуждается на 1то1 встречах.
Upd. Добавлю контекста)
Вы же разработчика не бросаете на растерзание менеджеров. Перед своим уходом своего разработчика нужно погрузить в текущие задачи, добавить на необходимые встречи и т.д. Т.е. нужно все подготовить так, чтобы и.о. по минимуму трогали всякие управленцы, и он был сосредоточен на команде и предстоящем релизе. Т.е. и.о. работает в лайт режиме.
Обычно, это интересно коллегам. Но если нет, то могут просто по-дружески заменить, если в коллективе хорошие отношения.
Назначение скорее добровольное, потому что обычно есть, чем заинтересовать разработчика побыть и.о.
Делегирование задач разработчику - так, чтобы окна помыть или забор на даче поправить, не бывает) Обычно я отправляю вместо себя разработчика, если вопрос и так его затронет и нужна его экспертиза или если это поспособствует его развитию.
Идея, что так не надо делать, прослеживается в пунктах 3 и 4. Я писал, как я пытался обработать абсолютно всех и сразу, и это была плохая идея, нужно планировать и поддерживать некоторый SLA по входящим вопросам.
Да, это важный момент, но когда я начинал, я и сам не знал, что от меня требуется и такой проблемы не было. Но сейчас, если проходишь собеседование на лидовую позицию, то это главный вопрос к интервьюерам. Спасибо.
Мы не считаем, что велосити пропорционально выбывшим сотрудникам, но нужно на что-то опереться при следующем планировании. Можно вычесть пропорционально, а можно вообще не вычитать и смотреть, сколько команда сделает.
Про признание авторов: знаете теорию публичного апи? Что оно зачастую используется не так, как задумано автором.
Согласен. И даже переоценивать фичи не приходится при незначительном изменении состава команды, т.к. сложность не меняется для оставшейся части команды, она просто не может выполнить тот же объем работы, и это нужно учитывать при планировании следующей итерации. Только если команда поменяется вся нужно переоценивать, но я такое на практике не встречал. Корреляции всегда есть от спринта к спринту, поэтому мы считаем среднее значение, на которое опираемся в дальнейшем.
В примере просто мало задач, поэтому, наверное, избыточно. Но, когда много задач и большая команда, планировать с диаграммой Ганта удобно, даже на недельном промежутке. В любом случае, у каждого модель немного своя :) Про MS не знал, интересно, поищу инфу про их процесс, спасибо.
Это зависит от того, кто делает системный анализ, от его опыта и знания продукта. В моем опыте неплохие показатели такие: простая фича – 1 день (пара экранов, пара запросов), средняя фича – 5-7 дней, сложная фича (обычно, когда участвуют смежные команды) – 2-3 недели.
В оценку мы хорошо попадаем (хотя это зависит от качества аналитики, но, когда она приличная, попасть несложно), даже если делаем что-то новое. 90% точно попадаем или заканчиваем немного раньше. Тут мне также помогают коэффициент разработки и оценка покером со всей командой. Т.е. мы всей командой собираемся и обсуждаем пути решения фичи. Это особенно помогает, если проект большой и всего не знаешь о нем. Например, на обсуждении понимаем, что нам нужно для этой фичи сделать вот то-то и то-то, а тут другой разработчик говорит, что что-то подобное в проекте уже есть, посмотрите там-то и там-то.
Бизнесу неважно, сколько мы делаем за спринт, да. Скорость разработки, в моем случае, это фактура, с которой мы идем бизнесу, если нам нужно объяснить, почему мы не успеем выполнить задачи в желаемый бизнесом срок. Т.е. мы не просто голословно заявляем, что не справимся (и, возможно, нас стоит уволить :) ), а приносим данные, с которыми сложно спорить. А когда есть данные, всегда можно конструктивно обсудить пути решения. Также по этим данным можно принимать и другие решения, например, о расширении команды.
Привет! Пробовал и такой вариант, но с ним был ряд проблем, которые мне не удалось решить. Кстати, в текущем примере я просто показал суммарную оценку в часах для каждой фичи, саму декомпозицию я опустил, т.к. решил, что про это достаточно было упомянуть. Обычно задача (часть фичи) не должна превышать 16 часов.
Оценка в SP хороша тем, что не требует деталей. И когда я работал без этапа системного анализа, оценивать в SP - это был единственный вариант. Я писал в статье, почему стоит включать системный анализ.
А когда он есть, уже есть возможность оценить именно в часах. А с оценкой в часах легко можно наполнить спринт и спланировать работу команды на диаграмме Ганта, а в SP я не знаю, как это сделать.
Также, когда у вас и фичи, и технические задачи, и баги в SP, сложно предоставить бизнесу информацию, а сколько же бизнес-задач делается за спринт. А когда вычитаешь SP для бизнес-задач из всех задач, то получаешь искаженное значение. И я ни разу не встречал бизнес, которому был бы интересен тех долг.
Поэтому у меня получился такой скомбинированный подход.
Итоговая оценка SP для фичи не зависит от последовательности работ над ней, вы просто оцениваете усилие команды. В первом примере наибольшие усилия потребуются от дизайнера, а 1 SP со стороны фронта, можно сказать, погрешность в данном случае. Итоговая оценка выбирается всеми участниками, часто в качестве итоговой выбирается оценка подкоманды, у которой больше всего возникнет трудностей. Точно могу сказать, что нельзя в качестве итоговой оценки брать среднее значение. Я поступаю так: команда оценила - обсудили, почему такие оценки поставили, - сошлись на некоторой общей оценке, которая всех устраивает, т.е. выбранная оценка покрывает предположительную сложность работы каждой подкоманды. p.s. Проверю размеры блоков, может, где-то промахнулся. Спасибо.
Такую штуку и не видел даже, в альфе ещё, вроде. Функционала недостаточно пока ещё, можно только передать результат, чем-то напоминает onActivityResult. Вот интересно, зачем в Гугл такую штуку добавили, ведь здесь тоже можно использовать SharedViewModel… Возможно, там тоже понимают проблему, и вскоре мы увидим новый arch component. Хорошо бы...
С процессами всегда возни много. В момент сохранения состояния сервис параметров сбрасывает свои данные на persistance storage, потом достает, если надо. Здесь, конечно, простой push/pop не подойдет.
Именно так.
Я время делю на внутренние дела (командные) и внешние (общение с бизнесом и т.д.), а оба типа этих дел есть в каждом пункте, поэтому сложно сказать, сколько времени уделяется на каждый пункт. По календарю у меня получается такая схема: 16 часов на команду и 24 часа в неделю на "внешние" вопросы (согласования с бизнесом и т.д.). Но не всегда все 24 часа в неделю заняты внешним общением, тогда я просто беру и делаю внутренние задачи. Я бы не советовал выделять конкретное время под каждый пункт, по крайней мере, у меня это не работает. Просто выделяйте слоты, и, когда есть свободное время, выполняйте накопившиеся дела.
Cейчас пользуемся своей внутренней разработкой, что-то типо trello на минималках. А раньше я пользовался Trello, Notion.
Обычно в команде есть кто-то, кому интересно брать на себя ответственность за команду, релизы. Основной и единственный мотиватор: пробовать себя в роли лида и развивать управленческие и софт скиллы. Это все выясняется и обсуждается на 1то1 встречах.
Upd. Добавлю контекста)
Вы же разработчика не бросаете на растерзание менеджеров. Перед своим уходом своего разработчика нужно погрузить в текущие задачи, добавить на необходимые встречи и т.д. Т.е. нужно все подготовить так, чтобы и.о. по минимуму трогали всякие управленцы, и он был сосредоточен на команде и предстоящем релизе. Т.е. и.о. работает в лайт режиме.
Обычно, это интересно коллегам. Но если нет, то могут просто по-дружески заменить, если в коллективе хорошие отношения.
Мобильная разработка, Android, финтех.
Назначение скорее добровольное, потому что обычно есть, чем заинтересовать разработчика побыть и.о.
Делегирование задач разработчику - так, чтобы окна помыть или забор на даче поправить, не бывает) Обычно я отправляю вместо себя разработчика, если вопрос и так его затронет и нужна его экспертиза или если это поспособствует его развитию.
Делегировать нужно аккуратно, тут я согласен.
По-разному пробовал сформулировать :) 4 проблемы - не занимаТЬся планированием. Подумаю над своими формулировками, спасибо.
Идея, что так не надо делать, прослеживается в пунктах 3 и 4. Я писал, как я пытался обработать абсолютно всех и сразу, и это была плохая идея, нужно планировать и поддерживать некоторый SLA по входящим вопросам.
Да, это важный момент, но когда я начинал, я и сам не знал, что от меня требуется и такой проблемы не было. Но сейчас, если проходишь собеседование на лидовую позицию, то это главный вопрос к интервьюерам. Спасибо.
Мы не считаем, что велосити пропорционально выбывшим сотрудникам, но нужно на что-то опереться при следующем планировании. Можно вычесть пропорционально, а можно вообще не вычитать и смотреть, сколько команда сделает.
Про признание авторов: знаете теорию публичного апи? Что оно зачастую используется не так, как задумано автором.
Согласен. И даже переоценивать фичи не приходится при незначительном изменении состава команды, т.к. сложность не меняется для оставшейся части команды, она просто не может выполнить тот же объем работы, и это нужно учитывать при планировании следующей итерации. Только если команда поменяется вся нужно переоценивать, но я такое на практике не встречал. Корреляции всегда есть от спринта к спринту, поэтому мы считаем среднее значение, на которое опираемся в дальнейшем.
В примере просто мало задач, поэтому, наверное, избыточно. Но, когда много задач и большая команда, планировать с диаграммой Ганта удобно, даже на недельном промежутке. В любом случае, у каждого модель немного своя :) Про MS не знал, интересно, поищу инфу про их процесс, спасибо.
Это зависит от того, кто делает системный анализ, от его опыта и знания продукта. В моем опыте неплохие показатели такие: простая фича – 1 день (пара экранов, пара запросов), средняя фича – 5-7 дней, сложная фича (обычно, когда участвуют смежные команды) – 2-3 недели.
В оценку мы хорошо попадаем (хотя это зависит от качества аналитики, но, когда она приличная, попасть несложно), даже если делаем что-то новое. 90% точно попадаем или заканчиваем немного раньше. Тут мне также помогают коэффициент разработки и оценка покером со всей командой. Т.е. мы всей командой собираемся и обсуждаем пути решения фичи. Это особенно помогает, если проект большой и всего не знаешь о нем. Например, на обсуждении понимаем, что нам нужно для этой фичи сделать вот то-то и то-то, а тут другой разработчик говорит, что что-то подобное в проекте уже есть, посмотрите там-то и там-то.
Бизнесу неважно, сколько мы делаем за спринт, да. Скорость разработки, в моем случае, это фактура, с которой мы идем бизнесу, если нам нужно объяснить, почему мы не успеем выполнить задачи в желаемый бизнесом срок. Т.е. мы не просто голословно заявляем, что не справимся (и, возможно, нас стоит уволить :) ), а приносим данные, с которыми сложно спорить. А когда есть данные, всегда можно конструктивно обсудить пути решения. Также по этим данным можно принимать и другие решения, например, о расширении команды.
Привет! Пробовал и такой вариант, но с ним был ряд проблем, которые мне не удалось решить. Кстати, в текущем примере я просто показал суммарную оценку в часах для каждой фичи, саму декомпозицию я опустил, т.к. решил, что про это достаточно было упомянуть. Обычно задача (часть фичи) не должна превышать 16 часов.
Оценка в SP хороша тем, что не требует деталей. И когда я работал без этапа системного анализа, оценивать в SP - это был единственный вариант. Я писал в статье, почему стоит включать системный анализ.
А когда он есть, уже есть возможность оценить именно в часах. А с оценкой в часах легко можно наполнить спринт и спланировать работу команды на диаграмме Ганта, а в SP я не знаю, как это сделать.
Также, когда у вас и фичи, и технические задачи, и баги в SP, сложно предоставить бизнесу информацию, а сколько же бизнес-задач делается за спринт. А когда вычитаешь SP для бизнес-задач из всех задач, то получаешь искаженное значение. И я ни разу не встречал бизнес, которому был бы интересен тех долг.
Поэтому у меня получился такой скомбинированный подход.
Я потерял картинку с оценкой фичей в часах, которую сделали после системного анализа, поэтому диаграмма казалась неверной. Обновил статью, спасибо.
Итоговая оценка SP для фичи не зависит от последовательности работ над ней, вы просто оцениваете усилие команды. В первом примере наибольшие усилия потребуются от дизайнера, а 1 SP со стороны фронта, можно сказать, погрешность в данном случае. Итоговая оценка выбирается всеми участниками, часто в качестве итоговой выбирается оценка подкоманды, у которой больше всего возникнет трудностей. Точно могу сказать, что нельзя в качестве итоговой оценки брать среднее значение. Я поступаю так: команда оценила - обсудили, почему такие оценки поставили, - сошлись на некоторой общей оценке, которая всех устраивает, т.е. выбранная оценка покрывает предположительную сложность работы каждой подкоманды. p.s. Проверю размеры блоков, может, где-то промахнулся. Спасибо.
Такую штуку и не видел даже, в альфе ещё, вроде. Функционала недостаточно пока ещё, можно только передать результат, чем-то напоминает onActivityResult. Вот интересно, зачем в Гугл такую штуку добавили, ведь здесь тоже можно использовать SharedViewModel… Возможно, там тоже понимают проблему, и вскоре мы увидим новый arch component. Хорошо бы...