Если он так хорош, то почему все не работают только по этой методологии? А те, кто якобы внедрил, часто демонстрирует чудовищный ScrumBut. Настоящий SCRUM оставляет на вашем сердце шрамы, раны и отметины, и сейчас я расскажу о своих.
Читать полностью »
Как и обещал в предыдущей статье, разворачиваем ситуацию в противоположную сторону. Мне довелось побыть не только разработчиком, но и руководителем разных уровней. Я уже упоминал, что в последнее время мне везет на команды и коллег. Но за все время работы бывало всякое.
(Григорий Остер)
Поговорим о том, о каких разработчиках мечтает руководство. В этот раз я выступлю в роли абстрактного управленца…
Читать полностью »
На вопросы отвечал Павел Зыков, СТО DomClick.ru
ДомКлику скоро 5 лет. Давайте немного вспомним историю и заодно познакомимся. Компания была основана в 2015 году. Ты помнишь день, с которого все начиналось?
Еще как помню. Я входил в число основателей, поэтому помню все в мельчайших деталях – как собеседовали первых людей, как в августе 2015 года сняли первый офис на улице Рабочая, который устраивал нас по цене, несмотря на то, что подоконники кабинетов всегда были в пыли от проходящих рядом поездов. Сейчас, сидя в максимально комфортном Agile Home в 2 минутах от ст. метро Кутузовская, с теплотой вспоминаем о тех временах, когда два интернет — провайдера в здании считалось нашим уникальным преимуществом.
На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).
Ее основными тезисами были:
Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.
Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.
Я уверен, где-то существует книга «Как подсидеть тимлида». Она передается из рук в руки, из команды в команду и содержит советы типа: «Тимлид никогда не уволится по своей воле, потому что это не работа, а сказка! Его нужно сломать», или «Если ваш тимлид уехал в отпуск, напишите ему, что вам нужно поговорить, когда он вернется. Пусть вместо серфинга думает, что в его отсутствие команда разбежалась», а еще «Саботируйте попытки тимлида внедрить новые полезные рабочие процессы фразой из Agile-манифеста о том, что люди и взаимодействие важнее процессов и инструментов». Иначе просто невозможно объяснить, почему все тимлиды сталкиваются с одними и теми же проблемами и страхами.
Я опросил более 400 тимлидов, чтобы провести деконструкцию некоторых из страхов тимлидов. Результаты опроса и исследование рынка тимлидов помогло понять, как с ними справиться, и я хочу поделиться результатами. Простые лайфхаки помогут меньше страдать от синдрома самозванца не только тимлидам, но и вообще любым специалистам, которые еще недавно выполняли конкретные задачи, а теперь руководят командой исполнителей.
Пока в мире бушует страшный вирус и все дружно переходят на онлайн-общение, мы решили вспомнить наше прошедшее офлайн-событие.
Месяц назад отгремел московский TeamLead Сonf 2020, пробив потолок в количестве тимлидов на кв.м — 1500 участников слетелись на площадку ЦМТ. Зачем их собрали и что с ними делали на конференции — расскажем тут. Если кратко: «Бог гРома» повелел смотреть доклады, участвовать в воркшопах и заниматься священным нетворкингом.
Канарейка — маленькая птица, которая постоянно поет. Эти птички чувствительны к метану и угарному газу. Даже от небольшой концентрации лишних газов в воздухе они теряют сознание или умирают. Золотоискатели и шахтеры брали птичек на добычу: пока канарейки поют, можно работать, если замолчали — в шахте газ и пора уходить. Шахтеры жертвовали маленькой птичкой, чтобы выбираться из шахт живыми.
Подобная практика нашла себя и в IT. Например, в стандартной задаче деплоя новой версии сервиса или приложения на продакшн с тестированием перед этим. Тестовое окружение может быть слишком дорогим, автоматизированные тесты не покрывают все, что хотелось бы, а не тестировать и жертвовать качеством рискованно. Как раз в таких случаях помогает подход Canary Deployment, когда немного настоящего продакшн-трафика пускается на новую версию. Подход помогает безопасно проверить новую версию на продакшн, жертвуя малым ради большой цели. Подробнее, как работает подход, чем полезен и как его реализовать, расскажет Андрей Маркелов (Andrey_V_Markelov), на примере реализации в компании Infobip.Читать полностью »
Toyota — мировой лидер автомобилестроения, один из самых дорогих автомобильных брендов и синоним слова «качество». Toyota известна своей сложной производственной системой, благодаря которой она стала мировым лидером. На её описание потребовалось 10 лет и 20 версий, в итоге появился документ «Философия Toyota 2001». Часть принципов из этой книги — кайдзен и канбан — используются в IT. Но эти принципы лишь часть системы постоянного обучения и непрерывного совершенствования, которая плотно интегрирована во все процессы корпорации.
В системе обучения много разных принципов и техник. Например, перед разработкой новой модели инженеры Toyota изучают передовые разработки поставщиков и технологии конкурентов: разбирают их автомобили, изучают и фиксируют удачные технические решения. При этом обучаются не только инженеры, но и вся компания. Для этого используются контрольные листки, матрицы качества, ретроспективы, таблицы навыков, базы данных стандартов и всех прошлых проектов. Всё это помогают сохранять и систематизировать знания, расти, обучаться и выпускать качественные продукты. Другими словами, в Toyota реализована почти идеальная система управления знаниями. Поэтому они лидеры.
История Toyota — отличный пример управления знаниями. Но что будет, если знаниями не управлять, а систему не выстраивать? Велосипеды, сломанные конвейеры, автобусы, «сжигание» денег на онбординге и legacy — все это случается с компаниями, когда они не задумываются об управлении знаниями.
Читать полностью »
Стоп, хватит, уберите немедленно! Для того чтобы закрыть провалившийся проект, нужны две вещи: нужно понять, что проект провалился, и нужно его закрыть. Но не все так просто.
Мы недавно писали, как затеяли конференцию, полностью посвященную инженерным процессам и практикам. Наша цель — собрать в одном месте профессионалов, которые развивают техническое лидерство у компании, продукта и дать им возможность поделиться опытом, обсудить свои задачи и проблемы индустрии, вместе найти новые подходы. Мы долго думали, что объединяет таких людей, как их распознать. И поняли, что это техлиды. Именно они несут ответственность за технологический вектор, внедряют те самые инженерные практики и настраивают процессы.
Но в нашей индустрии даже градация должностей junior/middle/senior колоссально отличается от компании к компании. Что уж говорить о техлиде, который и вовсе не должность, а роль. Поэтому решили разобраться, что вкладывают в это понятие чаще всего. Заодно очертить зоны ответственности, сформулировать ключевые навыки техлида и понять, наконец, чем техлид отличается от тимлида (Спойлер: тимлид — это тоже роль, поэтому один человек может одновременно быть и техлидом, и тимлидом. А может и не быть).
