На январь 2018 года Ситимобил был небольшим нишевым игроком. То, что в вашем понимании Ситимобил — большая и сформировавшаяся компания — это благодаря как раз росту за 2018 год :)
Онбордит сначала HR — рассказывает в общем про компанию, дает почитать документы про наши ценности, наши do's & don'ts, рассказывает где что находится и тд. Далее онбордит тимлид той команды, куда выходит человек — помогает развернуть тестовую среду, знакомит с процессом и инструментами разработки, дает первые небольшие задачи.
«перформанс ревью»
Перформанс ревью происходит раз в неделю на 1-to-1 встречах программиста с тимлидом. Не все это правило выполняют пока, но мы к этому стремимся.
«Как используете скрам»
Каждый день с утра каждая команда делает стендап, где за 2-3 минуты каждый рассказывает, что делал вчера и что планирует делать сегодня. На бэкенде таски планируются раз в неделю, команда их разбирает и начинает исполнять. Что-то срочное делается out-of-order. Таск релизится сразу по готовности. На мобильных приложениях то же самое, но релизы раз в 2-3 недели.
«Как организуете взаимодействие на стыке скрам-команд»
Через тимлидов. Если конфликт, то они на встречу зовут кого-то сеньорного по отношению к ним т делегируют ему принятие решения.
«микросервисной архитектуры»
Видим ее плюсы и минусы. Плюсы в меньшей зависимости модулей друг от друга. Минусы в том, что если один микросервис значительно использует другой микросервис, то эти два микросервиса начинают иметь все минусы монолита, а также дополнительные минусы в виде накладных расходов при взаимодействии. Идеально — это делать микросервисы минимально зависимыми друг от друга.
«Интересно, как распределены роли и ответственность между командами»
Каждая команда — это кусок продукта. Каждая команда отвечает за свой кусок продукта.
«Как принимаются архитектурные решения»
Каждый разработчик принимает сам все решения. Но он ревьюится тимлидом и отдельной командой дополнительно ревьюится на оптимальность кода.
«автотестам»
Юнит-тесты пишем. Автотестов минимум — только основной функционал. Остальной функционал меняется настолько часто, что автотесты на него пока скорее вредны.
Интересно было бы послушать истории внедрения этих менеджеров, как внедряли, какие конкретно бизнес показатели улучшились, как уменьшалась средняя продолжительность аварий и за счет чего
«Столько описанных вопросов решает Java со Spring в связке, все эти альтеры вне бранчей, отсутствие типизации» а что такое альтеры вне бранчей?
«После перехода на микросервисы + Marathon всегда есть возможность безболезненно в течение секунд переключиться на предыдущую рабочую версию согласованных сервисов или баз»
Привлечение инвестиций не означает не прибыльности бизнеса. Инвестиции могут привлекаться под рост, который может требовать больших вложений, чем можно получить из прибыли. Что касается конкретно экономики Ситимобил, то мы ее не раскрываем.
Такая — это какая?
«Если да, то какое количество клиентов, заказывающих прежде через телефон, стало заказывать через приложение?»
Не можем раскрыть эту цифру
«По ссылке [2] получается не удалось добится желаемого роста и среднее количество поездок на декабрь составило 3 750 000?»
А в чем ваш вопрос?
Постоянно. Это то, что я в статье как раз называю “пасхалки».
Онбордит сначала HR — рассказывает в общем про компанию, дает почитать документы про наши ценности, наши do's & don'ts, рассказывает где что находится и тд. Далее онбордит тимлид той команды, куда выходит человек — помогает развернуть тестовую среду, знакомит с процессом и инструментами разработки, дает первые небольшие задачи.
«перформанс ревью»
Перформанс ревью происходит раз в неделю на 1-to-1 встречах программиста с тимлидом. Не все это правило выполняют пока, но мы к этому стремимся.
«Как используете скрам»
Каждый день с утра каждая команда делает стендап, где за 2-3 минуты каждый рассказывает, что делал вчера и что планирует делать сегодня. На бэкенде таски планируются раз в неделю, команда их разбирает и начинает исполнять. Что-то срочное делается out-of-order. Таск релизится сразу по готовности. На мобильных приложениях то же самое, но релизы раз в 2-3 недели.
«Как организуете взаимодействие на стыке скрам-команд»
Через тимлидов. Если конфликт, то они на встречу зовут кого-то сеньорного по отношению к ним т делегируют ему принятие решения.
«микросервисной архитектуры»
Видим ее плюсы и минусы. Плюсы в меньшей зависимости модулей друг от друга. Минусы в том, что если один микросервис значительно использует другой микросервис, то эти два микросервиса начинают иметь все минусы монолита, а также дополнительные минусы в виде накладных расходов при взаимодействии. Идеально — это делать микросервисы минимально зависимыми друг от друга.
«Интересно, как распределены роли и ответственность между командами»
Каждая команда — это кусок продукта. Каждая команда отвечает за свой кусок продукта.
«Как принимаются архитектурные решения»
Каждый разработчик принимает сам все решения. Но он ревьюится тимлидом и отдельной командой дополнительно ревьюится на оптимальность кода.
«автотестам»
Юнит-тесты пишем. Автотестов минимум — только основной функционал. Остальной функционал меняется настолько часто, что автотесты на него пока скорее вредны.
«После перехода на микросервисы + Marathon всегда есть возможность безболезненно в течение секунд переключиться на предыдущую рабочую версию согласованных сервисов или баз»
А как понять, какая версия рабочая?