В этой статье постараюсь описать своё видение планирования спринта с учетом тестирования спринтовых задач и исправления багов по итогам тестирования. Внезапно для меня тема вызвала дискуссию на проекте, в разработке которого я участвую.
Меня зовут Султанов, и я тимлид (тяжелый вздох). Стараюсь делать разработку предсказуемой. Иногда даже получается.
Итак, к делу.
В один прекрасный день работаю я, никого не трогаю, и тут приходит ко мне руководитель и говорит: "Неправильно ты, дядя Федор, бутерброд ешь!" "У тебя неправильно распланированы спринты. Необходимо, чтобы задачи выходили из спринта уже протестированные и с исправленными багами, иначе мы не сможем их закрывать!". И тут же обрисовал всё схематично, примерно вот так:
Но подожди, отвечаю я руководителю, ведь пока идет тестирование, разработчик либо будет простаивать, либо возьмется за другую задачу, и ему придется прерываться, ну или третий вариант - будет делать задачу до конца спринта, и исправление багов уйдет на следующий спринт, и всё будет не слишком здорово?
"У меня 15 лет опыта в разработке, и всегда так работали, и ты сможешь!" - подбодрил руководитель и отключился. А я призадумался.
По сути, руководитель поставил мне 3 условия:
Все задачи спринта должны быть завершены в спринт;
Разработка и тестирование должны быть в одном спринте;
Все баги должны быть исправлены в этом же спринте;
Поставленные условия сразу и жестко привязывают процессы разработки, тестирования и исправления багов друг к другу. При таком подходе, когда есть прямая зависимость между звеньями, рабочий процесс будет постоянно лихорадить. Обычно это пытаются уладить волевыми решениями и жесткими требованиями руководства «лучше декомпозировать задачи», и это никогда не работает. А работать будет только при обеспечении слабой связности процессов разработки, тестирования и исправления багов.
Приведу пример из другой сферы.
Абсолютно во всех более-менее массовых промышленных процессах есть некие склады, запасы, фонды. В каждом магазине, на каждом производстве есть склад, чтобы обеспечивать стабильность работы и отвязать подвоз запасов от производства и продаж. Если попытаться работать без склада, то товар на полках магазинов, сырье на производстве будет периодически (и совершенно внезапно) заканчиваться, а запас не создать - склада-то нет. В таких случаях любое планирование будущих периодов практически перестает иметь смысл, и работа средних менеджеров превращается в постоянное преодоление кризисов.
Перейдем обратно к нашим баранам фичам, и попробуем запланировать спринт по тем условиям, которые поставлены руководителем.
Обычно при планировании спринта тимлид (и его команда, конечно же) сталкиваются с одним фактором неопределенности - временем выполнения задач. За счет компетенций команды, обсуждения и декомпозиции, ну и некоторого запаса по времени в спринте (оставляем разработчику пару дней свободными) этот фактор неопределенности преодолевается, и процесс разработки становится предсказуемым. Более или менее.
В случае же представленных граничных условий число факторов неопределенности возрастает до трех - это время выполнения спринтовых задач, момент передачи багов разработчику (это конечно очень неожиданно, но у тестировщиков тоже случаются завалы и они тоже болеют), и время отработки самих багов. При этом предварительно рассмотреть и оценить мы можем только спринтовые задачи. Спринт у нас стандартный – две недели, то есть 10 рабочих дней, из них примерно день (8 часов) уходит на обязательные встречи, митинги и ритуалы аджайл. То есть из 9 оставшихся дней я могу планировать работы только дня на 4, а остальное оставлять на запас и баги, при этом я даже не знаю, придут ли эти самые баги в спринт. Ну или говорить разработчику "твои косяки - ты и исправляй в свободной от работы время".
Но, как говорили наши мудрые предки, "критикуешь - предлагай". Да и решение вобщем-то на поверхности. Нужно не пытаться впихнуть невпихуемое объять необъятное, а использовать бэклог спринта для отвязки процессов друг от друга.
Иными словами, необходимо организовать процесс так:
Разработчик берет задачи в спринт и разрабатывает, складывая в бэклог следующего спринта тестировщиков;
Тестировщики в плановом порядке берут задачи в свой спринт, складывают баги в бэклог разработчиков;
Разработчики в плановом порядке берут в спринт баги с высшим приоритетом, и потом уже спринтовые задачи, исправленные баги складывают в бэклог тестировщикам на проверку;
Тестировщики проверяют исправление багов и ставят свой одобрямс. Фича готова.
Мы видим, что процесс полного тестирования занимает 4 спринта, зато всё предсказуемо, планово, оцениваемо и без кризисов, которые мы создаем себе сами.
Комментарии (24)
Apokalepsis
17.03.2024 19:35+1Переходите на Яндекс.Трекер, там есть очереди. У тестировщиков и разработчиков будут два разных спринта.
elenaverkhodanova
17.03.2024 19:35Можете пояснить про два разных спринта? В первый спринт разработчики ваяют новую фичу, которую тестировщики тестят в следующем спринте? А релиз тогда в какой момент происходит?
Apokalepsis
17.03.2024 19:35Когда фича протестирована. Я написал не про то что такой подход самый лучший, но с учетом написаного, идеальный инструмент.
Sid1111
17.03.2024 19:35+2Я так планирую спринты:
На решение багов закладывается до 30% времени разработки по задаче
На спринт выделяется от 20% времени на инциденты(которых может и не быть)
-
Время разработки определяет тимлид.
В итоге на спринт берется малая часть задач, которая заканчивается незадолго до окончания спринта. В оставшееся время разработчики делают либо срочные задачи, которые не были в спринте, либо внутренние задачи, либо начинают задачи, которые планировались на следующий спринт.
В итоге все довольны. Начальство довольно, что все планируемое закрывается, а заказчики довольны, т.к. их задачи реализуются раньше времени. А если возникают вопросы почему берется мало задач, то я с лёгкостью начинаю рассказывать про подводные камни, либо бизнес процесс механизма одной из задач и вопросы отпадают.
Trihlorid Автор
17.03.2024 19:35То есть от 50% времени вы закладываете на активности, которых может и не быть? Это очень точное планирование:))
MariaYakhnina
17.03.2024 19:35То есть правильно понимаю, вывод из статьи такой - в один спринт никак не упихнуть и разработку и тестирование, и никогда одна задача полностью не может быть сделана (разработана, оттестирована исправлена, выкачена на прод) за 1 двухнедельный спринт?
Trihlorid Автор
17.03.2024 19:35Нет, вы понимаете неправильно, и это показано на первой и второй схемах спринта. Я вообще писал не о невозможности упихнуть разработку, тестирование и исправление багов в один двухнедельный спринт, а о критически возрастающем уровне неопределённости при планировании спринта, что вобщем-то подтверждает другой мой комментатор, который закладывает от 50% времени спринта на активности, которых в спринте может и не случиться.
QArage
17.03.2024 19:35Эти активности, которые могут не случиться (а могут и случиться), в моем понимании называются "риски". И оценка рисков всегда необходима как при планировании, так и в управлении проектом в целом, и это отдельная большая тема. Кажется, что Вы построили некую модель с ограниченным набором факторов, тогда как в реальной жизни опций гораздо больше. Есть еще техдолг, есть ненаписанные и неактуальные кейсы, есть старые баги, до которых руки не доходили, есть неожиданные изменения требований - т.е. много того, чем можно заняться, если те самые 50% окажутся свободными. Поэтому обычно времени как раз и не хватает и мало ситуаций, когда делать нечего совсем.
joemast
17.03.2024 19:35+1вы понимаете неправильно, и это показано на первой и второй схемах спринта
В статье нет ни одной схемы, где все взятые задачи закрываются с тестированием по окончании спринта.
"У тебя неправильно распланированы спринты. Необходимо, чтобы задачи выходили из спринта уже протестированные и с исправленными багами, иначе мы не сможем их закрывать!"
Вот эта цель же не достигнута.
И основная проблема здесь - жесткое разделение ответственности разработчиков и тестировщиков. Тестировщики у вас занимаются контролем качества, а не обеспечением.
Я деталей не знаю, но предполагаю, что как и у многих, такое жёсткое разделение Dev и QA у вас заложено даже на организационном уровне: есть отдельные команды Dev и QA, участники которых общаются через очереди (бэклоги). Пока сохраняется такое взаимодействие, ваша задача не решаема, потому что кто-то всегда будет приходить к финишу итерации не готовым: либо Dev, либо QA.
Если хочется, чтобы по завершению спринта все взятые задачи были закрыты, с честно выполненным DoD, то необходимо использовать принцип "вытягивающего" производства: stop starting, start finishing, то есть не брать новую задачу, пока не доделана начатая. И работать над задачей QA и Dev должны одновременно с самого начала и до самого завершения, помогая друг другу её завершить.
Кстати, чуда не бывает, и планировать на итерацию придётся меньше. Зато всё будет честно закрыто.
joemast
17.03.2024 19:35Пока сохраняется такое взаимодействие, ваша задача не решаема, потому что кто-то всегда будет приходить к финишу итерации не готовым: либо Dev, либо QA.
Точнее, задача решаемая, но у команды (Dev+QA) должно быть время довести до ума начатые задачи: исправить баги в новых фичах, починить регрессию.
Для этого надо выделять время в конце итерации. То есть разработчики не должны начинать новые задачи задолго (примерно за 1/3) до окончания итерации, чтобы дать команде время на поиск, починку и проверку багов.
P.S.
И отказаться от попытки впихнуть в итерацию побольше задач - если они всё равно не доделываются, то смысла в этом нет
Xexa
17.03.2024 19:35У нас в команде(да и по предприятию в целом) используется оба метода. В случае отсутствия "непредвиденных" задач делится задача между спринтами разработчиками/тестировщиками.
Если приоритет резко повышается(извне, руководством) или у разработчика есть время(низкоприоритетная задача или заложенное на поддержку), то разработчик начинает плотно с тестировщиком взаимодействовать пока не решится проблема.
Кстати время "на тех поддержку" - всегда вносим, т.к лучше заложить его, чем потом двигать задачи записанные в спринт. Но это у нас взаимодействие с заказчиками идёт 24/7 в режиме "страна в опасности"(с). Верю/знаю, что есть команды "написал - забыл".
shornikov
17.03.2024 19:35+1Выходит либо красивая отчетность, либо загруженность специалистов.
Я себе планы сам пишу, левой ногой, поэтому сейчас будет ересь:
спринты сделать по неделе, а фиксить баги отдать другой команде, состоящей из "душнил", и сдвинуть ее 2/3 на половину спринта.
Тогда все будут при деле, а если багов не окажется - простОй второй команды сократится в 2 раза.Trihlorid Автор
17.03.2024 19:35Мне кажется, при вашем подходе потеряется воспитательный эффект. Кто баги делает, тот и должен их исправить
strelkove
17.03.2024 19:35Не понял, как проходят релизы в вашей схеме. Правильно понимаю, что по завершении спринта вы отдаёте непротестированные фичи, в которых могут быть (и, скорее всего, есть) баги?
Trihlorid Автор
17.03.2024 19:35Релизы проходят после одобрялся от тестировщиков. Разница только в моменте времени, в который происходит релиз.
strelkove
17.03.2024 19:35Раз в 4 спринта релиз, получается?
Trihlorid Автор
17.03.2024 19:35В зависимости от обстоятельств, но если у всех свои спринты, то да.
Aizz
17.03.2024 19:35А Вы по такому варианту уже работаете или это мысленный эксперимент? Мне кажется, в таком случае будет проблематично взаимодействовать с заказчиком фич. Вам или придется называть нереалистично большой срок в 4 спринта на реализацию даже небольшой фичи, потому что потенциально она может уехать (и ловить негатив по оценке и регулярные споры). Или называть реалистичные сроки, но ловить негатив от сдвига на следующий релиз.
Batalmv
17.03.2024 19:35+1Поделюсь своим опытом
Во-первых, все идет от релизов. Если вам важно выдавать каждый спринт поставку в прод или около того (я возможно пропустил, в статье было написано) - это одно. Если релиз в прод где-то там вдалеке - то это совсем другое. В первом случае таки важно после спринта выдавать что-то рабочее, во-втором - это внутренние "танцы" команды и если вам по какой-то причине их хочется усложнять, даже не знаю что вам сказать.
По взаимодействию QA & Dev - чуда нет в любом случае. Разраб кодит новые фичи, но одновременно ему может прилететь бага от QA по уже отданной фиче, а также бага с прода, если вы уже там. Т.е. с какого-то момента разраб, точнее вся команда разрабов работает минимум в трех "главных" ветках. Дев - там где пилятся новые фичи, QA - там где тестится следующий релиз, и прод - откуда прилетают баги. Это просто данность и как по мне, как-то это упросить низя. Можно только усложить, если к примеру есть бета на проде. Тогда веток будет 4 в такой момент :) Или еще по какой-то причине ... не имеет смысла фантазировать
По этому проблема отвлечения сразу отбрасывается как некритичная. Это просто данность, с которой надо жить и не жаловаться.
Из этого вытекает и банальное понимание того, что нарезка на спринты либо какие иные отрезки ни на что не влияет в контексте отвлечения. Все что тут важно - это релиз (повторяюсь). Релиз я бы всегда планировал "назад". Условно есть дата Х, это может быть даже каждый второй четверг, вечер. От этой даты отсчитываем назад, сколько времени надо нам и заказчику на тест. Соответственно планируем сколько остается для разрабочиком под новые фичи. Т.е. если идем таки спринтами, то на тест три дня, значит разработчикам - 7. Но это в общем. Но мы же не хотим идти маленькими waterfall'ами, поэтому для каждого спринта решает, какие фичи могут быть отданы раньше и тогда они начнутся раньше. И условный "финальный" тест может быть за счет этого сокращен.
Итого:
в начале спринта прикидываем, в каком порядке и приблизительно когда будут отдаваться фичи *учитывая зависимости и все остальное)
девелоперы их кодят именно в этом порядке
тестеры пишут тест кейсы и вообще готовятся + закрывают "хвосты" с прошлого спринта
на ежедневных стандапах смотрим, а вдруг что-то идет не так и чего с этим делать
девелоперы периодически отвлекаются на прод (это может быть самое важное) и на фиксы - приоритет решаем по ходу
С точки зрения кода тут задача бить его по модулям и максимально отрезать фичи друг от друга и от существующего кода. Тут уже в каждом конкретном проекте надо смотреть
yanpurvenes
17.03.2024 19:35Мне лично не понятна это бюрократия и разделение сприртов у dev и qa. Разве по готовности задачи не разумней ее брать в тест с учётом приоритета ее и бизнеса в данный момент?
Об проблеме сообщали вообще qa lead или head qa?
B_Z
"Тестировщики проверяют исправление багов и ставят свой одобрямс. Фича готова."
Или не готова. Или это всё растянется ещё на десяток спринтов.
Неужели не доводилось тестировать сложные алгоритмы, в которых разработчики ошибки не только с первого раза не могут исправить, но и со второго-третьего? Ну или когда исправление одной ошибки тянет за собой возникновение двух-трех новых?
Мне близка схема, которую предложил ваш руководитель, мы работаем именно по ней.
Trihlorid Автор
Фича формально готова, когда тестировщики приняли исправленные баги.
Бывает, что тестировщики не сразу находят баги, но это всегда фактор неопределенности, так как мы все люди, и мы все допускаем ошибки.
Если вам близка схема моего руководителя, то как вы планируете спринты?