Всё входит. Я отвечал на вопрос, чем заняться тестировщику, пока идёт разработка
В этом случае возникает вопрос, в какой момент тестировщик получает задачу на тестирование. Если вместе с разработчиком, то возникают забавные моменты:
подготовительная работа не бывает меньше времени разработки, даже если она реально недолгая. См. закон Паркинсона.
если задача в процессе разработки каким-то образом меняется (не знаю, как у вас, у меня регулярно бывает), то тестировщику придется переделывать.
о времени, пока правятся баги: тестировщик или завершает тестирование согласно разработанного тест-плана
То есть пока правятся старые баги, тестировщик выдает новые? Это именно то, с чем я люто борюсь - разработчик должен получить конечный результат тестирования, а не некое незавершенное непонятно что. Так же, как и тестировщик должен получить на тестирование разработанную задачу, а не задачу в процессе разработки. Нельзя передавать полуготовые части другим людям, это плохо.
В реальной жизни серьезная бага прода имеет высокий приоритет и должна быть пофикшена в фиче бренче
Именно! То есть иногда происходят ситуации, когда мы имеем серьезную багу на предпроде или даже на проде, которая врывается в спринт, отбрасывая остальные задачи. Но именно что - иногда, и это всегда кризис и крушение планов. Вы же предлагаете жить в этом перманентном кризисе, когда мы каждый спринт получаем неизвестное количество багов в неизвестный момент времени. Это заставляет планировщика (обычно это тимлид) оставлять очень большой запас по времени спринта, и носиться, как ошпаренному, когда баги внезапно не пришли, а разработчик доделал плановые задачи. Преодолевать им же самим созданный кризис.
Не нравится - ищите компанию, которая работает по другому :)
Коллега, я думал, мы тут все взрослые люди, а не молодые истерички. Не надо так:))
Вы время доставки задач бизнесу растягиваете на несколько спринтов
При этом возникает такое качество, как надежность поставки, то есть что хотели - то и получили. При вашем же подходе есть неопределенность - мы можем быстро получить фичу, а можем внезапно не получить, причем планированию это не поддается, это всегда форс-мажор. Неужели для бизнеса это благо?
Если же фича нужна позарез, то мы приходим к первой схеме спринтов, когда часть ресурсов ничем не занята и находится в режиме ожидания. Это вполне планируемо, но называется "простой", и очень дорого.
Смысл текста был в том, что буковки, вынесенные в эпиграф, есть прямая ложь, и внедрение аджайл не приводит к ускорению команд. Наверное я недостаточно ясно донес мысль.
Про БКС не знаю, может быть сравнивали плохой аджайл с хорошим.
Вы почему-то оставили команду без руководителя, который в традиционной модели и делает их командой, в не сотрудниками в комнате. В модели Agile команды вроде как должны самоорганизовываться, именно на это и направлены ритуалы, и так распределены роли. Но на моей практике я ни разу не видел самоорганизующуюся команду, только через личность руководителя/лидера. И часть смысла моего текста как раз была про это - мы тратим много времени команды на ритуалы, которые не достигают целей.
Не соглашусь, потому что единица измерения одна - скорость разработки.
Если условный Scrum дал 10% прирост
Дело не в приросте как таковом, а в соотношении прирост/расходы. Если время на ритуалы стоит 15% от команды + внешние команды трансформации + SCRUM-мастера + аудиторы, мы можем говорить, что за те же деньги увеличим команды процентов на 30-40, что немало. И вот тут возникает вопрос - а что было бы эффективнее?
Подождите, я хочу понять. У вас тест-план не входит в задачу на тестирование? И отчет тоже нет? И мок-сервисы тоже?
Если у вас такие процессы, как вы описали, то да, плохо понимаю.
Получается, вы включаете в спринт только задачу "выкопать яму", а задачи "наточить лопату" и "утилизировать выкопанный грунт" для вас как бы не существуют. Неужели вы правда считаете, что это нормально?
по мимо основных задач, у всех сторон есть другие, которые не всегда попадают в спринт и/или идут по умолчанию
То есть мы как бы говорим очень высокооплачиваемому специалисту: "Ты займись там чем-нибудь, что мы не включили в спринт, ну или техдолгом там, рефакторингом, сам знаешь". Такое себе управление процессом, на мой взгляд.
Для чего абсурд с планированием всего устраивать?
И правда, зачем мы вообще планируем задачи? Спринтовое планирование, квартальное планирование, оценка - просто потеря времени:)))
Сколько потратиться время на сам релиз тоже каким то образом планировать собираются?
Если релиз занимает значимое время, например рабочий день, то само собой. Эта задача есть всегда, но если её не делать, то в какой-то момент она не будет включена в спринт, и ваши разрабы будут релизить ночью. Вам, как человеку, ответственному за планирование, они объявят благодарность.
все равно он в себя будет включать плюс некоторый процент подстраховки по времени
Конечно, но это по известным задачам. А есть еще баги. Мало того, что неизвестно, сколько их, сколько времени они займут (так как оценки не было), так еще и сам момент их поступления неизвестен. Это и заставляет закладывать в спринт от 50% запаса по времени, и если баги не пришли (тестировщик заболел, например), резко думать, чем занять дорогущего разработчика, чтоб не простаивал.
Это примерно как проблема наледи. Она тоже есть всегда, но это не повод не разрабатывать зимних шин, правда?
это как "проблема необходимости нажимать на клавиши" програмируя. Это просто часть работы разработчика
Именно для решения подобной проблемы и разрабатывались IDE (Integrated Development Environment). Чтоб меньше клавиш нажимать и больше думать.
Теортически можно выделять отдельную фазу тестирования и не брать новые фичи - но в реальности это выглядит, как разработчики все остальное время, свободное от фикса багов "пинают детородный орган"
Именно с целью не пинать чего-то там и предложено разносить спринты и брать баги как задачи.
Ну вы уж совсем...в релиз входят только протестированные фичи. Когда фичи идут потоком, то для заказчика долгие спринты видны лишь первые три спринта, потом каждый спринт он будет получать протестированные фичи. Поток.
Но это я про большой и долгий проект (как у меня) пишу. Слышал, что есть проекты, в которых всего три спринта (на разработку отводится 6 недель), там наверное надо иначе подходить.
Но ведь верно и обратное: если мы за спринт не успеем сделать всё что запланировали, то с планированием что-то не так
Мне это не кажется обратным, и да, если не успели - что-то пошло не так. Но это не повод, по моему скромному мнению, выделять на подобные риски 50% времени, потому что время - это очень неслабые деньги (посмотрите зарплаты разработчиков).
И я как раз предложил способ не оставлять это самое время на риски (то есть не тратить деньги) путем простого разнесения спринтов разработки и тестирования, создания бэклога тестирования и планирования багов в спринт как задач.
её можно пересмотреть и уменьшить. При внимательном подходе к оценке и планированию
В том-то и штука, что нет. Вернее не совсем. Мы сможем более-менее четко представлять время на тестирование, количество багов и время на их отработку (то есть дополнительные факторы неопределенности), только когда мы делаем типовые операции слаженной командой долгое время. Если же:
возникает новая задача (не знаю, как у вас, у меня такое бывает ежедневно)
появляются новые сотрудники (иногда бывает)
возникает завал у тестировщиков\заболел тестировщик (регулярно)
то мы сразу улетаем в неопределенность.
можно эти активности обсуждать на дэйликах
Я же именно об этом и писал - "работа средних менеджеров превращается в постоянное преодоление кризисов". Ритмичности работы команды постановка новых (не включенных в спринт) задач на дейликах точно не способствует.
если включить их в бэклог, выставить им оценку, то, возможно, тяжело будет убедить проджект-оунера, почему это действительно нужно
А вот это очень известная проблема, на которую просто все закрывают глаза. Когда оунер проекта в разработке вообще мало понимает, зато в каждую дырку пытается влезть со своим, несомненно ценным, мнением. Прям тема для отдельной статьи:))
В разделении труда. В каждом деле должен быть профессионал. Именно поэтому у нас есть тестировщик, разработчик бэкэнда, разработчик фронтенда, аналитик.
проблема отвлечения сразу отбрасывается как некритичная. Это просто данность, с которой надо жить и не жаловаться
Так можно относиться к абсолютно любой проблеме, но ведет ли такое отношение к прогрессу? Если мы не можем решить проблему, это не значит, что на неё нужно закрыть глаза. К тому же решение вобщем-то нехитрое.
Разве по готовности задачи не разумней ее брать в тест с учётом приоритета ее и бизнеса в данный момент?
Вопрос не в этом, а в том, чем занят разработчик, пока задача тестируется. Чем занят тестировщик, пока правятся баги и идет разработка? Обычно предполагается, что "есть техдолг, есть старые баги, есть рефакторинг, всегда есть чем заняться", но мы же понимаем, что это к нормальному планированию не относится?
Очень знакомо:)
У меня именно так. Решения, кроме "просто начать делать через силу" я не нашел. Увы.
В этом случае возникает вопрос, в какой момент тестировщик получает задачу на тестирование. Если вместе с разработчиком, то возникают забавные моменты:
подготовительная работа не бывает меньше времени разработки, даже если она реально недолгая. См. закон Паркинсона.
если задача в процессе разработки каким-то образом меняется (не знаю, как у вас, у меня регулярно бывает), то тестировщику придется переделывать.
То есть пока правятся старые баги, тестировщик выдает новые? Это именно то, с чем я люто борюсь - разработчик должен получить конечный результат тестирования, а не некое незавершенное непонятно что. Так же, как и тестировщик должен получить на тестирование разработанную задачу, а не задачу в процессе разработки. Нельзя передавать полуготовые части другим людям, это плохо.
Именно! То есть иногда происходят ситуации, когда мы имеем серьезную багу на предпроде или даже на проде, которая врывается в спринт, отбрасывая остальные задачи. Но именно что - иногда, и это всегда кризис и крушение планов. Вы же предлагаете жить в этом перманентном кризисе, когда мы каждый спринт получаем неизвестное количество багов в неизвестный момент времени. Это заставляет планировщика (обычно это тимлид) оставлять очень большой запас по времени спринта, и носиться, как ошпаренному, когда баги внезапно не пришли, а разработчик доделал плановые задачи. Преодолевать им же самим созданный кризис.
Коллега, я думал, мы тут все взрослые люди, а не молодые истерички. Не надо так:))
При этом возникает такое качество, как надежность поставки, то есть что хотели - то и получили. При вашем же подходе есть неопределенность - мы можем быстро получить фичу, а можем внезапно не получить, причем планированию это не поддается, это всегда форс-мажор. Неужели для бизнеса это благо?
Если же фича нужна позарез, то мы приходим к первой схеме спринтов, когда часть ресурсов ничем не занята и находится в режиме ожидания. Это вполне планируемо, но называется "простой", и очень дорого.
Вот скажите, как профессионал, эпиграф - правдивый?
Смысл текста был в том, что буковки, вынесенные в эпиграф, есть прямая ложь, и внедрение аджайл не приводит к ускорению команд. Наверное я недостаточно ясно донес мысль.
Про БКС не знаю, может быть сравнивали плохой аджайл с хорошим.
Вы почему-то оставили команду без руководителя, который в традиционной модели и делает их командой, в не сотрудниками в комнате. В модели Agile команды вроде как должны самоорганизовываться, именно на это и направлены ритуалы, и так распределены роли. Но на моей практике я ни разу не видел самоорганизующуюся команду, только через личность руководителя/лидера. И часть смысла моего текста как раз была про это - мы тратим много времени команды на ритуалы, которые не достигают целей.
Не соглашусь, потому что единица измерения одна - скорость разработки.
Дело не в приросте как таковом, а в соотношении прирост/расходы. Если время на ритуалы стоит 15% от команды + внешние команды трансформации + SCRUM-мастера + аудиторы, мы можем говорить, что за те же деньги увеличим команды процентов на 30-40, что немало. И вот тут возникает вопрос - а что было бы эффективнее?
Почему нельзя напрямую сравнивать? Вроде единица измерения одна и та же - скорость разработки.
Подождите, я хочу понять. У вас тест-план не входит в задачу на тестирование? И отчет тоже нет? И мок-сервисы тоже?
Если у вас такие процессы, как вы описали, то да, плохо понимаю.
Получается, вы включаете в спринт только задачу "выкопать яму", а задачи "наточить лопату" и "утилизировать выкопанный грунт" для вас как бы не существуют. Неужели вы правда считаете, что это нормально?
То есть мы как бы говорим очень высокооплачиваемому специалисту: "Ты займись там чем-нибудь, что мы не включили в спринт, ну или техдолгом там, рефакторингом, сам знаешь". Такое себе управление процессом, на мой взгляд.
И правда, зачем мы вообще планируем задачи? Спринтовое планирование, квартальное планирование, оценка - просто потеря времени:)))
Если релиз занимает значимое время, например рабочий день, то само собой. Эта задача есть всегда, но если её не делать, то в какой-то момент она не будет включена в спринт, и ваши разрабы будут релизить ночью. Вам, как человеку, ответственному за планирование, они объявят благодарность.
Конечно, но это по известным задачам. А есть еще баги. Мало того, что неизвестно, сколько их, сколько времени они займут (так как оценки не было), так еще и сам момент их поступления неизвестен. Это и заставляет закладывать в спринт от 50% запаса по времени, и если баги не пришли (тестировщик заболел, например), резко думать, чем занять дорогущего разработчика, чтоб не простаивал.
Это примерно как проблема наледи. Она тоже есть всегда, но это не повод не разрабатывать зимних шин, правда?
Именно для решения подобной проблемы и разрабатывались IDE (Integrated Development Environment). Чтоб меньше клавиш нажимать и больше думать.
Именно с целью не пинать чего-то там и предложено разносить спринты и брать баги как задачи.
Ну вы уж совсем...в релиз входят только протестированные фичи. Когда фичи идут потоком, то для заказчика долгие спринты видны лишь первые три спринта, потом каждый спринт он будет получать протестированные фичи. Поток.
Но это я про большой и долгий проект (как у меня) пишу. Слышал, что есть проекты, в которых всего три спринта (на разработку отводится 6 недель), там наверное надо иначе подходить.
Мне это не кажется обратным, и да, если не успели - что-то пошло не так. Но это не повод, по моему скромному мнению, выделять на подобные риски 50% времени, потому что время - это очень неслабые деньги (посмотрите зарплаты разработчиков).
И я как раз предложил способ не оставлять это самое время на риски (то есть не тратить деньги) путем простого разнесения спринтов разработки и тестирования, создания бэклога тестирования и планирования багов в спринт как задач.
В том-то и штука, что нет. Вернее не совсем. Мы сможем более-менее четко представлять время на тестирование, количество багов и время на их отработку (то есть дополнительные факторы неопределенности), только когда мы делаем типовые операции слаженной командой долгое время. Если же:
возникает новая задача (не знаю, как у вас, у меня такое бывает ежедневно)
появляются новые сотрудники (иногда бывает)
возникает завал у тестировщиков\заболел тестировщик (регулярно)
то мы сразу улетаем в неопределенность.
Я же именно об этом и писал - "работа средних менеджеров превращается в постоянное преодоление кризисов". Ритмичности работы команды постановка новых (не включенных в спринт) задач на дейликах точно не способствует.
А вот это очень известная проблема, на которую просто все закрывают глаза. Когда оунер проекта в разработке вообще мало понимает, зато в каждую дырку пытается влезть со своим, несомненно ценным, мнением. Прям тема для отдельной статьи:))
В разделении труда. В каждом деле должен быть профессионал. Именно поэтому у нас есть тестировщик, разработчик бэкэнда, разработчик фронтенда, аналитик.
Так можно относиться к абсолютно любой проблеме, но ведет ли такое отношение к прогрессу? Если мы не можем решить проблему, это не значит, что на неё нужно закрыть глаза. К тому же решение вобщем-то нехитрое.
Вопрос не в этом, а в том, чем занят разработчик, пока задача тестируется. Чем занят тестировщик, пока правятся баги и идет разработка? Обычно предполагается, что "есть техдолг, есть старые баги, есть рефакторинг, всегда есть чем заняться", но мы же понимаем, что это к нормальному планированию не относится?
Я работал, пока не пришло руководство и не сказало, что я не прав.
Так релиз-то всё равно происходит раз в спринт, демо раз в спринт, фичи же разрабатываются потоком. Но убеждать заказчика надо, да.
И пока тестировщики тестируют, разработка стоит. И наоборот. Это кстати прекрасно показано в первой схеме.
То есть тестировщики должны разрабатывать, а разработчики - тестировать?