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

в 7:07, , рубрики: Leroy Merlin, Блог компании Леруа Мерлен, легаси, процесс, разработка, разработчики, розница, сервис, управление проектами, управление разработкой

Как мы развивали ИТ в «Леруа Мерлен»: пересборка двигателя на ходу - 1

Четыре года назад база клиентов велась отдельно в каждом магазине плюс ещё одна — на сайте.

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

Самый простой юзеркейс: сделать заказ через сайт и забрать его в реальном магазине «Леруа Мерлен» в России. Раньше заказы интернет-магазина обрабатывались в другом приложении вообще и по другой схеме. Теперь нам нужна была омниканальная витрина, чтобы любой заказ был разбит на интерфейс: касса в магазине, мобильное приложение, терминал в магазине, сайт — что угодно. Если вы поставите Linux на микроволновку — пускай будет микроволновка. Главное, чтобы какие-то интерфейсы могли стучать по API к беку и говорить, что вот тут надо оформить такой-то заказ. И получали на это внятный ответ. Вторая история была с запросами наличия и свойств товара из его карточки.

На фронте (скоро и про это напишем) у нас монстр — AEM, а за ним в беке было два больших приложения: OPUS и MoVe. Первое — это база данных свойств каждого товара (от габаритов до описания), второе — отвечает за чекаут, то есть монолит касс. Если сильно упростить.Читать полностью »

в 6:14, , рубрики: api, bot, C#, Dodo Pizza Engineering, dodois, dodopizza, release, Блог компании Dodo Pizza Engineering, управление разработкой

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

Консервативный распорядок и метод работы, рабское следование заведённому шаблону, превратившееся в механическую привычку. 6 букв.

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

в 7:02, , рубрики: CD Projekt RED, Cyberpunk 2077, rpg, witcher 3, Дизайн игр, дизайн квестов, Игры и игровые приставки, разработка игр, ролевые игры, управление разработкой
image

The Witcher 3 известен своим превосходным дизайном квестов, но разработчик игры CD Projekt Red обещает в своём новом проекте Cyberpunk 2077 развить и улучшить проверенный подход.

На E3 2019 директор отдела квестов Матеуш Томашкевич рассказал нам, чему он научился, управляя разработкой квестов Cyberpunk 2077, и поведал, какие трудности возникают при создании дизайна более нелинейной RPG.

Что изменилось в вашей жизни как директора отдела квестов с момента объявления о работе над Cyberpunk 2077?

Изменилось многое, я пришёл с проекта Thronebreaker: The Witcher Tales, и должен был догонять команду, разбираясь во всём, что у нас есть: прикидки, цели и так далее. Для меня этот проект особенный, по сравнению например, с The Witcher 3, тем, что мы больше не стремимся просто сочетать богатый ветвящийся нарратив с открытым миром — на этот раз мы добавим новый слой нелинейности — геймплейную нелинейность.

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

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

в 9:21, , рубрики: Блог компании Mail.Ru Group, никто не читает теги, Программирование, разработка, Совершенный код, управление разработкой
image

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

в 7:46, , рубрики: Блог компании Maxilect, вопросы на собеседовании, Карьера в IT-индустрии, распределённые коллективы, распределенные команды, собеседование, удаленное собеседование, удаленные работники, удаленные сотрудники, управление персоналом, управление проектами, управление разработкой

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

image

Спойлер: увы, но “правильных ответов” на эти вопросы здесь нет. Их попросту не существует.
Читать полностью »

в 9:00, , рубрики: teamleadconf, Блог компании Конференции Олега Бунина (Онтико), менеджмент, управление людьми, управление персоналом, управление проектами, управление проектами и командой, управление разработкой

Знакомьтесь, это Дима. Он тимлид и отвечает за техдолг и код-ревью, за планирование и технические процессы, за выполнение разработчиками задач в срок — мотивирует, нанимает и, если надо, увольняет. Дима хочет работать только над важными задачами, но работает над миллионом самых разных, постоянно думает о работе и не высыпается. У него все горит: сроки, задачи, время и самооценка. Дима в аду.

Мотивация, делегирование и автоматизация: рецепт создания суперкоманды - 1

Знакомая ситуация? Для Алексея Катаева (deusdeorum) — точно. Алексей больше 15 лет занимается веб-разработкой как backend, frontend, fullstack-разработчик и тимлид. Сейчас Алексей работает в Skyeng и как-то раз ему удалось сделать из команды суперкоманду — лучшую в компании. И с тех пор Алексей занимается тем, что создает в Skyeng суперкоманды на постоянной основе. Как он это делает, в расшифровке доклада, который участники TeamLead Conf 2019 назвали лучшим на конференции.

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

в 7:03, , рубрики: архитектура, Блог компании Туту.ру, легаси, монолит, проект, разработка, сервис, управление проектами, управление разработкой

Вечный вопрос технического долга - 1
Это одно из самых крутых облегчений проекта. На картинке — график суммарного времени, затрачиваемого CPU на обработку всех пользовательских запросов. В конце видно переход на PHP 7.0. с версии 5.6. Это 2016 год, переключение во второй половине дня с 24 ноября.

Туту.ру с точки зрения вычислений — это в первую очередь возможность купить билет из точки А в точку Б. Для этого мы перемалываем огромное количество расписаний, собираем в кэш ответы множества систем авиакомпаний и периодически делаем невероятно длинные join-запросы к базе данных. В целом мы написаны на PHP и до недавних пор были полностью на нём (если язык правильно готовить, то можно даже строить на нём системы реального времени). С недавнего времени критичные по производительности участки стали рефакториться на Go.

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

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

в 14:37, , рубрики: agile, scrum, Управление продуктом, управление проектами, управление разработкой

SCRUM? Какой SCRUM?

Впервые подход SCRUM (англ. scrum «схватка вокруг мяча») описали Хиротака Такэути и Икудзиро Нонака, которые заметили, что небольшие команды (5 — 9 человек), укомплектованные разнопрофильными специалистами, дают лучшие результаты. Наиболее полное описание SCRUM впервые представил в своей книге Джефф Сазерланд. Книга так и называется — SCRUM. Джефф начинал свою карьеру как военный летчик, во время войны во Вьетнаме выполнивший более ста боевых вылетов. Затем Джефф занимался наукой, но мир его запомнит как одного из родоначальников SCRUM. Книга начинается с реальной истории из жизни ФБР, тратившего миллионы долларов на разработку автоматизированной системы, предназначенной для поиска и отслеживания преступников. Проблема заключалась в том, что по истечении сроков проекта подрядчики демонстрировали ФБР абсолютно нерабочий продукт. Это означало лишь одно — американские налогоплательщики потратили миллионы впустую. Ситуация казалась безвыходной до тех пор, пока руководство ФБР не обратилось к тогда еще зарождавшемуся методу управления проектами SCRUM. Этот метод описан доступным языком в вышеупомянутой книге, которая, кстати, переведена на русский язык. Далее в статье рассмотрены основные заблуждения и мифы, которые могут отпугнуть топ менеджеров, задумавших внедрить SCRUM в свои проекты.

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

в 12:15, , рубрики: Dodo Pizza Engineering, dodois, Блог компании Dodo Pizza Engineering, управление людьми и проектами, управление проектами, управление разработкой

У каждого тимлида есть своё кладбище сотрудников управленческих ошибок. Каждый день публикуются новые статьи «5 ошибок начинающего разработчика», «7 примеров того, как не надо управлять процессами», «100 и 1 способ укладываться в сроки». И это круто!

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

5 ошибок начинающего лида - 1

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

в 9:39, , рубрики: Блог компании FunCorp, качество, качество кода, код, мартин фаулер, Программирование, процессы, разработка, Совершенный код, Управление продуктом, управление разработкой
Стоит ли высокое качество ПО затрат на его разработку? - 1

Часто в процессе реализации проектов команды сталкиваются с вопросом: чему следует уделять больше внимания – выпуску новых фич или повышению качества кода? Обычно менеджеры делают выбор в пользу фич. Зачастую разработчики таким положением дел недовольны, считая, что им выделяется недостаточно времени для работы над архитектурой и качеством кода.

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

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

1...1020...424344...5060...124
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js