Рубрика «процесс разработки»

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

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

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

Доброго времени суток!

Еще год назад мой процесс отладки кода в PHP заключался в двух строчках:

var_dump($variable);
die();

Периодически, конечно, приходилось использовать более «сложные» конструкции:

console.log(data);

echo json_encode($variable, JSON_UNESCAPED_UNICODE);
exit();

Нет, что вы! Я знал — в наше время не подобает культурному программисту заниматься этим

древним ремеслом

шутка про другое древнейшее ремесло

Но, честно говоря, я всегда боялся того, что не понимаю. В том числе и принтеров xDebug, в особенности, как все это дело настроить. В один прекрасный день у меня получилось это сделать на своей машине и в локальном проекте — радости не было предела. Спустя много месяцев я столкнулся с новой проблемой, как заниматься отладкой в PHPstorm через xDebug, если проект собирается удаленно докером через CI.

Если Вы так же, как и я, испытываете трудности с настройкой разных штук, добро пожаловать под кат, я расскажу о своем опыте настройки окружения отладки с такими страшными словами, как Docker, xDebug, CI.
Читать полностью »

Как Unsplash масштабируется силами небольшой команды - 1

Фото: Alex Smith | Unsplash

Добрый день!

Меня зовут Виктор Пряжников, я работаю в отделе Features компании Badoo. Основная задача нашего отдела — разработка функционала, который видят пользователи нашего сайта и приложений. Когда мне попалась на глаза статья сооснователя Unsplash Люка Чессера, она заинтриговала меня тем, что им удаётся развивать сравнительно большой проект совсем маленькой командой. Подход автора импонирует мне своей прагматичностью и чем-то напомнил «Вы — не Google», поэтому я решил её перевести.

Одна из самых забавных вещей в разработке Unsplash — большой масштаб и популярность продукта.

В обычный день наш API обрабатывает больше 10 млн. запросов от unsplash.com и тысяч сторонних приложений, через наш пайплайн обработки данных проходят миллионы событий, в наши ленты добавляются 60 млн. обновлений, и мы обслуживаем 60 млн. изображений.

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

Масштабирование Unsplash маленькой командой: 8 человек и 10 миллионов запросов в сутки - 1

Фото: Alex Smith | Unsplash

Добрый день!

Меня зовут Виктор Пряжников, я работаю в отделе Features компании Badoo. Основная задача нашего отдела — разработка функционала, который видят пользователи нашего сайта и приложений. Когда мне попалась на глаза статья сооснователя Unsplash Люка Чессера, она заинтриговала меня тем, что им удаётся развивать сравнительно большой проект совсем маленькой командой. Подход автора импонирует мне своей прагматичностью и чем-то напомнил «Вы — не Google», поэтому я решил её перевести.

Одна из самых забавных вещей в разработке Unsplash — большой масштаб и популярность продукта.

В обычный день наш API обрабатывает больше 10 млн. запросов от unsplash.com и тысяч сторонних приложений, через наш пайплайн обработки данных проходят миллионы событий, в наши ленты добавляются 60 млн. обновлений, и мы обслуживаем 60 млн. изображений.

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

Как восемь человек масштабируют highload-проект. Опыт Unsplash - 1

Фото: Alex Smith | Unsplash

Добрый день!

Меня зовут Виктор Пряжников, я работаю в отделе Features компании Badoo. Основная задача нашего отдела — разработка функционала, который видят пользователи нашего сайта и приложений. Когда мне попалась на глаза статья сооснователя Unsplash Люка Чессера, она заинтриговала меня тем, что им удаётся развивать сравнительно большой проект совсем маленькой командой. Подход автора импонирует мне своей прагматичностью и чем-то напомнил «Вы — не Google», поэтому я решил её перевести.

Одна из самых забавных вещей в разработке Unsplash — большой масштаб и популярность продукта.

В обычный день наш API обрабатывает больше 10 млн. запросов от unsplash.com и тысяч сторонних приложений, через наш пайплайн обработки данных проходят миллионы событий, в наши ленты добавляются 60 млн. обновлений, и мы обслуживаем 60 млн. изображений.

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

IX ВНЕДРЕНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

Нет ничего труднее, опаснее и неопределённее, чем руководить введением нового порядка вещей, потому что у каждого нововведения есть ярые враги, которым хорошо жилось по старому, и вялые сторонники, которые не уверены, смогут ли они жить по новому.
Н. Макиавелли

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

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

VII РАЗРАБОТКА ПЛАНА РЕАЛИЗАЦИИ И ВНЕДРЕНИЯ ПРОЕКТНОГО РЕШЕНИЯ

Блестящим планам везет на проектировщиков.
Скверным планам везет на исполнителей.
Веслав Брудзинский.

На этом этапе процесс вновь начинает крутиться вокруг руководителя проекта. Снова оценка трудоемкости, определение сроков, согласование объемов, утверждение порядка исполнения и т.п.

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

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

V РАЗРАБОТКА ПЛАНА-ГРАФИКА ПРОЕКТНЫХ РАБОТ

Чтобы выполнить большой и важный труд, необходимы две вещи:
ясный план и ограниченное время.
Элберт Хаббард

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

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

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

Первое, что руководитель проекта должен включить в план — это свои собственные работы. С протяженностью этой трассы на диаграмме Ганта вряд ли может конкурировать еще какая-то линия. Под ней располагаются, прерывающиеся в некоторых местах, колеи сотрудников проектно-аналитического цеха.

Производство информационных систем. Часть 2. Формирование проектного решения - 1
Читать полностью »

I ВСТУПЛЕНИЕ

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

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

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

7 команд и ни одного менеджера – думаете, такое возможно? Мы построили процесс, в котором показываем на каждом демо по 1-2 фичи от команды, проводим ретро команд, ретро релизов и при этом получаем реальное удовольствие от работы. Хотите организовать свою работу так же? Тогда добро пожаловать под кат.

Команда разработчиков Renga: как мы достигли идиллии, работая без менеджеров - 1

Мы, компания Renga Software, занимаемся разработкой программных продуктов для проектирования зданий и сооружений в соответствии с технологией информационного моделирования (BIM). Идем спринтами, выпускаем релизы каждые 3-4 месяца. Пользователей системы с каждой неделей становится всё больше. Продукт совсем молодой, поэтому бэклог переполнен важными, а главное, интересными задачами. Но как в короткие сроки разработать продукт, который будет использоваться для проектирования жилых домов, детских садов, больниц и театров?
Читать полностью »