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

Почему мы не стали делать идеально: как менялась инфраструктура серверов War Robots - 1

Первый прототип (например, игры в новой для вас нише) часто делается «на коленке» из палок и самизнаетечего. Причем палки, как правило, тоже из этого самизнаетечего. И на то есть несколько причин.

Во-первых, от неудачной идеи будет не так жалко отказаться. А во-вторых, в погоне за перфекционизмом можно забыть о потребностях конечных пользователей или никогда не закончить работу даже над альфа-версией. Но что, если в вашу «глиняную» повозку стало набираться так много людей, что перестраивать её на ходу уже не кажется такой привлекательной идеей? Примерно это с нами и случилось.

Забегу вперед и расскажу, что сейчас DAU в наших проектах около 1,5 млн. Но так было не всегда.Читать полностью »

Disclaimer: Вопрос из заголовка был задан на сайте Quora

и сопровождался ссылкой на твит разработчика Homebrew. Ответил, неожиданно, главный персонаж.

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

image

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

Но что, если вы не хотите признавать, что функцию или проект нужно менять или даже отказаться от них полностью?

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

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

Экономисты называют это ошибкой невозвратных затрат или ошибкой «Конкорда» (в память о разработке сверхзвукового пассажирского самолёта «Конкорд»). Это иррациональное усиление, при котором человеку кажется, что он вложил очень много денег/времени/энергии в работу и её прекращение окажется пустой тратой ресурсов. Однако в реальности решение продолжать не должно быть никак связано с предыдущими тратами; самое важное — это понять, оправдают ли себя дополнительные усилия.
Читать полностью »

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

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

Сегодня есть люди, которые заявляют что-то вроде «мы используем Docker для настройки окружения, так что включить нового человека в проект занимает меньше часа».

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

Автор статьи — Патрик "tyil" Спек

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

Перечислим платформы с поддержкой повторяющихся пожертвований. Это самый удобный способ обеспечить стабильный доход.
Читать полностью »

Devops в кровавом энтерпрайзе - 1
Вот к такому можно стремиться

У нас больше 350 своих разработчиков ПО и тестировщиков по всей стране, плюс мы часто взаимодействуем с инженерами и разработчиками заказчиков. Чтобы перейти на практическое использование devops, нам нужно было обеспечить не только внедрение методологии, но и приучить любимых российских заказчиков к некоторой базовой культуре. Просто пара диалогов для понимания:

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

Или:

— Почему не запускается по всей стране?
— Потому что у вас несколько десятков разных региональных инсталляций, каждая делалась руками, и на каждой разные конфиги. И ещё в паре случаев инженер ошибся.
— Поправите до завтра? Очень нужно! Только доступ удалённо мы вам не дадим.
— ..! Конечно, у нас есть команда высокооплачиваемых спецов, обожающих ездить на Дальний Восток. Нет проблем.

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

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

Как сделать внутренний продукт внешним. Опыт команды Яндекс.Трекера - 1

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

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

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

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

От 15 и больше: как обеспечить масштабируемость CI - 1

Сейчас публикуется много статей и докладов про конкретные технологии в DevOps: Docker, Kubernetes, Ansible… Я же хочу поговорить про построение процессов и про то, как мы в Wrike за два с половиной года эволюционировали от релизной системы для 15 фронтенд-разработчиков до почти 60-ти, и 2-3 деплоев в день.

Эта статья — про те уроки, которые мы на этом пути решили. Статья основана на моем докладе для DevOps митапа в Wrike Tech Club. Если некогда читать, есть видеозапись презентации. Читатели, добро пожаловать под кат.
Читать полностью »

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

Почему Agile не работает и что с этим делать - 1Читать полностью »

Почему я не веду разработку ПО в Trello? - 1

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