Верно, и Вы время доставки задач бизнесу растягиваете на несколько спринтов, хотя можно уложиться в один, и всё это время фича не работает, т.е. не приносит деньги, т.е. бизнес деньги теряет.
Если же ... то мы сразу улетаем в неопределенность...
..."работа средних менеджеров превращается в постоянное преодоление кризисов" ...
Вы не поверите, но я, как руководитель, всё это учитываю: и нагрузку по задачам, и перформанс, и больничные/отпуска, и необходимость поиска нового человека, и сроки его онбординга. В реальной жизни без этого никуда ) Вы же, со своей стороны, просто говорите "всё сложно, всего не учесть" и даже не пробуете. У меня в команде есть табличка с факторами рисков и с их весами (добавочный процент к времени выполнения). И, например, для новых задач он больше, для известных задач - меньше. Эта табличка живая, и по ходу жизни проекта цифры меняются.
Вообще, раз уж мы обсуждаем спринты, то мы говорим про scrum, верно? ) А скрам - это про скорость доставки, гибкость, адаптивность, работу в условиях неопределенности. У Вас же весь посыл про строгость, регламенты, увеличение сроков в пользу гарантированных метрик. Возможно, просто скрам не подходит вашей команде и нужно попробовать что-то другое )
если мы закладываем на риски от 50% времени спринта (а значит и разработки в целом), значит с планированием явно что-то не так.
Но ведь верно и обратное: если мы за спринт не успеем сделать всё что запланировали, то с планированием что-то не так. И ничего страшного нет, если риски переоценены на старте. 50% - это же не какая-то жесткая цифра, она меняется со временем, её можно пересмотреть и уменьшить. При внимательном подходе к оценке и планированию, Estimation Error будет снижаться от спринта к спринту.
можно держать под контролем и включать в бэклог, а можно просто говорить разработчику займись там чем-нибудь на своё усмотрение
Вы снова очень сужаете круг доступных опций. Не обязательно отпускать разработчиков в свободное плавание, можно эти активности обсуждать на дэйликах, расставлять приоритеты, контролировать результат. А если включить их в бэклог, выставить им оценку, то, возможно, тяжело будет убедить проджект-оунера, почему это действительно нужно и почему вместо этого не включили в спринт фичу с такой же оценкой
Эти активности, которые могут не случиться (а могут и случиться), в моем понимании называются "риски". И оценка рисков всегда необходима как при планировании, так и в управлении проектом в целом, и это отдельная большая тема. Кажется, что Вы построили некую модель с ограниченным набором факторов, тогда как в реальной жизни опций гораздо больше. Есть еще техдолг, есть ненаписанные и неактуальные кейсы, есть старые баги, до которых руки не доходили, есть неожиданные изменения требований - т.е. много того, чем можно заняться, если те самые 50% окажутся свободными. Поэтому обычно времени как раз и не хватает и мало ситуаций, когда делать нечего совсем.
Статья на самом деле должна называться "Как я нарисовал сову". Слишком мало содержания, кроме "я захотел в авто и у меня получилось", многие темы не то что не раскрыты, а даже не затронуты. А как же UI тестирование мобилок, а тесты для очередей и брокеров? Ни слова про PageObject, нет подробностей об инфраструктуре для автотестов и ресурсов под неё.
если в команде есть ручной тестировщик ... Компания ничего не теряет
А вот это вообще далеко от реалий. Если в Компании ручной тестировщик начинает изучать и тратить кучу времени на автоматизацию, значит это минус пара рабочих рук. Это либо уменьшить количество фичей за то же время, либо увеличить Time To Market, в любом случае ресурс тестирования просядет. А еще он попросит часть времени devops потратить на себя. Как ни крути, для Компании это затраты и инвестиции, которые еще нужно обсчитать и отбить со временем.
Подождите, Вы перестали подкреплять свои тезисы аргументами )
почему? Мы как раз-таки её получим по окончании спринта, потому что "внезапные" факторы мы учли в рисках, и они перестали для нас быть внезапными.
Про это я уже отвечал, есть куча всего, чем можно заняться, и это тоже будет вносить вклад в проект.
Верно, и Вы время доставки задач бизнесу растягиваете на несколько спринтов, хотя можно уложиться в один, и всё это время фича не работает, т.е. не приносит деньги, т.е. бизнес деньги теряет.
Вы не поверите, но я, как руководитель, всё это учитываю: и нагрузку по задачам, и перформанс, и больничные/отпуска, и необходимость поиска нового человека, и сроки его онбординга. В реальной жизни без этого никуда ) Вы же, со своей стороны, просто говорите "всё сложно, всего не учесть" и даже не пробуете. У меня в команде есть табличка с факторами рисков и с их весами (добавочный процент к времени выполнения). И, например, для новых задач он больше, для известных задач - меньше. Эта табличка живая, и по ходу жизни проекта цифры меняются.
Вообще, раз уж мы обсуждаем спринты, то мы говорим про scrum, верно? ) А скрам - это про скорость доставки, гибкость, адаптивность, работу в условиях неопределенности. У Вас же весь посыл про строгость, регламенты, увеличение сроков в пользу гарантированных метрик. Возможно, просто скрам не подходит вашей команде и нужно попробовать что-то другое )
Но ведь верно и обратное: если мы за спринт не успеем сделать всё что запланировали, то с планированием что-то не так. И ничего страшного нет, если риски переоценены на старте. 50% - это же не какая-то жесткая цифра, она меняется со временем, её можно пересмотреть и уменьшить. При внимательном подходе к оценке и планированию, Estimation Error будет снижаться от спринта к спринту.
Вы снова очень сужаете круг доступных опций. Не обязательно отпускать разработчиков в свободное плавание, можно эти активности обсуждать на дэйликах, расставлять приоритеты, контролировать результат. А если включить их в бэклог, выставить им оценку, то, возможно, тяжело будет убедить проджект-оунера, почему это действительно нужно и почему вместо этого не включили в спринт фичу с такой же оценкой
Эти активности, которые могут не случиться (а могут и случиться), в моем понимании называются "риски". И оценка рисков всегда необходима как при планировании, так и в управлении проектом в целом, и это отдельная большая тема. Кажется, что Вы построили некую модель с ограниченным набором факторов, тогда как в реальной жизни опций гораздо больше. Есть еще техдолг, есть ненаписанные и неактуальные кейсы, есть старые баги, до которых руки не доходили, есть неожиданные изменения требований - т.е. много того, чем можно заняться, если те самые 50% окажутся свободными. Поэтому обычно времени как раз и не хватает и мало ситуаций, когда делать нечего совсем.
Статья на самом деле должна называться "Как я нарисовал сову". Слишком мало содержания, кроме "я захотел в авто и у меня получилось", многие темы не то что не раскрыты, а даже не затронуты. А как же UI тестирование мобилок, а тесты для очередей и брокеров? Ни слова про PageObject, нет подробностей об инфраструктуре для автотестов и ресурсов под неё.
А вот это вообще далеко от реалий. Если в Компании ручной тестировщик начинает изучать и тратить кучу времени на автоматизацию, значит это минус пара рабочих рук. Это либо уменьшить количество фичей за то же время, либо увеличить Time To Market, в любом случае ресурс тестирования просядет. А еще он попросит часть времени devops потратить на себя. Как ни крути, для Компании это затраты и инвестиции, которые еще нужно обсчитать и отбить со временем.