Часто, для внедрения каких-то изменений надо показать какую проблему вы будете решать. Как в первом вашем кейсе. Чтобы не получилось так, что вы что-то внедрили из-за его популярности/полезности, но у команды/заказчика не было проблем в этой области. В таком случае, ваши изменения могут быть не оценены по заслуге или просто не прижиться.
В ws есть messages. Можно ли автотестами проверять статусы там? Например, есть плеер на фронте который общается с видеобекендом по ws. И в messages есть статусы текущей ситуации с видео (play, pause и тд).
Декомпозиция, задачи на исследования - очень хорошая практика, добавляющая прозрачности процесса для менеджмента и интересные задачи на команды.
В вашем описании процесса, на мой взгляд, есть пару проблемных мест: 1) Для оценки задач в вашем варианте есть техлид. По сути это тот же разработчик, просто с большим опытом, который в одно лицо оценивает задачи. Это может привести к некоторым проблемам: a) он, как и обычный разработчик, может что-то не заметить/неправильно понять и дать ложную оценку b) при его уходе/болезни/отпуске теряется экспертиза по навыку оценки задач в команде с) при смене техлида ему надо будет понять производительность каждого в команде, чтобы давать оценку по его задачам
Многое из этого пытаются решить planning poker-ом, где экспертность техлида по оценке задач передается команде. В процессе оценки люди выставляют свои числа и обсуждают почему именно такие числа, чтобы прийти к общему решению. Это помогает команде рости в техническом плане, узнавать что-то новое про продукт, а техлиду спокойно ходить в отпуск и не быть bus фактором в команде.
Про описанные вами проблемы, связанные с решением в одной задачи половины проблем проекта или траты большого количества ресурсов на не всегда важный баг. Для этого, в любой из подобных методологий, есть ежедневные созвоны. Думаю и в вашей команде есть что-то похожее. Именно на них можно заметить такие проблемные ситуации и попытаться их решить разными способами.
В целом оценка в часах и стори поинтах, попугаях походи. Иногда уход от прямого количества часов на задачу может дать психологический эффект. Разработчик не будет "загонятся" что он не успевает в отведенные ему 16 часов, если у него оценка задач в 5 стори поинтов :)
Важно разделять большой Ростелеком с их офисами связи и множество компаний, входящих в "холдинг" Ростелеком. Есть Ростелеком ит, есть рт лабс, солар (инфобез) и тд.
И в каждой из них может быть своя атмосфера, со своими правилами по зп, уровню задач, переходами между проектами и подобным.
Часто, для внедрения каких-то изменений надо показать какую проблему вы будете решать. Как в первом вашем кейсе.
Чтобы не получилось так, что вы что-то внедрили из-за его популярности/полезности, но у команды/заказчика не было проблем в этой области. В таком случае, ваши изменения могут быть не оценены по заслуге или просто не прижиться.
В ws есть messages. Можно ли автотестами проверять статусы там?
Например, есть плеер на фронте который общается с видеобекендом по ws. И в messages есть статусы текущей ситуации с видео (play, pause и тд).
Декомпозиция, задачи на исследования - очень хорошая практика, добавляющая прозрачности процесса для менеджмента и интересные задачи на команды.
В вашем описании процесса, на мой взгляд, есть пару проблемных мест:
1) Для оценки задач в вашем варианте есть техлид. По сути это тот же разработчик, просто с большим опытом, который в одно лицо оценивает задачи. Это может привести к некоторым проблемам:
a) он, как и обычный разработчик, может что-то не заметить/неправильно понять и дать ложную оценку
b) при его уходе/болезни/отпуске теряется экспертиза по навыку оценки задач в команде
с) при смене техлида ему надо будет понять производительность каждого в команде, чтобы давать оценку по его задачам
Многое из этого пытаются решить planning poker-ом, где экспертность техлида по оценке задач передается команде. В процессе оценки люди выставляют свои числа и обсуждают почему именно такие числа, чтобы прийти к общему решению. Это помогает команде рости в техническом плане, узнавать что-то новое про продукт, а техлиду спокойно ходить в отпуск и не быть bus фактором в команде.
Про описанные вами проблемы, связанные с решением в одной задачи половины проблем проекта или траты большого количества ресурсов на не всегда важный баг. Для этого, в любой из подобных методологий, есть ежедневные созвоны. Думаю и в вашей команде есть что-то похожее. Именно на них можно заметить такие проблемные ситуации и попытаться их решить разными способами.
В целом оценка в часах и стори поинтах, попугаях походи. Иногда уход от прямого количества часов на задачу может дать психологический эффект. Разработчик не будет "загонятся" что он не успевает в отведенные ему 16 часов, если у него оценка задач в 5 стори поинтов :)
Думаю, тут подразумевалась автоматизация со стороны QA, а не разработки.
Важно разделять большой Ростелеком с их офисами связи и множество компаний, входящих в "холдинг" Ростелеком. Есть Ростелеком ит, есть рт лабс, солар (инфобез) и тд.
И в каждой из них может быть своя атмосфера, со своими правилами по зп, уровню задач, переходами между проектами и подобным.