Comments 52
"Тестировщики проверяют исправление багов и ставят свой одобрямс. Фича готова."
Или не готова. Или это всё растянется ещё на десяток спринтов.
Неужели не доводилось тестировать сложные алгоритмы, в которых разработчики ошибки не только с первого раза не могут исправить, но и со второго-третьего? Ну или когда исправление одной ошибки тянет за собой возникновение двух-трех новых?
Мне близка схема, которую предложил ваш руководитель, мы работаем именно по ней.
Переходите на Яндекс.Трекер, там есть очереди. У тестировщиков и разработчиков будут два разных спринта.
Можете пояснить про два разных спринта? В первый спринт разработчики ваяют новую фичу, которую тестировщики тестят в следующем спринте? А релиз тогда в какой момент происходит?
Отдельная очередь для тестирования идея не плохая, плохая идея яндекс.трекер. пол года попыток настроить нормально работу, автоматизация, триггеры. Все равно упирались что чего-то не хватает, чтобы было удобно. Все общение идёт в рамках задачи dev, лид тестирования только и занимается как сводит номера из одной очереди с номерами из другой. Там даже Ганта нормально не построить. По итогу плюнув, вернули тестирование в очередь dev. Если у кого-то удавалось настроить и поработать эффективно в отдельных очередях разработка и тестирование в команде разработки от 12 человек. Напишите пожалуйста в ответ.
Яндекс трекер это сырой продукт. С неплохой поддержкой, кучей неописанных ручек в api, и множество ответов типа, такой функции нет, но мы запланируем.
Я так планирую спринты:
На решение багов закладывается до 30% времени разработки по задаче
На спринт выделяется от 20% времени на инциденты(которых может и не быть)
Время разработки определяет тимлид.
В итоге на спринт берется малая часть задач, которая заканчивается незадолго до окончания спринта. В оставшееся время разработчики делают либо срочные задачи, которые не были в спринте, либо внутренние задачи, либо начинают задачи, которые планировались на следующий спринт.
В итоге все довольны. Начальство довольно, что все планируемое закрывается, а заказчики довольны, т.к. их задачи реализуются раньше времени. А если возникают вопросы почему берется мало задач, то я с лёгкостью начинаю рассказывать про подводные камни, либо бизнес процесс механизма одной из задач и вопросы отпадают.
То есть правильно понимаю, вывод из статьи такой - в один спринт никак не упихнуть и разработку и тестирование, и никогда одна задача полностью не может быть сделана (разработана, оттестирована исправлена, выкачена на прод) за 1 двухнедельный спринт?
Нет, вы понимаете неправильно, и это показано на первой и второй схемах спринта. Я вообще писал не о невозможности упихнуть разработку, тестирование и исправление багов в один двухнедельный спринт, а о критически возрастающем уровне неопределённости при планировании спринта, что вобщем-то подтверждает другой мой комментатор, который закладывает от 50% времени спринта на активности, которых в спринте может и не случиться.
Эти активности, которые могут не случиться (а могут и случиться), в моем понимании называются "риски". И оценка рисков всегда необходима как при планировании, так и в управлении проектом в целом, и это отдельная большая тема. Кажется, что Вы построили некую модель с ограниченным набором факторов, тогда как в реальной жизни опций гораздо больше. Есть еще техдолг, есть ненаписанные и неактуальные кейсы, есть старые баги, до которых руки не доходили, есть неожиданные изменения требований - т.е. много того, чем можно заняться, если те самые 50% окажутся свободными. Поэтому обычно времени как раз и не хватает и мало ситуаций, когда делать нечего совсем.
Эти активности, которые могут не случиться (а могут и случиться), в моем понимании называются "риски"
Мне всегда казалось, что если мы закладываем на риски от 50% времени спринта (а значит и разработки в целом), значит с планированием явно что-то не так.
Есть еще техдолг, есть ненаписанные и неактуальные кейсы, есть старые баги, до которых руки не доходили, есть неожиданные изменения требований - т.е. много того, чем можно заняться
Все эти штуки можно держать под контролем и включать в бэклог и дальше в спринт, а можно просто говорить разработчику - я тебе заплачу очень немаленькие деньги, займись там чем-нибудь на своё усмотрение, тебе же всегда есть чем заняться.
если мы закладываем на риски от 50% времени спринта (а значит и разработки в целом), значит с планированием явно что-то не так.
Но ведь верно и обратное: если мы за спринт не успеем сделать всё что запланировали, то с планированием что-то не так. И ничего страшного нет, если риски переоценены на старте. 50% - это же не какая-то жесткая цифра, она меняется со временем, её можно пересмотреть и уменьшить. При внимательном подходе к оценке и планированию, Estimation Error будет снижаться от спринта к спринту.
можно держать под контролем и включать в бэклог, а можно просто говорить разработчику займись там чем-нибудь на своё усмотрение
Вы снова очень сужаете круг доступных опций. Не обязательно отпускать разработчиков в свободное плавание, можно эти активности обсуждать на дэйликах, расставлять приоритеты, контролировать результат. А если включить их в бэклог, выставить им оценку, то, возможно, тяжело будет убедить проджект-оунера, почему это действительно нужно и почему вместо этого не включили в спринт фичу с такой же оценкой
Но ведь верно и обратное: если мы за спринт не успеем сделать всё что запланировали, то с планированием что-то не так
Мне это не кажется обратным, и да, если не успели - что-то пошло не так. Но это не повод, по моему скромному мнению, выделять на подобные риски 50% времени, потому что время - это очень неслабые деньги (посмотрите зарплаты разработчиков).
И я как раз предложил способ не оставлять это самое время на риски (то есть не тратить деньги) путем простого разнесения спринтов разработки и тестирования, создания бэклога тестирования и планирования багов в спринт как задач.
её можно пересмотреть и уменьшить. При внимательном подходе к оценке и планированию
В том-то и штука, что нет. Вернее не совсем. Мы сможем более-менее четко представлять время на тестирование, количество багов и время на их отработку (то есть дополнительные факторы неопределенности), только когда мы делаем типовые операции слаженной командой долгое время. Если же:
возникает новая задача (не знаю, как у вас, у меня такое бывает ежедневно)
появляются новые сотрудники (иногда бывает)
возникает завал у тестировщиков\заболел тестировщик (регулярно)
то мы сразу улетаем в неопределенность.
можно эти активности обсуждать на дэйликах
Я же именно об этом и писал - "работа средних менеджеров превращается в постоянное преодоление кризисов". Ритмичности работы команды постановка новых (не включенных в спринт) задач на дейликах точно не способствует.
если включить их в бэклог, выставить им оценку, то, возможно, тяжело будет убедить проджект-оунера, почему это действительно нужно
А вот это очень известная проблема, на которую просто все закрывают глаза. Когда оунер проекта в разработке вообще мало понимает, зато в каждую дырку пытается влезть со своим, несомненно ценным, мнением. Прям тема для отдельной статьи:))
время - это очень неслабые деньги
Верно, и Вы время доставки задач бизнесу растягиваете на несколько спринтов, хотя можно уложиться в один, и всё это время фича не работает, т.е. не приносит деньги, т.е. бизнес деньги теряет.
Если же ... то мы сразу улетаем в неопределенность...
..."работа средних менеджеров превращается в постоянное преодоление кризисов" ...
Вы не поверите, но я, как руководитель, всё это учитываю: и нагрузку по задачам, и перформанс, и больничные/отпуска, и необходимость поиска нового человека, и сроки его онбординга. В реальной жизни без этого никуда ) Вы же, со своей стороны, просто говорите "всё сложно, всего не учесть" и даже не пробуете. У меня в команде есть табличка с факторами рисков и с их весами (добавочный процент к времени выполнения). И, например, для новых задач он больше, для известных задач - меньше. Эта табличка живая, и по ходу жизни проекта цифры меняются.
Вообще, раз уж мы обсуждаем спринты, то мы говорим про scrum, верно? ) А скрам - это про скорость доставки, гибкость, адаптивность, работу в условиях неопределенности. У Вас же весь посыл про строгость, регламенты, увеличение сроков в пользу гарантированных метрик. Возможно, просто скрам не подходит вашей команде и нужно попробовать что-то другое )
Вы время доставки задач бизнесу растягиваете на несколько спринтов
При этом возникает такое качество, как надежность поставки, то есть что хотели - то и получили. При вашем же подходе есть неопределенность - мы можем быстро получить фичу, а можем внезапно не получить, причем планированию это не поддается, это всегда форс-мажор. Неужели для бизнеса это благо?
Если же фича нужна позарез, то мы приходим к первой схеме спринтов, когда часть ресурсов ничем не занята и находится в режиме ожидания. Это вполне планируемо, но называется "простой", и очень дорого.
Подождите, Вы перестали подкреплять свои тезисы аргументами )
мы можем быстро получить фичу, а можем внезапно не получить, причем планированию это не поддается
почему? Мы как раз-таки её получим по окончании спринта, потому что "внезапные" факторы мы учли в рисках, и они перестали для нас быть внезапными.
ничем не занята и находится в режиме ожидания
Про это я уже отвечал, есть куча всего, чем можно заняться, и это тоже будет вносить вклад в проект.
вы понимаете неправильно, и это показано на первой и второй схемах спринта
В статье нет ни одной схемы, где все взятые задачи закрываются с тестированием по окончании спринта.
"У тебя неправильно распланированы спринты. Необходимо, чтобы задачи выходили из спринта уже протестированные и с исправленными багами, иначе мы не сможем их закрывать!"
Вот эта цель же не достигнута.
И основная проблема здесь - жесткое разделение ответственности разработчиков и тестировщиков. Тестировщики у вас занимаются контролем качества, а не обеспечением.
Я деталей не знаю, но предполагаю, что как и у многих, такое жёсткое разделение Dev и QA у вас заложено даже на организационном уровне: есть отдельные команды Dev и QA, участники которых общаются через очереди (бэклоги). Пока сохраняется такое взаимодействие, ваша задача не решаема, потому что кто-то всегда будет приходить к финишу итерации не готовым: либо Dev, либо QA.
Если хочется, чтобы по завершению спринта все взятые задачи были закрыты, с честно выполненным DoD, то необходимо использовать принцип "вытягивающего" производства: stop starting, start finishing, то есть не брать новую задачу, пока не доделана начатая. И работать над задачей QA и Dev должны одновременно с самого начала и до самого завершения, помогая друг другу её завершить.
Кстати, чуда не бывает, и планировать на итерацию придётся меньше. Зато всё будет честно закрыто.
Пока сохраняется такое взаимодействие, ваша задача не решаема, потому что кто-то всегда будет приходить к финишу итерации не готовым: либо Dev, либо QA.
Точнее, задача решаемая, но у команды (Dev+QA) должно быть время довести до ума начатые задачи: исправить баги в новых фичах, починить регрессию.
Для этого надо выделять время в конце итерации. То есть разработчики не должны начинать новые задачи задолго (примерно за 1/3) до окончания итерации, чтобы дать команде время на поиск, починку и проверку багов.
P.S.
И отказаться от попытки впихнуть в итерацию побольше задач - если они всё равно не доделываются, то смысла в этом нет
не брать новую задачу, пока не доделана начатая
И пока тестировщики тестируют, разработка стоит. И наоборот. Это кстати прекрасно показано в первой схеме.
работать над задачей QA и Dev должны одновременно с самого начала и до самого завершения, помогая друг другу её завершить
То есть тестировщики должны разрабатывать, а разработчики - тестировать?
То есть тестировщики должны разрабатывать, а разработчики - тестировать?
Тестировщики подготавливают разработчикам чек-листы для самостоятельной проверки своей работы. И разработчики тестируют, да, в чём проблема? Они и так должны проверять свою работу самостоятельно, прежде чем отдать в тестирование. А тут им тестировщики предоставят кейсы, для более подробной проверки.
Если тестировщик умеет писать код, то он может разрабатывать авто-тесты, помогая разработчику ускорить закрытие задачи.
Все при деле, работают вместе, и задача разработана и протестирована.
У нас в команде(да и по предприятию в целом) используется оба метода. В случае отсутствия "непредвиденных" задач делится задача между спринтами разработчиками/тестировщиками.
Если приоритет резко повышается(извне, руководством) или у разработчика есть время(низкоприоритетная задача или заложенное на поддержку), то разработчик начинает плотно с тестировщиком взаимодействовать пока не решится проблема.
Кстати время "на тех поддержку" - всегда вносим, т.к лучше заложить его, чем потом двигать задачи записанные в спринт. Но это у нас взаимодействие с заказчиками идёт 24/7 в режиме "страна в опасности"(с). Верю/знаю, что есть команды "написал - забыл".
Выходит либо красивая отчетность, либо загруженность специалистов.
Я себе планы сам пишу, левой ногой, поэтому сейчас будет ересь:
спринты сделать по неделе, а фиксить баги отдать другой команде, состоящей из "душнил", и сдвинуть ее 2/3 на половину спринта.
Тогда все будут при деле, а если багов не окажется - простОй второй команды сократится в 2 раза.
Не понял, как проходят релизы в вашей схеме. Правильно понимаю, что по завершении спринта вы отдаёте непротестированные фичи, в которых могут быть (и, скорее всего, есть) баги?
Релизы проходят после одобрялся от тестировщиков. Разница только в моменте времени, в который происходит релиз.
Раз в 4 спринта релиз, получается?
В зависимости от обстоятельств, но если у всех свои спринты, то да.
А Вы по такому варианту уже работаете или это мысленный эксперимент? Мне кажется, в таком случае будет проблематично взаимодействовать с заказчиком фич. Вам или придется называть нереалистично большой срок в 4 спринта на реализацию даже небольшой фичи, потому что потенциально она может уехать (и ловить негатив по оценке и регулярные споры). Или называть реалистичные сроки, но ловить негатив от сдвига на следующий релиз.
Вы по такому варианту уже работаете или это мысленный эксперимент?
Я работал, пока не пришло руководство и не сказало, что я не прав.
придется называть нереалистично большой срок в 4 спринта на реализацию даже небольшой фичи
Так релиз-то всё равно происходит раз в спринт, демо раз в спринт, фичи же разрабатываются потоком. Но убеждать заказчика надо, да.
Так релиз-то всё равно происходит раз в спринт
То есть, вы 3 раза релизите продукт с багами, а в четвёртый раз уже нормально протестированный и исправленный? А потом снова 3 раза с багами?
Ну вы уж совсем...в релиз входят только протестированные фичи. Когда фичи идут потоком, то для заказчика долгие спринты видны лишь первые три спринта, потом каждый спринт он будет получать протестированные фичи. Поток.
Но это я про большой и долгий проект (как у меня) пишу. Слышал, что есть проекты, в которых всего три спринта (на разработку отводится 6 недель), там наверное надо иначе подходить.
Поделюсь своим опытом
Во-первых, все идет от релизов. Если вам важно выдавать каждый спринт поставку в прод или около того (я возможно пропустил, в статье было написано) - это одно. Если релиз в прод где-то там вдалеке - то это совсем другое. В первом случае таки важно после спринта выдавать что-то рабочее, во-втором - это внутренние "танцы" команды и если вам по какой-то причине их хочется усложнять, даже не знаю что вам сказать.
По взаимодействию QA & Dev - чуда нет в любом случае. Разраб кодит новые фичи, но одновременно ему может прилететь бага от QA по уже отданной фиче, а также бага с прода, если вы уже там. Т.е. с какого-то момента разраб, точнее вся команда разрабов работает минимум в трех "главных" ветках. Дев - там где пилятся новые фичи, QA - там где тестится следующий релиз, и прод - откуда прилетают баги. Это просто данность и как по мне, как-то это упросить низя. Можно только усложить, если к примеру есть бета на проде. Тогда веток будет 4 в такой момент :) Или еще по какой-то причине ... не имеет смысла фантазировать
По этому проблема отвлечения сразу отбрасывается как некритичная. Это просто данность, с которой надо жить и не жаловаться.
Из этого вытекает и банальное понимание того, что нарезка на спринты либо какие иные отрезки ни на что не влияет в контексте отвлечения. Все что тут важно - это релиз (повторяюсь). Релиз я бы всегда планировал "назад". Условно есть дата Х, это может быть даже каждый второй четверг, вечер. От этой даты отсчитываем назад, сколько времени надо нам и заказчику на тест. Соответственно планируем сколько остается для разрабочиком под новые фичи. Т.е. если идем таки спринтами, то на тест три дня, значит разработчикам - 7. Но это в общем. Но мы же не хотим идти маленькими waterfall'ами, поэтому для каждого спринта решает, какие фичи могут быть отданы раньше и тогда они начнутся раньше. И условный "финальный" тест может быть за счет этого сокращен.
Итого:
в начале спринта прикидываем, в каком порядке и приблизительно когда будут отдаваться фичи *учитывая зависимости и все остальное)
девелоперы их кодят именно в этом порядке
тестеры пишут тест кейсы и вообще готовятся + закрывают "хвосты" с прошлого спринта
на ежедневных стандапах смотрим, а вдруг что-то идет не так и чего с этим делать
девелоперы периодически отвлекаются на прод (это может быть самое важное) и на фиксы - приоритет решаем по ходу
С точки зрения кода тут задача бить его по модулям и максимально отрезать фичи друг от друга и от существующего кода. Тут уже в каждом конкретном проекте надо смотреть
проблема отвлечения сразу отбрасывается как некритичная. Это просто данность, с которой надо жить и не жаловаться
Так можно относиться к абсолютно любой проблеме, но ведет ли такое отношение к прогрессу? Если мы не можем решить проблему, это не значит, что на неё нужно закрыть глаза. К тому же решение вобщем-то нехитрое.
Суть в том, что она есть всегда. Т.е. это как "проблема необходимости нажимать на клавиши" програмируя. Это просто часть работы разработчика
Теортически можно выделять отдельную фазу тестирования и не брать новые фичи - но в реальности это выглядит, как разработчики все остальное время, свободное от фикса багов "пинают детородный орган", что никак не может устроить тех, кто платит им ЗП.
Но так иногда бывает, как и наверное на любой позиции в ИТ, когда нагрузки меньше. Это нормально. Но делать это обязательной частью процесса наверное противоестественно
Суть в том, что она есть всегда
Это примерно как проблема наледи. Она тоже есть всегда, но это не повод не разрабатывать зимних шин, правда?
это как "проблема необходимости нажимать на клавиши" програмируя. Это просто часть работы разработчика
Именно для решения подобной проблемы и разрабатывались IDE (Integrated Development Environment). Чтоб меньше клавиш нажимать и больше думать.
Теортически можно выделять отдельную фазу тестирования и не брать новые фичи - но в реальности это выглядит, как разработчики все остальное время, свободное от фикса багов "пинают детородный орган"
Именно с целью не пинать чего-то там и предложено разносить спринты и брать баги как задачи.
В сферическом вакууме да. В реальной жизни серьезная бага прода имеет высокий приоритет и должна быть пофикшена в фиче бренче, которую надо отпочковать от мастера
Поэтому причем тут ваша аналогия? Тоде касается к примеру UAT. Вы хотите выйти в прод? Надо фиксить багу, так как релиз уже запланирован. А просто сидеть и не пилить ноаые фичи вам, как разоаботчику никто не даст, если этот кто-то считает деньги
Не нравится - ищите компанию, которая работает по другому :)
В реальной жизни серьезная бага прода имеет высокий приоритет и должна быть пофикшена в фиче бренче
Именно! То есть иногда происходят ситуации, когда мы имеем серьезную багу на предпроде или даже на проде, которая врывается в спринт, отбрасывая остальные задачи. Но именно что - иногда, и это всегда кризис и крушение планов. Вы же предлагаете жить в этом перманентном кризисе, когда мы каждый спринт получаем неизвестное количество багов в неизвестный момент времени. Это заставляет планировщика (обычно это тимлид) оставлять очень большой запас по времени спринта, и носиться, как ошпаренному, когда баги внезапно не пришли, а разработчик доделал плановые задачи. Преодолевать им же самим созданный кризис.
Не нравится - ищите компанию, которая работает по другому :)
Коллега, я думал, мы тут все взрослые люди, а не молодые истерички. Не надо так:))
Вы же предлагаете жить в этом перманентном кризисе, когда мы каждый спринт получаем неизвестное количество багов в неизвестный момент времени.
Ну почему неизвестное? Чтобы получать меньше багов - надо лучше кодить и тестить на предыдущем спринте. Возможно брать меньше задач на спринт. Все ж взаимосвязано.
Если команда говнокодит - она в кризисе.
Если команда берет больше задач, чем может переварить за спринт - она в кризисе
Когда задачи закончились - я вообще не вижу проблем. Есть наверняка рефакторинг, которых хотелось сделать, есть где добавить unit-тестов и т.д. Можно банально взять уже готовую таску из бэклога и начать ее пилить потихоньку
----------------
Просто заказчика интересует уже готовый релиз и проверенный функцонал. Отдельный спринт для тестирования - карт-бланш для разрабов делать тяп-ляп, абы побольше. Поэтому и ставится условие: результат спринта - протестированный функционал.
Вам не нравиться как лиду разработки - понимаю :) Но как заказчик либо его представитель в той или иной форме меня совершенно не интересует сколько тасок вы перенесете у себя там внутри. Есть вообще большой риск с таким подходом словить ситуацию, когда вообще ничего нет, а есть куча говнокода, которая делает вид что работает.
Я кстати вспомнил, была реальная ситуация. Таски переезжали к QA, что-то тестилось, иногда возвращалось. В общем котелок варился но в какой-то момент закралось подозрение, что имеет месть быть вранье и подтасовка. Углубленная проверка показала, что так и есть. В реальности таски полноценно не закрывались и скорее напоминали "тришкин кафтан".
В итоге тим лид получил пинок под зад, пару low performer'ов, которые работали по принципу "главное к вечеру чего-то собрать, чтобы пролезло через авто тесты" - тоже. Оставшаяся команда и выдвинутый тим лид "из народу" добили релиз, к сожалению где-то методом переписывания, так как код некоторых моделй в принципе не имел смысла. Ситуация вообще была печальная, так как какое-то время тим лиду было оказано доверие и в код никто кромие команды не лазил, а зря.
Мне лично не понятна это бюрократия и разделение сприртов у dev и qa. Разве по готовности задачи не разумней ее брать в тест с учётом приоритета ее и бизнеса в данный момент?
Об проблеме сообщали вообще qa lead или head qa?
Разве по готовности задачи не разумней ее брать в тест с учётом приоритета ее и бизнеса в данный момент?
Вопрос не в этом, а в том, чем занят разработчик, пока задача тестируется. Чем занят тестировщик, пока правятся баги и идет разработка? Обычно предполагается, что "есть техдолг, есть старые баги, есть рефакторинг, всегда есть чем заняться", но мы же понимаем, что это к нормальному планированию не относится?
Зачем городить огород? Ну по мимо основных задач, у всех сторон есть другие, которые не всегда попадают в спринт и/или идут по умолчанию. Для чего абсурд с планированием всего устраивать? Сколько потратиться время на сам релиз тоже каким то образом планировать собираются?
Тем более даже если при планировании спринта иметь идеальные метод оценки задач по трудозатратам, то все равно он в себя будет включать плюс некоторый процент подстраховки по времени. Это при условии, что в спринт попадает задача с полным описание, которую только взять и сделать.
по мимо основных задач, у всех сторон есть другие, которые не всегда попадают в спринт и/или идут по умолчанию
То есть мы как бы говорим очень высокооплачиваемому специалисту: "Ты займись там чем-нибудь, что мы не включили в спринт, ну или техдолгом там, рефакторингом, сам знаешь". Такое себе управление процессом, на мой взгляд.
Для чего абсурд с планированием всего устраивать?
И правда, зачем мы вообще планируем задачи? Спринтовое планирование, квартальное планирование, оценка - просто потеря времени:)))
Сколько потратиться время на сам релиз тоже каким то образом планировать собираются?
Если релиз занимает значимое время, например рабочий день, то само собой. Эта задача есть всегда, но если её не делать, то в какой-то момент она не будет включена в спринт, и ваши разрабы будут релизить ночью. Вам, как человеку, ответственному за планирование, они объявят благодарность.
все равно он в себя будет включать плюс некоторый процент подстраховки по времени
Конечно, но это по известным задачам. А есть еще баги. Мало того, что неизвестно, сколько их, сколько времени они займут (так как оценки не было), так еще и сам момент их поступления неизвестен. Это и заставляет закладывать в спринт от 50% запаса по времени, и если баги не пришли (тестировщик заболел, например), резко думать, чем занять дорогущего разработчика, чтоб не простаивал.
Чем занят тестировщик, пока правятся баги и идет разработка?
Пишет тест-план для тестирования разрабатываемой фичи, например? Отчёт о тестировании по предыдущему спринту? Если речь о тестировании каких-то интеграций, дорабатывает/пишет мок-сервисы? Есть ощущение, что вы плохо понимаете, как в целом построены процессы в кроссфункциональной команде, и смотрите на всё только через призму роли разработчика.
Подождите, я хочу понять. У вас тест-план не входит в задачу на тестирование? И отчет тоже нет? И мок-сервисы тоже?
Если у вас такие процессы, как вы описали, то да, плохо понимаю.
Получается, вы включаете в спринт только задачу "выкопать яму", а задачи "наточить лопату" и "утилизировать выкопанный грунт" для вас как бы не существуют. Неужели вы правда считаете, что это нормально?
У вас тест-план не входит в задачу на тестирование? И отчет тоже нет? И мок-сервисы тоже?
Всё входит. Я отвечал на вопрос, чем заняться тестировщику, пока идёт разработка. Теперь о времени, пока правятся баги: тестировщик или завершает тестирование согласно разработанного тест-плана, либо занимается исследовательским тестированием.
Всё входит. Я отвечал на вопрос, чем заняться тестировщику, пока идёт разработка
В этом случае возникает вопрос, в какой момент тестировщик получает задачу на тестирование. Если вместе с разработчиком, то возникают забавные моменты:
подготовительная работа не бывает меньше времени разработки, даже если она реально недолгая. См. закон Паркинсона.
если задача в процессе разработки каким-то образом меняется (не знаю, как у вас, у меня регулярно бывает), то тестировщику придется переделывать.
о времени, пока правятся баги: тестировщик или завершает тестирование согласно разработанного тест-плана
То есть пока правятся старые баги, тестировщик выдает новые? Это именно то, с чем я люто борюсь - разработчик должен получить конечный результат тестирования, а не некое незавершенное непонятно что. Так же, как и тестировщик должен получить на тестирование разработанную задачу, а не задачу в процессе разработки. Нельзя передавать полуготовые части другим людям, это плохо.
Это именно то, с чем я люто борюсь - разработчик должен получить конечный результат тестирования, а не некое незавершенное непонятно что. Так же, как и тестировщик должен получить на тестирование разработанную задачу, а не задачу в процессе разработки. Нельзя передавать полуготовые части другим людям, это плохо.
Ладно, у нас кардинально разные взгляды на разработку. Вам ближе старый-добрый водопад с чётким разделением на фазы "аналитика -> проектирование -> разработка -> тестирование -> поддержка" (или, скорее, инкрементальная модель разработки, т.е. повторяющийся несколько раз водопад) вместо концепции Agile и shift-left testing, когда тестирование нужно начинать как можно раньше (в идеале - со статического тестирования спецификации на наличие противоречий, несоответсвий и двусмысленных формулировок), сообщать о багах как можно раньше.
Поэтому для меня вполне нормальная практика, когда разработчик говорит "я выкатил вот такой билд, можешь в нём проверить вот это и вот это". И, вполне возможно, что в этой части могут найтись проблемы, которые могли повлечь за собой более серьёзные последствия, требующие больших изменений в программе. Поэтому чем быстрее разработчик узнает о проблеме, тем меньше лишней работы он будет выполнять.
В общем, мне ваша идея понятна, и я даже её разделяю, но считаю, что в условиях современного бизнеса она не очень хорошо подходит с точки зрения скорости доставки новой функциональности.
Коллеги, очень интересная статья и комментарии.
Подскажите, а в чем проблема взять в работу задачу, не запланированную в текущий спринт (с учетом приоритетов и тп) и сделать "задел на будущее"?
Почему это воспринимается как религиозное табу? Есть какие-то разумные аргументы против?
Спринт с багами, или как (не) создать себе проблем