Спасибо за интресный вопрос, подходить к большим изменениям как к продукту — очень здравое решение!
Отвечу по пунктам ниже
Неприятный тимлид
У меня вот неприятный тимлид был, я бы ему везде 0/A накидал 😁
Так как результаты не анонимные для руководителя тимлида, то такого рода ответы достаточно хорош заметны. Обычно они указывают на конфликт между людьми
Как я выше и рассказывал, этот опросник — это хороший замер температуры и начало для дискуссии. Если я вижу, что сотрудник оценивает заметно ниже остальных, то встречаюсь с ним лично и узнаю, как проходит взаимодействие. Как правильно и заметили, действительно, нужно копать вглубь
Компетенции по горизонтали, отвечающие по вертикали. Хорошо заметно, что сотрудник из колонки 1 оценивает заметно ниже чем другие
Тестирование сценариями
Всегда важно понимать, для чего мы это делаем ту или иную оценку. Теоретически тимлиды достаточно много знают — этому мы их обучаем. И на словах, как говорится, все дартаньяны! Все понимают, как надо подключать продакта и как работать с конфликтами, но на деле, бывает, что-то идет не так.
Тестирование кейсами — это хороший способ на собеседовании понять образ мышления, однако в реальной жизни уже лучше опираться на факты, как и Вы предложили вторым пунктом
Пост-анализ эффективности и обоснованности выбранных решений
Этот способ мне больше импонирует. На самом деле, работаем с тимлидом не ограничивается опросами раз в полгода-года. Мы на постоянку на 1-1 с тимлидом анализируем работу, а также думаем, как поступить в той или иной ситуации. Опрос, про который я написал — это способ комплексно посмотреть на ситуацию со всех сторон и понять как выглядит работа в разных аспектах и с разных точек зрения.
Почему без такого ревью не обойтись? Как говорил доктор Хаус — «все врут», поэтому взгляд на ситуацию другими глазами помогает найти точки роста для тимлида
Еще раз спасибо за интересный вопрос, заставил меня подумать!
Привет! Процесс был долгий и растянутый по времени. В статье описал уже финальную версию и как к ней пришли. Как правильно заметили, важная часть — это ОС от оцениваемых. Если бы тимлиды посчитали оценку бесполезной, то это бы не прижилось, поэтому проработка была тщательная и длилась примерно полгода (может даже и больше), а после первого внедрения мы постоянно улучшали и изменяли все, включая системы прохождения, состав и формулировку вопросов. Поэтому не могу сказать точно, сколько она приживалась. Наверное года через 2 мы поняли, что оно полетело, но изменения появляются и сейчас, так как меняется и компания и роль тимлида и IT и жизнь в целом
В тексте не называл Саутгейта не разу плохим менеджером, слово менеджер употреблено в значении не "футбольный менеджер", а "руководитель команды разработки"
Это же статья про то, на сколько компания известна именно как работодатель! Если так смотреть, то цифра, что 33% опрошенных знают, как работает условный Ozon внутри, вполне адекватна. Вот если бы было где-то 100%, то тогда бы надо было напрячься)
Очень частый вопрос: как вообще выделять правильно модули. Так и не смог для этого вынести какие-то формальные критерии. Получается что-то типа: отдельная фича — это кусок кода с изолированной логикой, не очень большой и не очень маленький >_<
Кризис в стране, батенька, ещё не понятно что с вашими сикуэлами будет, а вот в виду проблем с импортом качественной техники мастера-ремонтники могут озолотиться?
А почему так мало мобильных разработчиков? Если нужна помощь в проникновение в сообщество (тот же Android Dev Podcast или Android Broadcast), пишите в личку
У нас багфиксы умещаются внутри фичи. Дело в том, что тестирование фичей проходит в две стадии. Во время разработки QA обсуждает с разработчиком, что можно уже посмотреть, а куда лезть не стоит. Таким образом, когда фича начинает подходить к релизу QA начинает тестирование (пунктир на рисунке ниже). Перед тем, как влить фичу в develop, QA уже тестирует её и все, что можно задеть, капитально.
Таким образом мы получаем практически всегда стабильный develop. Да, конечно, туда может просочиться баг из-за мердж конфликтов или по невнимательности, но их уже фиксят обычно в релизной ветке. Исключения составляют, конечно же, те случаи, когда сломался develop.
Что касается времени прогона тестов и всех проверок — у нас есть вот такой вот дашборд:
Сейчас пришли к тому, что прогон выполняется около 40 минут на Android и около 50 минут на iOS
Чисто тесты проходят за минут 25 (взял рандомную ветку, поэтому число тестов отличается от того, что написал выше)
И да, кстати я вас обманул в первом сообщении, на самом деле распределение по числу тестов наоборот:
1) iOS и Android в разных репозиториях, поэтому тесты гоняются для каждой платформы отдельно
2) Ночные тесты гоняются на каждой фиче ветке и develop (на ветках разработческих не гоняем). Для ночного среза репозитория из примера(см картинку ниже) будет 3 прогона: 2 на больших фиче ветках и 1 на develop
3) Также гоняются тесты при PR в develop. Таких моментов на диаграмме изображено 3
Если просуммировать, то после 20 дневных коммитов может и не быть прогонов, если еще не настала ночь и мы не делали PR в develop. Так понятнее стало?
У нас два приложения в активной стадии разработки. Одно для соискателей (с которым все знакомы) уже довольно давно живет. В нём картина такая:
390 iOS
452 Android
Второе приложение для работодателей мы с нуля переписали недавно (это совсем другая история), его только сейчас начали покрывать тестами
Гоняются и в ночных прогонах и на PR в develop абсолютно все тесты. Это стало возможным благодаря уходу от trunk-based — не нужно каждый чих проверять на стабильность
Спасибо за интресный вопрос, подходить к большим изменениям как к продукту — очень здравое решение!
Отвечу по пунктам ниже
Неприятный тимлид
У меня вот неприятный тимлид был, я бы ему везде 0/A накидал 😁Так как результаты не анонимные для руководителя тимлида, то такого рода ответы достаточно хорош заметны. Обычно они указывают на конфликт между людьми
Как я выше и рассказывал, этот опросник — это хороший замер температуры и начало для дискуссии. Если я вижу, что сотрудник оценивает заметно ниже остальных, то встречаюсь с ним лично и узнаю, как проходит взаимодействие. Как правильно и заметили, действительно, нужно копать вглубь
Тестирование сценариями
Всегда важно понимать, для чего мы это делаем ту или иную оценку. Теоретически тимлиды достаточно много знают — этому мы их обучаем. И на словах, как говорится, все дартаньяны! Все понимают, как надо подключать продакта и как работать с конфликтами, но на деле, бывает, что-то идет не так.
Тестирование кейсами — это хороший способ на собеседовании понять образ мышления, однако в реальной жизни уже лучше опираться на факты, как и Вы предложили вторым пунктом
Пост-анализ эффективности и обоснованности выбранных решений
Этот способ мне больше импонирует. На самом деле, работаем с тимлидом не ограничивается опросами раз в полгода-года. Мы на постоянку на 1-1 с тимлидом анализируем работу, а также думаем, как поступить в той или иной ситуации. Опрос, про который я написал — это способ комплексно посмотреть на ситуацию со всех сторон и понять как выглядит работа в разных аспектах и с разных точек зрения.
Почему без такого ревью не обойтись? Как говорил доктор Хаус — «все врут», поэтому взгляд на ситуацию другими глазами помогает найти точки роста для тимлида
Еще раз спасибо за интересный вопрос, заставил меня подумать!
Привет! Процесс был долгий и растянутый по времени. В статье описал уже финальную версию и как к ней пришли. Как правильно заметили, важная часть — это ОС от оцениваемых. Если бы тимлиды посчитали оценку бесполезной, то это бы не прижилось, поэтому проработка была тщательная и длилась примерно полгода (может даже и больше), а после первого внедрения мы постоянно улучшали и изменяли все, включая системы прохождения, состав и формулировку вопросов. Поэтому не могу сказать точно, сколько она приживалась. Наверное года через 2 мы поняли, что оно полетело, но изменения появляются и сейчас, так как меняется и компания и роль тимлида и IT и жизнь в целом
В тексте не называл Саутгейта не разу плохим менеджером, слово менеджер употреблено в значении не "футбольный менеджер", а "руководитель команды разработки"
Претензий к финалу особо нет — обычно это скучная игра. Большие вопросы к другим встречам, где команда проскочила чисто на мастерстве исполнителей
Помню когда начинал работать с тимлидом одной из команд, у них 1-1 проходил тимлид - проджект менеджер - член команды.
И главное, никого не смущал этот треугольник?
Можно еще посмотреть на зарплаты на том же career.ru, вот к примеру у джавистов https://career.ru/profession/38?grade=senior
Если у вас есть крутые идеи, можете написать в телеграмм чатик с нашими разработчиками и передать их в первые руки так сказать https://t.me/hh_tech ;)
В чате обсуждаем больше технологии, архитектуру и тд, но годные идеи тоже рады будем слышать
Это же статья про то, на сколько компания известна именно как работодатель! Если так смотреть, то цифра, что 33% опрошенных знают, как работает условный Ozon внутри, вполне адекватна. Вот если бы было где-то 100%, то тогда бы надо было напрячься)
Очень частый вопрос: как вообще выделять правильно модули. Так и не смог для этого вынести какие-то формальные критерии. Получается что-то типа: отдельная фича — это кусок кода с изолированной логикой, не очень большой и не очень маленький >_<
Кризис в стране, батенька, ещё не понятно что с вашими сикуэлами будет, а вот в виду проблем с импортом качественной техники мастера-ремонтники могут озолотиться?
Видимо поиск считает, что с Вашими набором навыков неплохо себя и в разработке попробовать?
Вот тут в охэхэнной истории про релиз Даня рассказал, почему мы переходили на GIthub Flow и почему нас не устроил подход trunk based.
Вкратце: хотели стабильный develop, при этом минимально вкладываться в инфраструктуру
А почему так мало мобильных разработчиков? Если нужна помощь в проникновение в сообщество (тот же Android Dev Podcast или Android Broadcast), пишите в личку
У нас на iOS симуляторы, а Android вообще в k8s запускаем!
Интересно послушать, как вы с реальным устройствами справляетесь!
Мы на заре нашего UI тестирования пробовали, но не смогли добиться стабильности
Прошу прощения, в сообщении выше перепутал платформы. На самом деле у нас так на текущий момент:
±390 Android
±452 iOS
У нас багфиксы умещаются внутри фичи. Дело в том, что тестирование фичей проходит в две стадии. Во время разработки QA обсуждает с разработчиком, что можно уже посмотреть, а куда лезть не стоит. Таким образом, когда фича начинает подходить к релизу QA начинает тестирование (пунктир на рисунке ниже). Перед тем, как влить фичу в develop, QA уже тестирует её и все, что можно задеть, капитально.
Таким образом мы получаем практически всегда стабильный develop. Да, конечно, туда может просочиться баг из-за мердж конфликтов или по невнимательности, но их уже фиксят обычно в релизной ветке. Исключения составляют, конечно же, те случаи, когда сломался develop.
Что касается времени прогона тестов и всех проверок — у нас есть вот такой вот дашборд:
Сейчас пришли к тому, что прогон выполняется около 40 минут на Android и около 50 минут на iOS
Чисто тесты проходят за минут 25 (взял рандомную ветку, поэтому число тестов отличается от того, что написал выше)
И да, кстати я вас обманул в первом сообщении, на самом деле распределение по числу тестов наоборот:
390 Android
452 iOS
Нет, не правильно поняли!
1) iOS и Android в разных репозиториях, поэтому тесты гоняются для каждой платформы отдельно
2) Ночные тесты гоняются на каждой фиче ветке и develop (на ветках разработческих не гоняем). Для ночного среза репозитория из примера(см картинку ниже) будет 3 прогона: 2 на больших фиче ветках и 1 на develop
3) Также гоняются тесты при PR в develop. Таких моментов на диаграмме изображено 3
Если просуммировать, то после 20 дневных коммитов может и не быть прогонов, если еще не настала ночь и мы не делали PR в develop. Так понятнее стало?
У нас два приложения в активной стадии разработки. Одно для соискателей (с которым все знакомы) уже довольно давно живет. В нём картина такая:
390 iOS
452 Android
Второе приложение для работодателей мы с нуля переписали недавно (это совсем другая история), его только сейчас начали покрывать тестами
Гоняются и в ночных прогонах и на PR в develop абсолютно все тесты. Это стало возможным благодаря уходу от trunk-based — не нужно каждый чих проверять на стабильность
Спасибо, мне постоянно казалось, что называем неправильно — похоже мы изобрели hh-flow. Погнали патентовать?
Не понял, а у вас кроссплатформенные тесты на java?
А какой стек целиком? На сколько флакуют?