Рубрика «управление разработкой» - 68

В феврале этого года мы провели первую конференцию для тимлидов и о тимлидах. Конференцию посетило более 500 человек. Главным итогом можно считать то, что в принципе сообщество признало наличие проблемы, о чем свидетельствует количество и состав вопросов, которые были подняты на круглом столе (мы писали об этом в  обзоре). Поскольку есть проблема, то нужно искать её решение, что мы и планируем сделать в рамках Saint TeamLead Conf в Санкт-Петербурге 24 и 25 сентября. Прием заявок на доклады ещё идёт, и о конкретной программе говорить пока рано. Давайте поговорим о целях Программного комитета, вспомним прошедшую конференцию, а также поговорим о том, что ждёт нас в конце сентября в Питере.

Отличаются ли проблемы тимлидов в Санкт-Петербурге, выясним на Saint TeamLead Conf - 1
Читать полностью »

Добро пожаловать на борт: вводим новых разработчиков в команду - 1

Привет!

Меня зовут Андрей Гоменюк, я тимлид одной из команд серверной разработки Badoo.

На майском Badoo Techleads Meetup, посвящённом управлению разработкой, я поделился опытом интеграции новичков в команду. А сегодня делюсь текстовым дополненным и улучшенным вариантом своего доклада.

Представьте, что сегодня ваш первый рабочий день в Badoo. Каких же знаний и умений ждёт от вас отдел и в частности я, руководитель? Как минимум таких:
Читать полностью »

Технический директор ivi Евгений Россинский (eross) хорошо знаком участникам наших конференций по докладам о технической стороне стриминга. Но сегодня пред вами расшифровка доклада Евгения на TeamLead Conf о том, как отражается Agile-трансформация на лидерах команд.

Как тимлиду выжить в масштабируемом скраме и сохранить контроль за качеством кода - 1

Не так давно в ivi прошли Agile-трансформацию и получили от неё хороший профит в плане:

  • бизнеса,
  • скорости разработки,
  • time to market;
  • других интересных метрик.

Но последствия этого креативного решения довольно серьёзно ударили по лидерам команд. Доклад как раз о том, как с этим справляться, и какие применять инструменты.

Читать полностью »

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

Как мы перебанили обычных игроков и заDDoSили свои сервера: практическое руководство - 1
Читать полностью »

Всем доброго!

Как всегда немножечко о нас: курс "Руководитель разработки", несмотря на его новизну для как не совсем чистого "программерского" курса, оказался очень успешным в плане количества окончивших его: из более чем тридцати человек отсеялось всего четыре человека, да и то по не связанным с тематикой обучения причинам. Так что закончив один поток, запускаем теперь и второй, чуть обновив и добавив теперь ещё и открытые уроки, на которых можно познакомиться и с преподавателем — Станиславом Михальским, и в целом с тем, что даётся на нём.

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

Поехали.

DevHead_Deep_LAST_11.07_2_Site.png

«Всегда честно признавай свои ошибки, это притупит бдительность начальства и позволит тебе натворить новые.» Марк Твен Читать полностью »

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

Антисобеседования - 1

Собеседование — это экзамен

Ведущий — строгий учитель, а кандидат — студент. Классический сеттинг. Обычно проходит так. Спросили откуда ты, что ты, и потом пошло техническое собеседование.

Начинается с простых вопросов на раскачку, примерно таких:
Читать полностью »

«Что за бред? Разве бывают менеджеры по счастью?» – спросит пессимист, прочитав название статьи. «А ведь идея вполне реальная! В ОАЭ давно настоящий министр счастья работает!» – парирует оптимист.

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

Вопросами оптимизации бизнес-процессов с применением сервисного подхода я активно занимаюсь последние 10 лет. И мне всегда интересно общаться с коллегами на эту тему.

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

Читать полностью »

Введение
Что такое DoR
Зачем нужен DoR
Где применять DoR
Когда применять DoR
INVEST модель
Заключение
Список литературы

Definition of Ready — то, о чем нам забыли рассказать - 1

Введение

Наверняка вы не раз слышали, скорее даже использовали с командой артефакт Scrum — Definition of Done далее по тексту — DoD. Возможно, используете его, даже не осознавая этого. О DoD написано много русскоязычных статей. О нём говорят на конференциях, и тренингах. Разобраться для чего нужен этот артефакт, и найти примеры не трудно. DoD определяет критерии, по которой каждый член команды понимает, что задача закрыта. Глубинная цель — синхронизировать понятие Done, между каждым членом команды. Над этими критериями, часто, команда трудится во время ретроспективы. Существует похожий артефакт, о котором почему-то нет упоминания в русскоязычных ресурсах о Scrum, а там где этот артефакт упоминается, не даётся никаких разъяснений что это, зачем нужен, и как использовать.

Скорее всего, в вашей команде звучали фразы наподобие: «Мы завалили цель, потому что неправильно оценили задачу», или «Наш PO опять пришёл с задачей без должного описания». В моей команде, подобные “сигналы” появлялись не один раз, и я долго искал способ, чтобы решить эту проблему.

Читать полностью »

Всем привет. Я работаю в московском офисе Технологического Центра Дойче Банка. Для тех, кто не знает, — мы занимаемся разработкой приложений для CIB (Corporate and Investment Banking) бизнеса в Нью-Йорке, Лондоне, Франкфурте, Токио, Сингапуре, Чикаго, Сиднее. В России в Техцентре работают более 1000 человек — это примерно 130 команд. Всего в мире таких центров у Дойче Банка четыре: в России (Москва и Санкт-Петербург), США, Румынии и Индии.

Офис под Agile: где разместить тысячу разработчиков? - 1

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

Методологию скрам постепенно осваивают все большие по масштабам команды. Такой опыт есть и у нашей компании. Совместно с Unusual Concepts мы планируем поделиться своими наработками со всеми желающими в рамках дня Large-Scale Scrum — LeSS Day 2018, который пройдет 16 июля в офисе Comcity в Москве.

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

Скрам в большие команды: LeSS Day 2018 - 1
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js