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

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

Антисобеседования - 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
Читать полностью »

Контрибьютим в Go с помощью статического анализатора go-critic - 1

Вы, возможно, помните недавний анонс нового статического анализатора для Go под названием go-critic.

Я проверил с его помощью проект golang/go и отправил несколько патчей, которые исправляют некоторые найденные там проблемы.

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

Для самых нетерпеливых: обновляемый список трофеев.

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

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

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

Почему именно больница?

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

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

Секреты удачного проектирования ИС (информационной системы) на примере строительства больницы - 1

Программный код внутри (но этого никто не видит)

При чем тут больница, если мы разрабатываем ПО?

А вот и нет, дорогие разработчики, руководители, аналитики, тестировщики.

Не программное обеспечение вы разрабатываете… Возьмем Android, — это ПО. А если, например, перед вами бухгалтерская система, то вы уже имеете дело не просто с ПО, а с ИНФОРМАЦИОННОЙ СИСТЕМОЙ.
Читать полностью »

Как следует из названия, это продолжение серии статей про роли в scrum (часть 1 и часть 2). Сегодня рассмотрим следующую роль – scrum master. Как это ни парадоксально, успешность scrum во многом зависит от scrum мастера. Поэтому хочется снова призвать силу воображения и привести метафору (дисклеймер: пример никоим образом не должен оскорбить чьих-либо чувств). Есть культура, у которой есть свой культ, свои обряды, есть служители этого культа. Служителей можно разделить на различные классы:

  • те, кто со своей культурой предпочитают быть один на один — отшельники, затворники, просветленные;
  • те, кто выучили все правила, нашли лазейки, понимают, что и как делать, и используют культ в корыстных целях, наживаясь на людях, их страхах и предубеждениях;
  • фанатики, которые пытаются насадить свою культуру к месту и не к месту. Для которых кроме их знаний, всё остальное ересь;
  • те, кто искренне верит, чувствует и пытается поделиться, помочь и подарить это чудо людям; они рассказывают и объясняют, слушают и пытаются помочь.

Со Scrum и SM-ами, мне кажется, происходит очень похожая история. Попробуйте посмотреть на знакомых вам SM через такую призму. С какими SM вам бы хотелось работать?
image
Давайте разберемся, какие тревожные симптомы могут быть у SM.

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

image

Существует два основных пути становления топ-менеджмента в IT-компаниях:

  1. Менеджерский — когда менеджер проекта начинает управлять другими менеджерами.
  2. Технарский — когда разработчик начинает управлять другими разработчиками и количество управляемого им персонала увеличивается.

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

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


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