Pull to refresh
27
0
Евгений Россинский @eross

User

Send message
да в рублях, но верхнего предела не назову.
1. Пару недель раскачивались, но потом втянулись
2.Шла, но только в тех местах где требования определены, а конкретнее занимались больше архитектурными вопросами
3. От одного функционального блока к другому
в конечном счете, отвечает все, это же командная работа.
Тимлид, как и другой член команды, кодит, делает ревью, участвует в планировании, но помимо этого больше других участвует в решении архитектурных вопросах координирует сложные мержи, помогает вливать фичи(при возникновении проблем ), запиленные в стримах в develop.
Например, есть teamlead Android, это самый опытный разработчик или несколько разработчиков, в их задачу входит стратегия развития кода. У Teamled есть команда (мы ее называем «платформа»), которая так же работает по scrum. При этом есть команды value stream, в которых тоже есть Adnroid разработчики. Teamlead участвует в планировании платформы, но не участвует в планирование Android разработчиков, входящих в value stream'ов. Teamlead не называет сроки ни в команде платформы и уж тем более в команде value stream'ов. Сроки каждая команда определяет сама и сама старается их соблюсти.
teamlead роль не scrum, конечно не прописанная, но его жизнь радикально изменилась, как только участников его команды растащили по разным value stream. В задачу teamlead'a входит контролировать целостность кода следить за вопросами архитектуры и делать так, что бы код не превратился в спагетти. Создав кроссфункциональные команды, которые стимулируют быстрый запуск фич в прод, мы можем привести состояние кодовой, например Android, в неподдерживаемое состояние. Teamlead препятствует анархии.
Конечно в этом проблема, но синхронизировать работу большого количества людей непросто, речь тут не про сроки, речь про количество вариантов, которые надо оценить и про то, что в условиях постоянно меняющихся требований, нужно постоянно находить новые решения и переговариваться. В условиях большой команды нужны какие-то правила игры. Мы выбрали те правила, о которых я рассказал.
Масштабировать Scrum можно по разному, мы рассказал о нашей имплантации, думаю, если вы посмотрите выступление станет понятнее
«возможность к масштабированию», прошу прощения за опечатку.

Оттого, что scrum — это не только использование планирования, ретроспективы, dsm и других атрибутов, данная методология имеет возможность в масштабированию. В своём докладе я рассказал о нашем опыте имплементации одного из подходов к организации межкомадного взаимодействия.

При подобной координации получается потеря контекста задачи, а так же очень большая вариативность. Зачем придумывать сложный синхронизационный механизм, когда можно сделать саморегурируемый. А механизм синхронизации получается действительно сложным, так как надо учитывать совокупность всех фич, которые сейчас в работе, особенности платформ, релизный менеджмент, откаты функционала. В итоге оказывается, что синхпонизировать эту работу крайне сложно, а как побочный эффект центры синхронизации, становятся бутылочными горлышками и ещё сильнее тормозят процесс. 20ти менеджерам отвечающий за разные фичи очень сложно договориться между собой, что бы получилось что-то осмысленное

Не руководство, в сама команда увидела что time2market составляет 4 месяца, для очень простой фичи, что не простительно много. Стало ясно, что есть очень много сложных связей внутри большой команды и чем сложнее фича, тем вероятность успеха её внедрения меньше. Создавать под каждую фичу сложную и каждый раз разную структуру проектного управления неуелессодразно. Так что шаг, который мы предприняли помог уменьшить количество зависимостей между людьми внутри команды, которая пилит отдельную фичу. К слову Иметь в команде болтунрв и любителей футбола это намного лучше, чем людей не желающих общаться.

«А ведь сам доклад интересный. Я бы с удовольствием послушал его еще раз — в новой, «чистой» аранжировке.»

Из песни слов не выкинешь
Сотрудникам с ролями админов в слак приходит уведомление, о новой задаче в очереди. Кто освобождается берет ее
у нас в backend(е) нет develop ветки. Разработчики выделяют свои ветки из мастера, так же у разработчиков нет прав на merge своей ветки в master, это делать только jenkins с обязательным прогоном тестов. То есть для каждой из веток тесты будут проведены правильно. Мы стараемся не мариновать уже смеренные задачи в master(e). И разработчик практически сразу после успешного прохождения тестов и успешного мержа отправляет запрос на выгрузку и ждет свободного админа, кто бы ему выгрузил код. И наш бот помогает нам как в раз в том что бы понять кто раньше захотел зарелизиться. Без него можно было прошептавших ошибиться и выгрузить последний тег, минуя тот которые еще не выгружен.

Вероятность того о чем вы говорите не нулевая, я говорю о том что может выгружено сразу 2 задачи вместо одной (при этом прогон тестов будет корректный), но есть очень много механизмов, которые не допускают этой ситуации.
Бизнес требует от нас больше чем 1-2 релиза в день. Так что нам приходится соответствовать. Код проверяется долго с помощью unit тестов, функциональных тестов и нагрузочных. Ну и к тому же мы предусматриваем процедуру отката и процедру плавных релизов на часть аудитории.
Перед релизом задача проходит ревью, потом тестирование в тестовой среде, потом нажимается волшебная кнопка в jenkins, которая делает rebase, потом прогоняет тесты, потом ставится тег. И уже потом релиз
Иногда несколько десятков релизов в день. Чаще всего — да. Одна задача — один релиз. Однако, бывают релизы из 2-3 задач.
справедливо! сейчас исправлю
У нас много систем для автоматизации релизов, типа Jenkins и Capistrano, но они занимаются релизами конкретных проектов. А тут же речь про все проекты компании. Такого зверя готового мы не нашли.

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity