Ключевое в разработке
Ключевое в разработке
Для нас инженер - это
Разработчик программного обеспечения, сконцентрированный на доставке эпиков и устранении всех потерь в этой доставке.
Мы ожидаем, что разработчик берет на себя ответственность за доставку цели спринта (цель спринта – это эпик, или какое-то значимое достижение, это не случайный набор ценностей “лишь бы влезло в две недели”)
Мы ожидаем, что разработчик берет на себя ответственность за доставку цели спринта (цель спринта – это эпик, или какое-то значимое достижение, это не случайный набор ценностей “лишь бы влезло в две недели”)
Для нас инженер - это
Разработчик программного обеспечения, сконцентрированный на доставке эпиков и устранении всех потерь в этой доставке.
Мы ожидаем, что разработчик берет на себя ответственность за доставку цели спринта (цель спринта – это эпик, или какое-то значимое достижение, это не случайный набор ценностей “лишь бы влезло в две недели”)
Мы ожидаем, что разработчик берет на себя ответственность за доставку цели спринта (цель спринта – это эпик, или какое-то значимое достижение, это не случайный набор ценностей “лишь бы влезло в две недели”)
Принципы бережливой (Agile) разработки, которые мы ждем от инженеров:
- Целиком отвечать за выкладку на продуктив, включая devops часть (devops инженеры – ваши наставники, которые обучат операциям, необходимым для развертывания нового микросервиса):
- Нет деления на frontend и backend – предполагается, что все инженеры должны быть равной компетенции в команде, чтобы помогать друг другу. Разработчик несет ответственность целиком за свою цель (эпик)
- Уменьшать количество бюрократии и описания задач, фокусируясь на взаимодействии с продукт оунером
- Отсутствие синхронных code review (когда разработчик ждет кого-то для проверки кода)
4. Только слабо связанная архитектура. Каждый микросервис независим от другого, включая полностью свой фронт, обмен между микросервисами – через общий контекст (таблицу в базе знаний, или брокер сообщений, в зависимости от целесообразности и удобства)
5. Быть инженером, а не кодером:
- Использовать IDE с copilot как для написания кода, так и для code review
Цель техлида – привести всех в состояние техлидов и улучшать качество
7. Разработчик – тот, кто служит целям product owner или человеку, исполняющему его функции
8. Балансировать количество happy hours и улучшений/исправлений
9. Придерживаться парадигмы Zero Bug Policy
Что вы увидите во многих IT компаниях, но что мы не поощряем:
- Наличие тестовых стендов в любом проекте. Лучшие команды выкладывают на продуктив и обеспечивают always-releasable-state для кода. Мы считаем, тестовые стенды нужны далеко не всегда
- Выкладка на продуктив в особенное время (в пятницу вечером) – у нас выкладка должна быть каждый день (несколько раз в день)
- Тестировщиков и бизнес-аналитиков – они лишь увеличивают количество теряемой информации и статистически значимо ухудшают качество программного обеспечения (QSM) и не предусмотрены SCRUM`ом
- Детальных описаний задач – если разработчик понимает цель, его задача её достигнуть, а описание всегда будет отставать от реальности
- Создание UI/UX дизайнов синхронно с разработкой (сначала проектируется интерфейс, потом реализация). Мы считаем, что сначала должен быть рабочий функционал, которым реально начали пользоваться, а только потом приводить в красивый вид
- Трекинга за оценку задач – цель спринта можно сделать быстрее или медленнее, важно, как вы её делаете и по факту справляетесь, а не то, как вы посчитали себе оценку (обычно, с запасом сверху)
Грейды инженера
- Инженер L30 (senior) – самостоятельно, без микроменеджмента реализует эпики или цели спринта
- Инженер L20 (middle) – самостоятельно может сделать целиком бизнес-ценность (мало неопределенности, обычно – очевидный функционал). До состояния L30 желательно дорасти <3 месяцев
- Инженер L10 (junior) – без микроменеджмента выполненные простые технические задачи. До состояния L20 желательно дорасти <3 месяцев
Грейды инженера
- Инженер L30 (senior) – самостоятельно, без микроменеджмента реализует эпики или цели спринта
- Инженер L20 (middle) – самостоятельно может сделать целиком бизнес-ценность (мало неопределенности, обычно – очевидный функционал). До состояния L30 желательно дорасти <3 месяцев
- Инженер L10 (junior) – без микроменеджмента выполненные простые технические задачи. До состояния L20 желательно дорасти <3 месяцев