M
А какой мотив разбирать чужие баги?
В условиях работы над одним общим продуктом, такие понятия как "чужие", "не мое" и тд звучит как минимум странно
Size: a a a
2020 February 07
VP
ну окей. давайте проще - что делать?
S
"Что делать?" - Николай Чернышевский
VP
приказной порядок "иди и делай" плохо согласуется с agile manifest. кроме него я не знаю других способов. но вероятно они есть. вот об этом и вопрос
VP
ну вот так всега у коучей :) как доходит до дела - вопрос забалтывается. ясно, спасибо.
S
С годами понимаешь почему 😄
VP
ага, я тоже понимаю почему так происходит и расскажу об этом на панда митапе ближайшем )
S
Коучи там будут?
VP
@AgileBoy будет
АМ
Vasya Pupkin
получится так, что взрослые разгребают баги, а "молодые" занимаются интересными штуками. потом взрослым это надоедает и они увольняются нафиг
Более менее рабочий вариант привлекать еще более молодых чем молодые)), то есть что-то типа стажеров, готовых работать за хлеб)). Еще есть вариант найма старичков с рынка с соответствующей ментальной установкой, но это не простая задача для HR-а.
VP
Анатолий Матвеев
Более менее рабочий вариант привлекать еще более молодых чем молодые)), то есть что-то типа стажеров, готовых работать за хлеб)). Еще есть вариант найма старичков с рынка с соответствующей ментальной установкой, но это не простая задача для HR-а.
не совсем понял - ещё более молодых и старичков нанимать чисто баги фиксить?
АМ
Ну да
IS
Если никто не хочет фиксить баги, то это в том числе повод поговорить о том, как сделать так, что бы не совершать этих багов. Ну а дальше собственно, сделать.
EK
Vasya Pupkin
приказной порядок "иди и делай" плохо согласуется с agile manifest. кроме него я не знаю других способов. но вероятно они есть. вот об этом и вопрос
ну тут цель какая? Манифест соблюсти или людей сохранить и бизнес развить?)) По моему опыту, баги планируются в спринт, условно - спринт неделя, 4 дня каждый разработчик занимается новой фичей, 1 день - правит баги. Все работают над багами и никому не обидно.
VP
ну им тоже со временем надоест. у вас получается текучка в багофиксной команде, что довольно дорого (поиск, найм, адаптация, изучение продукта)
EK
как вариант выделить одну группу, которая занимается поддержкой, но это людей нужно искать неамбициозных
VP
Если никто не хочет фиксить баги, то это в том числе повод поговорить о том, как сделать так, что бы не совершать этих багов. Ну а дальше собственно, сделать.
да, так можно.
просто решение уже в проде и пользователи что-то находят и что-то хотят.
Проблема осложняется тем, что в проде легаси. а новое и вкусное - это переписывание постепенное этого легаси на новом стеке (потому что легаси в т.ч. уперся в некоторые ограничения).
просто решение уже в проде и пользователи что-то находят и что-то хотят.
Проблема осложняется тем, что в проде легаси. а новое и вкусное - это переписывание постепенное этого легаси на новом стеке (потому что легаси в т.ч. уперся в некоторые ограничения).
VP
Evgeniya Ko
как вариант выделить одну группу, которая занимается поддержкой, но это людей нужно искать неамбициозных
вариант наверное, спасибо. Надо только как-то оценить сколько времени потребуется эта поддержка, чтобы текучка была не слишком быстрой... а так наверное это вариант - отдельная команда выделенная.
S
В общем очередь багов это очередь, как работать с очередями запросов лучше всего описано в канбан-методе. В скраме там все усложняется в разы и этот вопрос просто спускается командам на откуп, чтобы они нашли "способ" это делать.
S
То есть правильный ответ СМ - команды должны решить :p