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

Все побежали, и я побежал. Недавно я запустил серию онлайн-митапов, куда приглашаю на дискуссию экспертов в области разработки крупных IT-проектов. Нашим первым гостем был Максим Барышников, Head of Platform из Wargaming. Ниже – расшифровка нашего разговора, вернее, её первая часть, посвященная архитектуре.

Из этой части вы узнаете, например:

  • сколько людей работает в Wargaming и сколько строк кода в «Танках»
  • как, какие и куда едут байты во время боя в «Танках»
  • какие подходы используют в Wargaming для обеспечения масштабируемости и отказоустойчивости
  • какие архитектурные боли испытывают и на какие компромиссы между геймплеем и инженерными практиками идут
  • почему в Python приходится отключать garbage collector, и где используется Erlang
  • какие у Wargaming open source policies, и что они открывают в паблик

Разговор получился достаточно длинным, но подробным, если вам интересна тема разработки больших игровых проектов — прошу под кат.

image

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

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

Методика развёртывания проектов, применяемая в Slack - 1

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

Обеспечить удалёнку и не облажаться. Советы ИТ-директору - 1

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

Еще одна проблема — как обеспечить работу всего набора корпоративных приложений из дома на разношерстном парке оборудования: от старенького ПК на Windows 7 до iPad’а.

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

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

МТС, как и многие другие современные компании, подверглась так называемой цифровой трансформации. Говоря простым языком, нашим приоритетом стал запуск цифровых процессов и продуктов.

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

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

Checklist для архитектора - 1
Читать полностью »

В последнее время возникает много обсуждений вынужденного удаленного режима работы для компаний. Один из наиболее интересных на мой взгляд вопросов: “Продолжат ли компании придерживаться удаленного режима или нет, когда вынужденный режим закончится?”.
Читать полностью »

В офисе никого: разработка игр на удаленке - 1

Дисклеймер. У нас нет «удаленных» сотрудников — в команде все равноудалены друг от друга. Просто кто-то работает (сейчас правильнее сказать «работал») в офисе, а кто-то дома или в коворкинге. Поэтому внутри мы предпочитаем термин «распределенная команда».

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

У нас много команд занимающихся разработкой продуктов — есть и по 10 человек, и по 40-50 — но нет ни одной, где все ребята сидели бы рядом в офисе. Зато есть команды, которые полностью работают из дома. Из-за последних событий на «домашний режим» перешли вообще все, но пандемия практически не повлияла на процессы, потому что всё было выстроено заранее.

Дальше — несколько больших разделов о внутренней кухне: онбординг, коммуникации и работа с командой, обмен опытом. А для разнообразия разбавим текст фотографиями наших «домашних офисов». Читать полностью »

SCRUM: поэма о любви и боли - 1

Если он так хорош, то почему все не работают только по этой методологии? А те, кто якобы внедрил, часто демонстрирует чудовищный ScrumBut. Настоящий SCRUM оставляет на вашем сердце шрамы, раны и отметины, и сейчас я расскажу о своих.
Читать полностью »

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

image

(Григорий Остер)

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

На вопросы отвечал Павел Зыков, СТО DomClick.ru

ДомКлику скоро 5 лет. Давайте немного вспомним историю и заодно познакомимся. Компания была основана в 2015 году. Ты помнишь день, с которого все начиналось?

Еще как помню. Я входил в число основателей, поэтому помню все в мельчайших деталях – как собеседовали первых людей, как в августе 2015 года сняли первый офис на улице Рабочая, который устраивал нас по цене, несмотря на то, что подоконники кабинетов всегда были в пыли от проходящих рядом поездов. Сейчас, сидя в максимально комфортном Agile Home в 2 минутах от ст. метро Кутузовская, с теплотой вспоминаем о тех временах, когда два интернет — провайдера в здании считалось нашим уникальным преимуществом.

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

На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).

Ее основными тезисами были:

  • GitFlow противоречит тезису "ветки должны быть короткоживущими".
    Это важно, потому что чем меньше живет ветка — тем меньше шанс конфликтов (не только git, но и логических)
  • GitFlow препятствует rebase-ам, чтобы сохранить merge-коммиты.
    Да, их можно сохранять и при ребейзах, но команды Git Flow не делают этого.
  • GitFlow отрицает подход Contunious Delivery, считая, что каждый акт Delivery должен совершаться релиз-инженером, да и в целом можно увидеть, что он ориентирован только на долгий релизный цикл.
  • GitFlow не дружит с микросервисами поверх мультирепозиториев (впрочем, тут вообще мало что подходит, это идея, которая всегда плохо заканчивается)
  • Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.

    Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.

Так что делать-то?

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


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