Artem
1 таски только на ближайший спринт и шанс этого не велик. 2 таски не очень большие, в идеале не более 8 часов, так что даже более слабый сотрудник много времени не потеряет. 3 все же у нас не вот в разы отличается экспертиза разрабов. 4 и самое банальное, мы не загружаем каждого человека на 80 часов )
Artem
Вывод - ничего страшного не произойдет
kiosaku
Я вас огорчу, но NASA деливерит код высочайшего качества без скрама, просто ребята коммуницируют процесс
народ из МинСредМаша деливерил код сильно лучше насы
Yuriy
Вывод - ничего страшного не произойдет
я не говорю, что страшно, просто для нас оказалось достаточно оценки в sp без часов
Artem
Ее может быть вполне достаточно, если у вас довольно мелкие стори и можно построить адекватный берндаун по сп или если вы используете что-то другое вместо берндауна.
Artem
Ну или если команда у вас слаженная, делает проект давно и без всяких инструментов может довольно точно и заранее предсказывать успех спринта
Artem
Моя команда считает, что она именно такая ))
Artem
И это наверно самый важный момент, не забывать, что берндаун, это инструмент команды, а не РО или скрам-мастера
Yuriy
👍
Artem
не спят же люди ) думал завтра обсудить. Но ок - в общем там три беклога получается, с двумя все вроде понятно - костыли и гипотезы. А баги, Билли, нам нужны баги. Как заполняется беклог багов? С участием ПО или нет? По видео похоже, что нет, но как тогда команда решает, какой баг достоин попадания в беклог?
🦠
Беклог багов? Эт сильная магия
🦠
Вообще при нормальном процессе обычно zero bug policy, у багов максимальный приоритет
Artem
погодь, вопрос по видео был
Artem
я понимаю, что подходы разные бывают, но вопрос про конкретный
🦠
Это новый уровень дна — заводить беклог для багов, рассматривать такое нет смысла
Artem
про зиро баг полиси тут отдельно поспорить можно, начав со спора про определение "что такое баг" ) Но я сейчас не готов )
🦠
Окей, у нас на проде падает чекаут, а давайте оценим и сложим его в беклог)))
Artem
у меня вот на сайте под Сафари на 1280 блок съезжает немного - это баг? Надо ли все бросать и править его )
🦠
Починим потом, как закончим более важные бизнес инкременты
Artem
ну а у меня вот блок съезжает
🦠
Это импрувмент
Artem
вооо, начинается )
Artem
так что же такое баг? )
🦠
Баг это аварийное окончание сценария, необработанное разработчиком
Artem
такое у нас называется критикал и есессно правится без очереди, но вопрос был не про такое и на видео речь тоже явно не про это
Artem
ок, давай назовем "отдельный беклог для импрувментов"
Dmitry
не спят же люди ) думал завтра обсудить. Но ок - в общем там три беклога получается, с двумя все вроде понятно - костыли и гипотезы. А баги, Билли, нам нужны баги. Как заполняется беклог багов? С участием ПО или нет? По видео похоже, что нет, но как тогда команда решает, какой баг достоин попадания в беклог?
Баги это автоматическая очередь, там из sentry создаёт
Но есть лимит 10
Если появляется 11 баг, то самый старый улетает
Таким образом, в очереди остаются только реально важные баги, которые часто случаются
Pavel
Так. Zero bug tolerance не означает, что надо все бросать и немедленно фиксить. Оно означает, что:
1. PBI с багом - не done и вернётся в бэклог, а не пойдёт в релиз
2. Баги с регрессии идут в топ бэклога
Artem
Artem
Pavel
Артем, когда нашли? В спринте при реализации «блока»? Если не успели пофиксить за спринт в рамках работы над pbi - весь pbi уйдёт в бэклог
Если на регрессии - пойдёт в топ бэклога и скорее всего в следующий спринт. Да, поверх бизнес-функциональности
Artem
Artem
Очень не согласен со второй частью
Artem
С какого черта он должен встать поверх бизнес-фанкциональности
Pavel
Артём, можно не соглашаться и по копеечке копить технический долг :)
Artem
Пусть копится, если асегда есть задачи, которые приносят больше ценности, то так ему и копиться да.
Pavel
С какого черта он должен встать поверх бизнес-фанкциональности
Потому что или это баг, ака проблема, и ее надо решать. Или это не проблема и нафиг ей в бэклога делать :)
Artem
Потому что или это баг, ака проблема, и ее надо решать. Или это не проблема и нафиг ей в бэклога делать :)
Вооот, а кто и когда это решает?
Artem
И почему если проблема, то значит сразу самая важная и в топ
Pavel
Продакт овнер и дев тим. На планинге и рефайнменте. И на ретро, обсуждая правила взаимодействия.
Artem
То есть все же через продукт овнера, но при этом не спрашивая его по приоритету
Artem
Имхо это неправильно
Pavel
И почему если проблема, то значит сразу самая важная и в топ
Артём, я не хочу с телефона устраивать долгие дискуссии про приоритеты. Если команда считает, что можно накапливать технический долг - не стоит вводить политику нулевой терпимости к багам. Если не считает - см. выше :)
Artem
Ок, принято
Pavel
Можно или нет - вопрос дискуссионный и во многом зависит от продукта. Если это pre-seed стартап, то можно вообще не тестировать :)
Artem
Так про тестирование речи вообще не велось, это отдельная жирная тема )
Artem
Баги/импрувменты и без тестирования находятся
Pavel
А если это зрелый продаваемый продукт, то мелочь типа «верстка немного поехала» может повлиять на конверсию куда сильней новой метафичи :)
Artem
Может конечно, а может и нет. И вот это как раз и должно влиять на очередность ее фикса ) а не сразу в топ
Pavel
Все может быть. Повторюсь - если команда считает, что можно копить технический долг, то пускай копит.
Pavel
Мой опыт говорит, что это очень плохая идея, но я её бесплатно никому не навязываю :)
Max
Все может быть. Повторюсь - если команда считает, что можно копить технический долг, то пускай копит.
Приходилось ли работать с ситуацией, когда у команды уже огромный техдолг? Скажем, хотя бы на 1 год разработки? Обычная ситуация для крупных технических продуктов - в публичных трекерах любой jira или gitlab сотни тысяч баг-репортов.
Как тут выйти на zero bug и стоит ли?
Alexey
Sergey
Sergey
Приходилось ли работать с ситуацией, когда у команды уже огромный техдолг? Скажем, хотя бы на 1 год разработки? Обычная ситуация для крупных технических продуктов - в публичных трекерах любой jira или gitlab сотни тысяч баг-репортов.
Как тут выйти на zero bug и стоит ли?
Зачем в этом проекте выходить на зеро баг. Так точнее
Max
Техдолг или баги?
Пока предлагаю ограничиться только той частью техдолга, которая вызвана отложенными к исправлению багами. Потому что с этого начали разговор и никчему сейчас усложнять.
Max
Зачем в этом проекте выходить на зеро баг. Так точнее
Этот вопрос я бы предложил в сторону убрать. Павел высказался по поводу техдолга в общем виде, из этого следует, как мне кажется, что он применяет практику в разнообразных контекстах. Более того, накопить сотни тысяч непочиненных багов можно практически в любом продукте =)
Artem
И зачем смешивать вообще техдолг и баги, если я правильно понял из контекста ваше определение техдолга
Artem
Техдолг у нас, например, не копится как раз. А вот баги легко
bebebe
техлол это хорошо
Artem
Техлол тоже имеется, конечно
Konstantin
Коллеги, есть серьезный вопрос)
есть несколько команд, одна работает двухнедельными спринтами, другая недельными спринтами, остальные команды - месячными спринтами. Вопрос - как можно наглядно представить работу всех команд? Как приоритизировать и спринтовать задачи всех команд в рамках месячного спринта (он используется по умолчанию в рамках всего департамента)?
Есть практика раз в пару-тройку месяцев делать недельный технический спринт для техдолга/саморазвития или исскуственно в спринт время для импрувмента резервировать: если есть техдолг - ковыряем его, нет - саморазвитие и подготовка к следующему спринту. Если нормальная команда - явно домой не пойдет, а начнет следуюший спринт ковырять ...
Igor
Коллеги, есть серьезный вопрос)
есть несколько команд, одна работает двухнедельными спринтами, другая недельными спринтами, остальные команды - месячными спринтами. Вопрос - как можно наглядно представить работу всех команд? Как приоритизировать и спринтовать задачи всех команд в рамках месячного спринта (он используется по умолчанию в рамках всего департамента)?
команды реализуют проекты для разных групп пользователей? если да, то нет смысла под одну гребенку всё собирать. даже если нет, то тоже смысла нет. Из вашего вопроса я вижу что заказчик не знает ничего про ваши процессы и не приходит к вам на обзор спринта - это как раз таки может быть проблемой.
Pavel
Приходилось ли работать с ситуацией, когда у команды уже огромный техдолг? Скажем, хотя бы на 1 год разработки? Обычная ситуация для крупных технических продуктов - в публичных трекерах любой jira или gitlab сотни тысяч баг-репортов.
Как тут выйти на zero bug и стоит ли?
Надо ли выходить? Т.е. причина накопить эти бани в бэклоге была, исчезла ли она.
Если очень надо, то надо оценить баги, решить, сколько времени в каждый спринт затратить на выплату и выплачивать. Для новой функциональности сразу zero tolerance поддерживать.
Max
Надо ли выходить? Т.е. причина накопить эти бани в бэклоге была, исчезла ли она.
Если очень надо, то надо оценить баги, решить, сколько времени в каждый спринт затратить на выплату и выплачивать. Для новой функциональности сразу zero tolerance поддерживать.
Тут интересный вопрос как раз - когда надо ставить на zero, а когда нет =)
🦠
если неинтересный проект, лучше не задумываться о zero bug policy
🦠
через несколько спринтов количество ongoing issues полностью заблокирует активную разработку)
🦠
как говорится, чисто не там где убирают, а там где не сорят)
Igor
через несколько спринтов количество ongoing issues полностью заблокирует активную разработку)
это самый банальный ретроспективный вопрос - какого хрена взяли то что не успели сделать. тут сразу видно что у команды проблемы с декомпозицией. количество тасок в беклоге на самом деле не особо привязано к количеству багов :D
Pavel
Тут интересный вопрос как раз - когда надо ставить на zero, а когда нет =)
Я не могу дать универсальный ответ на этот вопрос :) Мое мнение - в любом продукте с живыми пользователями стоит вводить такую политику. Даже если для неё придётся проинвестировать в разгребание авгиевых конюшен в бэклоге.
Pavel
Это, помимо благотворного влияния на мораль и удовлетворенность пользователей, ещё и жизнь разработки упрощает.
🦠
был в ситуации, когда техдолг и количество багов было зашкаливающим, но менеджмент запрещал рефакторинг и добавлял лишь новые фичи. команда плавненько перешла на дежурства)
Pavel
Накопление багов рано или поздно к такому и приводит.
Pavel
+ когда идёт разработка новых фичей поверх старых багов - идёт разработка новых багов :)
🦠
Сейчас у конторы очень плохие времена, живут на фрилансерах, которые влетают в копеечку
🦠
Потому что фуллтайм идти работать туда дураков нет)
Igor
Сейчас у конторы очень плохие времена, живут на фрилансерах, которые влетают в копеечку
так им и надо :D лучшее что можно сделать когда упираешься в такого манагера который не позволяет фиксить техдолг - свалить оттуда нахрен.
Igor
и до всей команды донести что надо сваливать ибо приехали