Пока в мире бушует страшный вирус и все дружно переходят на онлайн-общение, мы решили вспомнить наше прошедшее офлайн-событие.
Месяц назад отгремел московский 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 колоссально отличается от компании к компании. Что уж говорить о техлиде, который и вовсе не должность, а роль. Поэтому решили разобраться, что вкладывают в это понятие чаще всего. Заодно очертить зоны ответственности, сформулировать ключевые навыки техлида и понять, наконец, чем техлид отличается от тимлида (Спойлер: тимлид — это тоже роль, поэтому один человек может одновременно быть и техлидом, и тимлидом. А может и не быть).
Перевод репозитория github.com/dwmkerr/hacker-laws
При обсуждениях, связанных с разработкой ПО, люди часто говорят о различных законах. В данном репозитории хранятся ссылки и описания некоторых из наиболее известных из них.
Здесь содержатся объяснения некоторых законов, принципов и закономерностей, но нет никакой агитации в их пользу. Применять их или нет – это всегда вопрос спорный, и всё зависит от того, над чем вы работаете.
Закон Амдала — это формула, демонстрирующая потенциал ускорения вычислительной задачи, которого можно достичь при увеличении количества ресурсов системы. Обычно он используется в параллельных вычислениях, и может предсказать наличие реальных преимуществ от увеличения количества процессоров с учётом ограничений параллелизуемости программы.
Читать полностью »
Синий кит — отличный пример того, как проектирование сложного проекта пошло не по плану. Кит внешне похож на рыбу, но он млекопитающее: кормит детенышей молоком, у него есть шерсть, а в плавниках до сих пор сохранились кости предплечья и кистей с пальцами, как у сухопутных. Он живет в океанах, но не может дышать под водой, поэтому регулярно поднимается на поверхность глотнуть воздуха, даже когда спит. Кит самое большое животное в мире, длиной с девятиэтажный дом, а массой как 75 автомобилей Volkswagen Touareg, но при этом не хищник, а питается планктоном.
Когда разработчики работали над китом, то не стали писать все с нуля, а использовали наработки из старых проектов. Он словно слеплен из несовместимых частей кода, которые не тестировались, а все проектирование сводилось к выбору фреймворка и к срочному «велосипедированию» уже в продакшне. В итоге получился проект красивый внешне, но с кусками дремучего легаси и костылей под капотом.
Для создания проектов, которые помогают бизнесу зарабатывать, а не похожих на морское животное, которое не может дышать под водой, есть DDD. Это подход, который фокусируется не на инструментах или коде, а на изучении предметной области, отдельных бизнес-процессов и на том, как код или инструменты работают для бизнес-логики.
Что такое DDD и какие инструменты в нем есть, мы расскажем в статье на основе доклада Артема Малышева. Подход DDD в Python, инструменты, подводные камни, контрактное программирование и проектирование продукта вокруг решаемой проблемы, а не используемого фреймворка — все это под катом.
Читать полностью »
Чистый скрам — как единорог на музыкальном фестивале: вроде бы он существует, все о нём говорят, только вот показать тебе его никто не может. Так же сложилось и у нас в команде, об этом и поговорим. А если конкретнее — о том, как мы сократили время на встречи и не потеряли пользу от них.
Читать полностью »
В последнее время мне везет — я работаю в компаниях, где по-настоящему уважают разработчиков. Но так было не всегда, приходилось сталкиваться с разным подходом к взаимодействию. Хотел бы я сказать, что “дикие нравы” уходят в прошлое, но рассказы коллег об их предыдущих местах работы да и мои наблюдения за рынком опровергают это утверждение.
Что ж, поговорим о том, как “правильно” взаимодействовать с разработчиком, например лично со мной…
(Если всей семьей купаться вы отправились к реке,
не мешайте папе с мамой загорать на берегу.
Не устраивайте крика, дайте взрослым отдохнуть.
Ни к кому не приставая, постарайтесь утонуть, — Григорий Остер)...
Читать полностью »
Привет!
Меня зовут Вьет, и больше 10 лет я с любовью пишу код. В прошлом году меня пригласили в программный комитет, в котором большие фанаты качественной разработки делали конференцию QualityConf. Мы верим, что качественная разработка не ограничивается вопросами тестирования, поэтому собрали под одной крышей доклады про различные аспекты качества продуктов.
Но нашу команду поджидали две серьезные проблемы.
