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

Поехали!

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

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

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

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

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

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

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

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

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

Каждый из нас бывал на интервью собеседовании. Сначала в офисе, позже напротив собственного монитора сидел, потел, волновался, ошибался в самых элементарных вещах, а потом, когда уже всё кончилось, думал — почему же они спрашивают именно то, что спрашивают? Им правда необходимо, чтобы я наизусть знал методы класса Object? Неужели они реально используют Vector в своем коде? Или разрабатывают новые алгоритмы сортировки на основе сортировки пузырьком? Сегодня поговорим именно об этом — о вопросах на собеседовании и почему они именно такие.

Данный математический опус вдохновлен одним из комментариев к прошлой статье. Кто не читал, конечно же немедленно читать, но если вот именно ты ленив (а ты ленив!), то я напомню – статья была о том, что многоступенчатое собеседование вводится компаниями исключительно для снижения зарплат сотрудников.

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

Эта статья написана по мотивам НЕМИТАПА, проведенного компанией Авито. Когда я увидел ЭТО, сказать, что был шокирован – ничего не сказать. Сначала Яндекс, потом Тинькофф, ну и теперь вот Авито (и это только наши, отечественные) внедряет у себя шестиступенчатое собеседование.

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

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

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

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

Вместо предисловия

Agile. Кругом Agile. Наверное не осталось людей, команд и организаций, которые работают не по Agile. Слово «SCRUM» прочно вошло в жизнь разработчика. Я уже и не помню, была ли разработка иной. А когда спрашиваешь, почему у вас в организации насаждается Agile, в ответ получаешь либо цитату из эпиграфа, либо, если человек более откровенен, слова "так все делают". Ну не может же быть, чтобы миллионы мух ошибались то, что делают все, было ошибочным?

Но, как известно, есть некоторые особенные люди, которые могут попытаться проверить, ошибаются ли мухи верно ли то, что делают все? Приятно, черт возьми, ощущать себя особенным!

Для начала попробуем подсчитать стоимость ритуалов SCRUM

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

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

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

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