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

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

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

Поэтому рано или поздно заказчик пришлёт письмо: «Почему, чёрт возьми, это занимает так много времени?» Не будем забывать, что у нас как инженеров-программистов есть окно в мир, которого они зачастую лишены. Они очень нам доверяют, но иногда кажущееся незначительным изменение отнимает действительно много времени. Из-за этого и возникают вопросы.
Читать полностью »

Наш мир устроен очень странно. И чем дальше, тем становится страннее. И хрен поймешь, в чем дело.

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

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

Я говорю о «внедрении методик», «работе по фреймворку», «обязательном использовании всех артефактов». О сектах, короче.Читать полностью »

Матрица Эйзенхауэра – очень известный метод определения приоритетов. Например, в знаменитой книге Стивена Кови «Семь навыков высокоэффективных людей» матрице посвящена целая глава.

Матрица – это инструмент расстановки приоритетов задач. Придумал ее, говорят, 34-й президент США Дуайт Эйзенхауэр. Определять приоритеты с помощью матрицы просто и эффективно.

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

Что важно, а что — срочно? - 1

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

Ключевая проблема, с которой сталкиваются люди при работе с матрицей Эйзенхауэра, это классификация задач по срочности и важности. А если точнее, то главная беда – понять, что вообще такое срочность и важность. Так и не разобравшись, люди бросают матрицу, поигравшись день или два. Попробуем разобраться.Читать полностью »

Github представил сервис управления пакетами Package Registry - 1

Вчера Github представил службу управления пакетами Package Registry, которая упрощает публикацию общедоступных или частных пакетов рядом с исходным кодом.

Реестр пакетов полностью интегрирован с Github, здесь можно использовать те же инструменты поиска, просмотра и управления для поиска и публикации пакетов, что и для репозиториев. Для совместного управления кодом и пакетами также применимы разрешения для отдельных пользователей и групп. Github гарантирует «быструю и надёжную загрузку», поддерживаемую глобальным CDN Github. И поддерживает привычные инструменты управления пакетами: JavaScript (npm), Java (Maven), Ruby (RubyGems), .NET (NuGet) и образы Docker. В будущем список обещают расширить.
Читать полностью »

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

Во всем виноват сука-программист. Всё из-за него. Сейчас я тебе все расскажу.Читать полностью »

Ты – программист. Я – эффективный менеджер. Ну, ты так считаешь. Может, даже статью про меня напишешь, наберешь кучу плюсов – тема-то благодатная. В статье обязательно слово «эффективный» в кавычки поставишь.

Я уже не работаю в вашей компании. Решил рассказать тебе, как всё было на самом деле. Скоро эта история тебе аукнется, что меня очень расстраивает, но будет лучше, если ты обо всём узнаешь от меня.Читать полностью »

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

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

Ты утверждаешь, что знаешь об автоматизации все. Ты называешь себя властителем душ программистов. Говоришь, что они у тебя танцуют, как кобра под дудочку.
Что ж. Проверим.Читать полностью »

Прежде чем взяться за работу над user story, очень важно определить для себя критерии приемки. Это можно сделать, когда вы детализируете бэклог или планируете  ближайший спринт. Некоторые команды для этого проводят специальные встречи, которые называются 3 Амиго (подробнее о них в прошлой статье), митинги, kick-off по спецификации или встречи-исследования.

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

Но есть простой способ сделать такие встречи короткими и очень продуктивными. И называется этот способ Example Mapping или составление карт тест-кейсов.

Введение в Example Mapping - 1
Читать полностью »

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

Так что мы подготовили для вас следующие материалы:

  • Специальный контест, содержащий задачи, похожие на те, что мы даём на интервью.
  • Этот пост. В нём рассказывается, почему нужно проводить такие секции, а также разбираются все задачи контеста.
  • Два видео, в которых разбираются задачи из контеста: в первом — задача попроще, во втором — две задачи посложнее. Из этих видео вы узнаете о типичных ошибках, допускаемых и при прохождении алгоритмических секций, и при написании продакшен-кода.

Как проходят алгоритмические секции на собеседованиях в Яндекс - 1

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

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

Рассказывает Юрий Никулин, руководитель службы разработки технической документации.

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

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

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


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