Привет, Хабр! Я бизнес-тренер. Мы в ОТП Банке очень любим читать полезные книги и делиться своими наблюдениями с коллегами. Решили, что и с читателями Хабра тоже нужно поделиться. Возможно, кто-то их все уже прочёл, а кто-то нет — и тогда я буду очень рада, что рекомендации пригодились:) Эти книги помогут прокачать soft skills — полезные навыки на пути к большим зарплатам.

Всем привет! Меня зовут Сергей Бережной, я работаю в Яндексе уже 18 лет: в 2005 году пришёл разработчиком интерфейсов, потом руководил подразделениями разного размера, а сейчас я директор по взаимодействию с разработчиками. Ещё я много занимаюсь обучением: в рамках наших сезонных школ и в Практикуме (где я работал над курсом «Управление командой разработки»).

Познакомившись с практиками экстремального программирования ещё в начале карьеры, позже я стал внедрять их в свои команды. По моим наблюдениям, они позволяют улучшить качество кода, ускорить подготовку релизов и в целом сделать процессы более гладкими. Если вам интересно узнать, почему и как, — эта статья для вас. Я поделюсь своим опытом и расскажу, что это вообще такое, какие практики бывают и что они дают. 

Сразу оговорюсь, что со времён появления этих практик степень их «экстремальности» и инноваторства сильно уменьшилась. Некоторые из них стали стандартом де-факто в индустрии — их используют широко и не выделяют в отдельную категорию. Например, рефакторинг и непрерывная интеграция когда-то считались экстремальными, а сейчас ими никого не удивишь.

Привет, Хабр! Я Федор Щудло, team lead и fullstack-разработчик. Всего я в разработке 15 лет, из них 11 в роли team lead.

Три года назад я сменил работу и занялся проектом, состояние которого можно описать кратко: ему 25 лет.

За этот долгий срок проект пережил несколько слияний и разделений компании, означающих серьезные потери людей, знаний, и даже исходников от некоторых сервисов по юридическим соображениям.

На проекте были благополучные периоды, когда были созданы очень крутые и амбициозные вещи. Но были также периоды, когда команды еле хватало на выполнение самых срочных задач. И в это время многие сделанные или не доделанные большие штуки изрядно обветшали.

Как результат, разработка шла с большими накладными расходами (все делали долго), и с высокими рисками (выкатили и разломали прод). А команда при этом работала на износ.

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

На работе вам, как правило, встречаются три типа личности: тип А, тип В и тип IT. Последние сильно отличаются от остальных. Мы выделили восемь классических типов личности, которые вы найдете практически в любом достаточно крупном IT-отделе. Некоторые из них это Костюмы, которые были отправлены в IT против своей воли, или Акулы продаж, которые с удовольствием продадут лед эскимосам, как только закончат продавать песок саудитам. В общем, под катом путеводитель по флоре и фауне IT-отдела.

Меня зовут Саша Зебелева и я занимаюсь организационной терапией команд и компаний. Если проще, то я провожу различные сессии помогающие команде\организации найти свое решение их текущих задач и пути достижения целей.

Одним прекрасным зимним днем, коллеги из крупной IT-компании обратились ко мне с запросом на проведение стратегической сессии.

Это была большая работа, одним из этапов которой была сессия по созданию продуктовой стратегии. Чтобы решить эту задачу, я начала искать подходящий фреймворк. В поиске я наткнулась на фрейм, который хочу представить, а также поделиться своим опытом проведения сессии по этой структуре. В середине работы мы столкнулись с отсутствием CPO, поэтому в статье вы также сможете найти как мы с этим справились и что по итогу у нас вышло.

В конце этой статьи вы найдете ссылки на исходные материалы фрейма, инструкции на английском языке, а также на переведенный мной фрейм в Miro.

Здравствуйте! Меня зовут Михаил, и я пишу эту статью специально для начинающих программистов, желающих изучить основы веб-разработки с использованием Flask.
 Я сам активно занимаюсь разработкой проектов на Flask и хочу поделиться своими знаниями и опытом, чтобы помочь вам начать свой путь в мире веб-разработки.

Flask для начинающих - Часть 2 создание Веб проекта.

Мы создадим с вами мини проект - веб сайт с админ панелью и обновлением контента сайта. При помощи Python, HTML, CSS, Bootstrap, Flask, SQLite.

Часто слышу мнение, что unit-тесты не нужны для мобильной разработки: в приложении должно быть минимум логики, основная работа с UI, а его сложно тестировать, да ещё и тесты отнимают время, которое можно было бы потратить на написание фич. 

За этим мнением скрывается простая правда — люди, которые так говорят, не умеют писать тесты. Не умеют писать их быстро; писать там, где нужно; писать так, чтобы была ощутимая польза для бизнеса. Я тоже был таким — понимал, что тесты нужны, но не понимал какие, где и как их писать. 

Рассказываю, что поменялось спустя 2 года и 4 тысячи тестов. 

Как начать работать с Flask

Меня зовут Михаил, и я пишу эту статью специально для начинающих программистов, желающих изучить основы веб-разработки с использованием Flask.

Вы новичок в программировании и мечтаете о создании собственных веб-приложений? Эта статья — ваш ключ к пониманию Flask, одного из самых доступных и гибких веб-фреймворков на Python. От установки и простых примеров до работы с данными и базами данных — мы покрываем все, что вам нужно для старта.

За 15-20 минут чтения вы получите не только теоретические знания, но и практические советы от опытного разработчика. Присоединяйтесь к миру веб-разработки и откройте для себя, как просто и увлекательно может быть создание ваших первых веб-приложений с Flask!

Привет! Меня зовут Павел Ахметчанов, я руководитель направления улучшения процессов разработки. В статье расскажу про часто используемые методики оценок задач и есть ли в них ошибки. Посмотрим, как правильно ставить вопросы при оценке. Узнаем, что собой представляет время решения задач, а это далеко не очевидная вещь. Попробуем изменить свое мышление и получим рецепт для определения времени решения задач. 

Если спросить любого начинающего исследователя этой темы «А зачем нам оценка?», он скажет, что постоянно задают вопрос «Когда вы выполните эту задачу?», на который и надо ответить с помощью этой оценки. А что, если сам вопрос задан неверно?

Если возникает вопрос об описании архитектуры системы, то есть несколько основных решений где и как это сделать. Среди популярных нотаций для визуализации схемы архитектуры можно выбрать C4, разработанную Саймоном Брауном.

В этой статье я хочу показать пример применения нотации C4, который вы сможете использовать как ориентир в своей работе, а также инструменты для её создания. В частности, выделяю Structurizr.

Статья полезна для системных аналитиков, архитекторов, разработчиков, менеджеров проектов и тех, кто участвует в создании и принятии решений по организации архитектуры проекта.

Как мы к этому пришли? Как мы стали вместо решения наших задач, тратить кучи денег на решение проблем, которых у нас нет?

Современный мир бизнеса и разработки программного обеспечения характеризуется высокой динамикой и необходимостью быстрого реагирования на изменения в рыночных условиях. В этом контексте эффективная организация команд становится ключевым фактором успеха. 

Team Topologies - это концепция, которая предлагает рациональный и гибкий подход к организации команд внутри организации. Классические подходы к организации Agile команд, как правило, рекомендуют создавать универсальные и кроссфункциональные команды, где любая команда может сделать любую фичу из беклога.

Трудоустройство на новое место работы — стресс для сотрудника и хлопоты для команды, вовлеченной в процесс найма. При этом «мягкость» онбординга зависит лишь от того, какие меры приняла компания, чтобы новичок быстро вливался в коллектив и мог без проволочек приступать к рабочим задачам, а не тратить время на чтение инструкций.

Меня зовут Антон Гришин. Я продакт в медицинской компании СберЗдоровье. Когда-то я сам столкнулся с тяготами и лишениями трудоустройства на новую работу и после небольшого анализа понял, что эту проблему реально решить. Рассказываю, как медицинской компании СберЗдоровье удалось автоматизировать онбординг — с чего начинали, с чем столкнулись и что получили в итоге.

Привет! На связи лид команды аналитиков Magnus Tech Владислава Никитина.

В заказной разработке каждый проект начинается со сбора бизнес-требований к будущей системе. Это важный этап, ведь именно здесь определяются контуры задач, которыми займутся разработчики. И с ним связан вечный проблемный вопрос: как лучше собрать и зафиксировать эти требования, чтобы оптимизировать разработку?

Подходы у всех команд разработки в целом общие, но есть профессиональные хитрости, которые отражаются и на процессе сбора информации, и на том, как оформляются бизнес-функциональные требования. У нашего подразделения — свои подходы. Это не истина в последней инстанции, но у нас они работают достаточно хорошо. Мы хотим поделиться своим видением того, как собрать требования в единый документ, и покажем пример структуры шаблона. Используя его, можно сфокусироваться на качественном сборе требований, не тратя время на придумывание и реализацию оформления.

Начинающие бизнес- и системные аналитики найдут в этой статье что-то полезное для себя, а заказчики лучше поймут, как проходит этот этап работ, и это понимание поможет продуктивному сотрудничеству с аутсорс-разработчиками.

Без выстраивания хороших отношений со стейкхолдерами (или заинтересованными сторонами) на проекте далеко не уедешь. О том, как это делать like a boss, – годная статья автора Кэт Бугард в блоге Miro.

Все картинки – из Miro.

Привет! Меня зовут Илья, я руководитель команды индивидуальных интеграций CDEK. В рамках этой статьи хочу поговорить о спектральном анализе — инструменте для аналитики и прогнозирования задач команд разработки. По итогу мы с вами разберемся, когда стоит его применять, почему он делает оценку задач прозрачнее и как с его помощью улучшить не только доставку фич, но и атмосферу в команде.

Статья, как и сам инструмент, подойдёт тимлидам, product‑ и project‑менеджерам, которые уже имеют опыт управления командами, набили шишки в запуске фич и ищут понятный и наглядный инструмент планирования, но не обладают большим техническим опытом.

Это третья статья из серии. В ней мы разберём два типа клавиатур, обсудим фильтрацию сообщений в телеграм ботах.

Эта статья направлена именно на новичков, в ней я постараюсь объяснить тему ботов на примере сбора обратной связи.

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

У меня появились проблемы с мотивацией, и после сообщения куратора о том, что моя стажировка закончилась на середине из-за несерьезного подхода к работе, я понял, что надо менять отношение ко всему в своей жизни. Я решил завести этот блог, чтобы найти людей со схожими интересами и делится всем тем, что я переживу и чему научусь на своем пути.

В это статье я начну с базы JavaScript - переменных и типах данных.