Управление разработкой *

Моё знакомоство с предметметно-ориентированным проектированием началось не совсем книги, а конференций 2019 года. Встречи с коллегами на AgileDays 2019, DDDevotion, DotNext, ArchDays позволили ясно увидеть два лагеря: не многих у кого DDD заработал, и многих кто хотел, но не взлетает. Это натолкнуло на длинные рассуждения, что DDD применим только при определённых производственных отношениях, а команды должны эффективно обучаться и применять на практике DDD.

Предполагаю, что читатель данной статьи уже понимает ценность предметно-ориентированного проектирования: что это гибкий способ декомпозиции задач, дающий точки дальнейшего развития, расширения функционала; что это лучший способ декомпозиции микросервисов; что это методология сближающая бизнес и разработку; что события предметной области могут анализироваться новыми способами. Такой читатель, уверен, интересуется тем, как изучить DDD со своими коллегами, и в этом случае, описанное ниже будет ему полезно.

Привет, Хабр!

На связи Андрей Рыжкин, CTO AGIMA. В нашей компании более 30 команд разработки, и у каждой свой тимлид (или несколько). Людей много, а значит, их нужно нанимать, развивать, мотивировать, а иногда – расставаться с ними. Работа с людьми на мой взгляд – это одна из важнейших и при этом самых сложных функций тимлида или технического руководителя. Эта статья – об одном из аспектов этой работы: о том, как искать и нанимать разработчиков. В основе материала мой контент для курса «Руководитель команды разработки», а также мой опыт за весь карьерный путь от разработчика до CTO.

«Наши компьютеры создаются так же, как и наши города: долго, без планов и на руинах былого». Эллен Ульман (Ellen Ullman) написала это в 1998 году, но сегодня мы именно так и создаем современные приложения: долго, имея лишь краткосрочные планы и поверх унаследованного ПО. В этой статье мы рассмотрим несколько шаблонов и инструментов, которые, на наш взгляд, хорошо подходят для продуманной модернизации унаследованных приложений и создания современных управляемых событиями систем.

Три года назад в группе компаний ЦФТ задачи бизнеса потребовали увеличения штата разработчиков в два раза. Перед отделом эксплуатации встало две задачи: не допустить линейного роста OPS и уменьшить TTM, не потеряв при этом в недоступности, непрерывности и безопасности.

В результате в компании теперь есть всё — и NoOps, и DevOps. Где-то пришлось пойти на компромиссы и доработать концепт NoOps напильником под себя. Сергей Бердников, руководитель отдела эксплуатации, сегодня расскажет, что получилось, и разберет — почему.

Привет, Хабр! Меня зовут Максим Бутаков, я работаю руководителем отдела контроля качества и тестирования в компании «ВТБ Лизинг». Сегодня я хочу рассказать о создании этого направления: о том, как нам удалось менее чем за три года улучшить качество продукта и существенно уменьшить количество багов. Думаю, под катом найдётся чем вас удивить.

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

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

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

О том, какие барьеры возникают на разных этапах сотрудничества между стартапами и научными институтами, и как их возможно преодолеть, рассказали предприниматели и эксперты Академпарка.

Работники не понимают, чего хочет от них глава компании.

Я пообщался с несколькими бывшими (в том числе, теми, кто работал в компании более 5 лет назад) и текущими сотрудниками, чтобы понять, были ли недавние увольнения единичным случаем или у компании системные проблемы.

Всем привет! Меня зовут Семен. Я Java-разработчик и руководитель группы Java-разработки в Центре Big Data компании MTS Digital. В этом посте я хочу поговорить о Release Notes. Что это такое, почему не стоит писать их вручную и какие есть способы автоматизации. Покажу и реальный пример того, как организована  работа с Release Notes в нашем проекте.

Разработчики уделяют большое внимание дизайну программных продуктов для гаджетов, стараясь сделать их максимально удобными. Люди охотно устанавливают мобильные приложения и регистрируются в них. А что насчет безопасности данных, которые мы доверяем производителям этих приложений? И как научить(ся) создавать безопасные приложения?

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

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

Не хотите читать? У нас отличная новость: можно послушать подкаст-версию этой статьи. Выбирайте удобную вам платформу — и вперед!

Кстати, у нас есть целый подкаст, где мы говорим о практической безопасности, современных киберугрозах и защите от них, а также делимся самыми интересными выступлениями с форумов PHDays. Уже доступны 19 выпусков.

Внимание, разработчики, а еще хабровчане!

Кто еще, как ни вы, можете рассказать нам о том, как обстоят дела с безопасной разработкой у вас в компании — ее успехом, присутствием или отсутствием. Расскажите, что вы думаете о DevSecOps и что хотели бы узнать о нем.

Предлагаем пройти анонимный опрос. С вас — пара минут вашего времени, с нас — результаты исследования и полезные инсайты.

Привет! Меня зовут Катя, я руководитель команды технических писателей в Ozon.

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

Привет всем. Это продолжение истории про переход команды PVS-Studio на работу по методике kanban. На этот раз речь пойдет про YouTrack, как мы выбирали и внедряли этот трекер задач и с какими вызовами столкнулись в процессе. Статья не имеет цели рекламировать или ругать YouTrack. Тем не менее замечу, что по мнению нашей команды ребята из JetBrains проделали (и продолжают делать) отличную работу.

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

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

Hello World!

Меня зовут Сергей Павлов, я тимлид по системной аналитике в банке "Открытие” на продукте МСБ “Бизнес-Портал”. Хочу рассказать, как я решал задачи по управлению командой, когда к ней присоединился.

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

Итак, морозное утро, вежливый голос руководителя мне говорит: “Это команда системных аналитиков, начинай творить добро”. Я смог выдавить только “угу” и сел думать насчет того самого творить и того самого добра.

Меня зовут Марина Перескокова. Я проработала в Яндексе 10 лет, и из стажёра-разработчика выросла до руководителя службы разработки фронтенда. За это время получилось поработать над JS API Яндекс.Карт, поруководить фронтендом сервиса yandex.ru/maps и покодить движок для векторной карты на WebGL. По итогам моего тимлидства я написала книгу.

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

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

Программисты пишут код (удивил, да?) Если это пет-проект, то вы вольны делать со своим кодом все, что хотите. Но когда над одним проектом работает несколько человек или даже целая команда, рано или поздно встаёт вопрос о необходимости код-ревью. Кому отдать на ревью? Как ускорить этот процесс? Как равномерно распределять реквесты по ревьюерам? Вопросов много, а ответы не так очевидны. В этой статье расскажу, с какой проблемой мы столкнулись в команде автотестирования в Wrike, как у нас устроен процесс ревью и зачем нам понадобился самописный сервис.

В карьере каждого программиста случаются взлеты и падения. Наверняка у каждого есть пара запоротых проектов, каких-то конфликтных ситуаций, о которых сожалеешь, миллион проваленных по срокам  задач, десятки технических решений, которые противоречили потребностям заказчика, многочисленные ситуации, когда вы поддались давлению, может быть, не совсем корректные увольнения и т.д. и т.п. С некоторыми людьми работа доставляет истинное удовольствие, их можно назвать профессионалами. С другими коллегами все идет наперекосяк. Почему такое происходит? Что входит в понятие “профессионал”? 

За свою более чем 42-летнюю карьеру Роберт Мартин прошел огонь, воду и медные трубы и выработал принципы, которые, по его мнению, должен придерживаться программист, чтобы быть успешным профессионалом. В книге “Идеальный программист” он не боится делиться многочисленными примерами своих провалов и советами, как стоило бы действовать в таких ситуациях.

Внутри - тест, по которому вы сможете понять, насколько вы являетесь профессионалом по версии Р. Мартина.  

В Сети много рецептов приготовления CI/CD для решения различных проблем и организации процессов под определённые нужды. В этой статье мы опишем ещё один, суть которого - приготовить процесс, максимально близкий к классическому подходу, несмотря на то что предназначен он для разработки КХД, и решить проблему организации работы большой команды.

Почему я решил написать эту статью?

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

• краткосрочное планирование (спринты),

• планирование проектов (контрактов),

• планирование загрузки ресурсов

• и наконец финансовое планирование (квартал, год и т.д.).

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